From prakash at punnoor.de Sat Dec 1 03:01:50 2007 From: prakash at punnoor.de (Prakash Punnoor) Date: Sat, 1 Dec 2007 09:01:50 +0100 Subject: [Mono-dev] InterOp problems with 1.2.6pre2 In-Reply-To: References: <200711241924.12579.prakash@punnoor.de> <200711302210.51474.prakash@punnoor.de> Message-ID: <200712010901.53827.prakash@punnoor.de> On the day of Friday 30 November 2007 Andreas F?rber hast written: > Am 30.11.2007 um 22:10 schrieb Prakash Punnoor: > > On the day of Friday 30 November 2007 Robert Jordan hast written: > >> The layouts don't match, since declaring a field "private" won't > >> magically subtract it from struct layout. > > > > It would help if you'd look at the svn version as I wrote in my > > mail. Reading > > helps, really.... > > Careful there: You are writing to the development list of Mono and you > seem to want help for a problem you are encountering with some third > party library. So first of all, this is actually off-topic for this > list in two aspects. To get help non-the-less, file a proper bug > report with a self-contained test case, best place would be in > Novell's Bugzilla with a link here. Pointing people to some SVN code > they have to checkout and configure etc. is definitely not a self- > contained test-case. And when you do provide code then it's your > responsibility to make sure it's the correct code you're talking of, > not Robert's. > > See: http://www.mono-project.com/Bugs My time is limited. I could also simply ignore the bugs I encounter and try to find work-arounds. It is not my duty to give you test-cases. You the mono devs should see it as a courtesy that I report anything. It wouldn't take too much time to simply reproduce it and with the knowledge mono devs have they could pinpoint it faster then I have done it by wildly guessing. And in fact my report was pretty concise. I wrote down everything you need to know to reproduce that bug. I don't need your help. I report a bug in mono, so I help you to make your product better! I compare it with Linux kernel mailing list: There the devs respect the users and at least react to mails. The least I expected was a reaction and perhaps a hint what the posted error means so I could perhaps provide a small testcase within 5 minutes. In another post, I tried to contibute a small optimizing patch for UInt32.Parse. Did I get any reaction whatsoever? Did I? So moral of the story: I won't waste my time anymore on the mono mailing list. If you want people contributing - be it with code or bug reports - no matter whether the way of postig fits your taste or not - learn to respect that the contributers actually sacrifices some time for mono. Good luck! -- (?= =?) //\ Prakash Punnoor /\\ V_/ \_V -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071201/fa892f5c/attachment.bin From alan.mcgovern at gmail.com Sat Dec 1 08:12:33 2007 From: alan.mcgovern at gmail.com (Alan McGovern) Date: Sat, 1 Dec 2007 13:12:33 +0000 Subject: [Mono-dev] InterOp problems with 1.2.6pre2 In-Reply-To: <200712010901.53827.prakash@punnoor.de> References: <200711241924.12579.prakash@punnoor.de> <200711302210.51474.prakash@punnoor.de> <200712010901.53827.prakash@punnoor.de> Message-ID: <117799f00712010512w2b16a5f2gf2362d9b6b255793@mail.gmail.com> If you find a bug that affects you that you need fixed, it's up to you to show that there is a bug. If you paste code in an email, of course people are going to look at it. If that code is wrong, well, that's not our fault. You shouldn't paste code which supposedly shows an issue when in fact that code has nothing to do with the actual issue because the code is incorrect. Of course no-one would bother looking at SVN because they'd think they already found the bug. Your time may be limited, but suppose *everyone* who reported a bug expected the mono team to go download sources, compile sources, get god knows how many dependencies so the sources will actually compile, then try and track down a bug in that code. That'd take forever and nothing would get accomplished. http://www.mono-project.com/Bugs#How_to_make_a_good_bug_report If you want something done and want it fast, make it easy for the bug fixers. Alan. On Dec 1, 2007 8:01 AM, Prakash Punnoor wrote: > On the day of Friday 30 November 2007 Andreas F?rber hast written: > > Am 30.11.2007 um 22:10 schrieb Prakash Punnoor: > > > On the day of Friday 30 November 2007 Robert Jordan hast written: > > >> The layouts don't match, since declaring a field "private" won't > > >> magically subtract it from struct layout. > > > > > > It would help if you'd look at the svn version as I wrote in my > > > mail. Reading > > > helps, really.... > > > > Careful there: You are writing to the development list of Mono and you > > seem to want help for a problem you are encountering with some third > > party library. So first of all, this is actually off-topic for this > > list in two aspects. To get help non-the-less, file a proper bug > > report with a self-contained test case, best place would be in > > Novell's Bugzilla with a link here. Pointing people to some SVN code > > they have to checkout and configure etc. is definitely not a self- > > contained test-case. And when you do provide code then it's your > > responsibility to make sure it's the correct code you're talking of, > > not Robert's. > > > > See: http://www.mono-project.com/Bugs > > My time is limited. I could also simply ignore the bugs I encounter and > try to > find work-arounds. It is not my duty to give you test-cases. You the mono > devs should see it as a courtesy that I report anything. It wouldn't take > too > much time to simply reproduce it and with the knowledge mono devs have > they > could pinpoint it faster then I have done it by wildly guessing. And in > fact > my report was pretty concise. I wrote down everything you need to know to > reproduce that bug. > > I don't need your help. I report a bug in mono, so I help you to make your > product better! > > I compare it with Linux kernel mailing list: There the devs respect the > users > and at least react to mails. The least I expected was a reaction and > perhaps > a hint what the posted error means so I could perhaps provide a small > testcase within 5 minutes. > > In another post, I tried to contibute a small optimizing patch for > UInt32.Parse. Did I get any reaction whatsoever? Did I? > > So moral of the story: I won't waste my time anymore on the mono mailing > list. > If you want people contributing - be it with code or bug reports - no > matter > whether the way of postig fits your taste or not - learn to respect that > the > contributers actually sacrifices some time for mono. > > Good luck! > -- > (?= =?) > //\ Prakash Punnoor /\\ > V_/ \_V > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071201/5b9d79e7/attachment.html From robertj at gmx.net Sat Dec 1 08:35:24 2007 From: robertj at gmx.net (Robert Jordan) Date: Sat, 01 Dec 2007 14:35:24 +0100 Subject: [Mono-dev] String.GetHashCode() In-Reply-To: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> Message-ID: Alan McGovern wrote: > A thought struck me while i was dozing on the plane on the way home from the > summit. > > Since strings are immutable, shouldn't it be possible to compute the > hashcode once and store it rather than recomputing it over and over again? > Is there some really obvious reason that i can't think of that would make > this a bad idea? This idea already came up a couple of years ago (2002 or so). If memory serves (I was not able find the thread in the archives), the drawback was the additional "gint32" that every MonoString* will get, regardless how small it is. Someone (Paolo?) pointed out that adding this field will increase the average string size by some unacceptable amount. Therefore, the optimization should consider the string length and append the hash code after the string's bytes only if its length is greater than some amount (1K or so). Robert From mail at tinco.nl Sat Dec 1 10:16:41 2007 From: mail at tinco.nl (Tinco Andringa) Date: Sat, 1 Dec 2007 16:16:41 +0100 Subject: [Mono-dev] String.GetHashCode() In-Reply-To: <711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> <711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> Message-ID: (Woops, only replied to kamil) If Jerome is right and the overhead is only 4 bytes, then overhead shouldn't be a problem at all. The worst case size of a string would be 1 character, of 2 bytes + something to end it with, like an int containing its length, 2 bytes, or a terminating character, probably 2 bytes too. Making it at least 4 bytes. A worst case scenario of 100% extra data, that isn't so bad right? It's way less than the overhead of using unicode, since you almost never use the enormous range of character 2-3 bytes offers you. Speaking of unicode/utf-16 and memory, couldn't a lot of memory be spared if strings where stored as utf8 internally, which would be converted back to utf-16 when more than 256 different characters would be used? All you would need is a small translation table, and the view instructions it takes to look a char up in it. Or is this already being done? Just curious. Tinco > Date: Fri, 30 Nov 2007 19:10:07 -0800> From: kamil.skalski at gmail.com> To: alan.mcgovern at gmail.com> CC: mono-devel-list at lists.ximian.com> Subject: Re: [Mono-dev] String.GetHashCode()> > Extra memory cost, which would hit all allocated strings, also those> short ones. For some applications, which use millions of small strings> this would be unacceptable hit.> > 2007/11/30, Alan McGovern :> > A thought struck me while i was dozing on the plane on the way home from the> > summit.> >> > Since strings are immutable, shouldn't it be possible to compute the> > hashcode once and store it rather than recomputing it over and over again?> > Is there some really obvious reason that i can't think of that would make> > this a bad idea?> >> > Alan.> >> > _______________________________________________> > Mono-devel-list mailing list> > Mono-devel-list at lists.ximian.com> > http://lists.ximian.com/mailman/listinfo/mono-devel-list> >> >> > > -- > Kamil Skalski> http://nazgul.omega.pl> _______________________________________________> Mono-devel-list mailing list> Mono-devel-list at lists.ximian.com> http://lists.ximian.com/mailman/listinfo/mono-devel-list Express yourself instantly with MSN Messenger! MSN Messenger _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071201/8d5de359/attachment.html From robertj at gmx.net Sat Dec 1 11:09:00 2007 From: robertj at gmx.net (Robert Jordan) Date: Sat, 01 Dec 2007 17:09:00 +0100 Subject: [Mono-dev] String.GetHashCode() In-Reply-To: References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> <711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> Message-ID: Tinco Andringa wrote: > (Woops, only replied to kamil) > > If Jerome is right and the overhead is only 4 bytes, then overhead > shouldn't be a problem at all. The worst case size of a string would > be 1 character, of 2 bytes + something to end it with, like an int > containing its length, 2 bytes, or a terminating character, probably > 2 bytes too. Making it at least 4 bytes. A worst case scenario of Look at a heavy string consumer: [g]mcs. The average string length it has to process is probably only 4-5 chars long. That's roundabout 12 bytes. Adding 4 bytes for the hash code is a huge overhead that only pays out if GetHashCode is called frequently, but this is definitely not a common scenario for most of the strings. Robert From alan.mcgovern at gmail.com Sat Dec 1 11:21:52 2007 From: alan.mcgovern at gmail.com (Alan McGovern) Date: Sat, 1 Dec 2007 16:21:52 +0000 Subject: [Mono-dev] String.GetHashCode() In-Reply-To: References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> <711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> Message-ID: <117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> Also, just looking at the string source a bit more closely, it has a GetCaseInsensitiveHashcode method too, so i'd assume that would need to be cached too which would mean 8 bytes would be needed. This wouldn't scale well. Fair enough. Twas just an idea. Alan. On Dec 1, 2007 4:09 PM, Robert Jordan wrote: > Tinco Andringa wrote: > > (Woops, only replied to kamil) > > > > If Jerome is right and the overhead is only 4 bytes, then overhead > > shouldn't be a problem at all. The worst case size of a string would > > be 1 character, of 2 bytes + something to end it with, like an int > > containing its length, 2 bytes, or a terminating character, probably > > 2 bytes too. Making it at least 4 bytes. A worst case scenario of > > Look at a heavy string consumer: [g]mcs. The average string > length it has to process is probably only 4-5 chars long. > That's roundabout 12 bytes. Adding 4 bytes for the hash code > is a huge overhead that only pays out if GetHashCode is > called frequently, but this is definitely not a common scenario > for most of the strings. > > Robert > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071201/c0222236/attachment.html From laurentlb at gmail.com Sat Dec 1 11:32:55 2007 From: laurentlb at gmail.com (Laurent Le Brun) Date: Sat, 1 Dec 2007 17:32:55 +0100 Subject: [Mono-dev] How to create a dynamic library for Linux? Message-ID: <1bb08f400712010832u42f5e2a8j961c213ac4d21ae9@mail.gmail.com> Hi, I'd like to create a dynamic library (for Linux), from a .NET source file. I've searched in the web for this, but didn't find anything. I hope this is the right list for this question. So, I'd like to get a .so library, that I can call from C/C++ code. I compiled my .NET files into a .dll file. Then, I compiled it to native code (using mono --aot). But, the generated .so file doesn't export my library functions (I checked using nm). I've seen symbols like "method_info" or "class_info". Could they be useful for my need? Is it possible to do this? Any advice or link is welcome. Please note the main application is written in C++, but I don't want to run it with mono. Thanks. PS : my functions only use and return ints. I guess there won't be any problem with types. -- Laurent From robertj at gmx.net Sat Dec 1 11:55:39 2007 From: robertj at gmx.net (Robert Jordan) Date: Sat, 01 Dec 2007 17:55:39 +0100 Subject: [Mono-dev] How to create a dynamic library for Linux? In-Reply-To: <1bb08f400712010832u42f5e2a8j961c213ac4d21ae9@mail.gmail.com> References: <1bb08f400712010832u42f5e2a8j961c213ac4d21ae9@mail.gmail.com> Message-ID: Laurent Le Brun wrote: > Hi, > > I'd like to create a dynamic library (for Linux), from a .NET source > file. I've searched in the web for this, but didn't find anything. I > hope this is the right list for this question. There is a reason for the lack of informations about using a .NET assembly as a SO: there is no way to do it. > So, I'd like to get a .so library, that I can call from C/C++ code. > I compiled my .NET files into a .dll file. Then, I compiled it to > native code (using mono --aot). But, the generated .so file doesn't > export my library functions (I checked using nm). I've seen symbols > like "method_info" or "class_info". Could they be useful for my need? No. > > Is it possible to do this? Any advice or link is welcome. > Please note the main application is written in C++, but I don't want > to run it with mono. You have 3 choices: 1. Embed the mono runtime. See http://www.mono-project.com/Embedding_Mono 2. mkbundle/mkbundle2 with the --nomain option and manual compilation & linking. See "man mkbundle". 3. Convert your C++ application to a SO and DllImport it from a managed (C#) main application stub. In the stub you can expose the methods using delegates that you pass to the SO via DllImports. Robert From robertj at gmx.net Sat Dec 1 12:29:50 2007 From: robertj at gmx.net (Robert Jordan) Date: Sat, 01 Dec 2007 18:29:50 +0100 Subject: [Mono-dev] String.GetHashCode() In-Reply-To: <117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> <711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> <117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> Message-ID: Hi Alan, Alan McGovern wrote: > Also, just looking at the string source a bit more closely, it has a > GetCaseInsensitiveHashcode method too, so i'd assume that would need to be > cached too which would mean 8 bytes would be needed. This wouldn't scale > well. > > Fair enough. Twas just an idea. nah, don't give up too early! :) If the string is longer than "n", you could allocate 4 or even 8 additional bytes at the end of the array for lazily computed hash codes. Open questions: - What's the optimal "n" for all common application classes mono is used for? :) It looks like it should be dynamically computed & adjusted based on profiling data collected at runtime. - What's the real gain of this optimization? If "n" tends to be really large (say 1-4KB), what's the probability of such large strings being used as a hash key? This question can be reduced to "how frequently is s.GetHashCode called, where s.Length > n". In mono's class libs sources there is only one place (I know of) where large strings are potentially hashed: Sys.Web's cache management. Robert From alan.mcgovern at gmail.com Sat Dec 1 13:01:02 2007 From: alan.mcgovern at gmail.com (Alan McGovern) Date: Sat, 1 Dec 2007 18:01:02 +0000 Subject: [Mono-dev] String.GetHashCode() In-Reply-To: References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> <711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> <117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> Message-ID: <117799f00712011001u1a04169cq74c95c2cd351b028@mail.gmail.com> Well, 'N' could be computed by asking what percent bloat is 'OK' or it could be computed by asking 'What % speedup do we want to make this a worthwhile tradeoff'. Currently a string has these two fields, an int and a char. Add in the object overhead of (i think) 12 bytes per object, you're up to 18 bytes straight off for a zero length string. Lets assume that you're only going to precalculate the hashcode for strings greater than length 4. So, take the case of a string of length 5. This puts the size of the string at 18 + 5*2 = 28 bytes. Adding 4 bytes to this is 15% extra memory usage. As string length goes up, this % goes down. I'm unsure what % speedup precalculating the hashcode would result in, but i'm sure someone could run a few benchmarks if they have the time free. You could say that you want at least a 5x or maybe 10x improvement before it becomes worthwhile, this would then put a lower bound on the string length to make it worthwhile. Alan. On Dec 1, 2007 5:29 PM, Robert Jordan wrote: > Hi Alan, > > Alan McGovern wrote: > > Also, just looking at the string source a bit more closely, it has a > > GetCaseInsensitiveHashcode method too, so i'd assume that would need to > be > > cached too which would mean 8 bytes would be needed. This wouldn't scale > > well. > > > > Fair enough. Twas just an idea. > > nah, don't give up too early! :) If the string is longer than "n", > you could allocate 4 or even 8 additional bytes at the end of the > array for lazily computed hash codes. > > Open questions: > > - What's the optimal "n" for all common application classes > mono is used for? :) It looks like it should be dynamically > computed & adjusted based on profiling data collected at > runtime. > > - What's the real gain of this optimization? If "n" tends to > be really large (say 1-4KB), what's the probability of > such large strings being used as a hash key? > This question can be reduced to "how frequently is > s.GetHashCode called, where s.Length > n". > > In mono's class libs sources there is only one place (I know > of) where large strings are potentially hashed: Sys.Web's > cache management. > > Robert > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071201/80c2247b/attachment.html From alan.mcgovern at gmail.com Sat Dec 1 13:02:40 2007 From: alan.mcgovern at gmail.com (Alan McGovern) Date: Sat, 1 Dec 2007 18:02:40 +0000 Subject: [Mono-dev] String.GetHashCode() In-Reply-To: <117799f00712011001u1a04169cq74c95c2cd351b028@mail.gmail.com> References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> <711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> <117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> <117799f00712011001u1a04169cq74c95c2cd351b028@mail.gmail.com> Message-ID: <117799f00712011002qc94b7c5xd72eb49b999cd3e8@mail.gmail.com> Also, worst case scenario for a zero length string would mean a 22% increase, not a 100% increase as was said before. Alan. On Dec 1, 2007 6:01 PM, Alan McGovern wrote: > Well, 'N' could be computed by asking what percent bloat is 'OK' or it > could be computed by asking 'What % speedup do we want to make this a > worthwhile tradeoff'. > > Currently a string has these two fields, an int and a char. Add in the > object overhead of (i think) 12 bytes per object, you're up to 18 bytes > straight off for a zero length string. Lets assume that you're only going to > precalculate the hashcode for strings greater than length 4. > > So, take the case of a string of length 5. This puts the size of the > string at 18 + 5*2 = 28 bytes. Adding 4 bytes to this is 15% extra memory > usage. As string length goes up, this % goes down. > > I'm unsure what % speedup precalculating the hashcode would result in, but > i'm sure someone could run a few benchmarks if they have the time free. You > could say that you want at least a 5x or maybe 10x improvement before it > becomes worthwhile, this would then put a lower bound on the string length > to make it worthwhile. > > Alan. > > > On Dec 1, 2007 5:29 PM, Robert Jordan wrote: > > > Hi Alan, > > > > Alan McGovern wrote: > > > Also, just looking at the string source a bit more closely, it has a > > > GetCaseInsensitiveHashcode method too, so i'd assume that would need > > to be > > > cached too which would mean 8 bytes would be needed. This wouldn't > > scale > > > well. > > > > > > Fair enough. Twas just an idea. > > > > nah, don't give up too early! :) If the string is longer than "n", > > you could allocate 4 or even 8 additional bytes at the end of the > > array for lazily computed hash codes. > > > > Open questions: > > > > - What's the optimal "n" for all common application classes > > mono is used for? :) It looks like it should be dynamically > > computed & adjusted based on profiling data collected at > > runtime. > > > > - What's the real gain of this optimization? If "n" tends to > > be really large (say 1-4KB), what's the probability of > > such large strings being used as a hash key? > > This question can be reduced to "how frequently is > > s.GetHashCode called, where s.Length > n". > > > > In mono's class libs sources there is only one place (I know > > of) where large strings are potentially hashed: Sys.Web's > > cache management. > > > > Robert > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071201/0cb71eda/attachment.html From steveb at mindtouch.com Sat Dec 1 13:16:23 2007 From: steveb at mindtouch.com (Steve Bjorg) Date: Sat, 1 Dec 2007 10:16:23 -0800 Subject: [Mono-dev] String.GetHashCode() In-Reply-To: <117799f00712011002qc94b7c5xd72eb49b999cd3e8@mail.gmail.com> References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> <711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> <117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> <117799f00712011001u1a04169cq74c95c2cd351b028@mail.gmail.com> <117799f00712011002qc94b7c5xd72eb49b999cd3e8@mail.gmail.com> Message-ID: <45F27AE9-3CD0-4D93-8FAB-85652EB800D8@mindtouch.com> It doesn't make much sense to pre-compute the hashcode for a string whose length is not greater than the cacheline size. Anything that fits into the cacheline and is not memory bound is plenty fast enough. For the same reason, the size and hashcode of a string would need to be juxtaposed in memory to load both on first hit. Otherwise, the benefits are again wiped out due to the high cost of loading data from memory into the cache. If optimization at that level isn't interesting (b/c we talking nanoseconds in this realm), then the bound for N will go up quite quickly before a cached hashcode makes sense. And as Robert so insightfully pointed out, strings for which a pre-computed hashcode might make sense may never be used as keys. Hence, the complexity increase in th string code -- and therefore quality control headache -- introduced by it might not be worth the effort. Just some assembly hacker thoughts on the subject... :) - Steve -------------- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Dec 1, 2007, at 10:02 AM, Alan McGovern wrote: > Also, worst case scenario for a zero length string would mean a 22% > increase, not a 100% increase as was said before. > > Alan. > > On Dec 1, 2007 6:01 PM, Alan McGovern < alan.mcgovern at gmail.com> > wrote: > Well, 'N' could be computed by asking what percent bloat is 'OK' or > it could be computed by asking 'What % speedup do we want to make > this a worthwhile tradeoff'. > > Currently a string has these two fields, an int and a char. Add in > the object overhead of (i think) 12 bytes per object, you're up to > 18 bytes straight off for a zero length string. Lets assume that > you're only going to precalculate the hashcode for strings greater > than length 4. > > So, take the case of a string of length 5. This puts the size of > the string at 18 + 5*2 = 28 bytes. Adding 4 bytes to this is 15% > extra memory usage. As string length goes up, this % goes down. > > I'm unsure what % speedup precalculating the hashcode would result > in, but i'm sure someone could run a few benchmarks if they have > the time free. You could say that you want at least a 5x or maybe > 10x improvement before it becomes worthwhile, this would then put a > lower bound on the string length to make it worthwhile. > > Alan. > > > On Dec 1, 2007 5:29 PM, Robert Jordan wrote: > Hi Alan, > > Alan McGovern wrote: > > Also, just looking at the string source a bit more closely, it has a > > GetCaseInsensitiveHashcode method too, so i'd assume that would > need to be > > cached too which would mean 8 bytes would be needed. This > wouldn't scale > > well. > > > > Fair enough. Twas just an idea. > > nah, don't give up too early! :) If the string is longer than "n", > you could allocate 4 or even 8 additional bytes at the end of the > array for lazily computed hash codes. > > Open questions: > > - What's the optimal "n" for all common application classes > mono is used for? :) It looks like it should be dynamically > computed & adjusted based on profiling data collected at > runtime. > > - What's the real gain of this optimization? If "n" tends to > be really large (say 1-4KB), what's the probability of > such large strings being used as a hash key? > This question can be reduced to "how frequently is > s.GetHashCode called, where s.Length > n". > > In mono's class libs sources there is only one place (I know > of) where large strings are potentially hashed: Sys.Web's > cache management. > > Robert > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071201/1c181fe0/attachment.html From laurentlb at gmail.com Sat Dec 1 13:25:23 2007 From: laurentlb at gmail.com (Laurent Le Brun) Date: Sat, 1 Dec 2007 19:25:23 +0100 Subject: [Mono-dev] How to create a dynamic library for Linux? In-Reply-To: References: <1bb08f400712010832u42f5e2a8j961c213ac4d21ae9@mail.gmail.com> Message-ID: <1bb08f400712011025x29f58ab6sa44a504437f4e30@mail.gmail.com> On Dec 1, 2007 5:55 PM, Robert Jordan wrote: > You have 3 choices: > [...] Thanks for the quick answer. That was very helpful. > 1. Embed the mono runtime. See > http://www.mono-project.com/Embedding_Mono I've tried this solution. It works great. Thanks a lot. -- Laurent From meebey at meebey.net Sat Dec 1 13:31:56 2007 From: meebey at meebey.net (Mirco Bauer) Date: Sat, 01 Dec 2007 19:31:56 +0100 Subject: [Mono-dev] String.GetHashCode() In-Reply-To: <117799f00712011001u1a04169cq74c95c2cd351b028@mail.gmail.com> References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> <711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> <117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> <117799f00712011001u1a04169cq74c95c2cd351b028@mail.gmail.com> Message-ID: <1196533916.12507.3.camel@redbull.qnetp.net> On Sat, 2007-12-01 at 18:01 +0000, Alan McGovern wrote: > Well, 'N' could be computed by asking what percent bloat is 'OK' or it > could be computed by asking 'What % speedup do we want to make this a > worthwhile tradeoff'. Wouldn't be this a good case for "desktop" vs "server" runtime mode? Which Mono already supports (mono --desktop) but not really differentiates AFAIK. -- Regards, Mirco 'meebey' Bauer PGP-Key ID: 0xEEF946C8 FOSS Developer meebey at meebey.net http://www.meebey.net/ PEAR Developer meebey at php.net http://pear.php.net/ Debian Developer meebey at debian.org http://www.debian.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071201/56bb8972/attachment.bin From mono at glyps.com Sat Dec 1 14:04:40 2007 From: mono at glyps.com (mono at glyps.com) Date: Sat, 1 Dec 2007 20:04:40 +0100 (CET) Subject: [Mono-dev] FileSystemWatcher - FileSystemEventArgs - first byte of name & fullname Message-ID: <212.183.32.26.1196535880.wm@webmail.inode.at> hi ! i write a little class for fsw. under windows i received the fullname and name of the concerned file in the right length. if i copy the executables to opensuse10.2 (mono 1.2.5.1) on the vm and run the exe with "mono programmname.exe" i miss the first byte after slash if a get the FileSystemEventArgs-Event : e.g. : Windows Fullname >C:\fluffy.one< on Unix Fullname >/luffy.one< >From the RenamedEventArgs i get the correct length. thank you in advance, harald From olivier.duff at gmail.com Sat Dec 1 17:36:54 2007 From: olivier.duff at gmail.com (olivier dufour) Date: Sat, 1 Dec 2007 23:36:54 +0100 Subject: [Mono-dev] patch winform resource reader In-Reply-To: <008a01c8332d$05398620$d9071fac@cegekanv.corp.local> References: <69f7d8470711291559y2d93e01v6dc49ca324ac696c@mail.gmail.com> <008a01c8332d$05398620$d9071fac@cegekanv.corp.local> Message-ID: So, I have done a unit test (and run it on linux but not on windows) and fix some bug thanks to it ;) If someone can test it under the MS framework. So here is a new patch with unit test and modified class. I have truncate the patch to remove my other changes. So maybe it will not work. If you have issue to patch with it mail me and I will try to make a new one. cheers, Olivier 2007/11/30, Gert Driesen : > > Olivier, > > As you mention in your patch, you need unit tests to verify whether the > behavior matches the MS implementation. > > I suggest submitting a bug report, and attaching the current patch before > continueing working on it. > > Thay way the patch will not get lost in all the "noise" ... > > Gert > ----- Original Message ----- > From: "olivier dufour" > To: > Sent: Friday, November 30, 2007 7:45 AM > Subject: [Mono-dev] patch winform resource reader > > > > OK, I have done a small part at work. So I have forget to change the > > convention on it. > > I have attach the fixed patch. > > > > > > 2007/11/30, Jb Evain : > >> > >> Hey, > >> > >> On 11/30/07, olivier dufour < olivier.duff at gmail.com> wrote: > >> > Can someone check it before I commit. > >> > >> Please do not commit this as it is. The code: > >> > >> * doesn't respect the Mono coding conventions, > >> * mixes spaces and tabs all over the place. > >> > >> -- > >> Jb Evain > >> > > > > > > -------------------------------------------------------------------------------- > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071201/5c89399a/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch3.txt Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071201/5c89399a/attachment.txt From contact at i-nz.net Sat Dec 1 17:38:58 2007 From: contact at i-nz.net (Ivan N. Zlatev) Date: Sat, 1 Dec 2007 22:38:58 +0000 Subject: [Mono-dev] Mono Summit 2007 Photos Message-ID: <3db1ec7f0712011438w38d1d351q5d811070be3f2e27@mail.gmail.com> Dear Monkeys, I would like firstly to thank everyone for the great time I had during this Mono Summit. It was a pleasure for me to meet and spend this week with you guys. I suggest everyone replies to this e-mail with a link of his/her zip-ed/tar-ed/whatever photos of the event. Also if you don't feel like sharing your photos with The Others (you know, the ones that live on the other side of the island) I propose you archive them with a password same as the WiFi one from the summit. I could file a bug in bugzilla so we can track this easier. ;) Unfortunately I do not have any photos to share as I did not have a camera on me. Cheers! P.S: And no, I did not fix the transparency in WinForms... -- Ivan N. Zlatev Web: http://www.i-nZ.net "It's all some kind of whacked out conspiracy." From olivier.duff at gmail.com Sat Dec 1 18:10:16 2007 From: olivier.duff at gmail.com (olivier dufour) Date: Sun, 2 Dec 2007 00:10:16 +0100 Subject: [Mono-dev] mono summit & feedback Message-ID: Hi all, I just want to know if there are some videos of presentation/ review/ slides which are available somewhere? cheers, Olivier -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071202/3a8adbc8/attachment.html From arinai at mainsoft.com Sun Dec 2 07:57:25 2007 From: arinai at mainsoft.com (Arina Itkes) Date: Sun, 2 Dec 2007 04:57:25 -0800 Subject: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety fix. In-Reply-To: <474F29EB.5030209@ximian.com> Message-ID: The previous code: public string Url { - get { return url; } - set { - url = value; - uri = new Uri (url); - } can cause inconsistent values of uri and Url with multithreading work. -----Original Message----- From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Atsushi Eno Sent: Thursday, November 29, 2007 11:07 PM To: mono-devel Subject: Re: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety fix. Well, I'm still not sure. Why is the Uri change related to the thread safety issue? I know that your patch had included the change. I was asking for the reason why. Atsushi Eno Arina Itkes wrote: > Fix for thread safety had included changes in Url property. It was made > with calling to property supported only by net 2.0. Now it supported by > net 1.0 too. > > -----Original Message----- > From: mono-devel-list-bounces at lists.ximian.com > [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Atsushi > Eno > Sent: Tuesday, November 27, 2007 10:13 PM > To: mono-devel > Subject: Re: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety > fix. > > Hi, > > Please explain how come Uri is related to thread safety? > > Atsushi Eno > > Arina Itkes wrote: >> Please review additional fix for Url get property. Now it supported by >> NET_1_1 too. >> >> -----Original Message----- >> From: mono-devel-list-bounces at lists.ximian.com >> [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Arina >> Itkes >> Sent: Thursday, November 15, 2007 2:57 PM >> To: mono-devel >> Subject: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety fix. >> >> Hi all, >> >> Please review the attached patch. >> >> It contains synchronization fix for the class >> WebClientAsyncResult and light changes for the class WebClientProtocol >> that is a base of SoapHttpClientProtocol for thread safety purpose. >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From alan.mcgovern at gmail.com Sun Dec 2 08:14:26 2007 From: alan.mcgovern at gmail.com (Alan McGovern) Date: Sun, 2 Dec 2007 13:14:26 +0000 Subject: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety fix. In-Reply-To: References: <474F29EB.5030209@ximian.com> Message-ID: <117799f00712020514ma385787qc28dee722d91a8e7@mail.gmail.com> Well, it is explicitly stated that instance members are not threadsafe by default. If you're modifying an object from multiple threads simultaneously, then you have a bug in your code (unless the docs for that object explicitly state that the methods/properties you are using are threadsafe). Therefore a patch which has 'thread safety' fixes for stuff that is not supposed to be threadsafe doesn't make much sense. I think this is what Atsushi was saying. Alan. On Dec 2, 2007 12:57 PM, Arina Itkes wrote: > The previous code: > > public string Url { > - get { return url; } > - set { > - url = value; > - uri = new Uri (url); > - } > > can cause inconsistent values of uri and Url with multithreading work. > > -----Original Message----- > From: mono-devel-list-bounces at lists.ximian.com > [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Atsushi > Eno > Sent: Thursday, November 29, 2007 11:07 PM > To: mono-devel > Subject: Re: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety > fix. > > Well, I'm still not sure. Why is the Uri change related to the > thread safety issue? I know that your patch had included the change. > I was asking for the reason why. > > Atsushi Eno > > Arina Itkes wrote: > > Fix for thread safety had included changes in Url property. It was > made > > with calling to property supported only by net 2.0. Now it supported > by > > net 1.0 too. > > > > -----Original Message----- > > From: mono-devel-list-bounces at lists.ximian.com > > [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Atsushi > > Eno > > Sent: Tuesday, November 27, 2007 10:13 PM > > To: mono-devel > > Subject: Re: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety > > fix. > > > > Hi, > > > > Please explain how come Uri is related to thread safety? > > > > Atsushi Eno > > > > Arina Itkes wrote: > >> Please review additional fix for Url get property. Now it supported > by > >> NET_1_1 too. > >> > >> -----Original Message----- > >> From: mono-devel-list-bounces at lists.ximian.com > >> [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Arina > >> Itkes > >> Sent: Thursday, November 15, 2007 2:57 PM > >> To: mono-devel > >> Subject: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety fix. > >> > >> Hi all, > >> > >> Please review the attached patch. > >> > >> It contains synchronization fix for the class > >> WebClientAsyncResult and light changes for the class > WebClientProtocol > >> that is a base of SoapHttpClientProtocol for thread safety purpose. > >> > >> > >> > > > ------------------------------------------------------------------------ > >> _______________________________________________ > >> Mono-devel-list mailing list > >> Mono-devel-list at lists.ximian.com > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071202/e63c3e94/attachment.html From emperon at gmail.com Sun Dec 2 08:15:24 2007 From: emperon at gmail.com (Onur Gumus) Date: Sun, 2 Dec 2007 15:15:24 +0200 Subject: [Mono-dev] mono from svn can't make!! Message-ID: <8a7a2d050712020515j19a50323i73b21fcd58ba1ea4@mail.gmail.com> Hello when I try the mono from svn I am getting the following error when making it gcc -g -O2 -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -mno-tls-direct-seg-refs -o pedump pedump.o-pthread ./.libs/libmonoruntime.a ../io-layer/.libs/libwapi.a ../utils/.libs/libmonoutils.a ../../libgc/.libs/libmonogc.a /usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so -ldl -lpthread -lm ./.libs/libmonoruntime.a(process.o): In function `process_module_string_read': /home/onur/mono/mono/mono/metadata/process.c:197: undefined reference to `VerQueryValue' ./.libs/libmonoruntime.a(process.o): In function `process_get_fileversion': /home/onur/mono/mono/mono/metadata/process.c:250: undefined reference to `GetFileVersionInfoSize' /home/onur/mono/mono/mono/metadata/process.c:253: undefined reference to `GetFileVersionInfo' /home/onur/mono/mono/mono/metadata/process.c:262: undefined reference to `VerQueryValue' /home/onur/mono/mono/mono/metadata/process.c:292: undefined reference to `VerQueryValue' /home/onur/mono/mono/mono/metadata/process.c:323: undefined reference to `VerLanguageName' collect2: ld returned 1 exit status make[3]: *** [pedump] Error 1 make[3]: Leaving directory `/home/onur/mono/mono/mono/metadata' -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071202/872ef910/attachment.html From robertj at gmx.net Sun Dec 2 08:34:24 2007 From: robertj at gmx.net (Robert Jordan) Date: Sun, 02 Dec 2007 14:34:24 +0100 Subject: [Mono-dev] mono from svn can't make!! In-Reply-To: <8a7a2d050712020515j19a50323i73b21fcd58ba1ea4@mail.gmail.com> References: <8a7a2d050712020515j19a50323i73b21fcd58ba1ea4@mail.gmail.com> Message-ID: Onur Gumus wrote: > Hello when I try the mono from svn > I am getting the following error when making it Try "make maintainer-clean" followed by "./autogen.sh". Robert From robertj at gmx.net Sun Dec 2 08:36:17 2007 From: robertj at gmx.net (Robert Jordan) Date: Sun, 02 Dec 2007 14:36:17 +0100 Subject: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety fix. In-Reply-To: <117799f00712020514ma385787qc28dee722d91a8e7@mail.gmail.com> References: <474F29EB.5030209@ximian.com> <117799f00712020514ma385787qc28dee722d91a8e7@mail.gmail.com> Message-ID: Alan McGovern wrote: > Well, it is explicitly stated that instance members are not threadsafe by > default. If you're modifying an object from multiple threads simultaneously, From MSDN's docs of SoapHttpClientProtocol: Thread Safety This type is thread safe Robert > then you have a bug in your code (unless the docs for that object explicitly > state that the methods/properties you are using are threadsafe). Therefore a > patch which has 'thread safety' fixes for stuff that is not supposed to be > threadsafe doesn't make much sense. I think this is what Atsushi was saying. > > Alan. > > On Dec 2, 2007 12:57 PM, Arina Itkes wrote: > >> The previous code: >> >> public string Url { >> - get { return url; } >> - set { >> - url = value; >> - uri = new Uri (url); >> - } >> >> can cause inconsistent values of uri and Url with multithreading work. >> >> -----Original Message----- >> From: mono-devel-list-bounces at lists.ximian.com >> [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Atsushi >> Eno >> Sent: Thursday, November 29, 2007 11:07 PM >> To: mono-devel >> Subject: Re: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety >> fix. >> >> Well, I'm still not sure. Why is the Uri change related to the >> thread safety issue? I know that your patch had included the change. >> I was asking for the reason why. >> >> Atsushi Eno >> >> Arina Itkes wrote: >>> Fix for thread safety had included changes in Url property. It was >> made >>> with calling to property supported only by net 2.0. Now it supported >> by >>> net 1.0 too. >>> >>> -----Original Message----- >>> From: mono-devel-list-bounces at lists.ximian.com >>> [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Atsushi >>> Eno >>> Sent: Tuesday, November 27, 2007 10:13 PM >>> To: mono-devel >>> Subject: Re: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety >>> fix. >>> >>> Hi, >>> >>> Please explain how come Uri is related to thread safety? >>> >>> Atsushi Eno >>> >>> Arina Itkes wrote: >>>> Please review additional fix for Url get property. Now it supported >> by >>>> NET_1_1 too. >>>> >>>> -----Original Message----- >>>> From: mono-devel-list-bounces at lists.ximian.com >>>> [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Arina >>>> Itkes >>>> Sent: Thursday, November 15, 2007 2:57 PM >>>> To: mono-devel >>>> Subject: [Mono-dev] [PATCH] SoapHttpClientProtocol Thread Safety fix. >>>> >>>> Hi all, >>>> >>>> Please review the attached patch. >>>> >>>> It contains synchronization fix for the class >>>> WebClientAsyncResult and light changes for the class >> WebClientProtocol >>>> that is a base of SoapHttpClientProtocol for thread safety purpose. >>>> >>>> >>>> >> ------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Mono-devel-list mailing list >>>> Mono-devel-list at lists.ximian.com >>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list at lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >> >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From martin at martsoft.co.uk Sun Dec 2 09:26:31 2007 From: martin at martsoft.co.uk (Martin Green) Date: Sun, 2 Dec 2007 14:26:31 +0000 Subject: [Mono-dev] SerialPort - GetPortNames patch Message-ID: <200712021426.31645.martin@martsoft.co.uk> Hi, Attached is a patch to implement GetPortNames for windows by looking in the registry. Can someone test it out and commit it for me if it is acceptable. I have tested it on XP and Vista, but if anyone can check the registry location is also valid for 2000 that would be useful. I am working on a project that uses serial ports quite extensively and it would be useful if mono supported the full functionality with buffering and events. I should have some time to work on this myself so if whoever knows this class best can give me some idea of why it isn't already done and what approaches were considered. I can spend some time looking at it. Thanks, Martin P.S. This is the first patch I have submitted so if I need to do anything differently please let me know. I made it with TortoiseSVN but I assume it shouldn't be any different than svn. -------------- next part -------------- A non-text attachment was scrubbed... Name: serialport.patch Type: text/x-diff Size: 2318 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071202/5c05d79b/attachment.bin From fxjrlists at yahoo.com.br Sun Dec 2 09:44:17 2007 From: fxjrlists at yahoo.com.br (Francisco Figueiredo Jr.) Date: Sun, 02 Dec 2007 12:44:17 -0200 Subject: [Mono-dev] npgsql error on Mono In-Reply-To: <27d75530711220829k1f954bdsc3be145eddf69b48@mail.gmail.com> References: <27d75530711170838u6f1d5c36t1ead5c706a5aa546@mail.gmail.com> <473F24F7.1020907@yahoo.com.br> <27d75530711180856k219e23f9g8bda78fdaae5b80b@mail.gmail.com> <4740CC51.8090104@yahoo.com.br> <27d75530711220829k1f954bdsc3be145eddf69b48@mail.gmail.com> Message-ID: <4752C4C1.9060706@yahoo.com.br> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe Audette wrote: > Hi, > Hi, Joe! > Just a follow up. My best guess conclusion is that something is funky > in the packaging of pgsql under opensuse 10.3 > I resurrected a copy of my vm from before I upgraded to opensuse 10.3 > to get back to opensuse 10.2, then getting latest mono built from svn > it works as expected. > Great!! Nice to know you got it working. Well, I think your problem is very strange even because from windows you got it working and when connecting from linux it doesn't... Please, if you have opportunity, try to install opensuse from scratch and see if the problem still occurs. > Thanks, > Thank you too. Regards, Francisco Figueiredo Jr. http://fxjr.blogspot.com Npgsql Lead Developer http://pgfoundry.org/projects/npgsql Mono Project Contributor http://www.go-mono.com MonoBrasil Project Founder Member http://monobrasil.softwarelivre.org - -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBR1LEvv7iFmsNzeXfAQJC5wgAl+Up1kpeg6XSLDU1x3GrxCi460FTJ1mP D9HrBAaxawdG4Uwe5i4bycAS82QS7D1IHpNJ3Kx/OsYRRXdpqYDj4Lseeu1DYv4y N4nZlL7riLqy2LsPydnUGv5eTlM+n53hJGjjzeBYadSybLF8pesA7lp0XCkbMbJx ZTR8CPGUngPNf+r0Ndm78FXuHp+gF7j2VMPHp7xJG4rbaITCYhS9Gap8oSz4+5YE HUICchVxXLzMKEZd3oAYpB4wy4VOAILtuyh09x/j1qV2MKHKrNQlMLj6VZ0Oe0ZF 3vheripRT3wTqLnBmDvNqeho1PWMayCApuAo9wklTLLnthmpmxcDrw== =W/De -----END PGP SIGNATURE----- From robertj at gmx.net Sun Dec 2 09:58:26 2007 From: robertj at gmx.net (Robert Jordan) Date: Sun, 02 Dec 2007 15:58:26 +0100 Subject: [Mono-dev] SerialPort - GetPortNames patch In-Reply-To: <200712021426.31645.martin@martsoft.co.uk> References: <200712021426.31645.martin@martsoft.co.uk> Message-ID: Hi Martin, > Attached is a patch to implement GetPortNames for windows by looking in the > registry. Can someone test it out and commit it for me if it is acceptable. > I have tested it on XP and Vista, but if anyone can check the registry > location is also valid for 2000 that would be useful. it would even work on NT 3.1: http://support.microsoft.com/kb/102988 Please add a null check for "subkey" after RegistryKey subkey = Registry.LocalMachine.OpenSubKey("HARDWARE\\DEVICEMAP\\SERIALCOMM"); and consider the "using" pattern. Shouldn't be the default port name the first entry of this list? Your patch presets "COM1". Robert From robertj at gmx.net Sun Dec 2 10:07:12 2007 From: robertj at gmx.net (Robert Jordan) Date: Sun, 02 Dec 2007 16:07:12 +0100 Subject: [Mono-dev] FileSystemWatcher - FileSystemEventArgs - first byte of name & fullname In-Reply-To: <212.183.32.26.1196535880.wm@webmail.inode.at> References: <212.183.32.26.1196535880.wm@webmail.inode.at> Message-ID: mono at glyps.com wrote: > hi ! > > i write a little class for fsw. under windows i received > the fullname and name of the concerned file in the right length. > > if i copy the executables to opensuse10.2 (mono 1.2.5.1) on the vm and > run the exe with "mono programmname.exe" i miss the first byte after > slash if a get the FileSystemEventArgs-Event : Please attach a self-containing & compilable test case. Robert From ClassDevelopment at A-SoftTech.com Sun Dec 2 17:32:27 2007 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Sun, 2 Dec 2007 23:32:27 +0100 Subject: [Mono-dev] [U-SPAM] Re: String.GetHashCode() In-Reply-To: <117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com><711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> <117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> Message-ID: Don't forget that 4 bytes per Hashcode isn't enough. You also need a boolean to store if the hash is already computed (as e.g. 0 is a valid hash, too). And then you would need one additional check for this boolean per call. And don't forget that strings within the corelib ARE mutable to some extent. Greetings Andreas _____ Von: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag von Alan McGovern Gesendet: Samstag, 1. Dezember 2007 17:22 An: Robert Jordan Cc: mono-devel-list at lists.ximian.com Betreff: [U-SPAM] Re: [Mono-dev] String.GetHashCode() Also, just looking at the string source a bit more closely, it has a GetCaseInsensitiveHashcode method too, so i'd assume that would need to be cached too which would mean 8 bytes would be needed. This wouldn't scale well. Fair enough. Twas just an idea. Alan. On Dec 1, 2007 4:09 PM, Robert Jordan wrote: Tinco Andringa wrote: > (Woops, only replied to kamil) > > If Jerome is right and the overhead is only 4 bytes, then overhead > shouldn't be a problem at all. The worst case size of a string would > be 1 character, of 2 bytes + something to end it with, like an int > containing its length, 2 bytes, or a terminating character, probably > 2 bytes too. Making it at least 4 bytes. A worst case scenario of Look at a heavy string consumer: [g]mcs. The average string length it has to process is probably only 4-5 chars long. That's roundabout 12 bytes. Adding 4 bytes for the hash code is a huge overhead that only pays out if GetHashCode is called frequently, but this is definitely not a common scenario for most of the strings. Robert _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071202/1cc1655f/attachment.html From martin at martsoft.co.uk Sun Dec 2 17:41:04 2007 From: martin at martsoft.co.uk (Martin Green) Date: Sun, 2 Dec 2007 22:41:04 +0000 Subject: [Mono-dev] SerialPort - GetPortNames patch In-Reply-To: References: <200712021426.31645.martin@martsoft.co.uk> Message-ID: <200712022241.05055.martin@martsoft.co.uk> Hi Robert, > it would even work on NT 3.1: http://support.microsoft.com/kb/102988 I thought it would, thanks for confirming. > Please add a null check for "subkey" after > > RegistryKey subkey = > Registry.LocalMachine.OpenSubKey("HARDWARE\\DEVICEMAP\\SERIALCOMM"); > > and consider the "using" pattern. Done, attached. > Shouldn't be the default port name the first entry of this > list? Your patch presets "COM1". Yes i agree and have changed it to match. Anyone else got any thoughts on this? I checked on MSDN and it does say that COM1 should be default but it should always be first on the list, if it exists. I left in the previous defaults if GetPortNames doesn't return anything as i don't think it is supposed to throw an exception at that stage. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: serialport2.patch Type: text/x-diff Size: 2495 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071202/dccb47c1/attachment.bin From apenwarr at gmail.com Sun Dec 2 17:42:35 2007 From: apenwarr at gmail.com (Avery Pennarun) Date: Sun, 2 Dec 2007 17:42:35 -0500 Subject: [Mono-dev] [U-SPAM] Re: String.GetHashCode() In-Reply-To: References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> <711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> <117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> Message-ID: <32541b130712021442v130dada7r762038a8d7f75358@mail.gmail.com> On 02/12/2007, Andreas Nahr wrote: > Don't forget that 4 bytes per Hashcode isn't enough. You also need a boolean > to store if the hash is already computed (as e.g. 0 is a valid hash, too). > And then you would need one additional check for this boolean per call. Technically it would be safe (and no worse than current behaviour) to recalculate the hash every time in the rare case that it's exactly zero. > And don't forget that strings within the corelib ARE mutable to some extent. That sounds somewhat more important. Wouldn't it be better, in the cases where precomputing the hash would have a large benefit, just to create a new class like PrecomputedHashString that stores a string along with its hash? Then the application itself could optimize for the cases where this matters by using the different class as the key to its hash tables. Have fun, Avery From kamil.skalski at gmail.com Sun Dec 2 21:42:17 2007 From: kamil.skalski at gmail.com (Kamil Skalski) Date: Sun, 2 Dec 2007 18:42:17 -0800 Subject: [Mono-dev] [U-SPAM] Re: String.GetHashCode() In-Reply-To: <32541b130712021442v130dada7r762038a8d7f75358@mail.gmail.com> References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> <711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> <117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> <32541b130712021442v130dada7r762038a8d7f75358@mail.gmail.com> Message-ID: <711aea6b0712021842v398e0d2bp86b189e65a0cbd1f@mail.gmail.com> 2007/12/2, Avery Pennarun : > On 02/12/2007, Andreas Nahr wrote: > > Don't forget that 4 bytes per Hashcode isn't enough. You also need a boolean > > to store if the hash is already computed (as e.g. 0 is a valid hash, too). > > And then you would need one additional check for this boolean per call. > > Technically it would be safe (and no worse than current behaviour) to > recalculate the hash every time in the rare case that it's exactly > zero. > > > And don't forget that strings within the corelib ARE mutable to some extent. > > That sounds somewhat more important. > > Wouldn't it be better, in the cases where precomputing the hash would > have a large benefit, just to create a new class like > PrecomputedHashString that stores a string along with its hash? Then > the application itself could optimize for the cases where this matters > by using the different class as the key to its hash tables. If only they didn't make string sealed ;) > > Have fun, > > Avery > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Kamil Skalski http://nazgul.omega.pl From mono at glyps.com Mon Dec 3 01:04:58 2007 From: mono at glyps.com (mono at glyps.com) Date: Mon, 3 Dec 2007 07:04:58 +0100 (CET) Subject: [Mono-dev] [Fwd: Re: FileSystemWatcher - FileSystemEventArgs - first byte of name & fullname] Message-ID: <91.141.97.155.1196661898.wm@webmail.inode.at> hi ! here is a testproject. thank you in advance, harald -------- Urspr?ngliche Nachricht -------- Betreff: Re: [Mono-dev] FileSystemWatcher - FileSystemEventArgs - first byte of name & fullname Von: Robert Jordan Datum: Son, 2.12.2007, 16:07 An: mono-devel-list at lists.ximian.com mono at glyps.com wrote: > hi ! > > i write a little class for fsw. under windows i received > the fullname and name of the concerned file in the right length. > > if i copy the executables to opensuse10.2 (mono 1.2.5.1) on the vm > and run the exe with "mono programmname.exe" i miss the first byte > after slash if a get the FileSystemEventArgs-Event : Please attach a self-containing & compilable test case. Robert _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -------------- next part -------------- A non-text attachment was scrubbed... Name: testfsw.zip Type: application/zip Size: 18927 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071203/f3de50ad/attachment.zip From dev.malst at apsystems.it Mon Dec 3 03:46:44 2007 From: dev.malst at apsystems.it (APS) Date: Mon, 03 Dec 2007 09:46:44 +0100 Subject: [Mono-dev] Error installing mod_mono on Apache 1.3 In-Reply-To: <7.0.0.16.0.20071130092713.01f345e0@apsystems.it> References: <7.0.0.16.0.20071130092713.01f345e0@apsystems.it> Message-ID: <7.0.0.16.0.20071203094138.03640970@apsystems.it> No one? Mono 1.2.5 should run on Apache 1.3, it can be an undetected missing dependency? At 09.38 30/11/2007, APS wrote: >Hi, yesterday I tried to install mono to handle asp.net application >on a machine using Apache 1.3 >I finished rpms installation succesfully but when I configured >mod_mono and restarted apache I got an error: > >Syntax error on line 1011 of /etc/apache/conf/httpd.conf: >Cannot load /usr/local/apache/libexec/mod_mono.so into server: >/usr/local/apache/libexec/mod_mono.so: undefined symbol: unixd_config > >The versions of mono and mod_mono are the lastest, downloaded yesterday. >Linux version is Red Hat Enterprise Linux AS release 4 (Nahant Update 2) >uname says Linux .... 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT >2005 i686 i686 i386 GNU/Linux >Apache Server version: Apache/1.3.33 (Unix) Server built: Jun 6 >2006 09:59:45 >_______________________________________________ >Mono-devel-list mailing list >Mono-devel-list at lists.ximian.com >http://lists.ximian.com/mailman/listinfo/mono-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071203/6f943856/attachment.html From robertj at gmx.net Mon Dec 3 04:14:32 2007 From: robertj at gmx.net (Robert Jordan) Date: Mon, 03 Dec 2007 10:14:32 +0100 Subject: [Mono-dev] Error installing mod_mono on Apache 1.3 In-Reply-To: <7.0.0.16.0.20071203094138.03640970@apsystems.it> References: <7.0.0.16.0.20071130092713.01f345e0@apsystems.it> <7.0.0.16.0.20071203094138.03640970@apsystems.it> Message-ID: APS wrote: > No one? Mono 1.2.5 should run on Apache 1.3, it can be an undetected > missing dependency? It runs, but only if mod_mono was actually compiled for apache 1.3. Robert > > At 09.38 30/11/2007, APS wrote: >> Hi, yesterday I tried to install mono to handle asp.net application on >> a machine using Apache 1.3 >> I finished rpms installation succesfully but when I configured >> mod_mono and restarted apache I got an error: >> >> Syntax error on line 1011 of /etc/apache/conf/httpd.conf: >> Cannot load /usr/local/apache/libexec/mod_mono.so into server: >> /usr/local/apache/libexec/mod_mono.so: undefined symbol: unixd_config >> >> The versions of mono and mod_mono are the lastest, downloaded yesterday. >> Linux version is Red Hat Enterprise Linux AS release 4 (Nahant Update 2) >> uname says Linux .... 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT >> 2005 i686 i686 i386 GNU/Linux >> Apache Server version: Apache/1.3.33 (Unix) Server built: Jun 6 >> 2006 09:59:45 >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From dev.malst at apsystems.it Mon Dec 3 05:27:09 2007 From: dev.malst at apsystems.it (APS) Date: Mon, 03 Dec 2007 11:27:09 +0100 Subject: [Mono-dev] Error installing mod_mono on Apache 1.3 Message-ID: <7.0.0.16.0.20071203112704.035da4b0@apsystems.it> Many thanks, just to avoid unnecessary work, there's a place where I can download a version pre-compiled for 1.3 or I've to rebuild it on the target machine? At 10.14 03/12/2007, Robert Jordan wrote: >APS wrote: > > No one? Mono 1.2.5 should run on Apache 1.3, it can be an undetected > > missing dependency? > >It runs, but only if mod_mono was actually compiled for apache 1.3. > >Robert > > > > > At 09.38 30/11/2007, APS wrote: > >> Hi, yesterday I tried to install mono to handle asp.net application on > >> a machine using Apache 1.3 > >> I finished rpms installation succesfully but when I configured > >> mod_mono and restarted apache I got an error: > >> > >> Syntax error on line 1011 of /etc/apache/conf/httpd.conf: > >> Cannot load /usr/local/apache/libexec/mod_mono.so into server: > >> /usr/local/apache/libexec/mod_mono.so: undefined symbol: unixd_config > >> > >> The versions of mono and mod_mono are the lastest, downloaded yesterday. > >> Linux version is Red Hat Enterprise Linux AS release 4 (Nahant Update 2) > >> uname says Linux .... 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT > >> 2005 i686 i686 i386 GNU/Linux > >> Apache Server version: Apache/1.3.33 (Unix) Server built: Jun 6 > >> 2006 09:59:45 > >> _______________________________________________ > >> Mono-devel-list mailing list > >> Mono-devel-list at lists.ximian.com > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > >_______________________________________________ >Mono-devel-list mailing list >Mono-devel-list at lists.ximian.com >http://lists.ximian.com/mailman/listinfo/mono-devel-list From robertj at gmx.net Mon Dec 3 05:59:04 2007 From: robertj at gmx.net (Robert Jordan) Date: Mon, 03 Dec 2007 11:59:04 +0100 Subject: [Mono-dev] Error installing mod_mono on Apache 1.3 In-Reply-To: <7.0.0.16.0.20071203112704.035da4b0@apsystems.it> References: <7.0.0.16.0.20071203112704.035da4b0@apsystems.it> Message-ID: APS wrote: > Many thanks, just to avoid unnecessary work, there's a place where I > can download a version pre-compiled for 1.3 or I've to rebuild it on > the target machine? I'm not aware of any precompiled versions. Mono's mod_mono RPM for RHEL 4 is apache2 only. Robert > > At 10.14 03/12/2007, Robert Jordan wrote: >> APS wrote: >>> No one? Mono 1.2.5 should run on Apache 1.3, it can be an undetected >>> missing dependency? >> It runs, but only if mod_mono was actually compiled for apache 1.3. >> >> Robert >> >>> At 09.38 30/11/2007, APS wrote: >>>> Hi, yesterday I tried to install mono to handle asp.net application on >>>> a machine using Apache 1.3 >>>> I finished rpms installation succesfully but when I configured >>>> mod_mono and restarted apache I got an error: >>>> >>>> Syntax error on line 1011 of /etc/apache/conf/httpd.conf: >>>> Cannot load /usr/local/apache/libexec/mod_mono.so into server: >>>> /usr/local/apache/libexec/mod_mono.so: undefined symbol: unixd_config >>>> >>>> The versions of mono and mod_mono are the lastest, downloaded yesterday. >>>> Linux version is Red Hat Enterprise Linux AS release 4 (Nahant Update 2) >>>> uname says Linux .... 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT >>>> 2005 i686 i686 i386 GNU/Linux >>>> Apache Server version: Apache/1.3.33 (Unix) Server built: Jun 6 >>>> 2006 09:59:45 >>>> _______________________________________________ >>>> Mono-devel-list mailing list >>>> Mono-devel-list at lists.ximian.com >>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list at lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list From jonpryor at vt.edu Mon Dec 3 06:36:30 2007 From: jonpryor at vt.edu (Jonathan Pryor) Date: Mon, 03 Dec 2007 06:36:30 -0500 Subject: [Mono-dev] String.GetHashCode() In-Reply-To: References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> <711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> Message-ID: <1196681791.4926.16.camel@lina.magi.jprl.com> On Sat, 2007-12-01 at 16:16 +0100, Tinco Andringa wrote: > Speaking of unicode/utf-16 and memory, couldn't a lot of > memory be spared if strings where stored as utf8 internally, > which would be converted back to utf-16 when more than 256 > different characters would be used? It depends on what you're storing in the strings. If you're only storing ASCII or Western European characters in your strings, then yes, UTF-8 would require less memory. If, on the other hand, you're storing Asian language text (Japanese, Chinese, Korean), or anything else containing any character >= U+0800 (i.e. > 97%+ of all potential characters), then UTF-8 is a space *loss*, not a gain, as each glyph would require at least 3 bytes to store, while UTF-16 would need 2. See also: http://blogs.msdn.com/michkap/archive/2005/05/20/420317.aspx http://blogs.msdn.com/michkap/archive/2005/05/22/420822.aspx http://blogs.msdn.com/michkap/archive/2005/05/25/421828.aspx Because of this, it is not uncommon for Linux apps to use UTF-16 internally, e.g. Mozilla, Qt, Python (which iirc has a configure-time command to control use of UTF-16 vs. UTF-32 strings), etc. - Jon From lupus at ximian.com Mon Dec 3 08:13:32 2007 From: lupus at ximian.com (Paolo Molaro) Date: Mon, 3 Dec 2007 14:13:32 +0100 Subject: [Mono-dev] String.GetHashCode() In-Reply-To: References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> Message-ID: <20071203131332.GF5889@debian.org> On 12/01/07 Robert Jordan wrote: > > Since strings are immutable, shouldn't it be possible to compute the > > hashcode once and store it rather than recomputing it over and over again? > > Is there some really obvious reason that i can't think of that would make > > this a bad idea? > > This idea already came up a couple of years ago (2002 or so). [...] > Therefore, the optimization should consider the string length > and append the hash code after the string's bytes > only if its length is greater than some amount (1K or so). I'll reply to this mail and try to summarize all the responses and the constraints we need to obey. 1) we can't change the C-side MonoString struct, because it is part of the Mono ABI 2) we should try to not increase memory usage 3) we should try to not slowdown the case were the hashcode is calculated for the first time on a string instance 4) we can't use utf8 to hold string chars because this would break the mscorlib/CLI ABI (see how fixed on a string is compiled by the C# compiler, for example) 5) GetHashCode should never be called for a string that is not yet fully built (like in StringBuilder), so there is no worry aout the string changing after the hash code field has been set Point 1 means that if we were to add a new field to the string it can only be added at the end, after the character data (and the terminating null char). This also means that if we use an int, we have to be careful and properly align it (this also means more instructions to access this field). About memory usage: objects in Mono are always aligned on 8 byte boundaries so in some cases the overhead is 50%, 33%, 25%, 20% (for strings up to 15 chars) and sometimes it is 0. I would say that, as a mean, the memory overhead is 15% for up to 20 chars, 5% for up to 100 chars and it doesn't matter above that. After having written the moving GC, where fast computing of an object's size is important, I would also try to avoid allocating the extra field only for big strings (this would also slowdown string allocation somewhat). So, given the above constraints and considerations, I suggest the following: 1) wait for the moving GC to become the default: in that case we can use the same mechanism used to store object hash codes in the object header: this means no extra memory usage for strings and just a small slowdown when inserting the hashcode in the header (it needs a locked op). Implementing this mechanism with the current GC would slowdown a bit some common operations (lock/unlock), with the moving GC we would take the hit anyway. 2) in alternative, use a 16 bit hash code field: the memory overhead is smaller (5-10% for up to 20 chars, 2-3% for up to 100 chars on average), it requires no alignment calculation so it's fast to access. The drawback is that for very big hashtables (> 100 K entries) we'd have few bits. A cheap way to increase bits would be to or the hash with the first char shifted left 16 bits (but this wouldn't solve the issue for strings all beginning with the same char). I'm sure this drawback is not very significant, but I'm also sure someone will write a specific benchmark to exploit this weakness and whine in some blog or on the list about it:) 2 is very simple to implement so we could easily get some numbers (hint, hint). lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From miguel at novell.com Mon Dec 3 09:39:31 2007 From: miguel at novell.com (Miguel de Icaza) Date: Mon, 03 Dec 2007 09:39:31 -0500 Subject: [Mono-dev] mono summit & feedback In-Reply-To: References: Message-ID: <1196692771.4162.17.camel@erandi.boston.ximian.com> > I just want to know if there are some videos of presentation/ review/ > slides which are available somewhere? We will have Slides available for some of the presentation. Although it will be hard to write a summary, as I would say 90% of the action took place in people talking to each other, going out to dinner and hammering at problems during the week. It was a lot of fun. From miguel at novell.com Mon Dec 3 09:45:22 2007 From: miguel at novell.com (Miguel de Icaza) Date: Mon, 03 Dec 2007 09:45:22 -0500 Subject: [Mono-dev] [U-SPAM] Re: String.GetHashCode() In-Reply-To: References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com> <711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com> <117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> Message-ID: <1196693122.4162.22.camel@erandi.boston.ximian.com> Hello, First of all, I love the idea. > Don't forget that 4 bytes per Hashcode isn't enough. You also need a > boolean to store if the hash is already computed (as e.g. 0 is a valid > hash, too). You could assume that any string over N would contain the precomputed hashcode immediately after the string in a sizeof(IntPtr) aligned 32-bit location. What the N should still be measured. Miguel > From lupus at ximian.com Mon Dec 3 11:22:45 2007 From: lupus at ximian.com (Paolo Molaro) Date: Mon, 3 Dec 2007 17:22:45 +0100 Subject: [Mono-dev] Profiler and coverage problem? In-Reply-To: <20071130134752.wsg8sg00wwsks0g8@webmail.researchstudio.at> References: <20071130114511.wc40g8c8owggw00g@webmail.researchstudio.at> <20071130134752.wsg8sg00wwsks0g8@webmail.researchstudio.at> Message-ID: <20071203162245.GI5889@debian.org> On 11/30/07 Csaba Balazs wrote: > class ParentClass { > private int tval = 1; > public int PValue { > get { > return 2*tval; > } > } > } [...] > It says, the ParentClass.PValue (get_PValue) is not used, but we can see its > value on the screen. Why isn't it covered? I would like it to be in the COV > file. The method gets inlined. You can get the coverage info for it by running mono with inlining disabled: mono -O=-inline program.exe. I should likely change the coverage profiler to force inlining off so the results are not surprising (it would be more work to enable precise coverage info when inlining is enabled). lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From kumpera at gmail.com Mon Dec 3 14:23:51 2007 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Mon, 3 Dec 2007 17:23:51 -0200 Subject: [Mono-dev] segfault on an ARM processor but not on a x86 (Linux) or .NET on Windows In-Reply-To: <040d01c8339a$f67e6d80$e37b4880$@com> References: <040d01c8339a$f67e6d80$e37b4880$@com> Message-ID: <8cca42d80712031123r1e9352e3h2d732fcab0129bc6@mail.gmail.com> Could you please fill a bug report on that, so we can track the issue? Add a test case so it makes possible to have the bug tested. On Nov 30, 2007 7:50 PM, Dave Ferguson wrote: > We saw several seg faults when AppDomain.Unload was called in Mono on an > ARM processor. The same code executed fine on x86 mono and .NET on > Windows. What I think was happening, but not sure, was that we were > attempting to unload the only app domain in the process. It seems like mono > under x86 and .NET on windows handles this by ignoring the call and doesn't > cause a seg fault. Also, when we were seeing this, it was not at the line > of code, but just randomly after the call. I believe this had to do with > garbage collection removing references that it shouldn't have. We could > change the timing of the seg fault by introducing some more intensive > logging around the area. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071203/7005b5a0/attachment.html From surfzoid at gmail.com Mon Dec 3 15:22:01 2007 From: surfzoid at gmail.com (Petit Eric) Date: Mon, 3 Dec 2007 21:22:01 +0100 Subject: [Mono-dev] ClickOnce Message-ID: <84776a970712031222s2ab211aftf4a13270d221f5af@mail.gmail.com> hi folk I just see last week, there is a firefox addon to suport the Microsoft ClickOnce technology, so is Mono/MonoDevelop team plane to suport this one. Just for info here is the link of ClickOnce for firefox development : http://www.softwarepunk.com/ffclickonce/ @++ From pablosantosluac at terra.es Mon Dec 3 15:40:06 2007 From: pablosantosluac at terra.es (pablosantosluac) Date: Mon, 3 Dec 2007 21:40:06 +0100 Subject: [Mono-dev] [U-SPAM] Re: String.GetHashCode() References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com><711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com><117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> <1196693122.4162.22.camel@erandi.boston.ximian.com> Message-ID: <09fe01c835ec$b2895dc0$6a28a00a@beardtongue> I don't see the moment to try it with the plastic server... :-P ----- Original Message ----- From: "Miguel de Icaza" To: "Andreas Nahr" Cc: "'Robert Jordan'" ; Sent: Monday, December 03, 2007 3:45 PM Subject: Re: [Mono-dev] [U-SPAM] Re: String.GetHashCode() > Hello, > > First of all, I love the idea. > >> Don't forget that 4 bytes per Hashcode isn't enough. You also need a >> boolean to store if the hash is already computed (as e.g. 0 is a valid >> hash, too). > > You could assume that any string over N would contain the > precomputed hashcode immediately after the string in a sizeof(IntPtr) > aligned 32-bit location. > > What the N should still be measured. > > Miguel >> > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From pablosantosluac at terra.es Mon Dec 3 15:41:48 2007 From: pablosantosluac at terra.es (pablosantosluac) Date: Mon, 3 Dec 2007 21:41:48 +0100 Subject: [Mono-dev] The best way to secure remoting? Message-ID: <0a0401c835ec$ede486b0$6a28a00a@beardtongue> Hi there, AFAIK with .net 2.0 SSL is an standard channel, isn't it? But my question is: if I want to keep the mono-1.0 profile... what's the best way to secure remoting communication? Thanks! pablo From ClassDevelopment at A-SoftTech.com Mon Dec 3 16:36:00 2007 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Mon, 3 Dec 2007 22:36:00 +0100 Subject: [Mono-dev] [U-SPAM] Re: String.GetHashCode() In-Reply-To: <1196693122.4162.22.camel@erandi.boston.ximian.com> References: <117799f00711301723s1b91766fr1c7e273f0a415c11@mail.gmail.com><711aea6b0711301910w646ef71by10cf5311e9ddeb7@mail.gmail.com><117799f00712010821h26822fct8dd7bc68819419a0@mail.gmail.com> <1196693122.4162.22.camel@erandi.boston.ximian.com> Message-ID: > Don't forget that 4 bytes per Hashcode isn't enough. You also need a > boolean to store if the hash is already computed (as e.g. 0 is a valid > hash, too). > > You could assume that any string over N would contain the precomputed hashcode immediately after the string >in a sizeof(IntPtr) aligned 32-bit location. > I don't think precomputing (a.k. non-lazy init) may be a good thing. I for one have quite some applications that handle enormous amount of strings. However none of these Strings ever needs to compute the hashcode. I'd rather pay 1 (or 4) additional bytes and not precompute it. However for other projects things will be different... > 5) GetHashCode should never be called for a string that is not yet fully built (like in StringBuilder), so > there is no worry aout the string changing after the hash code field has been set Well string at least contains: internal unsafe void InternalSetChar (int idx, char val) internal unsafe void InternalSetLength (int newLength) Which may be usefull for more advanced optimizations in case they aren't already used. Greetings Andreas From robertj at gmx.net Mon Dec 3 16:35:14 2007 From: robertj at gmx.net (Robert Jordan) Date: Mon, 03 Dec 2007 22:35:14 +0100 Subject: [Mono-dev] The best way to secure remoting? In-Reply-To: <0a0401c835ec$ede486b0$6a28a00a@beardtongue> References: <0a0401c835ec$ede486b0$6a28a00a@beardtongue> Message-ID: pablosantosluac wrote: > Hi there, > > AFAIK with .net 2.0 SSL is an standard channel, isn't it? No, in MS.NET 2.0 it is based on NegotiateStream that uses whichever authentication and encryption Windows SSPI dictates. See MSDN. > But my question is: if I want to keep the mono-1.0 profile... what's the > best way to secure remoting communication? Host your remoting objects in XSP and use HttpChannel + SOAP formatter over SSL. Robert From lordhabbit at gmail.com Mon Dec 3 18:37:16 2007 From: lordhabbit at gmail.com (=?UTF-8?Q?Javier_Mart=C3=ADn?=) Date: Tue, 4 Dec 2007 00:37:16 +0100 Subject: [Mono-dev] DriveInfo implementation Message-ID: Hi all, I would like to help in the implementation of the System.IO.DriveInfo class, which as of now is semi-functional in Linux and little more than a stub in Windows. However, after thinking a bit about it, I've come to the conclusion that the methods that discover the volumes in the system (*GetDrives) require P/Invoke at the very least (windows), and possibly even unmanaged code (linux). The point of this message is asking for directions and rules on this matter. Is unmanaged code (at all) allowed? Can I create a portable "interface" (not necessarily a .NET interface) and then a separated, system-dependant implementation? How are those platform-dependant switches managed in the Mono autoconf files? Etcetera. I would appreciate any pointers on the matter. Habbit From miguel at novell.com Mon Dec 3 20:04:04 2007 From: miguel at novell.com (Miguel de Icaza) Date: Mon, 03 Dec 2007 20:04:04 -0500 Subject: [Mono-dev] DriveInfo implementation In-Reply-To: References: Message-ID: <1196730244.3977.71.camel@erandi.boston.ximian.com> Hello, > I would like to help in the implementation of the System.IO.DriveInfo > class, which as of now is semi-functional in Linux and little more > than a stub in Windows. However, after thinking a bit about it, I've > come to the conclusion that the methods that discover the volumes in > the system (*GetDrives) require P/Invoke at the very least (windows), > and possibly even unmanaged code (linux). Correct, for Windows we should use P/Invokes. For Linux, the current "trivial" implementation is enough, a more complete implementation probably should talk with DBus to Hal, but am unsure about that. For Unix, a full solution probably needs to use Mono.Posix to get the file system information (notice that information about actual devices is hard to obtain in Linux, unless we use something like Hal). > The point of this message is asking for directions and rules on this > matter. Is unmanaged code (at all) allowed? Can I create a portable > "interface" (not necessarily a .NET interface) and then a separated, > system-dependant implementation? How are those platform-dependant > switches managed in the Mono autoconf files? Etcetera. I believe that for the Windows case, you could get away with P/Invoke, we have used glue in the past, see the mono/support directory, it contains plenty of portability glue. > I would appreciate any pointers on the matter. > > Habbit > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From vlad.dimitrov at gmail.com Mon Dec 3 20:18:07 2007 From: vlad.dimitrov at gmail.com (Vladimir Dimitrov) Date: Tue, 4 Dec 2007 03:18:07 +0200 Subject: [Mono-dev] System.DllNotFoundException gtksharpglue-2 in mono 1.2.6 Message-ID: <003501c83613$8884eb30$4765a8c0@whitebook> Hi folks, is there something that I am missing here? I have a GTK# based application and I am trying to use the latest mono version (1.2.6.1) from the generic installer. I searched in Google about that issue but all I get are very old problems that should not be the case now. I see that on the mono page it is stated that the Gtk-sharp package is an "optional" package, but as far as I remember it used to be included in the generic installer and so it is right now. Can somebody point me to what I am missing and what is the easiest way to install the newest mono on a clean Linux machine (for example Ubuntu 7.10) with GTK# support. Thanks Vladimir Dimitrov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071204/e868552b/attachment.html From max at tfbc.com Mon Dec 3 20:19:29 2007 From: max at tfbc.com (Max de Lavenne) Date: Mon, 3 Dec 2007 17:19:29 -0800 Subject: [Mono-dev] DriveInfo implementation Message-ID: <00b501c83613$bbcfdea0$6647a8c0@tfbc.com> Hey, I can help here. I had to do this a few years ago for windows. This is very complete (we use it in production). Some of this code has been inspired from snippets in the internet. I can't remember where from though. You will find a Computer class that does a whole bunch of things, along with all the P/Invoke and enums with it. Best Regards Max /// /// Lists the different type of drives /// public enum DriveType { /// /// The drive type cannot be determined. /// DRIVE_UNKNOWN = 0, /// /// The root path is invalid. For example, no volume is mounted at the path. /// DRIVE_NO_ROOT_DIR = 1, /// /// The disk can be removed from the drive. /// DRIVE_REMOVABLE = 2, /// /// The disk cannot be removed from the drive. /// DRIVE_FIXED = 3, /// /// The drive is a remote (network) drive. /// DRIVE_REMOTE = 4, /// /// The drive is a CD-ROM drive. /// DRIVE_CDROM = 5, /// /// The drive is a RAM disk. /// DRIVE_RAMDISK = 6 } /// /// This class contains information about this computer /// public class Computer { /// /// Return the manufacturer hard drive serial number /// /// Drive to fetch serial number from /// Hard drive serial number public static string GetHardDriveSerial(char drive) { // call into Win32 uint serNum = 0; uint maxCompLen = 0; StringBuilder VolLabel = new StringBuilder(256); // Label UInt32 VolFlags = new UInt32(); StringBuilder FSName = new StringBuilder(256); // File System Name string strDriveLetter = drive + ":\\"; // fix up the passed-in drive letter for the API call long Ret = GetVolumeInformation(strDriveLetter, VolLabel, (UInt32)VolLabel.Capacity, ref serNum, ref maxCompLen, ref VolFlags, FSName, (UInt32)FSName.Capacity); if ( Ret == 0 ) { return null; // not found } return Convert.ToString(serNum); } [DllImport("kernel32.dll")] private static extern long GetVolumeInformation( string PathName, StringBuilder VolumeNameBuffer, UInt32 VolumeNameSize, ref UInt32 VolumeSerialNumber, ref UInt32 MaximumComponentLength, ref UInt32 FileSystemFlags, StringBuilder FileSystemNameBuffer, UInt32 FileSystemNameSize); /// /// Return a list of logical harddrives /// /// list of string ("c:\\","d:\\") public static string [] GetFixedHardDrives() { string [] drives = GetDrives(); ArrayList array = new ArrayList(drives.Length); for (int i = 0; i < drives.Length; i++ ) { // drive found. List only the hard drives (no cdrom, no network) if ( GetDriveType(drives[i]) == DriveType.DRIVE_FIXED ) { // hdd => store array.Add(drives[i]); } } // build up result array string [] logical_drives = new string[array.Count]; array.CopyTo(logical_drives,0); return logical_drives; } /// /// Return a complete list of used drives in this machine /// (without necessarily all the used network drives) /// /// list of string ("a:\","c:\\","d:\\") public static string [] GetDrives() { ArrayList array = new ArrayList(17); // call in the Win32 API int drives = GetLogicalDrives(); int test = 1; string rootPath; for (int i = 0; i < 16; i++, test<<=1 ) { if ( (drives & test) > 0 ) { rootPath = (char)('A'+i) + ":\\"; array.Add(rootPath); } } // build up result array string [] logical_drives = new string[array.Count]; array.CopyTo(logical_drives,0); return logical_drives; } /// /// Get the logical disk drives as a 16 bit bitmask /// [DllImport("kernel32.dll")] private static extern int GetLogicalDrives(); /// /// Get the type of a drive /// /// rootPath is on the form: "c:\\" [DllImport("kernel32.dll")] private static extern DriveType GetDriveType(string rootPathName); /// /// Gets the list of all unused drives /// public static string [] GetUnusedDrives() { string [] shares = GetNetworkDrives(); string [] drives = GetDrives(); ArrayList items = new ArrayList(); for (int i = 0; i <= (int)('Z'-'A'); i++ ) { string drive = (char)('A'+i)+":\\"; bool found = false; for (int j = 0; j < drives.Length; j++ ) { if ( drives[j].StartsWith(drive) ) { found = true; break; } continue; } if ( found ) continue; for (int j = 0; j < shares.Length;j++ ) { if ( shares[j].StartsWith(drive) ) { found = true; break; } } if ( found ) continue; items.Add(drive); } string [] list = new string[items.Count]; items.CopyTo(list); return list; } /// /// Prepare a system call for enumerating the network drives /// [DllImport("mpr.dll", CharSet=CharSet.Auto)] private static extern int WNetOpenEnum( RESOURCE_SCOPE dwScope, RESOURCE_TYPE dwType, RESOURCE_USAGE dwUsage, [MarshalAs(UnmanagedType.AsAny)][In] Object lpNetResource, out IntPtr lphEnum); /// /// Enumerate all the network resouces currently being used /// [DllImport("mpr.dll", CharSet=CharSet.Auto)] private static extern int WNetEnumResource( IntPtr hEnum, ref int lpcCount, IntPtr lpBuffer, ref int lpBufferSize ); /// /// Release resources used when enumerating the network drives /// [DllImport("mpr.dll", CharSet=CharSet.Auto)] private static extern int WNetCloseEnum( IntPtr hEnum ); /// /// Scope of the enumeration /// private enum RESOURCE_SCOPE { /// /// Enumerate all currently connected resources. /// The function ignores the dwUsage parameter. /// For more information, see the following Remarks section. /// RESOURCE_CONNECTED = 0x00000001, /// /// Enumerate only resources in the network context of the caller. /// Specify this value for a Network Neighborhood view. /// The function ignores the dwUsage parameter. /// RESOURCE_GLOBALNET = 0x00000002, /// /// Enumerate all resources on the network /// RESOURCE_REMEMBERED = 0x00000003, /// /// Enumerate all remembered (persistent) connections. /// The function ignores the dwUsage parameter. /// RESOURCE_RECENT= 0x00000004, /// /// All connected and recond connections /// RESOURCE_CONTEXT= 0x00000005 } /// /// Resource types to be enumerated /// private enum RESOURCE_TYPE { /// /// All resources. /// This value cannot be combined with RESOURCETYPE_DISK or RESOURCETYPE_PRINT. /// RESOURCETYPE_ANY= 0x00000000, /// /// All disk resources /// RESOURCETYPE_DISK= 0x00000001, /// /// All print resources /// RESOURCETYPE_PRINT = 0x00000002, /// /// Reserved by windows /// RESOURCETYPE_RESERVED = 0x00000008, } /// /// Resource usage type to be enumerated /// private enum RESOURCE_USAGE { /// /// All resources /// RESOURCEUSAGE_ALL = 0, /// /// All connectable resources /// RESOURCEUSAGE_CONNECTABLE =0x00000001, /// /// All container resources /// RESOURCEUSAGE_CONTAINER=0x00000002, /// /// need doc. /// RESOURCEUSAGE_NOLOCALDEVICE =0x00000004, /// /// need doc. /// RESOURCEUSAGE_SIBLING=0x00000008, /// /// Setting this value forces WNetOpenEnum to fail if the user is not authenticated. /// The function fails even if the network allows enumeration without authentication /// RESOURCEUSAGE_ATTACHED=0x00000010, /// /// All resources that are connectable, container and attached, /// RESOURCEUSAGE_ALL_LOCAL =(RESOURCEUSAGE_CONNECTABLE | RESOURCEUSAGE_CONTAINER | RESOURCEUSAGE_ATTACHED), } // private enum RESOURCE_DISPLAYTYPE { // RESOURCEDISPLAYTYPE_GENERIC= 0x00000000, // RESOURCEDISPLAYTYPE_DOMAIN= 0x00000001, // RESOURCEDISPLAYTYPE_SERVER= 0x00000002, // RESOURCEDISPLAYTYPE_SHARE= 0x00000003, // RESOURCEDISPLAYTYPE_FILE = 0x00000004, // RESOURCEDISPLAYTYPE_GROUP= 0x00000005, // RESOURCEDISPLAYTYPE_NETWORK= 0x00000006, // RESOURCEDISPLAYTYPE_ROOT = 0x00000007, // RESOURCEDISPLAYTYPE_SHAREADMIN = 0x00000008, // RESOURCEDISPLAYTYPE_DIRECTORY = 0x00000009, // RESOURCEDISPLAYTYPE_TREE = 0x0000000A, // RESOURCEDISPLAYTYPE_NDSCONTAINER = 0x0000000B // } /// /// The NETRESOURCE structure contains information about a network resource. /// The structure is returned during enumeration of network resources. /// NETRESOURCE is also specified when making or querying a network /// connection with calls to various Windows Networking functions. /// [StructLayout(LayoutKind.Sequential, Pack=1)] private struct NETRESOURCE { /// /// Scope of the enumeration /// public RESOURCE_SCOPE dwScope; /// /// Set of bit flags identifying the type of resource /// public RESOURCE_TYPE dwType; /// /// Display options for the network object in a network browsing user interface /// public int dwDisplayType; // RESOURCE_DISPLAYTYPE /// /// Set of bit flags describing how the resource can be used. /// Note that this member can be specified only /// if the dwScope member is equal to RESOURCE_GLOBALNET /// public RESOURCE_USAGE dwUsage; /// /// If the dwScope member is equal to RESOURCE_CONNECTED or RESOURCE_REMEMBERED, /// this member is a pointer to a null-terminated character string /// that specifies the name of a local device. /// This member is NULL if the connection does not use a device. /// [MarshalAs(System.Runtime.InteropServices.UnmanagedType.LPTStr)] public string lpLocalName; /// /// If the entry is a network resource, this member is a pointer to /// a null-terminated character string that specifies the remote network name.

///

/// If the entry is a current or persistent connection, /// lpRemoteName points to the network name associated with the name pointed to by the lpLocalName member.

///

/// The string can be MAX_PATH characters in length, /// and it must follow the network provider's naming conventions /// [MarshalAs(System.Runtime.InteropServices.UnmanagedType.LPTStr)] public string lpRemoteName; /// /// Pointer to a null-terminated string that contains a comment supplied by the network provider /// [MarshalAs(System.Runtime.InteropServices.UnmanagedType.LPTStr)] public string lpComment; /// /// Pointer to a null-terminated string that contains the name of the provider /// that owns the resource. This member can be NULL if the provider name is unknown. /// To retrieve the provider name, you can call the WNetGetProviderName function /// [MarshalAs(System.Runtime.InteropServices.UnmanagedType.LPTStr)] public string lpProvider; } /// /// Gets a list of all network drives currently connected /// in the form "M: \\server\share" /// public static string [] GetNetworkDrives() { return GetNetworkDrives(null); } /// /// Gets a list of all network drives currently connected /// in the form "M: \\server\share" /// private static string [] GetNetworkDrives(object rootObject) { ArrayList shares = new ArrayList(); try { int iRet; IntPtr enumHandle; // prepare the call to win32 iRet =WNetOpenEnum( RESOURCE_SCOPE.RESOURCE_CONNECTED, RESOURCE_TYPE.RESOURCETYPE_DISK, RESOURCE_USAGE.RESOURCEUSAGE_ALL, rootObject, out enumHandle ); if( iRet != 0 ) { return new string[0]; } // ok, list all entries int bufferLen = 16384; IntPtr ptrBuffer = Marshal.AllocHGlobal( bufferLen ); while ( true ) { int entries = -1; bufferLen = 16384; // list as many as we can in one go iRet =WNetEnumResource( enumHandle, ref entries, ptrBuffer, ref bufferLen ); if( (iRet != 0) || (entries < 1) ) { break; } // found a buch Int32 ptr = ptrBuffer.ToInt32(); // list them all for( int i = 0; i < entries; i++ ) { NETRESOURCE nr = (NETRESOURCE)Marshal.PtrToStructure( new IntPtr(ptr), typeof(NETRESOURCE) ); if( RESOURCE_USAGE.RESOURCEUSAGE_CONTAINER == (nr.dwUsage & RESOURCE_USAGE.RESOURCEUSAGE_CONTAINER) ) { // call recursively to get all entries in a container shares.AddRange(GetNetworkDrives(nr)); } ptr += Marshal.SizeOf( nr ); string share = string.Format("{0}\\ {1}",nr.lpLocalName,nr.lpRemoteName); shares.Add(share); } } Marshal.FreeHGlobal( ptrBuffer ); // release resources WNetCloseEnum( enumHandle ); } catch(Exception ) { } // build up result array string [] shares_list = new string[shares.Count]; shares.CopyTo(shares_list,0); return shares_list; } /// /// Force a reboot of the computer /// public static void Reboot() { DoExitWin( EWX.REBOOT | EWX.FORCEIFHUNG ); } /// /// Force a shutdown of the computer /// public static void ShutDown() { DoExitWin( EWX.POWEROFF | EWX.FORCE ); } /// /// retrieves a pseudo handle for the current process /// [DllImport("kernel32.dll", ExactSpelling=true) ] private static extern IntPtr GetCurrentProcess(); /// /// opens the access token associated with a process /// [DllImport("advapi32.dll", ExactSpelling=true, SetLastError=true) ] private static extern bool OpenProcessToken( IntPtr h, int acc, ref IntPtr phtok ); /// /// Retrieves the locally unique identifier (LUID) used on a specified system /// to locally represent the specified privilege name. /// [DllImport("advapi32.dll", SetLastError=true) ] private static extern bool LookupPrivilegeValue( string host, string name, ref long pluid ); /// /// enables or disables privileges in the specified access token. /// Enabling or disabling privileges in an access token requires TOKEN_ADJUST_PRIVILEGES access /// [DllImport("advapi32.dll", ExactSpelling=true, SetLastError=true) ] private static extern bool AdjustTokenPrivileges( IntPtr htok, bool disall, ref TokPriv1Luid newst, int len, IntPtr prev, IntPtr relen ); /// /// The ExitWindowsEx function either logs off the current user, shuts down the system, /// or shuts down and restarts the system.

/// It sends the WM_QUERYENDSESSION message to all applications to determine if they can be terminated. /// [DllImport("user32.dll", ExactSpelling=true, SetLastError=true) ] private static extern bool ExitWindowsEx( int flg, int rea ); /// /// Contains information about a set of privileges for an access token. /// [StructLayout(LayoutKind.Sequential, Pack=1)] private struct TokPriv1Luid { public int Count; public long Luid; public int Attr; } [Flags] private enum EWX { /// /// Shuts down all processes running in the logon session of the process that /// called the ExitWindowsEx function. Then it logs the user off.

/// This flag can be used only by processes running in an interactive user's logon session. /// LOGOFF = 0x00000000, /// /// Shuts down the system to a point at which it is safe to turn off the power. /// All file buffers have been flushed to disk, and all running processes have stopped.

/// The calling process must have the SE_SHUTDOWN_NAME privilege.

/// Specifying this flag will not turn off the power even if the system supports the power-off feature. /// You must specify EWX_POWEROFF to do this. /// SHUTDOWN = 0x00000001, /// /// Shuts down the system and then restarts the system. /// The calling process must have the SE_SHUTDOWN_NAME privilege. /// REBOOT = 0x00000002, /// /// Forces processes to terminate. /// When this flag is set, the system does not send the WM_QUERYENDSESSION /// and WM_ENDSESSION messages. This can cause the applications to lose data. /// Therefore, you should only use this flag in an emergency.

/// Starting with Windows XP, these messages will always be sent. /// FORCE = 0x00000004, /// /// Shuts down the system and turns off the power. The system must support the power-off feature. /// The calling process must have the SE_SHUTDOWN_NAME privilege. /// POWEROFF = 0x00000008, /// /// Forces processes to terminate if they do not respond to the /// WM_QUERYENDSESSION or WM_ENDSESSION message within the timeout interval /// FORCEIFHUNG = 0x00000010 } /// /// Exit windows a way or another, as indicated by the flags /// private static void DoExitWin( EWX flag ) { // some flags int SE_PRIVILEGE_ENABLED = 0x00000002; int TOKEN_QUERY = 0x00000008; int TOKEN_ADJUST_PRIVILEGES = 0x00000020; string SE_SHUTDOWN_NAME = "SeShutdownPrivilege"; // lets go bool ok; TokPriv1Luid tp; // get the current process handle IntPtr hproc = GetCurrentProcess(); // get access tokens IntPtr htok = IntPtr.Zero; ok = OpenProcessToken( hproc, TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, ref htok ); tp.Count = 1; tp.Luid = 0; tp.Attr = SE_PRIVILEGE_ENABLED; // lookup to see if we're allowed to shutdown this computer ok = LookupPrivilegeValue( null, SE_SHUTDOWN_NAME, ref tp.Luid ); ok = AdjustTokenPrivileges( htok, false, ref tp, 0, IntPtr.Zero, IntPtr.Zero ); // perform operation ok = ExitWindowsEx( (int)flag, 0 ); } } -----Original Message----- From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Miguel de Icaza Sent: Monday, December 03, 2007 5:04 PM To: Javier Mart?n Cc: mono-devel-list at lists.ximian.com Subject: Re: [Mono-dev] DriveInfo implementation Hello, > I would like to help in the implementation of the System.IO.DriveInfo > class, which as of now is semi-functional in Linux and little more > than a stub in Windows. However, after thinking a bit about it, I've > come to the conclusion that the methods that discover the volumes in > the system (*GetDrives) require P/Invoke at the very least (windows), > and possibly even unmanaged code (linux). Correct, for Windows we should use P/Invokes. For Linux, the current "trivial" implementation is enough, a more complete implementation probably should talk with DBus to Hal, but am unsure about that. For Unix, a full solution probably needs to use Mono.Posix to get the file system information (notice that information about actual devices is hard to obtain in Linux, unless we use something like Hal). > The point of this message is asking for directions and rules on this > matter. Is unmanaged code (at all) allowed? Can I create a portable > "interface" (not necessarily a .NET interface) and then a separated, > system-dependant implementation? How are those platform-dependant > switches managed in the Mono autoconf files? Etcetera. I believe that for the Windows case, you could get away with P/Invoke, we have used glue in the past, see the mono/support directory, it contains plenty of portability glue. > I would appreciate any pointers on the matter. > > Habbit > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From lordhabbit at gmail.com Mon Dec 3 20:22:59 2007 From: lordhabbit at gmail.com (=?UTF-8?Q?Javier_Mart=C3=ADn?=) Date: Tue, 4 Dec 2007 02:22:59 +0100 Subject: [Mono-dev] DriveInfo implementation In-Reply-To: <1196730244.3977.71.camel@erandi.boston.ximian.com> References: <1196730244.3977.71.camel@erandi.boston.ximian.com> Message-ID: Hi again, 2007/12/4, Miguel de Icaza : > Hello, > > > I would like to help in the implementation of the System.IO.DriveInfo > > class, which as of now is semi-functional in Linux and little more > > than a stub in Windows. However, after thinking a bit about it, I've > > come to the conclusion that the methods that discover the volumes in > > the system (*GetDrives) require P/Invoke at the very least (windows), > > and possibly even unmanaged code (linux). > > Correct, for Windows we should use P/Invokes. > > For Linux, the current "trivial" implementation is enough, a more > complete implementation probably should talk with DBus to Hal, but am > unsure about that. It's not enough for me, as I need to get the free space in the FS. That's how I found out that this class is incomplete, and, after seeing that it had been so for a long time, decided to volunteer on it. > > For Unix, a full solution probably needs to use Mono.Posix to get the > file system information (notice that information about actual devices is > hard to obtain in Linux, unless we use something like Hal). Hmm... You should be right about most unices, but I don't see the reason info would be hard to obtain in Linux - AFAIK it supports the statvfs(2) POSIX syscall, which df uses to get the FS data. I think it should provide most, if not all of the info needed. Besides, it's already in Mono.Posix.Native, so the code changes would probably not be too invasive. There _could_ be problems with esoteric (and not so strange) unices, as the massive display of #ifdefs in the GNU coreutils fsusage.[hc] shows, but, most probably it shouldn't be so tough for just Linux and BSD. > > > The point of this message is asking for directions and rules on this > > matter. Is unmanaged code (at all) allowed? Can I create a portable > > "interface" (not necessarily a .NET interface) and then a separated, > > system-dependant implementation? How are those platform-dependant > > switches managed in the Mono autoconf files? Etcetera. > > I believe that for the Windows case, you could get away with P/Invoke, > we have used glue in the past, see the mono/support directory, it > contains plenty of portability glue. I will look further into it, thanks for the $address. However, even when I can use P/Invoke, shouldn't it be separated from the platform-independent code by an interface? > > > I would appreciate any pointers on the matter. > > > > Habbit > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From pablosantosluac at terra.es Tue Dec 4 03:32:48 2007 From: pablosantosluac at terra.es (pablosantosluac) Date: Tue, 4 Dec 2007 09:32:48 +0100 Subject: [Mono-dev] The best way to secure remoting? References: <0a0401c835ec$ede486b0$6a28a00a@beardtongue> Message-ID: <0b2d01c83650$40ce3ac0$6a28a00a@beardtongue> Thanks for your answer Robert. The problem is that I can't host my objects on XSP (plasticd is actually a service or a daemon, but not a hosted XSP) neither use SOAP (performance!)... pablo ----- Original Message ----- From: "Robert Jordan" To: Sent: Monday, December 03, 2007 10:35 PM Subject: Re: [Mono-dev] The best way to secure remoting? > pablosantosluac wrote: >> Hi there, >> >> AFAIK with .net 2.0 SSL is an standard channel, isn't it? > > No, in MS.NET 2.0 it is based on NegotiateStream that uses > whichever authentication and encryption Windows SSPI dictates. > See MSDN. > >> But my question is: if I want to keep the mono-1.0 profile... what's the >> best way to secure remoting communication? > > Host your remoting objects in XSP and use HttpChannel + SOAP formatter > over SSL. > > Robert > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From miguel at novell.com Tue Dec 4 06:51:28 2007 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 04 Dec 2007 06:51:28 -0500 Subject: [Mono-dev] DriveInfo implementation In-Reply-To: References: <1196730244.3977.71.camel@erandi.boston.ximian.com> Message-ID: <1196769088.4491.7.camel@erandi.boston.ximian.com> > > For Linux, the current "trivial" implementation is enough, a more > > complete implementation probably should talk with DBus to Hal, but am > > unsure about that. > > It's not enough for me, as I need to get the free space in the FS. > That's how I found out that this class is incomplete, and, after > seeing that it had been so for a long time, decided to volunteer on > it. Ah, I see. > Hmm... You should be right about most unices, but I don't see the > reason info would be hard to obtain in Linux - AFAIK it supports the > statvfs(2) POSIX syscall, which df uses to get the FS data. I think it > should provide most, if not all of the info needed. Besides, it's > already in Mono.Posix.Native, so the code changes would probably not > be too invasive. If Mono.Posix has it, that seems to be enough. > There _could_ be problems with esoteric (and not so strange) unices, > as the massive display of #ifdefs in the GNU coreutils fsusage.[hc] > shows, but, most probably it shouldn't be so tough for just Linux and > BSD. Correct. In my opinion, this needs some "glue" support in C, to have the C compiler assist us when we port to an OS that has different fields (as you noticed fsusage.[hc] has that). I do not know if Mono.Posix today does it, if it already does, then we are set to go > I will look further into it, thanks for the $address. However, even > when I can use P/Invoke, shouldn't it be separated from the > platform-independent code by an interface? Not needed, just use an if based on the platform. Miguel From miguel at novell.com Tue Dec 4 06:52:22 2007 From: miguel at novell.com (Miguel de Icaza) Date: Tue, 04 Dec 2007 06:52:22 -0500 Subject: [Mono-dev] DriveInfo implementation In-Reply-To: <00b501c83613$bbcfdea0$6647a8c0@tfbc.com> References: <00b501c83613$bbcfdea0$6647a8c0@tfbc.com> Message-ID: <1196769142.4491.10.camel@erandi.boston.ximian.com> > I can help here. I had to do this a few years ago for windows. This is very > complete (we use it in production). Some of this code has been inspired from > snippets in the internet. I can't remember where from though. Are you able to license the code below under the MIT X11 license? If the code is based on snippets on the Internet, I wonder if the original authors would object to their code being labeled with the MIT X11 license. Miguel From emperon at gmail.com Tue Dec 4 07:32:45 2007 From: emperon at gmail.com (Onur Gumus) Date: Tue, 4 Dec 2007 14:32:45 +0200 Subject: [Mono-dev] System.DllNotFoundException gtksharpglue-2 in mono 1.2.6 In-Reply-To: <003501c83613$8884eb30$4765a8c0@whitebook> References: <003501c83613$8884eb30$4765a8c0@whitebook> Message-ID: <8a7a2d050712040432p173608b0me20aee20c2bf094@mail.gmail.com> Follow this guide step by step and you will be fine. For ubuntu you must have two mono's This is inescapable. You have to use them in parallel http://www.mono-project.com/Parallel_Mono_Environments On Dec 4, 2007 3:18 AM, Vladimir Dimitrov wrote: > Hi folks, > > is there something that I am missing here? I have a GTK# based > application and I am trying to use the latest mono version (1.2.6.1) from > the generic installer. I searched in Google about that issue but all I get > are very old problems that should not be the case now. I see that on the > mono page it is stated that the Gtk-sharp package is an "optional" package, > but as far as I remember it used to be included in the generic installer and > so it is right now. Can somebody point me to what I am missing and what is > the easiest way to install the newest mono on a clean Linux machine (for > example Ubuntu 7.10) with GTK# support. > > > > Thanks > > Vladimir Dimitrov > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071204/6504c57a/attachment.html From vlad.dimitrov at gmail.com Tue Dec 4 07:38:00 2007 From: vlad.dimitrov at gmail.com (Vladimir Dimitrov) Date: Tue, 4 Dec 2007 14:38:00 +0200 Subject: [Mono-dev] System.DllNotFoundException gtksharpglue-2 in mono 1.2.6 In-Reply-To: <8a7a2d050712040432p173608b0me20aee20c2bf094@mail.gmail.com> References: <003501c83613$8884eb30$4765a8c0@whitebook> <8a7a2d050712040432p173608b0me20aee20c2bf094@mail.gmail.com> Message-ID: <003301c83672$82ac4a00$4065a8c0@whitebook> Yes I have two mono installations but the paths are setup to use the new installation. The problem is that 'gtksharpglue-2' is only present in the old installation that comes with Ubuntu and when the paths start to point at the new location there is no such library. _____ From: Onur Gumus [mailto:emperon at gmail.com] Sent: Tuesday, December 04, 2007 2:33 PM To: Vladimir Dimitrov; monodevlist Subject: Re: [Mono-dev] System.DllNotFoundException gtksharpglue-2 in mono 1.2.6 Follow this guide step by step and you will be fine. For ubuntu you must have two mono's This is inescapable. You have to use them in parallel http://www.mono-project.com/Parallel_Mono_Environments On Dec 4, 2007 3:18 AM, Vladimir Dimitrov wrote: Hi folks, is there something that I am missing here? I have a GTK# based application and I am trying to use the latest mono version (1.2.6.1) from the generic installer. I searched in Google about that issue but all I get are very old problems that should not be the case now. I see that on the mono page it is stated that the Gtk-sharp package is an "optional" package, but as far as I remember it used to be included in the generic installer and so it is right now. Can somebody point me to what I am missing and what is the easiest way to install the newest mono on a clean Linux machine (for example Ubuntu 7.10) with GTK# support. Thanks Vladimir Dimitrov _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071204/0f87d44b/attachment.html From robertj at gmx.net Tue Dec 4 08:14:50 2007 From: robertj at gmx.net (Robert Jordan) Date: Tue, 04 Dec 2007 14:14:50 +0100 Subject: [Mono-dev] DriveInfo implementation In-Reply-To: References: Message-ID: Javier Mart?n wrote: > Hi all, > > I would like to help in the implementation of the System.IO.DriveInfo > class, which as of now is semi-functional in Linux and little more > than a stub in Windows. However, after thinking a bit about it, I've > come to the conclusion that the methods that discover the volumes in > the system (*GetDrives) require P/Invoke at the very least (windows), > and possibly even unmanaged code (linux). This is already implemented: Environment.GetLogicalDrives (). > The point of this message is asking for directions and rules on this > matter. Is unmanaged code (at all) allowed? Can I create a portable > "interface" (not necessarily a .NET interface) and then a separated, > system-dependant implementation? How are those platform-dependant > switches managed in the Mono autoconf files? Etcetera. Just follow the trails of Environment.GetLogicalDrives ()'s implementation. You'll find out it is an internal call, implemented in mono/metadata/icall.c, based on GetLogicalDriveStrings, a Windows API. On Unix, this API is emulated in mono/io-layer/. This is the place you can add other I/O related Windows API calls you might need to complete DriveInfo. Robert From robertj at gmx.net Tue Dec 4 10:01:17 2007 From: robertj at gmx.net (Robert Jordan) Date: Tue, 04 Dec 2007 16:01:17 +0100 Subject: [Mono-dev] The best way to secure remoting? In-Reply-To: <0b2d01c83650$40ce3ac0$6a28a00a@beardtongue> References: <0a0401c835ec$ede486b0$6a28a00a@beardtongue> <0b2d01c83650$40ce3ac0$6a28a00a@beardtongue> Message-ID: pablosantosluac wrote: > Thanks for your answer Robert. > > The problem is that I can't host my objects on XSP (plasticd is actually a > service or a daemon, but not a hosted XSP) neither use SOAP > (performance!)... I see. You could make a copy of TcpChannel and change it to encrypt the data. Since TcpChannel already has a connection pool, it should be already well prepared for SSL. Two days of work, I'd guess. Unfortunately, the remoting infrastructure is not flexible enough to allow other solutions. One could be deluded to implement encryption as a channel sink, but this is really suboptimal because you don't have sessions at this layer. W/out sessions, SSL (and any other symmetric encryption that needs an asymmetric key exchange phase) will be extremely slow. Robert > > > pablo > > > ----- Original Message ----- > From: "Robert Jordan" > To: > Sent: Monday, December 03, 2007 10:35 PM > Subject: Re: [Mono-dev] The best way to secure remoting? > > >> pablosantosluac wrote: >>> Hi there, >>> >>> AFAIK with .net 2.0 SSL is an standard channel, isn't it? >> No, in MS.NET 2.0 it is based on NegotiateStream that uses >> whichever authentication and encryption Windows SSPI dictates. >> See MSDN. >> >>> But my question is: if I want to keep the mono-1.0 profile... what's the >>> best way to secure remoting communication? >> Host your remoting objects in XSP and use HttpChannel + SOAP formatter >> over SSL. >> >> Robert >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.co