From lupus at ximian.com Wed Jan 2 10:24:34 2008 From: lupus at ximian.com (Paolo Molaro) Date: Wed, 2 Jan 2008 16:24:34 +0100 Subject: [Mono-dev] Control-C handler In-Reply-To: <31c001c8436d$b00c9510$0702a8c0@beardtongue> References: <1198179705.4430.116.camel@lina.magi.jprl.com> <31c001c8436d$b00c9510$0702a8c0@beardtongue> Message-ID: <20080102152434.GX5889@debian.org> On 12/21/07 pablosantosluac wrote: > Ok, I think I got a bit lost here... how should I proceed then? There is no guarantee that you can hook to signal handlers from C#, we don't support that usage and its inclusion in Mono.Posix is a mistake. I'm actually going to add code to mono to detect such unsupported uses so we can flag error reports from applications that hook signal handlers as unusable and we can discard them. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From apenwarr at gmail.com Wed Jan 2 11:10:30 2008 From: apenwarr at gmail.com (Avery Pennarun) Date: Wed, 2 Jan 2008 11:10:30 -0500 Subject: [Mono-dev] Control-C handler In-Reply-To: <20080102152434.GX5889@debian.org> References: <1198179705.4430.116.camel@lina.magi.jprl.com> <31c001c8436d$b00c9510$0702a8c0@beardtongue> <20080102152434.GX5889@debian.org> Message-ID: <32541b130801020810m53ddbc8blbc3aeb1be5e8c3d7@mail.gmail.com> On 02/01/2008, Paolo Molaro wrote: > On 12/21/07 pablosantosluac wrote: > > Ok, I think I got a bit lost here... how should I proceed then? > > There is no guarantee that you can hook to signal handlers > from C#, we don't support that usage and its inclusion in Mono.Posix is > a mistake. > I'm actually going to add code to mono to detect such unsupported uses > so we can flag error reports from applications that hook signal handlers > as unusable and we can discard them. Surely there must be *some* way to handle signals from inside a mono app? This seems like a huge omission. Even perl can do it! (http://search.cpan.org/~lbaxter/Sys-SigAction-0.10/lib/Sys/SigAction.pm) Have fun, Avery From ClassDevelopment at A-SoftTech.com Wed Jan 2 11:24:58 2008 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Wed, 2 Jan 2008 17:24:58 +0100 Subject: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited In-Reply-To: References: <1199036057.4400.10.camel@funnyfarm.hotfeet.ch> Message-ID: <8C1DC99174C541A7BD5DE875FAE6B2E0@ansirua> The array initialization should also be done lazily and not in the static constructor (should be removed completely because it drags in other static fields that need to be preinitialized, code compiled and so on). Especially the Hex support is IMHO completely off bounds. I (personally) rarely see hex output and making EVERYBODY pay for a hex speedup doesn't seem right. A simple if (array == null) Init (); will be enough. You will pay per-call, but it is relatively cheap. Otherwise a single Console.WriteLine (1.ToString()); will get an EXTREMELY slow operation when you need to init a whole array just for a (potentially) single conversion. Greetings Andreas -----Urspr?ngliche Nachricht----- Von: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag von Eyal Alaluf Gesendet: Montag, 31. Dezember 2007 13:24 An: Juraj Skripsky; Atsushi Eno Cc: Miguel de Icaza; mono-devel-list at lists.ximian.com Betreff: [SPAM] Re: [Mono-dev] ToString() performace in Mono revisited Hi, all. Thanks for the feedback. The amount of used memory is indeed not appropriate for small devices and is not economic enough. The 'DblExpTab' is essential in order for the double ToString to be efficient. As for the other two arrays they cache a simple arithmetic caclcualtion. I'll therefore eliminate the '_decHexLen' array and use static readonly int[] _decHexDigits = new int [100]; I'll make DblRep into a struct and remove one member out of it (and slightly improve the double.ToString() perf along the way). This will change the allocation size to 100 * 4 + 2048 * (3 * 4) = ~25K. The performance impact is betweek 3-10% overall for simple ToString() depending on the hardware. Eyal. -----Original Message----- From: Juraj Skripsky [mailto:js at hotfeet.ch] Sent: 30 December 2007 19:34 To: Atsushi Eno Cc: Eyal Alaluf; Miguel de Icaza; mono-devel-list at lists.ximian.com Subject: Re: [Mono-dev] ToString() performace in Mono revisited Hello, I think the following two arrays account for most of those 300KB: static readonly int[] _decHexDigits = new int [10000]; static readonly int[] _decHexLen = new int [0x10000]; The first one consumes almost 40KB, the second one 256KB... The "DblExpTab" array uses 2048 * 4 = 8KB and its referenced DblRep objects 2048 * (8 + 4 * 4) = 48KB. This means a total of 56KB. Turning DblExbTab into a struct would reduce this to 2048 * (4 * 4) = 32KB. - Juraj On Mon, 2007-12-31 at 00:19 +0900, Atsushi Eno wrote: > Hello, > > Kazuki pointed out that the static initialization part of > NumberFormatter allocates 300KB. It is probably here: > > public static readonly DblRep[] DblExpTab = new DblRep [ExponentMax + 1]; > > It does not look good. > > Atsushi Eno > > > Eyal Alaluf wrote: > > > > > > With the attchments zipped to reduce size. > > > > > > > > * From: * mono-devel-list-bounces at lists.ximian.com > > [mailto:mono-devel-list-bounces at lists.ximian.com] *On Behalf Of *Eyal Alaluf > > *Sent:* 27 December 2007 17:28 > > *To:* mono-devel-list at lists.ximian.com > > *Cc:* Miguel de Icaza > > *Subject:* [Mono-dev] ToString() performace in Mono revisited > > > > > > > > I got complaints that the font color within the table is white so this > > is a resent J > > > > > > > > Hi, all. > > > > > > > > Attached is a redesigned implementation of the NumberFormatter class. > > The patch includes a new algorithm for float and double ToString > > implementation that improves performance by a factor of 25(!) and upto > > 440(!!!). The patch includes further improvements to integer /ToString/ > > as well as Andreas suggestion of avoiding calling > > /NumberFormatInfo.CurrentInfo/ in the case of integer types default > > /ToString()/ implementation. > > > > This patch should improve Mono's performance in important use cases such > > as web-services where primitive /ToString/ performance is an important > > factor. > > > > > > > > The following is a table showing the improvements for the different > > primitive types using the patch. All the results are in milliseconds and > > for a run of 10,000,000 iterations with warm-up of 10,000,000 iterations > > as well. > > > > > > > > > > > > > > > > Mono 1.2.6 > > > > > > > > Patch > > > > > > > > Improvement > > > > 12345.ToString("G") > > > > > > > > 10079 > > > > > > > > 7328 > > > > > > > > 1.37 > > > > 12345L.ToString("G")> > > > > > > 13203 > > > > > > > > 7297 > > > > > > > > 1.81 > > > > 0.12345.ToString("G") > > > > > > > > 323750 > > > > > > > > 13047 > > > > > > > > 24.8(!) > > > > 1.2345E-200.ToString("G") > > > > > > > > 6376500 > > > > > > > > 14328 > > > > > > > > 445(!!!) > > > > 0.12345m.ToString("G") > > > > > > > > 51078 > > > > > > > > 9875 > > > > > > > > 5.2 > > > > 12345.ToString() > > > > > > > > 12406/7781 > > > > > > > > 5687 > > > > > > > > 2.2/1.37 > > > > 12345L.ToString() > > > > > > > > > > 281090 > > > > > > > > 4006 > > > > > > > > 3897 > > > > > > > > 72.1(!!) > > > > > > > > 1.03 > > > > 1.2345E-200.ToString("G") > > > > > > > > 5686000 > > > > >12345.ToString("G")/!) and the second is after applying Andreas > > suggestion on top of Mono 1.2.6. > > > > > > > > The following are the results of the new algorithm compared to the old > > Mono algorithm and the .Net 2.0 native ToString performance, all three > > running on Microsoft .Net 2.0. The results show that the new code > > matches and even out-performs .Net /ToString/ implementation. > > > > > > > > > > > > Mono 1.2.6 algorithm > > > > > > > > Microsoft .Net 2.0 > > > > > > > > New Patch algorithm > > > > > > > > Improvement over Mono 1.2.6 > > > > > > > > Improvement over .Net 2.0 > > > > 12345.ToString("G") > > > > > > > > 3700 > > > > > > > > 2291 > > > > > > > > 1827 > > > > > > > > 2.0 > > > > > > > > 1.25 > > > > 12345L.ToString("G") > > > > > > > > 4559 > > > > > > > > 2242 > > > > > > > > 1919 > > > > > > > > 2.38 > > > > > > > > 1.17 > > > > 0.12345.ToString("G") > > > > > > > > 281090 > > > > > > > > 4006 > > > > > > > > 3897 > > > > > > > > 72.1(!!) > > > > > > > > 1.03 > > > > 1.2345E-200.ToString("G") > > > > > > > > 5686000 > > > > > > > > 4634 > > > > > > > > 4613 > > > > > > > > 1233(!!!) > > > > > > > > 1.00 > > > > 0.12345m.ToString("G") > > > > > > > > 14562 > > > > > > > > 3095 > > > > > > > > 2294 > > > > > > > > 6.3 > > > > > > > > 1.35 > > > > 12345.ToString() > > > > > > > > 3900/3002 > > > > > > > > 2344 > > > > > > > > 1313 > > > > > > > > 3.0/2.3 > > > > > > > > 1.79 > > > > 12345L.ToString() > > > > > > > > 4684/3823 > > > > > > > > 2245 > > > > > > > > 1383 > > > > > > > > 3.4/2.8 > > > > > > > > 1.62 > > > > > > > > It should be noted that the new code performance improvement are even > > more visible on top of .Net. > > > > It should also be noted that .Net runs the same algorithm 4 times faster > > then Mono. Since this code is self contained and almost completely > > algorithmic - I believe that it may serve as a good practical test case > > for improving Mono's JIT. > > > > > > > > The redesign is composed of three main changes > > > > * An O(1) arithmetic transformation of a double (composed of > > sign, 2's exponent and mantissa bits) to sign, long and 10's exponent. > > > > * Using a character array instead of a string buffer to construct > > the string result. > > > > * Representing the number digits using hexadecimal values. That > > is /12345/ will be represented by /0x12345/. > > > > > > > > The patch passes Mono's unit tests on both 1.1 and 2.0. > > > > > > > > Please review and provide us with your feedback as soon as possible. > > > > > > > > Sasha, Roei & Eyal. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 meebey at meebey.net Wed Jan 2 11:32:38 2008 From: meebey at meebey.net (Mirco Bauer) Date: Wed, 02 Jan 2008 17:32:38 +0100 Subject: [Mono-dev] Make use of --desktop and --server VM modes [was Re: ToString() performace in Mono revisited] In-Reply-To: References: <4777B6EB.3060801@ximian.com> <1199036057.4400.10.camel@funnyfarm.hotfeet.ch> <47784CCE.5090604@ximian.com> <1199104753.7849.18.camel@redbull.qnetp.net> Message-ID: <1199291558.6247.6.camel@redbull.qnetp.net> On Mon, 2007-12-31 at 14:44 +0100, Robert Jordan wrote: > Mirco Bauer wrote: > > On Mon, 2007-12-31 at 10:58 +0900, Atsushi Eno wrote: > >> Oops yes ;-) > >> > >> BTW Kazuki cooked patches to reduce those memory usage with little > >> cost: > >> > >> http://kserver.panicode.com/memo/2007/12/30/0 > >> (327KB -> 57KB) > > > > looking at those number like: > > CPU 9.3sec -> 31.5sec > > MEM 389KB -> 32KB > > > > gives me mixed feelings, it's the typical: use less memory needs more > > CPU scenario. > > Then you must be reading Japanese better than I do ;-) > Hint: scroll down to see the real results. Didn't notice that only the last measurement is the final one. > > > I still believe we should start optimizing both ends and using the > > --desktop and --server modes we already support but which we are not > > using yet. > > This is wrong, at least in the context of this mail. Those switches > will affect JIT compiler optimizations, whereas this mail is > about suboptimal implementation of ToString (). Even a ?ber-JIT > won't be able to turn a suboptimal algorithm into a good one. If the setting is exposed via an icall then managed can decide between 2 algorithms/implementations depending on the switch, one being more CPU friendly and the other more memory friendly. -- 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/20080102/8fbe3b11/attachment.bin From meebey at meebey.net Wed Jan 2 11:33:46 2008 From: meebey at meebey.net (Mirco Bauer) Date: Wed, 02 Jan 2008 17:33:46 +0100 Subject: [Mono-dev] Make use of --desktop and --server VM modes [was Re: ToString() performace in Mono revisited] In-Reply-To: <1199123633.4472.89.camel@erandi.boston.ximian.com> References: <4777B6EB.3060801@ximian.com> <1199036057.4400.10.camel@funnyfarm.hotfeet.ch> <47784CCE.5090604@ximian.com> <1199104753.7849.18.camel@redbull.qnetp.net> <1199123633.4472.89.camel@erandi.boston.ximian.com> Message-ID: <1199291626.6247.7.camel@redbull.qnetp.net> [resent to the mailing list as the MTA refused the email with an obscure "date in future" error, sems like the server is behind ;)] On Mon, 2007-12-31 at 12:53 -0500, Miguel de Icaza wrote: > Another option would be to expose the setting to class libraries, so the > class libraries could pick between two implementation. thats exactly was I was trying to point out :-P sorry for my bad explainations. > > But I feel uneasy about adding this sort of feature, because it would > basically create another column in matrix testing (we would then have to > test everything against both configurations). True, and it's difficult to test the performance of both modes as other things like JIT opts or other classes of the BCL influence the results. > > Am not sure that this extra source of potential errors is worth it at > this point. In this case I don't think either, now that I learned it's actually just 10% more CPU usage, which is acceptable compared to the memory savings of 10x. But sooner or later it might become useful to have 2 implementations. I just wanted to point out that the possibility exists to target both cases, CPU friendly or memory friendly using the VM mode switchs. -- 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/20080102/9d821831/attachment.bin From ClassDevelopment at A-SoftTech.com Wed Jan 2 11:37:51 2008 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Wed, 2 Jan 2008 17:37:51 +0100 Subject: [Mono-dev] [SPAM] Re: [PATCH] Implement support for .emitbyte directive onilasm In-Reply-To: <8cca42d80712301058o2ea2520lde3dc4244526173b@mail.gmail.com> References: <8cca42d80712301050h62d54616p9db9386c98a5250f@mail.gmail.com> <8cca42d80712301058o2ea2520lde3dc4244526173b@mail.gmail.com> Message-ID: <96D4A626610E4228B674B8CB4356E4FD@ansirua> Any reason why the class is named EmitByteIntr instead of EmitByteInstr ? _____ Von: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag von Rodrigo Kumpera Gesendet: Sonntag, 30. Dezember 2007 19:58 An: mono-devel-list at lists.ximian.com; Ankit Jain Betreff: [SPAM] Re: [Mono-dev] [PATCH] Implement support for .emitbyte directive onilasm Forgot to attach EmityteInst.cs. On Dec 30, 2007 4:50 PM, Rodrigo Kumpera wrote: The attached patch implements support for the .emitbyte directive. Please review it. Thanks, Rodrigo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080102/7d1b4a67/attachment.html From vladimirk at mainsoft.com Wed Jan 2 11:42:15 2008 From: vladimirk at mainsoft.com (Vladimir Krasnov) Date: Wed, 2 Jan 2008 08:42:15 -0800 Subject: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor Message-ID: Hello, Please review and approve attached patch for TypeDescriptor.GetProperties() method. This fixes the order of properties in the returning collection which is important for System.Web data bound controls. Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: TypeDescriptor.cs.patch Type: application/octet-stream Size: 767 bytes Desc: TypeDescriptor.cs.patch Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080102/4741cf6a/attachment.obj From kumpera at gmail.com Wed Jan 2 11:55:29 2008 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Wed, 2 Jan 2008 14:55:29 -0200 Subject: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited In-Reply-To: <8C1DC99174C541A7BD5DE875FAE6B2E0@ansirua> References: <1199036057.4400.10.camel@funnyfarm.hotfeet.ch> <8C1DC99174C541A7BD5DE875FAE6B2E0@ansirua> Message-ID: <8cca42d80801020855m6300d1c3ic2ec2cb208777217@mail.gmail.com> If the null test is not desired, a nested class can be used instead and the cctor trampoline will be patched later by the runtime. On Jan 2, 2008 2:24 PM, Andreas Nahr wrote: > The array initialization should also be done lazily and not in the static > constructor (should be removed completely because it drags in other static > fields that need to be preinitialized, code compiled and so on). > Especially the Hex support is IMHO completely off bounds. I (personally) > rarely see hex output and making EVERYBODY pay for a hex speedup doesn't > seem right. A simple > if (array == null) Init (); > will be enough. You will pay per-call, but it is relatively cheap. > Otherwise a single > Console.WriteLine (1.ToString()); > will get an EXTREMELY slow operation when you need to init a whole array > just for a (potentially) single conversion. > > Greetings > Andreas > > -----Urspr?ngliche Nachricht----- > Von: mono-devel-list-bounces at lists.ximian.com > [mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag von Eyal > Alaluf > Gesendet: Montag, 31. Dezember 2007 13:24 > An: Juraj Skripsky; Atsushi Eno > Cc: Miguel de Icaza; mono-devel-list at lists.ximian.com > Betreff: [SPAM] Re: [Mono-dev] ToString() performace in Mono revisited > > Hi, all. > > Thanks for the feedback. The amount of used memory is indeed not > appropriate > for small devices and is not economic enough. > > The 'DblExpTab' is essential in order for the double ToString to be > efficient. > As for the other two arrays they cache a simple arithmetic caclcualtion. > > I'll therefore eliminate the '_decHexLen' array and use > static readonly int[] _decHexDigits = new int [100]; I'll make DblRep > into > a struct and remove one member out of it (and slightly improve the > double.ToString() perf along the way). > This will change the allocation size to 100 * 4 + 2048 * (3 * 4) = ~25K. > > The performance impact is betweek 3-10% overall for simple ToString() > depending on the hardware. > > Eyal. > > -----Original Message----- > From: Juraj Skripsky [mailto:js at hotfeet.ch] > Sent: 30 December 2007 19:34 > To: Atsushi Eno > Cc: Eyal Alaluf; Miguel de Icaza; mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] ToString() performace in Mono revisited > > Hello, > > I think the following two arrays account for most of those 300KB: > > static readonly int[] _decHexDigits = new int [10000]; static readonly > int[] > _decHexLen = new int [0x10000]; > > The first one consumes almost 40KB, the second one 256KB... > > The "DblExpTab" array uses 2048 * 4 = 8KB and its referenced DblRep > objects > 2048 * (8 + 4 * 4) = 48KB. This means a total of 56KB. Turning DblExbTab > into a struct would reduce this to 2048 * (4 * 4) = 32KB. > > - Juraj > > > On Mon, 2007-12-31 at 00:19 +0900, Atsushi Eno wrote: > > Hello, > > > > Kazuki pointed out that the static initialization part of > > NumberFormatter allocates 300KB. It is probably here: > > > > public static readonly DblRep[] DblExpTab = new DblRep > [ExponentMax + 1]; > > > > It does not look good. > > > > Atsushi Eno > > > > > > Eyal Alaluf wrote: > > > > > > > > > With the attchments zipped to reduce size. > > > > > > > > > > > > * From: * mono-devel-list-bounces at lists.ximian.com > > > [mailto:mono-devel-list-bounces at lists.ximian.com] *On Behalf Of > *Eyal Alaluf > > > *Sent:* 27 December 2007 17:28 > > > *To:* mono-devel-list at lists.ximian.com > > > *Cc:* Miguel de Icaza > > > *Subject:* [Mono-dev] ToString() performace in Mono revisited > > > > > > > > > > > > I got complaints that the font color within the table is white so > this > > > is a resent J > > > > > > > > > > > > Hi, all. > > > > > > > > > > > > Attached is a redesigned implementation of the NumberFormatter > class. > > > The patch includes a new algorithm for float and double ToString > > > implementation that improves performance by a factor of 25(!) and > upto > > > 440(!!!). The patch includes further improvements to integer > /ToString/ > > > as well as Andreas suggestion of avoiding calling > > > /NumberFormatInfo.CurrentInfo/ in the case of integer types default > > > /ToString()/ implementation. > > > > > > This patch should improve Mono's performance in important use cases > such > > > as web-services where primitive /ToString/ performance is an > important > > > factor. > > > > > > > > > > > > The following is a table showing the improvements for the different > > > primitive types using the patch. All the results are in milliseconds > and > > > for a run of 10,000,000 iterations with warm-up of 10,000,000 > iterations > > > as well. > > > > > > > > > > > > > > > > > > > > > > > > Mono 1.2.6 > > > > > > > > > > > > Patch > > > > > > > > > > > > Improvement > > > > > > 12345.ToString("G") > > > > > > > > > > > > 10079 > > > > > > > > > > > > 7328 > > > > > > > > > > > > 1.37 > > > > > > 12345L.ToString("G")> > > > > > > > > > 13203 > > > > > > > > > > > > 7297 > > > > > > > > > > > > 1.81 > > > > > > 0.12345.ToString("G") > > > > > > > > > > > > 323750 > > > > > > > > > > > > 13047 > > > > > > > > > > > > 24.8(!) > > > > > > 1.2345E-200.ToString("G") > > > > > > > > > > > > 6376500 > > > > > > > > > > > > 14328 > > > > > > > > > > > > 445(!!!) > > > > > > 0.12345m.ToString("G") > > > > > > > > > > > > 51078 > > > > > > > > > > > > 9875 > > > > > > > > > > > > 5.2 > > > > > > 12345.ToString() > > > > > > > > > > > > 12406/7781 > > > > > > > > > > > > 5687 > > > > > > > > > > > > 2.2/1.37 > > > > > > 12345L.ToString() > > > > > > > > > > > > > > 281090 > > > > > > > > > > > > 4006 > > > > > > > > > > > > 3897 > > > > > > > > > > > > 72.1(!!) > > > > > > > > > > > > 1.03 > > > > > > 1.2345E-200.ToString("G") > > > > > > > > > > > > 5686000 > > > > > > > >12345.ToString("G")/!) and the second is after applying Andreas > > > suggestion on top of Mono 1.2.6. > > > > > > > > > > > > The following are the results of the new algorithm compared to the > old > > > Mono algorithm and the .Net 2.0 native ToString performance, all > three > > > running on Microsoft .Net 2.0. The results show that the new code > > > matches and even out-performs .Net /ToString/ implementation. > > > > > > > > > > > > > > > > > > Mono 1.2.6 algorithm > > > > > > > > > > > > Microsoft .Net 2.0 > > > > > > > > > > > > New Patch algorithm > > > > > > > > > > > > Improvement over Mono 1.2.6 > > > > > > > > > > > > Improvement over .Net 2.0 > > > > > > 12345.ToString("G") > > > > > > > > > > > > 3700 > > > > > > > > > > > > 2291 > > > > > > > > > > > > 1827 > > > > > > > > > > > > 2.0 > > > > > > > > > > > > 1.25 > > > > > > 12345L.ToString("G") > > > > > > > > > > > > 4559 > > > > > > > > > > > > 2242 > > > > > > > > > > > > 1919 > > > > > > > > > > > > 2.38 > > > > > > > > > > > > 1.17 > > > > > > 0.12345.ToString("G") > > > > > > > > > > > > 281090 > > > > > > > > > > > > 4006 > > > > > > > > > > > > 3897 > > > > > > > > > > > > 72.1(!!) > > > > > > > > > > > > 1.03 > > > > > > 1.2345E-200.ToString("G") > > > > > > > > > > > > 5686000 > > > > > > > > > > > > 4634 > > > > > > > > > > > > 4613 > > > > > > > > > > > > 1233(!!!) > > > > > > > > > > > > 1.00 > > > > > > 0.12345m.ToString("G") > > > > > > > > > > > > 14562 > > > > > > > > > > > > 3095 > > > > > > > > > > > > 2294 > > > > > > > > > > > > 6.3 > > > > > > > > > > > > 1.35 > > > > > > 12345.ToString() > > > > > > > > > > > > 3900/3002 > > > > > > > > > > > > 2344 > > > > > > > > > > > > 1313 > > > > > > > > > > > > 3.0/2.3 > > > > > > > > > > > > 1.79 > > > > > > 12345L.ToString() > > > > > > > > > > > > 4684/3823 > > > > > > > > > > > > 2245 > > > > > > > > > > > > 1383 > > > > > > > > > > > > 3.4/2.8 > > > > > > > > > > > > 1.62 > > > > > > > > > > > > It should be noted that the new code performance improvement are > even > > > more visible on top of .Net. > > > > > > It should also be noted that .Net runs the same algorithm 4 times > faster > > > then Mono. Since this code is self contained and almost completely > > > algorithmic - I believe that it may serve as a good practical test > case > > > for improving Mono's JIT. > > > > > > > > > > > > The redesign is composed of three main changes > > > > > > * An O(1) arithmetic transformation of a double (composed of > > > sign, 2's exponent and mantissa bits) to sign, long and 10's > exponent. > > > > > > * Using a character array instead of a string buffer to > construct > > > the string result. > > > > > > * Representing the number digits using hexadecimal values. > That > > > is /12345/ will be represented by /0x12345/. > > > > > > > > > > > > The patch passes Mono's unit tests on both 1.1 and 2.0. > > > > > > > > > > > > Please review and provide us with your feedback as soon as possible. > > > > > > > > > > > > Sasha, Roei & Eyal. > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > 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/20080102/30befb7d/attachment.html From rook at roo.k.pl Wed Jan 2 11:58:09 2008 From: rook at roo.k.pl (=?ISO-8859-2?Q?Micha=B3_Ziemski?=) Date: Wed, 02 Jan 2008 17:58:09 +0100 Subject: [Mono-dev] Using block inside an anonymous method crashes GMCS 1.2.6 Message-ID: <477BC2A1.4040607@roo.k.pl> Hi! I consider this to be serious so I decided to post to the group. I have filed a bug with a testcase (#351157) Everything was fine with 1.2.5. I would be grateful for information if the issue can be resolved more or less quickly. Best regards, Micha? Ziemski From robertj at gmx.net Wed Jan 2 12:09:45 2008 From: robertj at gmx.net (Robert Jordan) Date: Wed, 02 Jan 2008 18:09:45 +0100 Subject: [Mono-dev] Control-C handler In-Reply-To: <32541b130801020810m53ddbc8blbc3aeb1be5e8c3d7@mail.gmail.com> References: <1198179705.4430.116.camel@lina.magi.jprl.com> <31c001c8436d$b00c9510$0702a8c0@beardtongue> <20080102152434.GX5889@debian.org> <32541b130801020810m53ddbc8blbc3aeb1be5e8c3d7@mail.gmail.com> Message-ID: Avery Pennarun wrote: > On 02/01/2008, Paolo Molaro wrote: >> On 12/21/07 pablosantosluac wrote: >>> Ok, I think I got a bit lost here... how should I proceed then? >> There is no guarantee that you can hook to signal handlers >> from C#, we don't support that usage and its inclusion in Mono.Posix is >> a mistake. >> I'm actually going to add code to mono to detect such unsupported uses >> so we can flag error reports from applications that hook signal handlers >> as unusable and we can discard them. > > Surely there must be *some* way to handle signals from inside a mono > app? This seems like a huge omission. Even perl can do it! > (http://search.cpan.org/~lbaxter/Sys-SigAction-0.10/lib/Sys/SigAction.pm) Well, perl's standard signal handlers suffer from the same limitations like mono's and the new "deferred" signal handlers are just a lame compromise. Robert From andreas.faerber at web.de Wed Jan 2 12:17:16 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Wed, 2 Jan 2008 18:17:16 +0100 Subject: [Mono-dev] Control-C handler In-Reply-To: <20080102152434.GX5889@debian.org> References: <1198179705.4430.116.camel@lina.magi.jprl.com> <31c001c8436d$b00c9510$0702a8c0@beardtongue> <20080102152434.GX5889@debian.org> Message-ID: <24F723EA-7493-4AFB-854E-FD0FFBC74AE8@web.de> Am 02.01.2008 um 16:24 schrieb Paolo Molaro: > There is no guarantee that you can hook to signal handlers > from C#, we don't support that usage and its inclusion in Mono.Posix > is > a mistake. > I'm actually going to add code to mono to detect such unsupported uses > so we can flag error reports from applications that hook signal > handlers > as unusable and we can discard them. Wouldn't that affect mono-service as well? It's a managed application and depends on signals. Andreas From miguel at novell.com Wed Jan 2 12:16:29 2008 From: miguel at novell.com (Miguel de Icaza) Date: Wed, 02 Jan 2008 12:16:29 -0500 Subject: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited In-Reply-To: <8C1DC99174C541A7BD5DE875FAE6B2E0@ansirua> References: <1199036057.4400.10.camel@funnyfarm.hotfeet.ch> <8C1DC99174C541A7BD5DE875FAE6B2E0@ansirua> Message-ID: <1199294189.2296.90.camel@erandi.boston.ximian.com> Hey, > The array initialization should also be done lazily and not in the static > constructor (should be removed completely because it drags in other static > fields that need to be preinitialized, code compiled and so on). > Especially the Hex support is IMHO completely off bounds. I (personally) > rarely see hex output and making EVERYBODY pay for a hex speedup doesn't > seem right. A simple > if (array == null) Init (); > will be enough. You will pay per-call, but it is relatively cheap. The only thing that is worth keeping in mind is that if this is a static field, initialization probably needs to be protected by a lock (I say probably, because we *could* ignore the race by carefully making sure that we assign the public array only after it has been initialized, so we would end up with N copies of an array initialized in the worst case, but N-1 will be discarded by the GC). > Otherwise a single > Console.WriteLine (1.ToString()); > will get an EXTREMELY slow operation when you need to init a whole array > just for a (potentially) single conversion. > > Greetings > Andreas > > -----Urspr?ngliche Nachricht----- > Von: mono-devel-list-bounces at lists.ximian.com > [mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag von Eyal Alaluf > Gesendet: Montag, 31. Dezember 2007 13:24 > An: Juraj Skripsky; Atsushi Eno > Cc: Miguel de Icaza; mono-devel-list at lists.ximian.com > Betreff: [SPAM] Re: [Mono-dev] ToString() performace in Mono revisited > > Hi, all. > > Thanks for the feedback. The amount of used memory is indeed not appropriate > for small devices and is not economic enough. > > The 'DblExpTab' is essential in order for the double ToString to be > efficient. > As for the other two arrays they cache a simple arithmetic caclcualtion. > > I'll therefore eliminate the '_decHexLen' array and use > static readonly int[] _decHexDigits = new int [100]; I'll make DblRep into > a struct and remove one member out of it (and slightly improve the > double.ToString() perf along the way). > This will change the allocation size to 100 * 4 + 2048 * (3 * 4) = ~25K. > > The performance impact is betweek 3-10% overall for simple ToString() > depending on the hardware. > > Eyal. > > -----Original Message----- > From: Juraj Skripsky [mailto:js at hotfeet.ch] > Sent: 30 December 2007 19:34 > To: Atsushi Eno > Cc: Eyal Alaluf; Miguel de Icaza; mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] ToString() performace in Mono revisited > > Hello, > > I think the following two arrays account for most of those 300KB: > > static readonly int[] _decHexDigits = new int [10000]; static readonly int[] > _decHexLen = new int [0x10000]; > > The first one consumes almost 40KB, the second one 256KB... > > The "DblExpTab" array uses 2048 * 4 = 8KB and its referenced DblRep objects > 2048 * (8 + 4 * 4) = 48KB. This means a total of 56KB. Turning DblExbTab > into a struct would reduce this to 2048 * (4 * 4) = 32KB. > > - Juraj > > > On Mon, 2007-12-31 at 00:19 +0900, Atsushi Eno wrote: > > Hello, > > > > Kazuki pointed out that the static initialization part of > > NumberFormatter allocates 300KB. It is probably here: > > > > public static readonly DblRep[] DblExpTab = new DblRep > [ExponentMax + 1]; > > > > It does not look good. > > > > Atsushi Eno > > > > > > Eyal Alaluf wrote: > > > > > > > > > With the attchments zipped to reduce size. > > > > > > > > > > > > * From: * mono-devel-list-bounces at lists.ximian.com > > > [mailto:mono-devel-list-bounces at lists.ximian.com] *On Behalf Of > *Eyal Alaluf > > > *Sent:* 27 December 2007 17:28 > > > *To:* mono-devel-list at lists.ximian.com > > > *Cc:* Miguel de Icaza > > > *Subject:* [Mono-dev] ToString() performace in Mono revisited > > > > > > > > > > > > I got complaints that the font color within the table is white so > this > > > is a resent J > > > > > > > > > > > > Hi, all. > > > > > > > > > > > > Attached is a redesigned implementation of the NumberFormatter > class. > > > The patch includes a new algorithm for float and double ToString > > > implementation that improves performance by a factor of 25(!) and > upto > > > 440(!!!). The patch includes further improvements to integer > /ToString/ > > > as well as Andreas suggestion of avoiding calling > > > /NumberFormatInfo.CurrentInfo/ in the case of integer types default > > > /ToString()/ implementation. > > > > > > This patch should improve Mono's performance in important use cases > such > > > as web-services where primitive /ToString/ performance is an > important > > > factor. > > > > > > > > > > > > The following is a table showing the improvements for the different > > > primitive types using the patch. All the results are in milliseconds > and > > > for a run of 10,000,000 iterations with warm-up of 10,000,000 > iterations > > > as well. > > > > > > > > > > > > > > > > > > > > > > > > Mono 1.2.6 > > > > > > > > > > > > Patch > > > > > > > > > > > > Improvement > > > > > > 12345.ToString("G") > > > > > > > > > > > > 10079 > > > > > > > > > > > > 7328 > > > > > > > > > > > > 1.37 > > > > > > 12345L.ToString("G")> > > > > > > > > > 13203 > > > > > > > > > > > > 7297 > > > > > > > > > > > > 1.81 > > > > > > 0.12345.ToString("G") > > > > > > > > > > > > 323750 > > > > > > > > > > > > 13047 > > > > > > > > > > > > 24.8(!) > > > > > > 1.2345E-200.ToString("G") > > > > > > > > > > > > 6376500 > > > > > > > > > > > > 14328 > > > > > > > > > > > > 445(!!!) > > > > > > 0.12345m.ToString("G") > > > > > > > > > > > > 51078 > > > > > > > > > > > > 9875 > > > > > > > > > > > > 5.2 > > > > > > 12345.ToString() > > > > > > > > > > > > 12406/7781 > > > > > > > > > > > > 5687 > > > > > > > > > > > > 2.2/1.37 > > > > > > 12345L.ToString() > > > > > > > > > > > > > > 281090 > > > > > > > > > > > > 4006 > > > > > > > > > > > > 3897 > > > > > > > > > > > > 72.1(!!) > > > > > > > > > > > > 1.03 > > > > > > 1.2345E-200.ToString("G") > > > > > > > > > > > > 5686000 > > > > > > > >12345.ToString("G")/!) and the second is after applying Andreas > > > suggestion on top of Mono 1.2.6. > > > > > > > > > > > > The following are the results of the new algorithm compared to the > old > > > Mono algorithm and the .Net 2.0 native ToString performance, all > three > > > running on Microsoft .Net 2.0. The results show that the new code > > > matches and even out-performs .Net /ToString/ implementation. > > > > > > > > > > > > > > > > > > Mono 1.2.6 algorithm > > > > > > > > > > > > Microsoft .Net 2.0 > > > > > > > > > > > > New Patch algorithm > > > > > > > > > > > > Improvement over Mono 1.2.6 > > > > > > > > > > > > Improvement over .Net 2.0 > > > > > > 12345.ToString("G") > > > > > > > > > > > > 3700 > > > > > > > > > > > > 2291 > > > > > > > > > > > > 1827 > > > > > > > > > > > > 2.0 > > > > > > > > > > > > 1.25 > > > > > > 12345L.ToString("G") > > > > > > > > > > > > 4559 > > > > > > > > > > > > 2242 > > > > > > > > > > > > 1919 > > > > > > > > > > > > 2.38 > > > > > > > > > > > > 1.17 > > > > > > 0.12345.ToString("G") > > > > > > > > > > > > 281090 > > > > > > > > > > > > 4006 > > > > > > > > > > > > 3897 > > > > > > > > > > > > 72.1(!!) > > > > > > > > > > > > 1.03 > > > > > > 1.2345E-200.ToString("G") > > > > > > > > > > > > 5686000 > > > > > > > > > > > > 4634 > > > > > > > > > > > > 4613 > > > > > > > > > > > > 1233(!!!) > > > > > > > > > > > > 1.00 > > > > > > 0.12345m.ToString("G") > > > > > > > > > > > > 14562 > > > > > > > > > > > > 3095 > > > > > > > > > > > > 2294 > > > > > > > > > > > > 6.3 > > > > > > > > > > > > 1.35 > > > > > > 12345.ToString() > > > > > > > > > > > > 3900/3002 > > > > > > > > > > > > 2344 > > > > > > > > > > > > 1313 > > > > > > > > > > > > 3.0/2.3 > > > > > > > > > > > > 1.79 > > > > > > 12345L.ToString() > > > > > > > > > > > > 4684/3823 > > > > > > > > > > > > 2245 > > > > > > > > > > > > 1383 > > > > > > > > > > > > 3.4/2.8 > > > > > > > > > > > > 1.62 > > > > > > > > > > > > It should be noted that the new code performance improvement are > even > > > more visible on top of .Net. > > > > > > It should also be noted that .Net runs the same algorithm 4 times > faster > > > then Mono. Since this code is self contained and almost completely > > > algorithmic - I believe that it may serve as a good practical test > case > > > for improving Mono's JIT. > > > > > > > > > > > > The redesign is composed of three main changes > > > > > > * An O(1) arithmetic transformation of a double (composed of > > > sign, 2's exponent and mantissa bits) to sign, long and 10's > exponent. > > > > > > * Using a character array instead of a string buffer to > construct > > > the string result. > > > > > > * Representing the number digits using hexadecimal values. > That > > > is /12345/ will be represented by /0x12345/. > > > > > > > > > > > > The patch passes Mono's unit tests on both 1.1 and 2.0. > > > > > > > > > > > > Please review and provide us with your feedback as soon as possible. > > > > > > > > > > > > Sasha, Roei & Eyal. > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > 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 gert.driesen at telenet.be Wed Jan 2 12:46:06 2008 From: gert.driesen at telenet.be (Gert Driesen) Date: Wed, 2 Jan 2008 18:46:06 +0100 Subject: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor In-Reply-To: Message-ID: <20080102174658.6EB97500E7@nelson.telenet-ops.be> Vladimir, Can you also add a unit test for this ? Thanks! Gert -----Original Message----- From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Vladimir Krasnov Sent: woensdag 2 januari 2008 17:42 To: mono-devel-list at lists.ximian.com Subject: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor Hello, Please review and approve attached patch for TypeDescriptor.GetProperties() method. This fixes the order of properties in the returning collection which is important for System.Web data bound controls. Vladimir From apenwarr at gmail.com Wed Jan 2 13:08:07 2008 From: apenwarr at gmail.com (Avery Pennarun) Date: Wed, 2 Jan 2008 13:08:07 -0500 Subject: [Mono-dev] Control-C handler In-Reply-To: References: <1198179705.4430.116.camel@lina.magi.jprl.com> <31c001c8436d$b00c9510$0702a8c0@beardtongue> <20080102152434.GX5889@debian.org> <32541b130801020810m53ddbc8blbc3aeb1be5e8c3d7@mail.gmail.com> Message-ID: <32541b130801021008i57a1ed36j459a6f077e8a4699@mail.gmail.com> On 02/01/2008, Robert Jordan wrote: > Avery Pennarun wrote: > > Surely there must be *some* way to handle signals from inside a mono > > app? This seems like a huge omission. Even perl can do it! > > (http://search.cpan.org/~lbaxter/Sys-SigAction-0.10/lib/Sys/SigAction.pm) > > Well, perl's standard signal handlers suffer from the same limitations > like mono's and the new "deferred" signal handlers are just a lame > compromise. All signal handlers in any language suffer from the same limitations: there's no guarantee that the mainline is in a safe state at the time the signal handler is called. That means the set of "safe" things you can do in a signal handler is extremely limited. In C, this basically restricts you to direct syscalls (ie. manpages section 2, not section 3) and setting variables. Generally this is enough, leading to two safe options in C: 1) Set a (volatile) variable in the signal handler and check it from the mainline. 2) write() to a pipe during a signal, and poll the read side of the pipe in the mainline so that it wakes up. This is safe in a signal handler because write() is a syscall. and one unfortunately all-too-common unsafe option: 3) Just ignore the fact that it might not work and do whatever you want in the signal handler anyhow. It'll work 99% of the time. It seems like if mono could guarantee certain things, such as the fact that an already-JITted function will never be thrown away, that a safe implementation of #1 would be possible as Jonathan Pryor posted above. Does mono make that guarantee? Will it continue to do so? Currently implementation #2 is probably impossible (or unsafe) in mono since the socket code is probably much more complex than a syscall and may still be in an unsafe state. Perl has a similar problem, which is why the "deferred" signal handlers were created. Option #3 is probably not 99% safe in mono, which has more runtime state outside the kernel than a C program would. What makes the perl ones a "lame compromise" in your opinion? How does Microsoft's .Net handle Windows-style "signals", such as memory-access errors? Could we use a similar method in mono? Have fun, Avery From jonpryor at vt.edu Wed Jan 2 13:20:42 2008 From: jonpryor at vt.edu (Jonathan Pryor) Date: Wed, 02 Jan 2008 13:20:42 -0500 Subject: [Mono-dev] Can not checkout trunk on windows In-Reply-To: <47716040.4090405@lanwin.de> References: <47716040.4090405@lanwin.de> Message-ID: <1199298042.3676.18.camel@lina.magi.jprl.com> On Tue, 2007-12-25 at 20:55 +0100, Steve Wagner wrote: > Hi, currently i can not checkout the trunk on windows, because in > "/monodoc/class/System.Security/en" are an file with name > "System.Security.Cryptography.Xml" and an folder with the same name. > > If i try to check out, ive allways get an "object of the same name > already exists. This should now be fixed. Monodocer now produces namespace XML files with a ns- prefix (to avoid this conflict), and all the documentation within the monodoc/class module has been renamed accordingly. - Jon From jonpryor at vt.edu Wed Jan 2 13:25:50 2008 From: jonpryor at vt.edu (Jonathan Pryor) Date: Wed, 02 Jan 2008 13:25:50 -0500 Subject: [Mono-dev] [Mono-docs-list] Can not checkout trunk on windows In-Reply-To: <1198683174.11168.172.camel@erandi.boston.ximian.com> References: <47716040.4090405@lanwin.de> <1198658399.29665.11.camel@lina.magi.jprl.com> <1198683174.11168.172.camel@erandi.boston.ximian.com> Message-ID: <1199298350.3676.23.camel@lina.magi.jprl.com> On Wed, 2007-12-26 at 10:32 -0500, Miguel de Icaza wrote: > > Suggestions? All I can suggest is that namespace XML files should > > contain some character/string that namespaces are highly unlikely to > > contain, e.g. instead of "en/System.xml" for the XML documentation on > > the System namespace, use "en/Namespace-System.xml". Any such > > character/string *must* be usable on Windows, so no ':' or similar > > characters can be used. > > We should add support for a different name like: > > ns-System.xml > > And then we can rename the files for the docs that we maintain. This has been done. Mike Kestner suggested using a namespaces.xml file; I chose not to do this as it made the migration of monodocer/monodocs2html/ecma-provider easier. > And keep the old code for documentation that might be out that has not > been updated by us. Monodoc will currently look for the older filename and rename accordingly; ecma-provider will check for both, with a preference for the non ns-prefixed name. monodocs2html currently requires the ns- prefixed files, as I couldn't think of an easy way to do the fallback within the XSLT. - Jon From prakash at punnoor.de Wed Jan 2 13:30:05 2008 From: prakash at punnoor.de (Prakash Punnoor) Date: Wed, 2 Jan 2008 19:30:05 +0100 Subject: [Mono-dev] =?iso-8859-1?q?=5BSPAM=5D_Re=3A_ToString=28=29_perform?= =?iso-8859-1?q?ace_in_Mono=09revisited?= In-Reply-To: <1199294189.2296.90.camel@erandi.boston.ximian.com> References: <1199036057.4400.10.camel@funnyfarm.hotfeet.ch> <8C1DC99174C541A7BD5DE875FAE6B2E0@ansirua> <1199294189.2296.90.camel@erandi.boston.ximian.com> Message-ID: <200801021930.06105.prakash@punnoor.de> On the day of Wednesday 02 January 2008 Miguel de Icaza hast written: > Hey, > > > The array initialization should also be done lazily and not in the static > > constructor (should be removed completely because it drags in other > > static fields that need to be preinitialized, code compiled and so on). > > Especially the Hex support is IMHO completely off bounds. I (personally) > > rarely see hex output and making EVERYBODY pay for a hex speedup doesn't > > seem right. A simple > > if (array == null) Init (); > > will be enough. You will pay per-call, but it is relatively cheap. > > The only thing that is worth keeping in mind is that if this is a static > field, initialization probably needs to be protected by a lock (I say > probably, because we *could* ignore the race by carefully making sure > that we assign the public array only after it has been initialized, so > we would end up with N copies of an array initialized in the worst case, > but N-1 will be discarded by the GC). You can also use the Bill Pugh's trick by using a nested class, so the jit should lazily initialize it (it works with .net, no idea whether it does with mono.) -- (?= =?) //\ Prakash Punnoor /\\ V_/ \_V -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080102/265b2446/attachment.bin From js at hotfeet.ch Wed Jan 2 13:41:08 2008 From: js at hotfeet.ch (Juraj Skripsky) Date: Wed, 02 Jan 2008 19:41:08 +0100 Subject: [Mono-dev] "Label2" in commit 92114 Message-ID: <1199299268.2826.19.camel@funnyfarm.hotfeet.ch> Hi Igor, I've noticed something strange in your latest commit: + private void WriteExpandoAttributes (HtmlTextWriter writer) { + if (_expandoAttributes != null) { + for (int i = 0; i < _expandoAttributes.Count; i++) { + RegisteredExpandoAttribute attr = _expandoAttributes [i]; + if (HasBeenRendered (attr.Control)) + WriteCallbackOutput (writer, expando, "document.getElementById('Label2')['" + attr.Name + "']", "\"" + attr.Value + "\""); + } + } + } You're sending "document.getElementById('Label2')['" + attr.Name + "']" to the html writer. Is this really correct or just a leftover from testing? - Juraj From jonpryor at vt.edu Wed Jan 2 14:19:08 2008 From: jonpryor at vt.edu (Jonathan Pryor) Date: Wed, 02 Jan 2008 14:19:08 -0500 Subject: [Mono-dev] Control-C handler In-Reply-To: <32541b130801021008i57a1ed36j459a6f077e8a4699@mail.gmail.com> References: <1198179705.4430.116.camel@lina.magi.jprl.com> <31c001c8436d$b00c9510$0702a8c0@beardtongue> <20080102152434.GX5889@debian.org> <32541b130801020810m53ddbc8blbc3aeb1be5e8c3d7@mail.gmail.com> <32541b130801021008i57a1ed36j459a6f077e8a4699@mail.gmail.com> Message-ID: <1199301548.3676.39.camel@lina.magi.jprl.com> On Wed, 2008-01-02 at 13:08 -0500, Avery Pennarun wrote: > How does Microsoft's .Net handle Windows-style "signals", such as > memory-access errors? Could we use a similar method in mono? I'm not entirely sure, but I can guess intelligently. :-) Win32 doesn't have signals either; instead, it uses Structured Exception Handling (SEH) to report out-of-band error conditions such as invalid memory access, etc. .NET exceptions use SEH. Consequently, I'll intelligently guess that .NET reports out-of-band errors via exceptions, probably as a subclass of SEHException. This obviously isn't an answer for Mono, as no Unix platform uses SEH for anything, signals serving a similar (if less flexible) purpose. That said, I think that there should be a way to use signals from C#. Even if such use is severely limited -- e.g. only setting a volatile variable within the signal handler -- signals are required for decent integration with Unix platforms, so saying "don't use them" isn't an adequate answer. We need to have a well defined, supported, set of things that signal handlers can do. The alternative -- requiring that all signal handlers be written in C -- isn't as useful. It would require that every Gnome Gtk# app (Tomboy, Beagle, etc) have a C library to properly handle session ending (SIGTERM followed by SIGKILL), which just sounds like severe overkill. So why can't setting a volatile variable within a signal handler be supported? And/or use a Constrained Execution Region to *ensure* that the signal handler is JITed before the signal is emitted (does mono even support CERs yet?)? - Jon From shawn at cogmation.com Wed Jan 2 15:35:37 2008 From: shawn at cogmation.com (Shawn Schaerer) Date: Wed, 2 Jan 2008 14:35:37 -0600 Subject: [Mono-dev] Cannot unload appdomain which includes a Visual Basic generated dll Message-ID: <508E344D-77F4-4EEC-87C8-62992FFCA56E@cogmation.com> Hi, I have a problem unloading a appdomain that uses a visual basic dll. We have a c# application that creates a new appdomain, which loads a C# program (from a dll). This C# dll uses functions from a visualbasic dll. If we don't use (load) functions from the visualbasic dll then we can unload the appdomain. Also if we use functions from a different C# dll, we can unload the appdomain. The error we get is: CannotUnloadAppDomainException: Aborting of threads in domain Domain1 timed out. System.AppDomain.Unload (System.AppDomain domain) Any ideas ? Thanks, Shawn Schaerer Director of Research and Development Cogmation Robotics Inc www.cogmation.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080102/f22a9b4b/attachment.html From michi at zeroc.com Wed Jan 2 14:41:43 2008 From: michi at zeroc.com (Michi Henning) Date: Thu, 03 Jan 2008 05:41:43 +1000 Subject: [Mono-dev] Control-C handler In-Reply-To: <1199301548.3676.39.camel@lina.magi.jprl.com> References: <1198179705.4430.116.camel@lina.magi.jprl.com> <31c001c8436d$b00c9510$0702a8c0@beardtongue> <20080102152434.GX5889@debian.org> <32541b130801020810m53ddbc8blbc3aeb1be5e8c3d7@mail.gmail.com> <32541b130801021008i57a1ed36j459a6f077e8a4699@mail.gmail.com> <1199301548.3676.39.camel@lina.magi.jprl.com> Message-ID: <477BE8F7.9030907@zeroc.com> Jonathan Pryor wrote: > So why can't setting a volatile variable within a signal handler be > supported? And/or use a Constrained Execution Region to *ensure* that > the signal handler is JITed before the signal is emitted (does mono even > support CERs yet?)? > Something to support signal handling would definitely be useful. I'm currently in the situation where I'm maintaining a code base that must run on both .NET and Mono. The code is a middleware library (www.zeroc.com) that must allow allow applications to react to signals so they can shut down themselves and the Ice run time in an orderly fashion. Under Windows, the code uses P/Invoke to call SetConsoleCtrlHandler so it can intercept Ctrl-C, Ctrl-Break, and shutdown, logoff, and window closure. With Mono, I'm pretty much stuck because there is no equivalent mechanism. As far as I can see, the only option to achieve equivalent functionality is to create a C library that sets the necessary signal handlers and to then P/Invoke into that library from my C# Mono code. But that sort of defeats the purpose because I'd rather not ship a DLL for every possible platform Mono runs on. Console.CancelKeyPress, which was added with .NET 2.0, unfortunately doesn't work for this purpose: it only intercepts keyboard interrupts, but doesn't trigger on logoff, shutdown, or window closure. One could argue that all this is a limitation of .NET, which should offer a way to reliably intercept process termination. But, under Windows, I at least get an acceptable work-around in the form of SetConsoleCtrlHandler whereas, with Mono, I don't. So, anything to improve on this situation would be great. While I understand all the arguments about what can and can't safely be done from within a signal handler, the need to react to signals and perform some clean-up before a process goes away is a real-world requirement. If Mono offered at least rudimentary support for signal handling that doesn't require P/Invoke and external non-standard libraries, it would at least allow me to then build something on top of that. Right now, I can't do anything much at all, as far as I can see. Cheers, Michi. From lists at lanwin.de Wed Jan 2 16:40:25 2008 From: lists at lanwin.de (Steve Wagner) Date: Wed, 02 Jan 2008 22:40:25 +0100 Subject: [Mono-dev] [Mono-docs-list] Can not checkout trunk on windows In-Reply-To: <1199298350.3676.23.camel@lina.magi.jprl.com> References: <47716040.4090405@lanwin.de> <1198658399.29665.11.camel@lina.magi.jprl.com> <1198683174.11168.172.camel@erandi.boston.ximian.com> <1199298350.3676.23.camel@lina.magi.jprl.com> Message-ID: <477C04C9.80708@lanwin.de> Sorry but it isnt totaly solved. Now ive got the following error: Cant check out path 'C:\mono-svn\monodoc\class\System.Web\en\System.Web\<>c__CompilerGenerated2+<>c__CompilerGenerated13.xml': Bad syntax for filename, directoryname or drivename * This is free text translated from german windows Steve Jonathan Pryor schrieb: > On Wed, 2007-12-26 at 10:32 -0500, Miguel de Icaza wrote: >>> Suggestions? All I can suggest is that namespace XML files should >>> contain some character/string that namespaces are highly unlikely to >>> contain, e.g. instead of "en/System.xml" for the XML documentation on >>> the System namespace, use "en/Namespace-System.xml". Any such >>> character/string *must* be usable on Windows, so no ':' or similar >>> characters can be used. >> We should add support for a different name like: >> >> ns-System.xml >> >> And then we can rename the files for the docs that we maintain. > > This has been done. Mike Kestner suggested using a namespaces.xml file; > I chose not to do this as it made the migration of > monodocer/monodocs2html/ecma-provider easier. > >> And keep the old code for documentation that might be out that has not >> been updated by us. > > Monodoc will currently look for the older filename and rename > accordingly; ecma-provider will check for both, with a preference for > the non ns-prefixed name. > > monodocs2html currently requires the ns- prefixed files, as I couldn't > think of an easy way to do the fallback within the XSLT. > > - Jon > > From contact at i-nz.net Wed Jan 2 19:24:23 2008 From: contact at i-nz.net (Ivan N. Zlatev) Date: Thu, 03 Jan 2008 00:24:23 +0000 Subject: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor In-Reply-To: References: Message-ID: <477C2B37.5080700@i-nz.net> Vladimir Krasnov wrote: > > > Hello, > > Please review and approve attached patch for > TypeDescriptor.GetProperties() method. This fixes the order of > properties in the returning collection which is important for System.Web > data bound controls. > You can get rid off the Hashtable used in TypeInfo.GetProperties. I introduced it because at some point Type.GetProperties used to return two AnotherProperty PropertyInfos for typeof(B) in the following case: class A { public string AnotherProperty { } } class B : A { public new string AnotherProperty { } } It seems to no longer be the case (back then I did not test the Type.GetProperties behavior on msnet and assumed bug in TypeDescriptor), but you should test to make sure. You can check test #G2 in TestGetProperties in TypeDescriptorTests. Regards, -- Ivan N. Zlatev Web: http://www.i-nZ.net "It's all some kind of whacked out conspiracy." From ClassDevelopment at A-SoftTech.com Wed Jan 2 20:16:36 2008 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Thu, 3 Jan 2008 02:16:36 +0100 Subject: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited In-Reply-To: <200801021930.06105.prakash@punnoor.de> References: <1199036057.4400.10.camel@funnyfarm.hotfeet.ch> <8C1DC99174C541A7BD5DE875FAE6B2E0@ansirua> <1199294189.2296.90.camel@erandi.boston.ximian.com> <200801021930.06105.prakash@punnoor.de> Message-ID: <24F2C2D50897416684FB1C1297E32077@ansirua> > > The array initialization should also be done lazily and not in the > > static constructor (should be removed completely because it drags in > > other static fields that need to be preinitialized, code compiled and so on). > > Especially the Hex support is IMHO completely off bounds. I > > (personally) rarely see hex output and making EVERYBODY pay for a > > hex speedup doesn't seem right. A simple if (array == null) Init (); > > will be enough. You will pay per-call, but it is relatively cheap. > > The only thing that is worth keeping in mind is that if this is a > static field, initialization probably needs to be protected by a lock > (I say probably, because we *could* ignore the race by carefully > making sure that we assign the public array only after it has been > initialized, so we would end up with N copies of an array initialized > in the worst case, but N-1 will be discarded by the GC). You can also use the Bill Pugh's trick by using a nested class, so the jit should lazily initialize it (it works with .net, no idea whether it does with mono.) I don't know whether it would work with mono either but you may get additional problems having a nested class in a structure ;) Also there is no need to lock for multithreading. As Miguel wrote we can simply ignore the race in this situation. Worst case two (or n) Lookuparrays get created and all except one immediately garbage-collected after their use. All you need to have is void Init () { int[] temp = new int[x]; doinits() staticField = temp; // Must not happen before doinits() } Greetings Andreas From jonpryor at vt.edu Wed Jan 2 23:20:16 2008 From: jonpryor at vt.edu (Jonathan Pryor) Date: Wed, 02 Jan 2008 23:20:16 -0500 Subject: [Mono-dev] [Mono-docs-list] Can not checkout trunk on windows In-Reply-To: <477C04C9.80708@lanwin.de> References: <47716040.4090405@lanwin.de> <1198658399.29665.11.camel@lina.magi.jprl.com> <1198683174.11168.172.camel@erandi.boston.ximian.com> <1199298350.3676.23.camel@lina.magi.jprl.com> <477C04C9.80708@lanwin.de> Message-ID: <1199334016.4581.0.camel@lina.magi.jprl.com> This file has been removed. Any other issues with a Win32 checkout? - Jon On Wed, 2008-01-02 at 22:40 +0100, Steve Wagner wrote: > Sorry but it isnt totaly solved. Now ive got the following error: > > Cant check out path > 'C:\mono-svn\monodoc\class\System.Web\en\System.Web\<>c__CompilerGenerated2+<>c__CompilerGenerated13.xml': > > Bad syntax for filename, directoryname or drivename > > * This is free text translated from german windows > > Steve > > Jonathan Pryor schrieb: > > On Wed, 2007-12-26 at 10:32 -0500, Miguel de Icaza wrote: > >>> Suggestions? All I can suggest is that namespace XML files should > >>> contain some character/string that namespaces are highly unlikely to > >>> contain, e.g. instead of "en/System.xml" for the XML documentation on > >>> the System namespace, use "en/Namespace-System.xml". Any such > >>> character/string *must* be usable on Windows, so no ':' or similar > >>> characters can be used. > >> We should add support for a different name like: > >> > >> ns-System.xml > >> > >> And then we can rename the files for the docs that we maintain. > > > > This has been done. Mike Kestner suggested using a namespaces.xml file; > > I chose not to do this as it made the migration of > > monodocer/monodocs2html/ecma-provider easier. > > > >> And keep the old code for documentation that might be out that has not > >> been updated by us. > > > > Monodoc will currently look for the older filename and rename > > accordingly; ecma-provider will check for both, with a preference for > > the non ns-prefixed name. > > > > monodocs2html currently requires the ns- prefixed files, as I couldn't > > think of an easy way to do the fallback within the XSLT. > > > > - Jon > > > > From alcherenga at gmail.com Thu Jan 3 01:02:09 2008 From: alcherenga at gmail.com (alcherenga alcherenga) Date: Thu, 3 Jan 2008 11:32:09 +0530 Subject: [Mono-dev] mono xml In-Reply-To: <1198950785.4181.59.camel@erandi.boston.ximian.com> References: <29073d310712282349r644eb91ey6809b6c1577f2235@mail.gmail.com> <1198950785.4181.59.camel@erandi.boston.ximian.com> Message-ID: <29073d310801022202y333d374ena54451853a4a07f6@mail.gmail.com> Thanks Miguel, On Dec 29, 2007 11:23 PM, Miguel de Icaza wrote: > > > > is there any work around for that ? I mean using network stream and > > then use beginread instead of the normal read() method. > > Yes, there is a very simple work around. If you wrap your code in a > delegate, you can invoke the delegate in async mode. > > So essentially, you can turn any sync operation into an async one. > > Here is a simple program that shows you how to use BeginInvoke and > EndInvoke methods (these are automatically generated for all delegates): > > using System; > using System.Threading; > > delegate int Worker (); > > class X { > static void Main () > { > Worker w = delegate { > Console.WriteLine (" Async: sleeping for five > seconds"); > Thread.Sleep (5000); > Console.WriteLine (" Async: done"); > return 10; > }; > Console.WriteLine ("Main thread: Launching async method"); > IAsyncResult r = null; > > r = w.BeginInvoke (delegate { > > Console.WriteLine (" Async: notification Callback > invoked, method finished"); > Console.WriteLine (" Async: result from worker > was: {0}", w.EndInvoke (r)); > }, null); > Console.WriteLine ("Main thread: waiting for async call to > finish"); > r.AsyncWaitHandle.WaitOne (); > Console.WriteLine ("Main thread: finishing"); > } > } > > > the second question is based on an article written in msdn, > > xmltextreader cannot read file above 2GB. why is this limititation > > imposed when it is a forward only reader. or is there any such > > limitation imposed by mono's implementation of the same. > > I do not know that there is any limitation in our implementation, let us > know what you find out. > > Miguel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080103/1461e052/attachment.html From steveb at mindtouch.com Thu Jan 3 02:21:34 2008 From: steveb at mindtouch.com (Steve Bjorg) Date: Wed, 2 Jan 2008 23:21:34 -0800 Subject: [Mono-dev] set culture uses serialization? Message-ID: <59FD03ED-8580-4878-BFC3-48DEBED853A9@mindtouch.com> I ran into the following error today on our system (note: I truncated the stack for legibility). The interesting part is in bold (prefixed by * in case the formatting got lost) Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS Stacktrace: at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) <0x00004> at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) <0xffffffff> at System.IO.MemoryStream.set_Capacity (int) <0x0004c> at System.IO.MemoryStream.Write (byte[],int,int) <0x0007a> at System.IO.BinaryWriter.Write (string) <0x000c8> at GregorianCalendar__TypeMetadata.WriteTypeData (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,System.IO.B inaryWriter,bool) <0x0001f> at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject (System.IO.BinaryWriter,long,object) <0x0020d> at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectI nstance (System.IO.BinaryWriter,object,bool) <0x0014c> at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQueuedO bjects (System.IO.BinaryWriter) <0x0002d> at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectG raph (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.Header[ ]) <0x0003a> at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header []) <0x00206> * at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize (System.IO.Stream,object) <0x00015> * at System.Threading.Thread.set_CurrentUICulture (System.Globalization.CultureInfo) <0x00056> at MindTouch.Dream.Task.Execute (System.VoidHandler,MindTouch.Dream.TaskBehavior) <0x00093> The odd thing is that it appears setting the culture invokes the serializer!?! Our async execution framework sets the culture for all asynchronous operations. Question is, why is it using serialization though? Can I avoid this somehow and still set the culture? Thx. - Steve -------------- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080102/4c32a92e/attachment.html From eyala at mainsoft.com Thu Jan 3 03:21:20 2008 From: eyala at mainsoft.com (Eyal Alaluf) Date: Thu, 3 Jan 2008 00:21:20 -0800 Subject: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited In-Reply-To: <24F2C2D50897416684FB1C1297E32077@ansirua> Message-ID: Hi, all. Let me try to clarify a few things: 1. The "Hex support" is not for hexadecimal formatting but for speeding up decimal formatting. 2. Following the reviews about the array size, the _decHexLen' array is removed and the '_decHexDigits' is reduced to size of 400 bytes. 3. The third array that is part of the double ToString algorithm is already defined within a nested class and will be initialized only when a double/float ToString is invoked. Attached is a revised version of 'NumberFormatter.cs' that includes these changes. Eyal. -----Original Message----- From: Andreas Nahr [mailto:ClassDevelopment at A-SoftTech.com] Sent: 03 January 2008 03:17 To: 'Prakash Punnoor'; mono-devel-list at lists.ximian.com Cc: 'Miguel de Icaza'; 'Andreas Nahr'; 'Atsushi Eno'; 'Juraj Skripsky'; Eyal Alaluf Subject: AW: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited > > The array initialization should also be done lazily and not in the > > static constructor (should be removed completely because it drags in > > other static fields that need to be preinitialized, code compiled and so on). > > Especially the Hex support is IMHO completely off bounds. I > > (personally) rarely see hex output and making EVERYBODY pay for a > > hex speedup doesn't seem right. A simple if (array == null) Init (); > > will be enough. You will pay per-call, but it is relatively cheap. > > The only thing that is worth keeping in mind is that if this is a > static field, initialization probably needs to be protected by a lock > (I say probably, because we *could* ignore the race by carefully > making sure that we assign the public array only after it has been > initialized, so we would end up with N copies of an array initialized > in the worst case, but N-1 will be discarded by the GC). You can also use the Bill Pugh's trick by using a nested class, so the jit should lazily initialize it (it works with .net, no idea whether it does with mono.) I don't know whether it would work with mono either but you may get additional problems having a nested class in a structure ;) Also there is no need to lock for multithreading. As Miguel wrote we can simply ignore the race in this situation. Worst case two (or n) Lookuparrays get created and all except one immediately garbage-collected after their use. All you need to have is void Init () { int[] temp = new int[x]; doinits() staticField = temp; // Must not happen before doinits() } Greetings Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: NumberFormatter.cs Type: application/octet-stream Size: 56580 bytes Desc: NumberFormatter.cs Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080103/38b0b15f/attachment.obj From ClassDevelopment at A-SoftTech.com Thu Jan 3 04:18:37 2008 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Thu, 3 Jan 2008 10:18:37 +0100 Subject: [Mono-dev] [SPAM] Re: [SPAM] Re: ToString() performace in Mono revisited In-Reply-To: References: <24F2C2D50897416684FB1C1297E32077@ansirua> Message-ID: <947E4199BDE74E6994D8E502FF846F68@ansirua> Sorry that I did not suggest this earlier, but did you look at using a scheme for embedding the Lookuptables in the runtime like e.g. Char does? The problem with using static fields is that they are per-domain and always need to be ("re")initialized. Assume the following (worst) case: We have 1000 Appdomains and each appdomain does a single ToString for a double value. In that case your implementation will: * Consume more than 36MB RAM just for the lookup-tables * Each of the single ToStrings will probably be about 100000 times (just making up a number) slower than now because for every single call you recreate the entire lookuptable(s) Moving the (pregenerated) lookuptables into the runtime will: * Reduce the memory to a *single* instance of the lookuptable for all Appdomains/Processes * Potentially reduce memory by using mem-mapping * Remove *ALL* initialization, which means full speed even with a single ToString call. * Nearly no overhead except a single internalcall to retieve the datapointer(s) * No race-conditions, no locking This way it might even make sense to keep some of the original _decHex Tables (maybe reduced in array size and do they both need Int32 anyways?). Greetings Andreas -----Urspr?ngliche Nachricht----- Von: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag von Eyal Alaluf Gesendet: Donnerstag, 3. Januar 2008 09:21 An: Andreas Nahr; Prakash Punnoor; mono-devel-list at lists.ximian.com Cc: Atsushi Eno; Miguel de Icaza; Juraj Skripsky Betreff: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited Hi, all. Let me try to clarify a few things: 1. The "Hex support" is not for hexadecimal formatting but for speeding up decimal formatting. 2. Following the reviews about the array size, the _decHexLen' array is removed and the '_decHexDigits' is reduced to size of 400 bytes. 3. The third array that is part of the double ToString algorithm is already defined within a nested class and will be initialized only when a double/float ToString is invoked. Attached is a revised version of 'NumberFormatter.cs' that includes these changes. Eyal. -----Original Message----- From: Andreas Nahr [mailto:ClassDevelopment at A-SoftTech.com] Sent: 03 January 2008 03:17 To: 'Prakash Punnoor'; mono-devel-list at lists.ximian.com Cc: 'Miguel de Icaza'; 'Andreas Nahr'; 'Atsushi Eno'; 'Juraj Skripsky'; Eyal Alaluf Subject: AW: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited > > The array initialization should also be done lazily and not in the > > static constructor (should be removed completely because it drags in > > other static fields that need to be preinitialized, code compiled and so on). > > Especially the Hex support is IMHO completely off bounds. I > > (personally) rarely see hex output and making EVERYBODY pay for a > > hex speedup doesn't seem right. A simple if (array == null) Init (); > > will be enough. You will pay per-call, but it is relatively cheap. > > The only thing that is worth keeping in mind is that if this is a > static field, initialization probably needs to be protected by a lock > (I say probably, because we *could* ignore the race by carefully > making sure that we assign the public array only after it has been > initialized, so we would end up with N copies of an array initialized > in the worst case, but N-1 will be discarded by the GC). You can also use the Bill Pugh's trick by using a nested class, so the jit should lazily initialize it (it works with .net, no idea whether it does with mono.) I don't know whether it would work with mono either but you may get additional problems having a nested class in a structure ;) Also there is no need to lock for multithreading. As Miguel wrote we can simply ignore the race in this situation. Worst case two (or n) Lookuparrays get created and all except one immediately garbage-collected after their use. All you need to have is void Init () { int[] temp = new int[x]; doinits() staticField = temp; // Must not happen before doinits() } Greetings Andreas From vladimirk at mainsoft.com Thu Jan 3 06:32:39 2008 From: vladimirk at mainsoft.com (Vladimir Krasnov) Date: Thu, 3 Jan 2008 03:32:39 -0800 Subject: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor In-Reply-To: <477C2B37.5080700@i-nz.net> Message-ID: Hi Ivan, You are right, I've reverted the "Hashtable patch" and everything works fine. TestGetProperties in TypeDescriptorTests is ok also. Look at attached patch. Regards, Vladimir -----Original Message----- From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Ivan N. Zlatev Sent: Thursday, January 03, 2008 2:24 AM To: mono-devel-list at lists.ximian.com Subject: Re: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor Vladimir Krasnov wrote: > > > Hello, > > Please review and approve attached patch for > TypeDescriptor.GetProperties() method. This fixes the order of > properties in the returning collection which is important for > System.Web data bound controls. > You can get rid off the Hashtable used in TypeInfo.GetProperties. I introduced it because at some point Type.GetProperties used to return two AnotherProperty PropertyInfos for typeof(B) in the following case: class A { public string AnotherProperty { } } class B : A { public new string AnotherProperty { } } It seems to no longer be the case (back then I did not test the Type.GetProperties behavior on msnet and assumed bug in TypeDescriptor), but you should test to make sure. You can check test #G2 in TestGetProperties in TypeDescriptorTests. Regards, -- Ivan N. Zlatev Web: http://www.i-nZ.net "It's all some kind of whacked out conspiracy." _______________________________________________ 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: TypeDescriptor.cs.patch Type: application/octet-stream Size: 1112 bytes Desc: TypeDescriptor.cs.patch Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080103/da151eb3/attachment.obj From contact at i-nz.net Thu Jan 3 10:28:18 2008 From: contact at i-nz.net (Ivan N. Zlatev) Date: Thu, 03 Jan 2008 15:28:18 +0000 Subject: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor In-Reply-To: References: Message-ID: <1199374098.29492.3.camel@vosthea.site> On Thu, 2008-01-03 at 03:32 -0800, Vladimir Krasnov wrote: > Hi Ivan, > > You are right, I've reverted the "Hashtable patch" and everything works > fine. TestGetProperties in TypeDescriptorTests is ok also. > Look at attached patch. > Looks good, please commit, thanks. > > -----Original Message----- > From: mono-devel-list-bounces at lists.ximian.com > [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Ivan N. > Zlatev > Sent: Thursday, January 03, 2008 2:24 AM > To: mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor > > Vladimir Krasnov wrote: > > > > > > Hello, > > > > Please review and approve attached patch for > > TypeDescriptor.GetProperties() method. This fixes the order of > > properties in the returning collection which is important for > > System.Web data bound controls. > > > > You can get rid off the Hashtable used in TypeInfo.GetProperties. I > introduced it because at some point Type.GetProperties used to return > two AnotherProperty PropertyInfos for typeof(B) in the following case: > > class A > { > public string AnotherProperty { > } > } > > class B : A > { > public new string AnotherProperty { > } > } > > It seems to no longer be the case (back then I did not test the > Type.GetProperties behavior on msnet and assumed bug in TypeDescriptor), > but you should test to make sure. You can check test #G2 in > TestGetProperties in TypeDescriptorTests. > > Regards, > -- > Ivan N. Zlatev > > Web: http://www.i-nZ.net > "It's all some kind of whacked out conspiracy." > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Ivan N. Zlatev Web: http://www.i-nZ.net "It's all some kind of whacked out conspiracy." From eyala at mainsoft.com Thu Jan 3 08:34:31 2008 From: eyala at mainsoft.com (Eyal Alaluf) Date: Thu, 3 Jan 2008 05:34:31 -0800 Subject: [Mono-dev] [SPAM] Re: [SPAM] Re: ToString() performace in Mono revisited In-Reply-To: <947E4199BDE74E6994D8E502FF846F68@ansirua> Message-ID: Hi, Andreas. It does make sense to make the 'DblExpTab' common to all appdomains. How do you implement such a scheme in Mono? Is it possible to achieve this without going out to unsafe code and internal methods? If the above is complicated, do you think that it makes sense to consider the above as a separate task since the array size is now 24K and a scenario with 1000 domains is a rare scenario? Thanks, Eyal. -----Original Message----- From: Andreas Nahr [mailto:ClassDevelopment at A-SoftTech.com] Sent: 03 January 2008 11:19 To: Eyal Alaluf; 'Andreas Nahr'; 'Prakash Punnoor'; mono-devel-list at lists.ximian.com Cc: 'Atsushi Eno'; 'Miguel de Icaza'; 'Juraj Skripsky' Subject: AW: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited Sorry that I did not suggest this earlier, but did you look at using a scheme for embedding the Lookuptables in the runtime like e.g. Char does? The problem with using static fields is that they are per-domain and always need to be ("re")initialized. Assume the following (worst) case: We have 1000 Appdomains and each appdomain does a single ToString for a double value. In that case your implementation will: * Consume more than 36MB RAM just for the lookup-tables * Each of the single ToStrings will probably be about 100000 times (just making up a number) slower than now because for every single call you recreate the entire lookuptable(s) Moving the (pregenerated) lookuptables into the runtime will: * Reduce the memory to a *single* instance of the lookuptable for all Appdomains/Processes * Potentially reduce memory by using mem-mapping * Remove *ALL* initialization, which means full speed even with a single ToString call. * Nearly no overhead except a single internalcall to retieve the datapointer(s) * No race-conditions, no locking This way it might even make sense to keep some of the original _decHex Tables (maybe reduced in array size and do they both need Int32 anyways?). Greetings Andreas -----Urspr?ngliche Nachricht----- Von: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag von Eyal Alaluf Gesendet: Donnerstag, 3. Januar 2008 09:21 An: Andreas Nahr; Prakash Punnoor; mono-devel-list at lists.ximian.com Cc: Atsushi Eno; Miguel de Icaza; Juraj Skripsky Betreff: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited Hi, all. Let me try to clarify a few things: 1. The "Hex support" is not for hexadecimal formatting but for speeding up decimal formatting. 2. Following the reviews about the array size, the _decHexLen' array is removed and the '_decHexDigits' is reduced to size of 400 bytes. 3. The third array that is part of the double ToString algorithm is already defined within a nested class and will be initialized only when a double/float ToString is invoked. Attached is a revised version of 'NumberFormatter.cs' that includes these changes. Eyal. -----Original Message----- From: Andreas Nahr [mailto:ClassDevelopment at A-SoftTech.com] Sent: 03 January 2008 03:17 To: 'Prakash Punnoor'; mono-devel-list at lists.ximian.com Cc: 'Miguel de Icaza'; 'Andreas Nahr'; 'Atsushi Eno'; 'Juraj Skripsky'; Eyal Alaluf Subject: AW: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited > > The array initialization should also be done lazily and not in the > > static constructor (should be removed completely because it drags in > > other static fields that need to be preinitialized, code compiled and so on). > > Especially the Hex support is IMHO completely off bounds. I > > (personally) rarely see hex output and making EVERYBODY pay for a > > hex speedup doesn't seem right. A simple if (array == null) Init (); > > will be enough. You will pay per-call, but it is relatively cheap. > > The only thing that is worth keeping in mind is that if this is a > static field, initialization probably needs to be protected by a lock > (I say probably, because we *could* ignore the race by carefully > making sure that we assign the public array only after it has been > initialized, so we would end up with N copies of an array initialized > in the worst case, but N-1 will be discarded by the GC). You can also use the Bill Pugh's trick by using a nested class, so the jit should lazily initialize it (it works with .net, no idea whether it does with mono.) I don't know whether it would work with mono either but you may get additional problems having a nested class in a structure ;) Also there is no need to lock for multithreading. As Miguel wrote we can simply ignore the race in this situation. Worst case two (or n) Lookuparrays get created and all except one immediately garbage-collected after their use. All you need to have is void Init () { int[] temp = new int[x]; doinits() staticField = temp; // Must not happen before doinits() } Greetings Andreas From vargaz at gmail.com Thu Jan 3 09:49:51 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Thu, 3 Jan 2008 15:49:51 +0100 Subject: [Mono-dev] set culture uses serialization? In-Reply-To: <59FD03ED-8580-4878-BFC3-48DEBED853A9@mindtouch.com> References: <59FD03ED-8580-4878-BFC3-48DEBED853A9@mindtouch.com> Message-ID: <295e750a0801030649g108f646elfd748ac013ce3b37@mail.gmail.com> Hi, The current culture is shared between appdomains so the runtime stores it in serialized form. Zoltan On Jan 3, 2008 8:21 AM, Steve Bjorg wrote: > > I ran into the following error today on our system (note: I truncated the > stack for legibility). The interesting part is in bold (prefixed by * in > case the formatting got lost) > > > Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS > Stacktrace: > at (wrapper managed-to-native) > System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) <0x00004> > at (wrapper managed-to-native) > System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) > <0xffffffff> > at System.IO.MemoryStream.set_Capacity (int) <0x0004c> > at System.IO.MemoryStream.Write (byte[],int,int) <0x0007a> > at System.IO.BinaryWriter.Write (string) <0x000c8> > at GregorianCalendar__TypeMetadata.WriteTypeData > (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,System.IO.BinaryWriter,bool) > <0x0001f> > at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject > (System.IO.BinaryWriter,long,object) <0x0020d> > at > System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectInstance > (System.IO.BinaryWriter,object,bool) <0x0014c> > at > System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQueuedObjects > (System.IO.BinaryWriter) <0x0002d> > at > System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectGraph > (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.Header[]) > <0x0003a> > at > System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize > (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header[]) > <0x00206> > * at > System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize > (System.IO.Stream,object) <0x00015> > * at System.Threading.Thread.set_CurrentUICulture > (System.Globalization.CultureInfo) <0x00056> > at MindTouch.Dream.Task.Execute > (System.VoidHandler,MindTouch.Dream.TaskBehavior) <0x00093> > > The odd thing is that it appears setting the culture invokes the > serializer!?! Our async execution framework sets the culture for all > asynchronous operations. Question is, why is it using serialization though? > Can I avoid this somehow and still set the culture? Thx. > > > - Steve > > -------------- > Steve G. Bjorg > http://wiki.mindtouch.com > http://wiki.opengarden.org > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From steveb at mindtouch.com Thu Jan 3 10:30:08 2008 From: steveb at mindtouch.com (Steve Bjorg) Date: Thu, 3 Jan 2008 07:30:08 -0800 Subject: [Mono-dev] set culture uses serialization? In-Reply-To: <295e750a0801030649g108f646elfd748ac013ce3b37@mail.gmail.com> References: <59FD03ED-8580-4878-BFC3-48DEBED853A9@mindtouch.com> <295e750a0801030649g108f646elfd748ac013ce3b37@mail.gmail.com> Message-ID: <53F19FE0-7D14-495F-8553-D2025AA9A21A@mindtouch.com> Zoltan, thx for response. I can see how serialization applies to app domains, but why would it serialize inside the same app domain? Isn't CultureInfo an immutable object? - Steve -------------- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote: > Hi, > > The current culture is shared between appdomains so the runtime > stores it in > serialized form. > > Zoltan > > On Jan 3, 2008 8:21 AM, Steve Bjorg wrote: >> >> I ran into the following error today on our system (note: I >> truncated the >> stack for legibility). The interesting part is in bold (prefixed >> by * in >> case the formatting got lost) >> >> >> Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS >> Stacktrace: >> at (wrapper managed-to-native) >> System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) >> <0x00004> >> at (wrapper managed-to-native) >> System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) >> <0xffffffff> >> at System.IO.MemoryStream.set_Capacity (int) <0x0004c> >> at System.IO.MemoryStream.Write (byte[],int,int) <0x0007a> >> at System.IO.BinaryWriter.Write (string) <0x000c8> >> at GregorianCalendar__TypeMetadata.WriteTypeData >> (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,System.I >> O.BinaryWriter,bool) >> <0x0001f> >> at >> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObje >> ct >> (System.IO.BinaryWriter,long,object) <0x0020d> >> at >> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObje >> ctInstance >> (System.IO.BinaryWriter,object,bool) <0x0014c> >> at >> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQueu >> edObjects >> (System.IO.BinaryWriter) <0x0002d> >> at >> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObje >> ctGraph >> (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.Head >> er[]) >> <0x0003a> >> at >> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serial >> ize >> (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header[]) >> <0x00206> >> * at >> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serial >> ize >> (System.IO.Stream,object) <0x00015> >> * at System.Threading.Thread.set_CurrentUICulture >> (System.Globalization.CultureInfo) <0x00056> >> at MindTouch.Dream.Task.Execute >> (System.VoidHandler,MindTouch.Dream.TaskBehavior) <0x00093> >> >> The odd thing is that it appears setting the culture invokes the >> serializer!?! Our async execution framework sets the culture for all >> asynchronous operations. Question is, why is it using >> serialization though? >> Can I avoid this somehow and still set the culture? Thx. >> >> >> - Steve >> >> -------------- >> Steve G. Bjorg >> http://wiki.mindtouch.com >> http://wiki.opengarden.org >> >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> > > From js at hotfeet.ch Thu Jan 3 11:29:36 2008 From: js at hotfeet.ch (Juraj Skripsky) Date: Thu, 03 Jan 2008 17:29:36 +0100 Subject: [Mono-dev] Accidental changes in commit 91959? Message-ID: <1199377776.2726.37.camel@leonardo.hotfeet.ch> Hi Miguel, I've noticed that you made the following change to System.Net.Mail/SmtpClient.cs in commit 91959*: --- trunk/mcs/class/System/System.Net.Mail/SmtpClient.cs 2007/12/06 14:22:51 90809 +++ trunk/mcs/class/System/System.Net.Mail/SmtpClient.cs 2007/12/27 18:30:23 91959 @@ -275,7 +275,7 @@ private string EncodeBody (AlternateView av) { - Encoding encoding = av.ContentType.CharSet != null ? Encoding.GetEncoding (av.ContentType.CharSet) : Encoding.UTF8; + //Encoding encoding = av.ContentType.CharSet != null ? Encoding.GetEncoding (av.ContentType.CharSet) : Encoding.UTF8; byte [] bytes = new byte [av.ContentStream.Length]; av.ContentStream.Read (bytes, 0, bytes.Length); The Changelog only describes a change to WebClient.cs. There are also two small changes to HttpListenerContext.cs without Changelog entry. Were those changes intended and what's the motivation/Changelog behind them? - Juraj *) http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/System/System.Net.Mail/SmtpClient.cs?rev=91959&view=log From dna at informatik.uni-kiel.de Thu Jan 3 11:34:06 2008 From: dna at informatik.uni-kiel.de (Daniel Nauck) Date: Thu, 03 Jan 2008 17:34:06 +0100 Subject: [Mono-dev] System.Web.Extensions Version 1.0.61025.0 Message-ID: <477D0E7E.6080909@informatik.uni-kiel.de> Hello Igor, you removed the System.Web.Extensions Version 1.0.61025.0 in revision 92081. Now we have a Sys.Web.Extension only for 3.5 and a System.Web.Extensions.Design version 1.0.61025.0. This breaks existing .NET 2.0 Applications that are using the 2.0 AddOn version 1.0.61025.0. I also noticed that on current svn head i got following error (with the 1.0.61025.0 assembly) upgraded from working r89031: System.Web.HttpException: Path '/ScriptResource.axd' was not found. at System.Web.StaticFileHandler.ProcessRequest (System.Web.HttpContext context) [0x00000] at System.Web.HttpApplication+<>c__CompilerGenerated2.MoveNext () [0x00000] at System.Web.HttpApplication.Tick () [0x00000] Daniel From vargaz at gmail.com Thu Jan 3 11:48:25 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Thu, 3 Jan 2008 17:48:25 +0100 Subject: [Mono-dev] set culture uses serialization? In-Reply-To: <53F19FE0-7D14-495F-8553-D2025AA9A21A@mindtouch.com> References: <59FD03ED-8580-4878-BFC3-48DEBED853A9@mindtouch.com> <295e750a0801030649g108f646elfd748ac013ce3b37@mail.gmail.com> <53F19FE0-7D14-495F-8553-D2025AA9A21A@mindtouch.com> Message-ID: <295e750a0801030848t6348550cp9fa38c6578cdda20@mail.gmail.com> Because code in other appdomains might call Thread.CurrentCulture on the same thread object since thread objects are shared between appdomains. Zoltan On Jan 3, 2008 4:30 PM, Steve Bjorg wrote: > Zoltan, thx for response. > > I can see how serialization applies to app domains, but why would it > serialize inside the same app domain? Isn't CultureInfo an immutable > object? > > > - Steve > > -------------- > Steve G. Bjorg > http://wiki.mindtouch.com > http://wiki.opengarden.org > > > > On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote: > > > Hi, > > > > The current culture is shared between appdomains so the runtime > > stores it in > > serialized form. > > > > Zoltan > > > > On Jan 3, 2008 8:21 AM, Steve Bjorg wrote: > >> > >> I ran into the following error today on our system (note: I > >> truncated the > >> stack for legibility). The interesting part is in bold (prefixed > >> by * in > >> case the formatting got lost) > >> > >> > >> Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS > >> Stacktrace: > >> at (wrapper managed-to-native) > >> System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) > >> <0x00004> > >> at (wrapper managed-to-native) > >> System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) > >> <0xffffffff> > >> at System.IO.MemoryStream.set_Capacity (int) <0x0004c> > >> at System.IO.MemoryStream.Write (byte[],int,int) <0x0007a> > >> at System.IO.BinaryWriter.Write (string) <0x000c8> > >> at GregorianCalendar__TypeMetadata.WriteTypeData > >> (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,System.I > >> O.BinaryWriter,bool) > >> <0x0001f> > >> at > >> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObje > >> ct > >> (System.IO.BinaryWriter,long,object) <0x0020d> > >> at > >> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObje > >> ctInstance > >> (System.IO.BinaryWriter,object,bool) <0x0014c> > >> at > >> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQueu > >> edObjects > >> (System.IO.BinaryWriter) <0x0002d> > >> at > >> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObje > >> ctGraph > >> (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.Head > >> er[]) > >> <0x0003a> > >> at > >> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serial > >> ize > >> (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header[]) > >> <0x00206> > >> * at > >> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serial > >> ize > >> (System.IO.Stream,object) <0x00015> > >> * at System.Threading.Thread.set_CurrentUICulture > >> (System.Globalization.CultureInfo) <0x00056> > >> at MindTouch.Dream.Task.Execute > >> (System.VoidHandler,MindTouch.Dream.TaskBehavior) <0x00093> > >> > >> The odd thing is that it appears setting the culture invokes the > >> serializer!?! Our async execution framework sets the culture for all > >> asynchronous operations. Question is, why is it using > >> serialization though? > >> Can I avoid this somehow and still set the culture? Thx. > >> > >> > >> - Steve > >> > >> -------------- > >> Steve G. Bjorg > >> http://wiki.mindtouch.com > >> http://wiki.opengarden.org > >> > >> > >> _______________________________________________ > >> Mono-devel-list mailing list > >> Mono-devel-list at lists.ximian.com > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > >> > >> > > > > > > From igorz at mainsoft.com Thu Jan 3 12:01:24 2008 From: igorz at mainsoft.com (Igor Zelmanovich) Date: Thu, 3 Jan 2008 09:01:24 -0800 Subject: [Mono-dev] System.Web.Extensions Version 1.0.61025.0 In-Reply-To: <477D0E7E.6080909@informatik.uni-kiel.de> References: <477D0E7E.6080909@informatik.uni-kiel.de> Message-ID: Daniel, I will revert version to 1.0.61025.0, It suppose to solve the problems. Igor. -----Original Message----- From: Daniel Nauck [mailto:dna at informatik.uni-kiel.de] Sent: Thursday, January 03, 2008 6:34 PM To: Igor Zelmanovich; mono-devel-list at lists.ximian.com Cc: Marek Habersack Subject: System.Web.Extensions Version 1.0.61025.0 Hello Igor, you removed the System.Web.Extensions Version 1.0.61025.0 in revision 92081. Now we have a Sys.Web.Extension only for 3.5 and a System.Web.Extensions.Design version 1.0.61025.0. This breaks existing .NET 2.0 Applications that are using the 2.0 AddOn version 1.0.61025.0. I also noticed that on current svn head i got following error (with the 1.0.61025.0 assembly) upgraded from working r89031: System.Web.HttpException: Path '/ScriptResource.axd' was not found. at System.Web.StaticFileHandler.ProcessRequest (System.Web.HttpContext context) [0x00000] at System.Web.HttpApplication+<>c__CompilerGenerated2.MoveNext () [0x00000] at System.Web.HttpApplication.Tick () [0x00000] Daniel From steveb at mindtouch.com Thu Jan 3 12:40:19 2008 From: steveb at mindtouch.com (Steve Bjorg) Date: Thu, 3 Jan 2008 09:40:19 -0800 Subject: [Mono-dev] set culture uses serialization? In-Reply-To: <295e750a0801030848t6348550cp9fa38c6578cdda20@mail.gmail.com> References: <59FD03ED-8580-4878-BFC3-48DEBED853A9@mindtouch.com> <295e750a0801030649g108f646elfd748ac013ce3b37@mail.gmail.com> <53F19FE0-7D14-495F-8553-D2025AA9A21A@mindtouch.com> <295e750a0801030848t6348550cp9fa38c6578cdda20@mail.gmail.com> Message-ID: <3F0A15AF-9EF4-406D-9015-4C69C4462DDC@mindtouch.com> In short, I cannot change the current culture without incurring the serialization cost, correct? Or am I missing something? - Steve -------------- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 8:48 AM, Zoltan Varga wrote: > Because code in other appdomains might call Thread.CurrentCulture > on the same > thread object since thread objects are shared between appdomains. > > Zoltan > > On Jan 3, 2008 4:30 PM, Steve Bjorg wrote: >> Zoltan, thx for response. >> >> I can see how serialization applies to app domains, but why would it >> serialize inside the same app domain? Isn't CultureInfo an immutable >> object? >> >> >> - Steve >> >> -------------- >> Steve G. Bjorg >> http://wiki.mindtouch.com >> http://wiki.opengarden.org >> >> >> >> On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote: >> >>> Hi, >>> >>> The current culture is shared between appdomains so the runtime >>> stores it in >>> serialized form. >>> >>> Zoltan >>> >>> On Jan 3, 2008 8:21 AM, Steve Bjorg wrote: >>>> >>>> I ran into the following error today on our system (note: I >>>> truncated the >>>> stack for legibility). The interesting part is in bold (prefixed >>>> by * in >>>> case the formatting got lost) >>>> >>>> >>>> Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS >>>> Stacktrace: >>>> at (wrapper managed-to-native) >>>> System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) >>>> <0x00004> >>>> at (wrapper managed-to-native) >>>> System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) >>>> <0xffffffff> >>>> at System.IO.MemoryStream.set_Capacity (int) <0x0004c> >>>> at System.IO.MemoryStream.Write (byte[],int,int) <0x0007a> >>>> at System.IO.BinaryWriter.Write (string) <0x000c8> >>>> at GregorianCalendar__TypeMetadata.WriteTypeData >>>> (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,System >>>> .I >>>> O.BinaryWriter,bool) >>>> <0x0001f> >>>> at >>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb >>>> je >>>> ct >>>> (System.IO.BinaryWriter,long,object) <0x0020d> >>>> at >>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb >>>> je >>>> ctInstance >>>> (System.IO.BinaryWriter,object,bool) <0x0014c> >>>> at >>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQu >>>> eu >>>> edObjects >>>> (System.IO.BinaryWriter) <0x0002d> >>>> at >>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb >>>> je >>>> ctGraph >>>> (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.He >>>> ad >>>> er[]) >>>> <0x0003a> >>>> at >>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Seri >>>> al >>>> ize >>>> (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header >>>> []) >>>> <0x00206> >>>> * at >>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Seri >>>> al >>>> ize >>>> (System.IO.Stream,object) <0x00015> >>>> * at System.Threading.Thread.set_CurrentUICulture >>>> (System.Globalization.CultureInfo) <0x00056> >>>> at MindTouch.Dream.Task.Execute >>>> (System.VoidHandler,MindTouch.Dream.TaskBehavior) <0x00093> >>>> >>>> The odd thing is that it appears setting the culture invokes the >>>> serializer!?! Our async execution framework sets the culture >>>> for all >>>> asynchronous operations. Question is, why is it using >>>> serialization though? >>>> Can I avoid this somehow and still set the culture? Thx. >>>> >>>> >>>> - Steve >>>> >>>> -------------- >>>> Steve G. Bjorg >>>> http://wiki.mindtouch.com >>>> http://wiki.opengarden.org >>>> >>>> >>>> _______________________________________________ >>>> Mono-devel-list mailing list >>>> Mono-devel-list at lists.ximian.com >>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>> >>>> >>> >>> >> >> > > From gert.driesen at telenet.be Thu Jan 3 12:57:47 2008 From: gert.driesen at telenet.be (Gert Driesen) Date: Thu, 3 Jan 2008 18:57:47 +0100 Subject: [Mono-dev] [PATCH] assembly name fixes for AssemblyName and runtime In-Reply-To: <477B4B93.4010902@gmail.com> Message-ID: <20080103175747.6ED0654070@monty.telenet-ops.be> Hey Andr?s, Yes, you're right. I've updated that bug report with some additional info. Gert -----Original Message----- From: news [mailto:news at ger.gmane.org] On Behalf Of "Andr?s G. Aragoneses [ knocte ]" Sent: woensdag 2 januari 2008 9:30 To: mono-devel-list at lists.ximian.com Subject: Re: [PATCH] assembly name fixes for AssemblyName and runtime Gert Driesen escribi?: > The attached patches fix some issue in self-constructed AssemblyName > instances, and more importantly it fixes the FullName and > GetPublicKey(Token) of AssemblyName instances returned for > AssemblyBuilders and "baked" assemblies. > > For baked assemblies, AssemblyName.FullName did not contain the > PublicKeyToken=null spec for non-signed assemblies, like MS does. > Fixing this involved changes in both corlib and the runtime. > > In the runtime we were also not reporting a failure for an assembly > name containing a Version, Culture or PublicKeyToken spec without an > actual value. Fixing this allows us to enable several tests that were > previously failing. > > More details are available in the changelog for each patch. Hey Gert, looking the tests briefly it seems that this patch would also cover bug 322919, am I right? Regards, Andr?s [ knocte ] -- From miguel at novell.com Thu Jan 3 13:32:40 2008 From: miguel at novell.com (Miguel de Icaza) Date: Thu, 03 Jan 2008 13:32:40 -0500 Subject: [Mono-dev] Accidental changes in commit 91959? In-Reply-To: <1199377776.2726.37.camel@leonardo.hotfeet.ch> References: <1199377776.2726.37.camel@leonardo.hotfeet.ch> Message-ID: <1199385160.3965.49.camel@erandi.boston.ximian.com> Hey, > The Changelog only describes a change to WebClient.cs. There are also > two small changes to HttpListenerContext.cs without Changelog entry. > > Were those changes intended and what's the motivation/Changelog behind > them? I forgot to update the ChangeLog for that, but the only reason for the change was that "encoding" was an unused variable, so it removed the warning that we got on every build. > - Juraj > > > *) http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/System/System.Net.Mail/SmtpClient.cs?rev=91959&view=log > > From js at hotfeet.ch Thu Jan 3 13:33:35 2008 From: js at hotfeet.ch (Juraj Skripsky) Date: Thu, 03 Jan 2008 19:33:35 +0100 Subject: [Mono-dev] Accidental changes in commit 91959? In-Reply-To: <1199385160.3965.49.camel@erandi.boston.ximian.com> References: <1199377776.2726.37.camel@leonardo.hotfeet.ch> <1199385160.3965.49.camel@erandi.boston.ximian.com> Message-ID: <1199385215.2726.43.camel@leonardo.hotfeet.ch> Ah, I see. Sorry about the noise then. - Juraj On Thu, 2008-01-03 at 13:32 -0500, Miguel de Icaza wrote: > Hey, > > > The Changelog only describes a change to WebClient.cs. There are also > > two small changes to HttpListenerContext.cs without Changelog entry. > > > > Were those changes intended and what's the motivation/Changelog behind > > them? > > I forgot to update the ChangeLog for that, but the only reason for the > change was that "encoding" was an unused variable, so it removed the > warning that we got on every build. > > > - Juraj > > > > > > *) http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/System/System.Net.Mail/SmtpClient.cs?rev=91959&view=log > > > > > From vargaz at gmail.com Thu Jan 3 14:17:15 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Thu, 3 Jan 2008 20:17:15 +0100 Subject: [Mono-dev] set culture uses serialization? In-Reply-To: <3F0A15AF-9EF4-406D-9015-4C69C4462DDC@mindtouch.com> References: <59FD03ED-8580-4878-BFC3-48DEBED853A9@mindtouch.com> <295e750a0801030649g108f646elfd748ac013ce3b37@mail.gmail.com> <53F19FE0-7D14-495F-8553-D2025AA9A21A@mindtouch.com> <295e750a0801030848t6348550cp9fa38c6578cdda20@mail.gmail.com> <3F0A15AF-9EF4-406D-9015-4C69C4462DDC@mindtouch.com> Message-ID: <295e750a0801031117o19caaf2bh4d3e40eb3da3e702@mail.gmail.com> You could try calling Thread.CurrentCulture, compare the return value with the culture you want to set, and only call the setter if the two are different. Zoltan On Jan 3, 2008 6:40 PM, Steve Bjorg wrote: > In short, I cannot change the current culture without incurring the > serialization cost, correct? Or am I missing something? > > - Steve > > -------------- > Steve G. Bjorg > http://wiki.mindtouch.com > http://wiki.opengarden.org > > > > On Jan 3, 2008, at 8:48 AM, Zoltan Varga wrote: > > > Because code in other appdomains might call Thread.CurrentCulture > > on the same > > thread object since thread objects are shared between appdomains. > > > > Zoltan > > > > On Jan 3, 2008 4:30 PM, Steve Bjorg wrote: > >> Zoltan, thx for response. > >> > >> I can see how serialization applies to app domains, but why would it > >> serialize inside the same app domain? Isn't CultureInfo an immutable > >> object? > >> > >> > >> - Steve > >> > >> -------------- > >> Steve G. Bjorg > >> http://wiki.mindtouch.com > >> http://wiki.opengarden.org > >> > >> > >> > >> On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote: > >> > >>> Hi, > >>> > >>> The current culture is shared between appdomains so the runtime > >>> stores it in > >>> serialized form. > >>> > >>> Zoltan > >>> > >>> On Jan 3, 2008 8:21 AM, Steve Bjorg wrote: > >>>> > >>>> I ran into the following error today on our system (note: I > >>>> truncated the > >>>> stack for legibility). The interesting part is in bold (prefixed > >>>> by * in > >>>> case the formatting got lost) > >>>> > >>>> > >>>> Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS > >>>> Stacktrace: > >>>> at (wrapper managed-to-native) > >>>> System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) > >>>> <0x00004> > >>>> at (wrapper managed-to-native) > >>>> System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) > >>>> <0xffffffff> > >>>> at System.IO.MemoryStream.set_Capacity (int) <0x0004c> > >>>> at System.IO.MemoryStream.Write (byte[],int,int) <0x0007a> > >>>> at System.IO.BinaryWriter.Write (string) <0x000c8> > >>>> at GregorianCalendar__TypeMetadata.WriteTypeData > >>>> (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,System > >>>> .I > >>>> O.BinaryWriter,bool) > >>>> <0x0001f> > >>>> at > >>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb > >>>> je > >>>> ct > >>>> (System.IO.BinaryWriter,long,object) <0x0020d> > >>>> at > >>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb > >>>> je > >>>> ctInstance > >>>> (System.IO.BinaryWriter,object,bool) <0x0014c> > >>>> at > >>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQu > >>>> eu > >>>> edObjects > >>>> (System.IO.BinaryWriter) <0x0002d> > >>>> at > >>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb > >>>> je > >>>> ctGraph > >>>> (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.He > >>>> ad > >>>> er[]) > >>>> <0x0003a> > >>>> at > >>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Seri > >>>> al > >>>> ize > >>>> (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header > >>>> []) > >>>> <0x00206> > >>>> * at > >>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Seri > >>>> al > >>>> ize > >>>> (System.IO.Stream,object) <0x00015> > >>>> * at System.Threading.Thread.set_CurrentUICulture > >>>> (System.Globalization.CultureInfo) <0x00056> > >>>> at MindTouch.Dream.Task.Execute > >>>> (System.VoidHandler,MindTouch.Dream.TaskBehavior) <0x00093> > >>>> > >>>> The odd thing is that it appears setting the culture invokes the > >>>> serializer!?! Our async execution framework sets the culture > >>>> for all > >>>> asynchronous operations. Question is, why is it using > >>>> serialization though? > >>>> Can I avoid this somehow and still set the culture? Thx. > >>>> > >>>> > >>>> - Steve > >>>> > >>>> -------------- > >>>> Steve G. Bjorg > >>>> http://wiki.mindtouch.com > >>>> http://wiki.opengarden.org > >>>> > >>>> > >>>> _______________________________________________ > >>>> Mono-devel-list mailing list > >>>> Mono-devel-list at lists.ximian.com > >>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > From steveb at mindtouch.com Thu Jan 3 14:37:39 2008 From: steveb at mindtouch.com (Steve Bjorg) Date: Thu, 3 Jan 2008 11:37:39 -0800 Subject: [Mono-dev] set culture uses serialization? In-Reply-To: <295e750a0801031117o19caaf2bh4d3e40eb3da3e702@mail.gmail.com> References: <59FD03ED-8580-4878-BFC3-48DEBED853A9@mindtouch.com> <295e750a0801030649g108f646elfd748ac013ce3b37@mail.gmail.com> <53F19FE0-7D14-495F-8553-D2025AA9A21A@mindtouch.com> <295e750a0801030848t6348550cp9fa38c6578cdda20@mail.gmail.com> <3F0A15AF-9EF4-406D-9015-4C69C4462DDC@mindtouch.com> <295e750a0801031117o19caaf2bh4d3e40eb3da3e702@mail.gmail.com> Message-ID: <0645B905-C54D-40C8-8200-B806366CEA5D@mindtouch.com> Well, the application runs in 10 different languages simultaneously. So, this is only going to help in a few cases. In other words, I should forget about CurrentCulture and instead use a manual override in all my date and number formatting invocations? That's going to be a major pain... :( Is this how it behaves under .Net as well? I'm really surprised about the behavior since CultureInfo is immutable (afaik). - Steve --------------------------------- Steve G. Bjorg MindTouch 555 W. Beech St. Suite 501 San Diego, CA 92101 619.795.8459x1106 office 619.795.3948 fax 425.891.5913 mobile On Jan 3, 2008, at 11:17 AM, Zoltan Varga wrote: > You could try calling Thread.CurrentCulture, compare the return > value with the > culture you want to set, and only call the setter if the two are > different. > > Zoltan > > On Jan 3, 2008 6:40 PM, Steve Bjorg wrote: >> In short, I cannot change the current culture without incurring the >> serialization cost, correct? Or am I missing something? >> >> - Steve >> >> -------------- >> Steve G. Bjorg >> http://wiki.mindtouch.com >> http://wiki.opengarden.org >> >> >> >> On Jan 3, 2008, at 8:48 AM, Zoltan Varga wrote: >> >>> Because code in other appdomains might call Thread.CurrentCulture >>> on the same >>> thread object since thread objects are shared between appdomains. >>> >>> Zoltan >>> >>> On Jan 3, 2008 4:30 PM, Steve Bjorg wrote: >>>> Zoltan, thx for response. >>>> >>>> I can see how serialization applies to app domains, but why >>>> would it >>>> serialize inside the same app domain? Isn't CultureInfo an >>>> immutable >>>> object? >>>> >>>> >>>> - Steve >>>> >>>> -------------- >>>> Steve G. Bjorg >>>> http://wiki.mindtouch.com >>>> http://wiki.opengarden.org >>>> >>>> >>>> >>>> On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote: >>>> >>>>> Hi, >>>>> >>>>> The current culture is shared between appdomains so the runtime >>>>> stores it in >>>>> serialized form. >>>>> >>>>> Zoltan >>>>> >>>>> On Jan 3, 2008 8:21 AM, Steve Bjorg wrote: >>>>>> >>>>>> I ran into the following error today on our system (note: I >>>>>> truncated the >>>>>> stack for legibility). The interesting part is in bold (prefixed >>>>>> by * in >>>>>> case the formatting got lost) >>>>>> >>>>>> >>>>>> Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS >>>>>> Stacktrace: >>>>>> at (wrapper managed-to-native) >>>>>> System.Object.__icall_wrapper_mono_array_new_specific >>>>>> (intptr,int) >>>>>> <0x00004> >>>>>> at (wrapper managed-to-native) >>>>>> System.Object.__icall_wrapper_mono_array_new_specific >>>>>> (intptr,int) >>>>>> <0xffffffff> >>>>>> at System.IO.MemoryStream.set_Capacity (int) <0x0004c> >>>>>> at System.IO.MemoryStream.Write (byte[],int,int) <0x0007a> >>>>>> at System.IO.BinaryWriter.Write (string) <0x000c8> >>>>>> at GregorianCalendar__TypeMetadata.WriteTypeData >>>>>> (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,Syst >>>>>> em >>>>>> .I >>>>>> O.BinaryWriter,bool) >>>>>> <0x0001f> >>>>>> at >>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write >>>>>> Ob >>>>>> je >>>>>> ct >>>>>> (System.IO.BinaryWriter,long,object) <0x0020d> >>>>>> at >>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write >>>>>> Ob >>>>>> je >>>>>> ctInstance >>>>>> (System.IO.BinaryWriter,object,bool) <0x0014c> >>>>>> at >>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write >>>>>> Qu >>>>>> eu >>>>>> edObjects >>>>>> (System.IO.BinaryWriter) <0x0002d> >>>>>> at >>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write >>>>>> Ob >>>>>> je >>>>>> ctGraph >>>>>> (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging. >>>>>> He >>>>>> ad >>>>>> er[]) >>>>>> <0x0003a> >>>>>> at >>>>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Se >>>>>> ri >>>>>> al >>>>>> ize >>>>>> (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header >>>>>> []) >>>>>> <0x00206> >>>>>> * at >>>>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Se >>>>>> ri >>>>>> al >>>>>> ize >>>>>> (System.IO.Stream,object) <0x00015> >>>>>> * at System.Threading.Thread.set_CurrentUICulture >>>>>> (System.Globalization.CultureInfo) <0x00056> >>>>>> at MindTouch.Dream.Task.Execute >>>>>> (System.VoidHandler,MindTouch.Dream.TaskBehavior) <0x00093> >>>>>> >>>>>> The odd thing is that it appears setting the culture invokes the >>>>>> serializer!?! Our async execution framework sets the culture >>>>>> for all >>>>>> asynchronous operations. Question is, why is it using >>>>>> serialization though? >>>>>> Can I avoid this somehow and still set the culture? Thx. >>>>>> >>>>>> >>>>>> - Steve >>>>>> >>>>>> -------------- >>>>>> Steve G. Bjorg >>>>>> http://wiki.mindtouch.com >>>>>> http://wiki.opengarden.org >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mono-devel-list mailing list >>>>>> Mono-devel-list at lists.ximian.com >>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From vargaz at gmail.com Thu Jan 3 14:59:01 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Thu, 3 Jan 2008 20:59:01 +0100 Subject: [Mono-dev] set culture uses serialization? In-Reply-To: <0645B905-C54D-40C8-8200-B806366CEA5D@mindtouch.com> References: <59FD03ED-8580-4878-BFC3-48DEBED853A9@mindtouch.com> <295e750a0801030649g108f646elfd748ac013ce3b37@mail.gmail.com> <53F19FE0-7D14-495F-8553-D2025AA9A21A@mindtouch.com> <295e750a0801030848t6348550cp9fa38c6578cdda20@mail.gmail.com> <3F0A15AF-9EF4-406D-9015-4C69C4462DDC@mindtouch.com> <295e750a0801031117o19caaf2bh4d3e40eb3da3e702@mail.gmail.com> <0645B905-C54D-40C8-8200-B806366CEA5D@mindtouch.com> Message-ID: <295e750a0801031159o410474c1gd10abc1a803034e5@mail.gmail.com> Hi, CultureInfo might be inmutable, but its components like NumberFormatInfo are not. Also, even if it is inmutable, objects cannot be shared across appdomains, so we couldn't use the object set by the application in another domain. We assume that the thread culture is set only rarely, so the serialization overhead should not be a problem. Zoltan On Jan 3, 2008 8:37 PM, Steve Bjorg wrote: > Well, the application runs in 10 different languages simultaneously. > So, this is only going to help in a few cases. In other words, I > should forget about CurrentCulture and instead use a manual override > in all my date and number formatting invocations? That's going to be > a major pain... :( > > Is this how it behaves under .Net as well? I'm really surprised > about the behavior since CultureInfo is immutable (afaik). > > > - Steve > > --------------------------------- > Steve G. Bjorg > > MindTouch > 555 W. Beech St. > Suite 501 > San Diego, CA 92101 > > 619.795.8459x1106 office > 619.795.3948 fax > 425.891.5913 mobile > > > > > On Jan 3, 2008, at 11:17 AM, Zoltan Varga wrote: > > > You could try calling Thread.CurrentCulture, compare the return > > value with the > > culture you want to set, and only call the setter if the two are > > different. > > > > Zoltan > > > > On Jan 3, 2008 6:40 PM, Steve Bjorg wrote: > >> In short, I cannot change the current culture without incurring the > >> serialization cost, correct? Or am I missing something? > >> > >> - Steve > >> > >> -------------- > >> Steve G. Bjorg > >> http://wiki.mindtouch.com > >> http://wiki.opengarden.org > >> > >> > >> > >> On Jan 3, 2008, at 8:48 AM, Zoltan Varga wrote: > >> > >>> Because code in other appdomains might call Thread.CurrentCulture > >>> on the same > >>> thread object since thread objects are shared between appdomains. > >>> > >>> Zoltan > >>> > >>> On Jan 3, 2008 4:30 PM, Steve Bjorg wrote: > >>>> Zoltan, thx for response. > >>>> > >>>> I can see how serialization applies to app domains, but why > >>>> would it > >>>> serialize inside the same app domain? Isn't CultureInfo an > >>>> immutable > >>>> object? > >>>> > >>>> > >>>> - Steve > >>>> > >>>> -------------- > >>>> Steve G. Bjorg > >>>> http://wiki.mindtouch.com > >>>> http://wiki.opengarden.org > >>>> > >>>> > >>>> > >>>> On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> The current culture is shared between appdomains so the runtime > >>>>> stores it in > >>>>> serialized form. > >>>>> > >>>>> Zoltan > >>>>> > >>>>> On Jan 3, 2008 8:21 AM, Steve Bjorg wrote: > >>>>>> > >>>>>> I ran into the following error today on our system (note: I > >>>>>> truncated the > >>>>>> stack for legibility). The interesting part is in bold (prefixed > >>>>>> by * in > >>>>>> case the formatting got lost) > >>>>>> > >>>>>> > >>>>>> Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS > >>>>>> Stacktrace: > >>>>>> at (wrapper managed-to-native) > >>>>>> System.Object.__icall_wrapper_mono_array_new_specific > >>>>>> (intptr,int) > >>>>>> <0x00004> > >>>>>> at (wrapper managed-to-native) > >>>>>> System.Object.__icall_wrapper_mono_array_new_specific > >>>>>> (intptr,int) > >>>>>> <0xffffffff> > >>>>>> at System.IO.MemoryStream.set_Capacity (int) <0x0004c> > >>>>>> at System.IO.MemoryStream.Write (byte[],int,int) <0x0007a> > >>>>>> at System.IO.BinaryWriter.Write (string) <0x000c8> > >>>>>> at GregorianCalendar__TypeMetadata.WriteTypeData > >>>>>> (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,Syst > >>>>>> em > >>>>>> .I > >>>>>> O.BinaryWriter,bool) > >>>>>> <0x0001f> > >>>>>> at > >>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write > >>>>>> Ob > >>>>>> je > >>>>>> ct > >>>>>> (System.IO.BinaryWriter,long,object) <0x0020d> > >>>>>> at > >>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write > >>>>>> Ob > >>>>>> je > >>>>>> ctInstance > >>>>>> (System.IO.BinaryWriter,object,bool) <0x0014c> > >>>>>> at > >>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write > >>>>>> Qu > >>>>>> eu > >>>>>> edObjects > >>>>>> (System.IO.BinaryWriter) <0x0002d> > >>>>>> at > >>>>>> System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write > >>>>>> Ob > >>>>>> je > >>>>>> ctGraph > >>>>>> (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging. > >>>>>> He > >>>>>> ad > >>>>>> er[]) > >>>>>> <0x0003a> > >>>>>> at > >>>>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Se > >>>>>> ri > >>>>>> al > >>>>>> ize > >>>>>> (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header > >>>>>> []) > >>>>>> <0x00206> > >>>>>> * at > >>>>>> System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Se > >>>>>> ri > >>>>>> al > >>>>>> ize > >>>>>> (System.IO.Stream,object) <0x00015> > >>>>>> * at System.Threading.Thread.set_CurrentUICulture > >>>>>> (System.Globalization.CultureInfo) <0x00056> > >>>>>> at MindTouch.Dream.Task.Execute > >>>>>> (System.VoidHandler,MindTouch.Dream.TaskBehavior) <0x00093> > >>>>>> > >>>>>> The odd thing is that it appears setting the culture invokes the > >>>>>> serializer!?! Our async execution framework sets the culture > >>>>>> for all > >>>>>> asynchronous operations. Question is, why is it using > >>>>>> serialization though? > >>>>>> Can I avoid this somehow and still set the culture? Thx. > >>>>>> > >>>>>> > >>>>>> - Steve > >>>>>> > >>>>>> -------------- > >>>>>> Steve G. Bjorg > >>>>>> http://wiki.mindtouch.com > >>>>>> http://wiki.opengarden.org > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Mono-devel-list mailing list > >>>>>> Mono-devel-list at lists.ximian.com > >>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > From steveb at mindtouch.com Thu Jan 3 15:22:29 2008 From: steveb at mindtouch.com (Steve Bjorg) Date: Thu, 3 Jan 2008 12:22:29 -0800 Subject: [Mono-dev] set culture uses serialization? In-Reply-To: <295e750a0801031159o410474c1gd10abc1a803034e5@mail.gmail.com> References: <59FD03ED-8580-4878-BFC3-48DEBED853A9@mindtouch.com> <295e750a0801030649g108f646elfd748ac013ce3b37@mail.gmail.com> <53F19FE0-7D14-495F-8553-D2025AA9A21A@mindtouch.com> <295e750a0801030848t6348550cp9fa38c6578cdda20@mail.gmail.com> <3F0A15AF-9EF4-406D-9015-4C69C4462DDC@mindtouch.com> <295e750a0801031117o19caaf2bh4d3e40eb3da3e702@mail.gmail.com> <0645B905-C54D-40C8-8200-B806366CEA5D@mindtouch.com> <295e750a0801031159o410474c1gd10abc1a803034e5@mail.gmail.com> Message-ID: <05D1F4CE-3E58-4F05-AA0C-468A01B1A1F5@mindtouch.com> Zoltan, thanks again for your quick reply. That assumption might be true for desktop applications, but not for a server which runs a localized application. Each request is handled in the website's configured culture. The matter is made even worse when the server tries to be smart and handle the request by using asynchronous operations. Each completion handler must reset the current culture since it it will resume on an arbitrary thread of the thread pool. Maybe I'm going all wrong about this? What is the recommended pattern for running a localized web-application that uses asynchronous operations? - Steve -------------- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 11:59 AM, Zoltan Varga wrote: > Hi, > > CultureInfo might be inmutable, but its components like > NumberFormatInfo are not. > Also, even if it is inmutable, objects cannot be shared across > appdomains, so we > couldn't use the object set by the application in another domain. > We assume that the thread culture is set only rarely, so the > serialization overhead > should not be a problem. > > Zoltan > > On Jan 3, 2008 8:37 PM, Steve Bjorg wrote: >> Well, the application runs in 10 different languages simultaneously. >> So, this is only going to help in a few cases. In other words, I >> should