From russell.kay at realtimeworlds.com Fri Aug 1 10:15:44 2008 From: russell.kay at realtimeworlds.com (russell.kay at realtimeworlds.com) Date: Fri, 1 Aug 2008 15:15:44 +0100 Subject: [Mono-dev] Win32 Mono 2.0 compiled from SVN branch - dies inside mono_get_lmf_addr Message-ID: All, Does anyone have any ideas why I am seeing my code dying inside mono_get_lmf_addr at the g_assert_not_reached(), it looks like this code has something to do with trampolines but there are not a lot of comments around this function. I have compiled mono from the 2.0 branch (using cygwin) and everything else seems to be working fine, well I am seeing what I expect, just it is dying on exit. The code that I am running is using System.Timers.Timer, running around 10 of them and it dies on exit. Does anyone have any ideas why it may be hanging? Russell ____________________________________________________________________ DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080801/0d9eba44/attachment.html From billholmes54 at gmail.com Fri Aug 1 10:30:59 2008 From: billholmes54 at gmail.com (Bill Holmes) Date: Fri, 1 Aug 2008 10:30:59 -0400 Subject: [Mono-dev] [PATCH] eglib memory allocation changes Message-ID: <37c5788d0808010730t3776ffcbh8bdaa0aa9d12f056@mail.gmail.com> Hello All, Attached is a patch to change eglib memory allocation methods to return NULL if the size is passed in is zero. If this is approved I would also like to put it into the 2.0 branch. I tracked a bug to load_modules in image.c. In this particular case image->modules was being set to a non-null value when the image->module_count was equal to 0. There is another area of the code later that checks the modules but not he module_count and causes an assert. I could have simply changed this code but after reading the glib documentation I believe that this patch is the right change. Also there may be more critical areas that I have not discovered yet that could hit this problem. Documentation malloc If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned. calloc If either nelem or elsize is 0, then either a null pointer or a unique pointer value that can be successfully passed to free() shall be returned. realloc If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned. If size is 0 and ptr is not a null pointer, the object pointed to is freed. g_malloc If n_bytes is 0 it returns NULL. g_malloc0 () If n_bytes is 0 it returns NULL. g_realloc () n_bytes may be 0, in which case NULL will be returned and mem will be freed unless it is NULL. thanks -bill -------------- next part -------------- A non-text attachment was scrubbed... Name: g_allocation_08_08_01.diff Type: application/octet-stream Size: 2203 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080801/a47d8bbc/attachment.obj From robertj at gmx.net Fri Aug 1 11:08:54 2008 From: robertj at gmx.net (Robert Jordan) Date: Fri, 01 Aug 2008 17:08:54 +0200 Subject: [Mono-dev] Win32 Mono 2.0 compiled from SVN branch - dies inside mono_get_lmf_addr In-Reply-To: References: Message-ID: russell.kay at realtimeworlds.com wrote: > All, > > > > Does anyone have any ideas why I am seeing my code dying inside > mono_get_lmf_addr at the g_assert_not_reached(), it looks like this code > has something to do with trampolines but there are not a lot of comments > around this function. > > > > I have compiled mono from the 2.0 branch (using cygwin) and everything > else seems to be working fine, well I am seeing what I expect, just it > is dying on exit. > > > > The code that I am running is using System.Timers.Timer, running around > 10 of them and it dies on exit. Please file a bug with a test case at http://www.mono-project.com/Bugs. Robert From selvakumar at touchpointindia.com Fri Aug 1 03:04:41 2008 From: selvakumar at touchpointindia.com (Selvakumar) Date: Fri, 01 Aug 2008 12:34:41 +0530 Subject: [Mono-dev] mono run time not found Message-ID: <4892B589.7060007@touchpointindia.com> hai, i am using mono 1.9.1 for windows and vspr2make ver 0.99.0.2 but when i click test mono i got error message box that is mono runtime not found now what i do pls help me -- Thanks & Regards, Selva kumar.A From vargaz at gmail.com Fri Aug 1 16:55:24 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Fri, 1 Aug 2008 22:55:24 +0200 Subject: [Mono-dev] [PATCH] eglib memory allocation changes In-Reply-To: <37c5788d0808010730t3776ffcbh8bdaa0aa9d12f056@mail.gmail.com> References: <37c5788d0808010730t3776ffcbh8bdaa0aa9d12f056@mail.gmail.com> Message-ID: <295e750a0808011355l2f2a034cm3a58110587b50f18@mail.gmail.com> Hi, Approved. Zoltan 2008/8/1 Bill Holmes : > Hello All, > > Attached is a patch to change eglib memory allocation methods to > return NULL if the size is passed in is zero. If this is approved I > would also like to put it into the 2.0 branch. > > I tracked a bug to load_modules in image.c. In this particular case > image->modules was being set to a non-null value when the > image->module_count was equal to 0. There is another area of the code > later that checks the modules but not he module_count and causes an > assert. I could have simply changed this code but after reading the > glib documentation I believe that this patch is the right change. > Also there may be more critical areas that I have not discovered yet > that could hit this problem. > > Documentation > > malloc > If size is 0, either a null pointer or a unique pointer that can be > successfully passed to free() shall be returned. > > calloc > If either nelem or elsize is 0, then either a null pointer or a unique > pointer value that can be successfully passed to free() shall be > returned. > > realloc > If size is 0, either a null pointer or a unique pointer that can be > successfully passed to free() shall be returned. > If size is 0 and ptr is not a null pointer, the object pointed to is freed. > > g_malloc > If n_bytes is 0 it returns NULL. > > g_malloc0 () > If n_bytes is 0 it returns NULL. > > g_realloc () > n_bytes may be 0, in which case NULL will be returned and mem will be > freed unless it is NULL. > > thanks > -bill > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From mchristensen at novell.com Fri Aug 1 19:05:52 2008 From: mchristensen at novell.com (Marc Christensen) Date: Fri, 01 Aug 2008 17:05:52 -0600 Subject: [Mono-dev] Mono 2.0 Preview 1 is out!! Message-ID: <489396D0.6020509@novell.com> Hey Everyone, We've just released Mono 2.0 Preview 1 today! Please help us out by giving it a try with your applications. As always, you can get the preview releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them! http://www.mono-project.com/Bugs You can see the bugs we're tracking for Mono 2.0 here: https://bugzilla.novell.com/buglist.cgi?bug_file_loc_type=allwordssubstr&bug_file_loc=http%3A%2F%2Fwww.go-mono.com%2Farchive%2F2.0%2F&order=bugs.bug_status%20 The earlier you file the bugs and reply to this message, the more likely your bugs will get fixed. Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you tag the summary of the bug with [Regression], then it is much more likely your bug will get fixed. Please help the Mono team to make 2.0 the best ever. Thanks again! Mono QA From atsushi at ximian.com Fri Aug 1 22:51:27 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Sat, 02 Aug 2008 11:51:27 +0900 Subject: [Mono-dev] Mono 2.0 Preview 1 is out!! In-Reply-To: <489396D0.6020509@novell.com> References: <489396D0.6020509@novell.com> Message-ID: <4893CBAF.0@ximian.com> To make sure, the release notes contain changes only from 1.9 (unlike the page title implies), right? Atsushi Eno Marc Christensen wrote: > Hey Everyone, > > We've just released Mono 2.0 Preview 1 today! Please help us out by > giving it a try with your applications. > > As always, you can get the preview releases here: > http://mono.ximian.com/monobuild/preview/download-preview/ > > Please report any bugs that you may find using our Bugs page, AND reply > to this thread with the bug numbers so we can track them! > http://www.mono-project.com/Bugs > > You can see the bugs we're tracking for Mono 2.0 here: > https://bugzilla.novell.com/buglist.cgi?bug_file_loc_type=allwordssubstr&bug_file_loc=http%3A%2F%2Fwww.go-mono.com%2Farchive%2F2.0%2F&order=bugs.bug_status%20 > > The earlier you file the bugs and reply to this message, the more likely > your bugs will get fixed. > > Special attention is given to regressions, so if you can tell us a > version of Mono where the bug worked and you tag the summary of the bug > with [Regression], then it is much more likely your bug will get fixed. > > Please help the Mono team to make 2.0 the best ever. > > Thanks again! > > Mono QA > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From miguel at novell.com Sat Aug 2 00:05:22 2008 From: miguel at novell.com (Miguel de Icaza) Date: Sat, 02 Aug 2008 00:05:22 -0400 Subject: [Mono-dev] Mono 2.0 Preview 1 is out!! In-Reply-To: <4893CBAF.0@ximian.com> References: <489396D0.6020509@novell.com> <4893CBAF.0@ximian.com> Message-ID: <1217649922.8518.0.camel@linux-bytm.site> Hello, > To make sure, the release notes contain changes only from 1.9 (unlike > the page title implies), right? The release notes includes changes since 1.9, and contains links to the full changes since 1.2.0 Should I get all the release for previous releases consolidated? > Atsushi Eno > > Marc Christensen wrote: > > Hey Everyone, > > > > We've just released Mono 2.0 Preview 1 today! Please help us out by > > giving it a try with your applications. > > > > As always, you can get the preview releases here: > > http://mono.ximian.com/monobuild/preview/download-preview/ > > > > Please report any bugs that you may find using our Bugs page, AND reply > > to this thread with the bug numbers so we can track them! > > http://www.mono-project.com/Bugs > > > > You can see the bugs we're tracking for Mono 2.0 here: > > https://bugzilla.novell.com/buglist.cgi?bug_file_loc_type=allwordssubstr&bug_file_loc=http%3A%2F%2Fwww.go-mono.com%2Farchive%2F2.0%2F&order=bugs.bug_status%20 > > > > The earlier you file the bugs and reply to this message, the more likely > > your bugs will get fixed. > > > > Special attention is given to regressions, so if you can tell us a > > version of Mono where the bug worked and you tag the summary of the bug > > with [Regression], then it is much more likely your bug will get fixed. > > > > Please help the Mono team to make 2.0 the best ever. > > > > Thanks again! > > > > Mono QA > > > > _______________________________________________ > > 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 miguel at novell.com Sat Aug 2 00:07:10 2008 From: miguel at novell.com (Miguel de Icaza) Date: Sat, 02 Aug 2008 00:07:10 -0400 Subject: [Mono-dev] [PATCH] eglib memory allocation changes In-Reply-To: <37c5788d0808010730t3776ffcbh8bdaa0aa9d12f056@mail.gmail.com> References: <37c5788d0808010730t3776ffcbh8bdaa0aa9d12f056@mail.gmail.com> Message-ID: <1217650030.8518.2.camel@linux-bytm.site> Hello, > I tracked a bug to load_modules in image.c. In this particular case > image->modules was being set to a non-null value when the > image->module_count was equal to 0. There is another area of the code > later that checks the modules but not he module_count and causes an > assert. I could have simply changed this code but after reading the > glib documentation I believe that this patch is the right change. > Also there may be more critical areas that I have not discovered yet > that could hit this problem. It would be useful to add unit test cases so this behavior is also enforced in the code. Mind adding those? Miguel. From atsushi at ximian.com Sat Aug 2 00:44:46 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Sat, 02 Aug 2008 13:44:46 +0900 Subject: [Mono-dev] Mono 2.0 Preview 1 is out!! In-Reply-To: <1217649922.8518.0.camel@linux-bytm.site> References: <489396D0.6020509@novell.com> <4893CBAF.0@ximian.com> <1217649922.8518.0.camel@linux-bytm.site> Message-ID: <4893E63E.30002@ximian.com> Hey, When 1.2 was released, we had somewhat summarized version of the release notes which describes difference from 1.0. I was wondering this time if we are to write similar one as well, and put such one as the final release notes. Current document content is (should be) different, while the title implies as if it were for the final release notes. IMO current release notes (including the document title) should be distinguished from the final one. Atsushi Eno Miguel de Icaza wrote: > Hello, > >> To make sure, the release notes contain changes only from 1.9 (unlike >> the page title implies), right? > > The release notes includes changes since 1.9, and contains links to the > full changes since 1.2.0 > > Should I get all the release for previous releases consolidated? > >> Atsushi Eno >> >> Marc Christensen wrote: >>> Hey Everyone, >>> >>> We've just released Mono 2.0 Preview 1 today! Please help us out by >>> giving it a try with your applications. >>> >>> As always, you can get the preview releases here: >>> http://mono.ximian.com/monobuild/preview/download-preview/ >>> >>> Please report any bugs that you may find using our Bugs page, AND reply >>> to this thread with the bug numbers so we can track them! >>> http://www.mono-project.com/Bugs >>> >>> You can see the bugs we're tracking for Mono 2.0 here: >>> https://bugzilla.novell.com/buglist.cgi?bug_file_loc_type=allwordssubstr&bug_file_loc=http%3A%2F%2Fwww.go-mono.com%2Farchive%2F2.0%2F&order=bugs.bug_status%20 >>> >>> The earlier you file the bugs and reply to this message, the more likely >>> your bugs will get fixed. >>> >>> Special attention is given to regressions, so if you can tell us a >>> version of Mono where the bug worked and you tag the summary of the bug >>> with [Regression], then it is much more likely your bug will get fixed. >>> >>> Please help the Mono team to make 2.0 the best ever. >>> >>> Thanks again! >>> >>> Mono QA >>> >>> _______________________________________________ >>> 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 boris.dusek at gmail.com Sat Aug 2 11:25:17 2008 From: boris.dusek at gmail.com (=?UTF-8?Q?Boris_Du=C5=A1ek?=) Date: Sat, 2 Aug 2008 17:25:17 +0200 Subject: [Mono-dev] Mono preview 2.0 binary and DTrace Message-ID: Hi, I grabbed the Mono Preview 2.0 installer for OS X and wanted to test new DTrace probes mentioned in Release Notes[1], but it did not work. On the #mono IRC channel, I learned that DTrace probes in mono are not enabled in the binary packages provided, since it would incur performance penalty even when no tracing is done. However, from the DTrace docs, they say especially that "... No instrumented code is present for inactive probes, so your system does not experience any kind of performance degradation when you are not using DTrace. ... No effective difference exists between a system where DTrace is not active and one where the DTrace software is not installed." (quote from 2nd paragraph of http://docs.sun.com/app/docs/doc/817-6223/chp-intro-3?a=view ) I will understand not having DTrace-enabled Mono binary package for OS X if there is a performance penalty, however in situation when the DTrace documentation states the contrary, and Perl, Python, Ruby and Java SE 6 shipped[1] with OS X Leopard are DTrace-enabled, I really want to know if disabling of DTrace probes in Mono is correctly reasoned. I think with the release notes wording "In MacOS and Solaris Mono supports DTrace probes. To use this feature, you must configure mono with --enable-dtrace.", many people will think like me that the "configure with --enable-dtrace" holds only for compiling from source, and that the Mono binary package offered for download has this enabled just like Java, Python etc. in OS X. I have to note that I am no DTrace usage expert (not to speak about implementation), and started learning DTrace just this Monday, so I am just curious about the situation. Anyway, thanks for making the DTrace probes, compiling Mono from source with --enable-dtrace configure flag, as specified in Release Notes, does the trick. Boris Du?ek [1]: yes, I know it says it must be enabled with configure --enable-dtrace flag, but I thought that holds for compiling from source only and that the binary packages provided for OS X do have this enabled [2]: OK, Java SE 6 was shipped after Leopard From andreas.faerber at web.de Sat Aug 2 12:30:09 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sat, 2 Aug 2008 18:30:09 +0200 Subject: [Mono-dev] Mono preview 2.0 binary and DTrace In-Reply-To: References: Message-ID: Hi, Am 02.08.2008 um 17:25 schrieb Boris Du?ek: > I grabbed the Mono Preview 2.0 installer for OS X and wanted to test > new DTrace probes mentioned in Release Notes[1], but it did not work. Just to be sure, how did you test? As described in mono's man page? > On the #mono IRC channel, I learned that DTrace probes in mono are not > enabled in the binary packages provided, since it would incur > performance penalty even when no tracing is done. I had inquired about the sentence in the Release Notes myself and have not yet received an answer. ;) > However, from the > DTrace docs, they say especially that "... No instrumented code is > present for inactive probes, so your system does not experience any > kind of performance degradation when you are not using DTrace. ... No > effective difference exists between a system where DTrace is not > active and one where the DTrace software is not installed." (quote > from 2nd paragraph of > http://docs.sun.com/app/docs/doc/817-6223/chp-intro-3?a=view ) Not fully true, there is of course a minimal degradation (~5 nop instructions on Solaris), but it should be hardly noticeable. I have taken care to only call helper functions when the probe is active. Was the answer on IRC in any way official? I could think of three possible reasons: a) Worries about performance degradation. b) No one updated the build system. c) The build machine isn't DTrace-capable. The main reason for not automatically enabling DTrace support was that it is somewhat hard to detect correctly. That's why we preferred -- enable-dtrace over --disable-dtrace. So, to get a DTrace-enabled Mono.framework, the build bots need to specify that argument. And I thought we had agreed that if someone is really worried about performance, they should build their own Mono. Inversing this significantly limits the usefulness of the feature as most Mac users will just download the available binary. Not enabling it during the previews is especially bad, since it reduces the amount of testing this new feature gets. Apart from the issue of mono.d not yet being installed, I've been considering marking the provider as stable for better usability. Andreas From gnorton at novell.com Sat Aug 2 13:16:33 2008 From: gnorton at novell.com (Geoff Norton) Date: Sat, 02 Aug 2008 13:16:33 -0400 Subject: [Mono-dev] Mono preview 2.0 binary and DTrace In-Reply-To: References: Message-ID: <1217697393.5951.17.camel@limestone> On Sat, 2008-08-02 at 18:30 +0200, Andreas F?rber wrote: > Not fully true, there is of course a minimal degradation (~5 nop > instructions on Solaris), but it should be hardly noticeable. I have > taken care to only call helper functions when the probe is active. > > Was the answer on IRC in any way official? I could think of three > possible reasons: > > a) Worries about performance degradation. Yes > b) No one updated the build system. True but minor > c) The build machine isn't DTrace-capable. d) We havn't tested it fully in our QA process, nor has it been available long enough for us to feel comfortable turning it on at this stage. We also would need to invesgate how to do it in our universal binaries, etc. Its a lot of testing and it unfortunately will not make 2.0 unless there is a compelling argument against this and support from the runtime team and from the QA team. -g From vargaz at gmail.com Sat Aug 2 13:20:38 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Sat, 2 Aug 2008 19:20:38 +0200 Subject: [Mono-dev] Mono preview 2.0 binary and DTrace In-Reply-To: <1217697393.5951.17.camel@limestone> References: <1217697393.5951.17.camel@limestone> Message-ID: <295e750a0808021020t3a8d5f35lcf96467d0bacc002@mail.gmail.com> Hi, Looking at dtrace.h, all the current probes seem to be in non-critical code-paths, so they are unlikely to have a perf impact. We could make --enable-dtrace=true the default in HEAD, so it gets some testing. Zoltan On Sat, Aug 2, 2008 at 7:16 PM, Geoff Norton wrote: > On Sat, 2008-08-02 at 18:30 +0200, Andreas F?rber wrote: > >> Not fully true, there is of course a minimal degradation (~5 nop >> instructions on Solaris), but it should be hardly noticeable. I have >> taken care to only call helper functions when the probe is active. >> >> Was the answer on IRC in any way official? I could think of three >> possible reasons: >> >> a) Worries about performance degradation. > > Yes > >> b) No one updated the build system. > > True but minor > >> c) The build machine isn't DTrace-capable. > > d) We havn't tested it fully in our QA process, nor has it been > available long enough for us to feel comfortable turning it on at this > stage. We also would need to invesgate how to do it in our universal > binaries, etc. Its a lot of testing and it unfortunately will not make > 2.0 unless there is a compelling argument against this and support from > the runtime team and from the QA team. > > -g > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From gnorton at novell.com Sat Aug 2 14:14:48 2008 From: gnorton at novell.com (Geoff Norton) Date: Sat, 02 Aug 2008 14:14:48 -0400 Subject: [Mono-dev] Mono preview 2.0 binary and DTrace In-Reply-To: <295e750a0808021020t3a8d5f35lcf96467d0bacc002@mail.gmail.com> References: <1217697393.5951.17.camel@limestone> <295e750a0808021020t3a8d5f35lcf96467d0bacc002@mail.gmail.com> Message-ID: <1217700888.5951.18.camel@limestone> Zoltan, I'm fine with this on trunk, but I still think barring any compelling reason we should leave the branch as is. -g On Sat, 2008-08-02 at 19:20 +0200, Zoltan Varga wrote: > Hi, > > Looking at dtrace.h, all the current probes seem to be in > non-critical code-paths, so they > are unlikely to have a perf impact. We could make --enable-dtrace=true > the default in HEAD, > so it gets some testing. > > Zoltan > > On Sat, Aug 2, 2008 at 7:16 PM, Geoff Norton wrote: > > On Sat, 2008-08-02 at 18:30 +0200, Andreas F?rber wrote: > > > >> Not fully true, there is of course a minimal degradation (~5 nop > >> instructions on Solaris), but it should be hardly noticeable. I have > >> taken care to only call helper functions when the probe is active. > >> > >> Was the answer on IRC in any way official? I could think of three > >> possible reasons: > >> > >> a) Worries about performance degradation. > > > > Yes > > > >> b) No one updated the build system. > > > > True but minor > > > >> c) The build machine isn't DTrace-capable. > > > > d) We havn't tested it fully in our QA process, nor has it been > > available long enough for us to feel comfortable turning it on at this > > stage. We also would need to invesgate how to do it in our universal > > binaries, etc. Its a lot of testing and it unfortunately will not make > > 2.0 unless there is a compelling argument against this and support from > > the runtime team and from the QA team. > > > > -g > > > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From dean at brettle.com Sat Aug 2 23:45:18 2008 From: dean at brettle.com (Dean Brettle) Date: Sat, 2 Aug 2008 20:45:18 -0700 Subject: [Mono-dev] [PATCH] Cleanup of code for processing *.browser Message-ID: Hi all, Attached is slightly revised version of a patch that Owen Brady sent me. Owen is the original author of the code that Mono's ASP.NET 2.0 implementation uses for processing *.browser files. The patch updates his email in the copyright notices at the top of each file and removes some files and methods that Mono doesn't use at all. It doesn't add anything or change any existing implementation. System.Web still compiles and passes all tests, so it is should be clear that this change doesn't remove anything that other code depends on. OK to commit to mono-2-0 and trunk? I'd like to commit to both to minimize branch divergence and facilitate future merges. --Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080802/e65a9ce2/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: nBrowserCleanup.patch Type: text/x-patch Size: 29094 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080802/e65a9ce2/attachment-0001.bin From andreas.faerber at web.de Sun Aug 3 08:50:59 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sun, 3 Aug 2008 14:50:59 +0200 Subject: [Mono-dev] [PATCH] Compilation fix for pre-C99 Message-ID: <823E9D93-D4CF-4BCB-AB99-C4CDE466E9AE@web.de> Hello, Attached is a patch that fixes compilation with GCC 2.x. With this single ANSI C fix in place, Mono compiles with GCC 2.95.3. Please let me know if it's okay to commit on trunk. Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc2-2008-08-01.diff Type: application/octet-stream Size: 1061 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080803/fcd9a165/attachment.obj -------------- next part -------------- From vargaz at gmail.com Sun Aug 3 09:39:35 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Sun, 3 Aug 2008 15:39:35 +0200 Subject: [Mono-dev] [PATCH] Compilation fix for pre-C99 In-Reply-To: <823E9D93-D4CF-4BCB-AB99-C4CDE466E9AE@web.de> References: <823E9D93-D4CF-4BCB-AB99-C4CDE466E9AE@web.de> Message-ID: <295e750a0808030639m63cba0d6kbc6c6477483e4d95@mail.gmail.com> Hi, Its ok to commit. Zoltan 2008/8/3 Andreas F?rber : > Hello, > > Attached is a patch that fixes compilation with GCC 2.x. With this single > ANSI C fix in place, Mono compiles with GCC 2.95.3. > > Please let me know if it's okay to commit on trunk. > > Andreas > > > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From andreas.faerber at web.de Sun Aug 3 10:08:03 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sun, 3 Aug 2008 16:08:03 +0200 Subject: [Mono-dev] Mono preview 2.0 binary and DTrace In-Reply-To: <1217700888.5951.18.camel@limestone> References: <1217697393.5951.17.camel@limestone> <295e750a0808021020t3a8d5f35lcf96467d0bacc002@mail.gmail.com> <1217700888.5951.18.camel@limestone> Message-ID: Hi, Are you talking of the once announced binary snapshots of trunk Mono.framework, so that you would make some Novell-internal setting to configure with --enable-dtrace? Or do you suggest me to change trunk's configure.in to enable DTrace when specifically Mac OS X v10.5+ is detected and no --disable-dtrace was passed? Changes other than that I am skeptical about. Btw Universal Binaries shouldn't be a problem, since iirc you use lipo to combine two separate builds and the mono.d file would be platform- independent so no special handling necessary. Andreas Am 02.08.2008 um 20:14 schrieb Geoff Norton: > Zoltan, > > I'm fine with this on trunk, but I still think barring any compelling > reason we should leave the branch as is. > > -g > > On Sat, 2008-08-02 at 19:20 +0200, Zoltan Varga wrote: >> Hi, >> >> Looking at dtrace.h, all the current probes seem to be in >> non-critical code-paths, so they >> are unlikely to have a perf impact. We could make --enable- >> dtrace=true >> the default in HEAD, >> so it gets some testing. >> >> Zoltan >> >> On Sat, Aug 2, 2008 at 7:16 PM, Geoff Norton >> wrote: >>> On Sat, 2008-08-02 at 18:30 +0200, Andreas F?rber wrote: >>> >>>> Not fully true, there is of course a minimal degradation (~5 nop >>>> instructions on Solaris), but it should be hardly noticeable. I >>>> have >>>> taken care to only call helper functions when the probe is active. >>>> >>>> Was the answer on IRC in any way official? I could think of three >>>> possible reasons: >>>> >>>> a) Worries about performance degradation. >>> >>> Yes >>> >>>> b) No one updated the build system. >>> >>> True but minor >>> >>>> c) The build machine isn't DTrace-capable. >>> >>> d) We havn't tested it fully in our QA process, nor has it been >>> available long enough for us to feel comfortable turning it on at >>> this >>> stage. We also would need to invesgate how to do it in our >>> universal >>> binaries, etc. Its a lot of testing and it unfortunately will not >>> make >>> 2.0 unless there is a compelling argument against this and support >>> from >>> the runtime team and from the QA team. >>> >>> -g >>> >>> >>> _______________________________________________ >>> 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 Sun Aug 3 10:52:20 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Sun, 3 Aug 2008 16:52:20 +0200 Subject: [Mono-dev] Mono preview 2.0 binary and DTrace In-Reply-To: References: <1217697393.5951.17.camel@limestone> <295e750a0808021020t3a8d5f35lcf96467d0bacc002@mail.gmail.com> <1217700888.5951.18.camel@limestone> Message-ID: <295e750a0808030752u8135f48t89c79b509fcf4f8b@mail.gmail.com> Hi, On mono HEAD, dtrace is now enabled under solaris and macosx if the dtrace utility is detected by configure. Zoltan On Sun, Aug 3, 2008 at 4:08 PM, Andreas F?rber wrote: > Hi, > > Are you talking of the once announced binary snapshots of trunk > Mono.framework, so that you would make some Novell-internal setting to > configure with --enable-dtrace? > > Or do you suggest me to change trunk's configure.in to enable DTrace when > specifically Mac OS X v10.5+ is detected and no --disable-dtrace was passed? > Changes other than that I am skeptical about. > > Btw Universal Binaries shouldn't be a problem, since iirc you use lipo to > combine two separate builds and the mono.d file would be > platform-independent so no special handling necessary. > > Andreas > > Am 02.08.2008 um 20:14 schrieb Geoff Norton: > >> Zoltan, >> >> I'm fine with this on trunk, but I still think barring any compelling >> reason we should leave the branch as is. >> >> -g >> >> On Sat, 2008-08-02 at 19:20 +0200, Zoltan Varga wrote: >>> >>> Hi, >>> >>> Looking at dtrace.h, all the current probes seem to be in >>> non-critical code-paths, so they >>> are unlikely to have a perf impact. We could make --enable-dtrace=true >>> the default in HEAD, >>> so it gets some testing. >>> >>> Zoltan >>> >>> On Sat, Aug 2, 2008 at 7:16 PM, Geoff Norton wrote: >>>> >>>> On Sat, 2008-08-02 at 18:30 +0200, Andreas F?rber wrote: >>>> >>>>> Not fully true, there is of course a minimal degradation (~5 nop >>>>> instructions on Solaris), but it should be hardly noticeable. I have >>>>> taken care to only call helper functions when the probe is active. >>>>> >>>>> Was the answer on IRC in any way official? I could think of three >>>>> possible reasons: >>>>> >>>>> a) Worries about performance degradation. >>>> >>>> Yes >>>> >>>>> b) No one updated the build system. >>>> >>>> True but minor >>>> >>>>> c) The build machine isn't DTrace-capable. >>>> >>>> d) We havn't tested it fully in our QA process, nor has it been >>>> available long enough for us to feel comfortable turning it on at this >>>> stage. We also would need to invesgate how to do it in our universal >>>> binaries, etc. Its a lot of testing and it unfortunately will not make >>>> 2.0 unless there is a compelling argument against this and support from >>>> the runtime team and from the QA team. >>>> >>>> -g >>>> >>>> >>>> _______________________________________________ >>>> Mono-devel-list mailing list >>>> Mono-devel-list at lists.ximian.com >>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>> >> > > From andreas.faerber at web.de Sun Aug 3 10:53:32 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sun, 3 Aug 2008 16:53:32 +0200 Subject: [Mono-dev] [PATCH] Compilation fix for pre-C99 In-Reply-To: <295e750a0808030639m63cba0d6kbc6c6477483e4d95@mail.gmail.com> References: <823E9D93-D4CF-4BCB-AB99-C4CDE466E9AE@web.de> <295e750a0808030639m63cba0d6kbc6c6477483e4d95@mail.gmail.com> Message-ID: <59B5087F-AFF3-47C5-BF1D-9CC394932536@web.de> Thanks, in r109505. Am 03.08.2008 um 15:39 schrieb Zoltan Varga: > Hi, > > Its ok to commit. > > Zoltan > > 2008/8/3 Andreas F?rber : >> Hello, >> >> Attached is a patch that fixes compilation with GCC 2.x. With this >> single >> ANSI C fix in place, Mono compiles with GCC 2.95.3. >> >> Please let me know if it's okay to commit on trunk. >> >> Andreas >> >> >> >> >> >> _______________________________________________ >> 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 andreas.faerber at web.de Sun Aug 3 11:14:08 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sun, 3 Aug 2008 17:14:08 +0200 Subject: [Mono-dev] Mono preview 2.0 binary and DTrace In-Reply-To: <295e750a0808030752u8135f48t89c79b509fcf4f8b@mail.gmail.com> References: <1217697393.5951.17.camel@limestone> <295e750a0808021020t3a8d5f35lcf96467d0bacc002@mail.gmail.com> <1217700888.5951.18.camel@limestone> <295e750a0808030752u8135f48t89c79b509fcf4f8b@mail.gmail.com> Message-ID: Hi, Am 03.08.2008 um 16:52 schrieb Zoltan Varga: > On mono HEAD, dtrace is now enabled under solaris and macosx if the > dtrace utility is > detected by configure. Looks okay to me. In this form it would even allow to build with DTrace enabled on pre-10 Solaris once the tool becomes available there. Let's just hope my Solaris build script doesn't break too soon... Andreas From boris.dusek at gmail.com Sun Aug 3 11:32:48 2008 From: boris.dusek at gmail.com (=?UTF-8?Q?Boris_Du=C5=A1ek?=) Date: Sun, 3 Aug 2008 17:32:48 +0200 Subject: [Mono-dev] Mono preview 2.0 binary and DTrace In-Reply-To: References: Message-ID: Hi Andreas, On Sat, Aug 2, 2008 at 6:30 PM, Andreas F?rber wrote: >> I grabbed the Mono Preview 2.0 installer for OS X and wanted to test >> new DTrace probes mentioned in Release Notes[1], but it did not work. > > Just to be sure, how did you test? As described in mono's man page? With the same command that worked with mono that I compiled myself. (with one difference - I used '/path/to/mono' for customly compiled mono since my install prefix binary dir was not in $PATH): boris at Pioneer:~/Documents/dev/mono/usr/bin$ sudo dtrace -P mono'$target' -l -c mono ID PROVIDER MODULE FUNCTION NAME dtrace: failed to match mono3618:::: No probe matches description boris at Pioneer:~/Documents/dev/mono/usr/bin$ sudo dtrace -P mono'$target' -l -c ./mono ID PROVIDER MODULE FUNCTION NAME 20188 mono3620 mono mono_gc_collect gc-begin 20189 mono3620 mono mono_gc_collect gc-end 21858 mono3620 mono mini_method_compile method-compile-begin 21859 mono3620 mono mini_method_compile method-compile-end 21860 mono3620 mono mini_init ves-init-begin 21861 mono3620 mono mini_init ves-init-end btw. while we are at it, is it already possible now or do you plan to add jstack support (so that the names of ".NET functions" appear instead of addresses of frames for the part inside mono runtime?) right now, with this Hello World program: class Test { public static void Main(string[] args) { System.Console.WriteLine("Hello from C#"); } } and this tracing script (tracing usermode stack at every write syscall): syscall::write:entry /pid == $target/ { trace(arg0); jstack(); } I get this output which makes me believe it's either not implemented or I am doing something wrong (both writes are to fd 1 = stderr): boris at Pioneer:~/Documents/dev/mono/usr/bin$ DYLD_LIBRARY_PATH=`pwd`/../lib sudo dtrace -s tracemono.d -c './mono /Users/boris/Test.exe' dtrace: script 'tracemono.d' matched 1 probe Hello from C# dtrace: pid 1528 has exited CPU ID FUNCTION:NAME 1 17600 write:entry 1 libSystem.B.dylib`write$UNIX2003+0xa mono`ves_icall_System_IO_MonoIO_Write+0x66 0x7d6084 0x7d5d60 0x7d5bae 0x7d5ae6 0x7cc8cd 0x7d4ed8 0x7d4e6e 0x7d4df8 0x7d4db6 0x7ca289 0x7ca24b 0x7ca1ce mono`mono_runtime_exec_main+0xfe mono`mono_runtime_run_main+0x153 mono`mono_main+0x1360 mono`start+0x36 0x2 1 17600 write:entry 1 libSystem.B.dylib`write$UNIX2003+0xa mono`ves_icall_System_IO_MonoIO_Write+0x66 0x7d6084 0x7d5d60 0x7d5bae 0x7d5ae6 0x7cc8cd 0x7d63bf 0x7d61bd 0x7d614e 0x7d6128 0x7d4e0a 0x7d4db6 0x7ca289 0x7ca24b 0x7ca1ce mono`mono_runtime_exec_main+0xfe mono`mono_runtime_run_main+0x153 mono`mono_main+0x1360 mono`start+0x36 0x2 Tracing Java in this way yields empty trace, so probably it's me doing something stupid. Thanks, Boris From andyhume32 at yahoo.co.uk Sun Aug 3 12:32:26 2008 From: andyhume32 at yahoo.co.uk (Andy Hume) Date: Sun, 3 Aug 2008 09:32:26 -0700 (PDT) Subject: [Mono-dev] Win32 Mono 2.0 compiled from SVN branch - dies inside mono_get_lmf_addr In-Reply-To: References: Message-ID: <18800101.post@talk.nabble.com> Looks like you're not the only one hitting this... See https://bugzilla.novell.com/show_bug.cgi?id=414159 Andy russell.kay wrote: > > All, > > > > Does anyone have any ideas why I am seeing my code dying inside > mono_get_lmf_addr at the g_assert_not_reached(), it looks like this code > has something to do with trampolines but there are not a lot of comments > around this function. > > > > I have compiled mono from the 2.0 branch (using cygwin) and everything > else seems to be working fine, well I am seeing what I expect, just it > is dying on exit. > > > > The code that I am running is using System.Timers.Timer, running around > 10 of them and it dies on exit. > > > > Does anyone have any ideas why it may be hanging? > > > > Russell > > > ____________________________________________________________________ > DISCLAIMER > > This message and any attachments contain privileged and confidential > information intended for the use of the addressee named above. If you are > not the intended recipient of this message, you are hereby notified that > any use, dissemination, distribution or reproduction of this message is > prohibited. Please note that we cannot guarantee that this message or any > attachment is virus free or that it has not been intercepted and amended. > The views of the author may not necessarily reflect those of Realtime > Worlds Ltd. > > > > Realtime Worlds Ltd is registered in Scotland, number 225628. Registered > Office: 152 West Marketgait, Dundee, DD1 1NJ. > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- View this message in context: http://www.nabble.com/Win32-Mono-2.0-compiled-from-SVN-branch---dies-inside-mono_get_lmf_addr-tp18775284p18800101.html Sent from the Mono - Dev mailing list archive at Nabble.com. From andreas.faerber at web.de Sun Aug 3 15:57:34 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Sun, 3 Aug 2008 21:57:34 +0200 Subject: [Mono-dev] Mono preview 2.0 binary and DTrace In-Reply-To: References: Message-ID: <5C1A1789-A27F-47D1-B56F-EF7985483F76@web.de> Hi Boris, Am 03.08.2008 um 17:32 schrieb Boris Du?ek: > On Sat, Aug 2, 2008 at 6:30 PM, Andreas F?rber > wrote: >>> I grabbed the Mono Preview 2.0 installer for OS X and wanted to test >>> new DTrace probes mentioned in Release Notes[1], but it did not >>> work. >> >> Just to be sure, how did you test? As described in mono's man page? > > With the same command that worked with mono that I compiled myself. > (with one difference - I used '/path/to/mono' for customly compiled > mono since my install prefix binary dir was not in $PATH): > > boris at Pioneer:~/Documents/dev/mono/usr/bin$ sudo dtrace -P > mono'$target' -l -c mono > ID PROVIDER MODULE FUNCTION > NAME > dtrace: failed to match mono3618:::: No probe matches description > > boris at Pioneer:~/Documents/dev/mono/usr/bin$ sudo dtrace -P > mono'$target' -l -c ./mono > ID PROVIDER MODULE FUNCTION > NAME > 20188 mono3620 mono mono_gc_collect > gc-begin > 20189 mono3620 mono mono_gc_collect > gc-end > 21858 mono3620 mono mini_method_compile > method-compile-begin > 21859 mono3620 mono mini_method_compile > method-compile-end > 21860 mono3620 mono mini_init > ves-init-begin > 21861 mono3620 mono mini_init > ves-init-end Looks right. > btw. while we are at it, is it already possible now or do you plan to > add jstack support (so that the names of ".NET functions" appear > instead of addresses of frames for the part inside mono runtime?) > > right now, with this Hello World program: > > class Test { > public static void Main(string[] args) { > System.Console.WriteLine("Hello from C#"); > } > } > > and this tracing script (tracing usermode stack at every write > syscall): > > syscall::write:entry > /pid == $target/ > { > trace(arg0); > jstack(); > } > > I get this output which makes me believe it's either not implemented > or I am doing something wrong (both writes are to fd 1 = stderr): > > boris at Pioneer:~/Documents/dev/mono/usr/bin$ > DYLD_LIBRARY_PATH=`pwd`/../lib sudo dtrace -s tracemono.d -c './mono > /Users/boris/Test.exe' > dtrace: script 'tracemono.d' matched 1 probe > Hello from C# > dtrace: pid 1528 has exited > CPU ID FUNCTION:NAME > 1 17600 write:entry 1 > libSystem.B.dylib`write$UNIX2003+0xa > mono`ves_icall_System_IO_MonoIO_Write+0x66 > 0x7d6084 > 0x7d5d60 > 0x7d5bae > 0x7d5ae6 > 0x7cc8cd > 0x7d4ed8 > 0x7d4e6e > 0x7d4df8 > 0x7d4db6 > 0x7ca289 > 0x7ca24b > 0x7ca1ce > mono`mono_runtime_exec_main+0xfe > mono`mono_runtime_run_main+0x153 > mono`mono_main+0x1360 > mono`start+0x36 > 0x2 > > 1 17600 write:entry 1 > libSystem.B.dylib`write$UNIX2003+0xa > mono`ves_icall_System_IO_MonoIO_Write+0x66 > 0x7d6084 > 0x7d5d60 > 0x7d5bae > 0x7d5ae6 > 0x7cc8cd > 0x7d63bf > 0x7d61bd > 0x7d614e > 0x7d6128 > 0x7d4e0a > 0x7d4db6 > 0x7ca289 > 0x7ca24b > 0x7ca1ce > mono`mono_runtime_exec_main+0xfe > mono`mono_runtime_run_main+0x153 > mono`mono_main+0x1360 > mono`start+0x36 > 0x2 > > Tracing Java in this way yields empty trace, so probably it's me doing > something stupid. DTrace support has been a recurrently requested feature for about two years now. I'm happy that I got it working so far! :) All current DTrace features are documented in mono's man page, that is the six probes. I don't pretend that this is in any way conclusive, there are many more probes and features imaginable, some listed as a roadmap in the to-be Wiki documentation, see attached. Suggestions and contributions always welcome. The current probes are meant to allow a little profiling of the runtime, and were a convenient way for me to trace what the runtime would be doing if my ppc64 port were working... I haven't used jstack() yet and would need to look it up in the documentation. It sounds non-trivial to implement compared to probes. What I will be looking into next is method-enter/method-exit probes for tracing managed function flow, but it seems more complicated (the JIT would need to always emit a call to a helper function, supplying it the data to conditionally pass out - otherwise the dynamic part of DTrace wouldn't work) and thus cannot be on by default for performance reasons, just like in Java. Andreas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: DTrace.txt Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080803/31827b55/attachment.txt -------------- next part -------------- From akalyanasundaram at novell.com Mon Aug 4 07:49:58 2008 From: akalyanasundaram at novell.com (Arun Kalyanasundaram) Date: Mon, 04 Aug 2008 05:49:58 -0600 Subject: [Mono-dev] UnixDriveInfo.GetDrives doesnt show mounted disks Message-ID: <489738BA.79FB.0040.0@novell.com> Hello List, Iam using the method UnixDriveInfo.GetDrives to look for a drive which has maximum free space. But the api does not return the disks mounted manually or by automount. Is there any other api which i can use to get info of mounted drives or is there another way to handle this. Can anyone please help me? Thanks, Arun Kalyanasundaram -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080804/b45663fd/attachment.html From billholmes54 at gmail.com Mon Aug 4 10:09:49 2008 From: billholmes54 at gmail.com (Bill Holmes) Date: Mon, 4 Aug 2008 10:09:49 -0400 Subject: [Mono-dev] [PATCH] eglib memory allocation changes In-Reply-To: <1217650030.8518.2.camel@linux-bytm.site> References: <37c5788d0808010730t3776ffcbh8bdaa0aa9d12f056@mail.gmail.com> <1217650030.8518.2.camel@linux-bytm.site> Message-ID: <37c5788d0808040709n48234446g113b3bf8c6cad114@mail.gmail.com> > It would be useful to add unit test cases so this behavior is also > enforced in the code. Mind adding those? I may not understand what you want. I attached a test for what I think you want. -bill -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: memory.c Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080804/d2bab125/attachment.c From russell.kay at realtimeworlds.com Mon Aug 4 11:10:08 2008 From: russell.kay at realtimeworlds.com (russell.kay at realtimeworlds.com) Date: Mon, 4 Aug 2008 16:10:08 +0100 Subject: [Mono-dev] Win32 Mono 2.0 compiled from SVN branch - dies inside mono_get_lmf_addr In-Reply-To: <18800101.post@talk.nabble.com> References: <18800101.post@talk.nabble.com> Message-ID: Excellent... I have added a bug (#414310) as well for my test case that appears to be slightly different (but probably related). While I was simplifying to a test case I discovered that the simpler code worked on its own and only the large scale test failed, fortunately I have managed to replicate the larger scale test through the use nUnit which seems to help with applying extra pressure to the runtime. Any problems / questions then let me know. Russell -----Original Message----- From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Andy Hume Sent: 03 August 2008 17:32 To: mono-devel-list at lists.ximian.com Subject: Re: [Mono-dev] Win32 Mono 2.0 compiled from SVN branch - dies inside mono_get_lmf_addr Looks like you're not the only one hitting this... See https://bugzilla.novell.com/show_bug.cgi?id=414159 Andy russell.kay wrote: > > All, > > > > Does anyone have any ideas why I am seeing my code dying inside > mono_get_lmf_addr at the g_assert_not_reached(), it looks like this code > has something to do with trampolines but there are not a lot of comments > around this function. > > > > I have compiled mono from the 2.0 branch (using cygwin) and everything > else seems to be working fine, well I am seeing what I expect, just it > is dying on exit. > > > > The code that I am running is using System.Timers.Timer, running around > 10 of them and it dies on exit. > > > > Does anyone have any ideas why it may be hanging? > > > > Russell > > > ____________________________________________________________________ > DISCLAIMER > > This message and any attachments contain privileged and confidential > information intended for the use of the addressee named above. If you are > not the intended recipient of this message, you are hereby notified that > any use, dissemination, distribution or reproduction of this message is > prohibited. Please note that we cannot guarantee that this message or any > attachment is virus free or that it has not been intercepted and amended. > The views of the author may not necessarily reflect those of Realtime > Worlds Ltd. > > > > Realtime Worlds Ltd is registered in Scotland, number 225628. Registered > Office: 152 West Marketgait, Dundee, DD1 1NJ. > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- View this message in context: http://www.nabble.com/Win32-Mono-2.0-compiled-from-SVN-branch---dies-ins ide-mono_get_lmf_addr-tp18775284p18800101.html Sent from the Mono - Dev mailing list archive at Nabble.com. _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ____________________________________________________________________ This email has been scanned by the MessageLabs Email Security System ____________________________________________________________________ DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. From miguel at novell.com Mon Aug 4 12:23:07 2008 From: miguel at novell.com (Miguel de Icaza) Date: Mon, 04 Aug 2008 12:23:07 -0400 Subject: [Mono-dev] [PATCH] eglib memory allocation changes In-Reply-To: <37c5788d0808040709n48234446g113b3bf8c6cad114@mail.gmail.com> References: <37c5788d0808010730t3776ffcbh8bdaa0aa9d12f056@mail.gmail.com> <1217650030.8518.2.camel@linux-bytm.site> <37c5788d0808040709n48234446g113b3bf8c6cad114@mail.gmail.com> Message-ID: <1217866987.4261.8.camel@linux-1p3a.site> Hello, Exactly! Lets get this in. > > It would be useful to add unit test cases so this behavior is also > > enforced in the code. Mind adding those? > > I may not understand what you want. I attached a test for what I > think you want. > > -bill From tsalvagno at gmail.com Mon Aug 4 13:56:40 2008 From: tsalvagno at gmail.com (linuxfreak@uy) Date: Mon, 4 Aug 2008 10:56:40 -0700 (PDT) Subject: [Mono-dev] VisualwebGUI 6.0.4, Framework 2.0 working with Linux + Mono. Message-ID: <18816346.post@talk.nabble.com> I don't know if it's me but I could find any successfull story about VisualwebGUI and Mono out there so I decided to start from scratch believing in the VisualwebGUI guys that claimed that VisualwebGUI working with mono is a sure thing, well after all they were right!!! Working test environment: OpenSuSe 11.0 + Apache2 (2.2.8-28.1) + mod_mono module (1.9-20.1) + mono (1.9.1-6.1) Problems found: mod_module as it works after installation using "mod-mono-server" won't work at all (I have more details but is too large to put it here) Basically the problem is that VisualwebGUI uses .NET framework 2.0 assemblies that are not loaded when needed. Workaround: 1. Using xsp2 directly works perfectly fine. 2. Some minor modification is needed in the Web.config generated by VisualwebGUI. I've already put more detailed info in an article at VisualwebGUI site, "Forum/How to's..." but it's pending for approval. -- View this message in context: http://www.nabble.com/VisualwebGUI-6.0.4%2C-Framework-2.0-working-with-Linux-%2B-Mono.-tp18816346p18816346.html Sent from the Mono - Dev mailing list archive at Nabble.com. From andreas.faerber at web.de Mon Aug 4 16:33:21 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Mon, 4 Aug 2008 22:33:21 +0200 Subject: [Mono-dev] [PATCH] Fix autogen.sh warnings Message-ID: <4BA282FE-4C08-47A6-8DA6-45782CA37845@web.de> Hello, The attached patch suppresses an autogen.sh warning when run with NOCONFIGURE=1. Currently, autogen.sh claims to run configure without arguments, even when invoked in such a way as to not run configure at all. Such an invocation is necessary for VPATH builds. Please review the change and let me know if it's okay to apply on trunk. Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: autogen.sh-NOCONFIGURE.diff Type: application/octet-stream Size: 1317 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080804/4932dc2e/attachment.obj -------------- next part -------------- From vargaz at gmail.com Mon Aug 4 17:00:51 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Mon, 4 Aug 2008 23:00:51 +0200 Subject: [Mono-dev] [PATCH] Fix autogen.sh warnings In-Reply-To: <4BA282FE-4C08-47A6-8DA6-45782CA37845@web.de> References: <4BA282FE-4C08-47A6-8DA6-45782CA37845@web.de> Message-ID: <295e750a0808041400k3f4ed40by42ce9aa710b9f007@mail.gmail.com> Hi, Looks ok to me. Zoltan 2008/8/4 Andreas F?rber : > Hello, > > The attached patch suppresses an autogen.sh warning when run with > NOCONFIGURE=1. > > Currently, autogen.sh claims to run configure without arguments, even when > invoked in such a way as to not run configure at all. Such an invocation is > necessary for VPATH builds. > > Please review the change and let me know if it's okay to apply on trunk. > > Andreas > > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From bassraf at gmail.com Mon Aug 4 22:17:00 2008 From: bassraf at gmail.com (BaSS) Date: Tue, 05 Aug 2008 04:17:00 +0200 Subject: [Mono-dev] Embedding Mono. Message-ID: <75495c6e.1c8f6a1.81b6bdc.5af1@gmail.com> Hi Guys, When using mono.dll for scripting/embedding purposes, the only way to get ?scrip code? into the compiler is to use a ?native? .net assembly and move the script code into the managed world first? Or is there some obvious exported method somewhere in the dll where I can directly inject ?(script) code to be executed? into the JIT (and execute it)? Thanks and best regards, Bas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080805/38f94242/attachment.html From massi at ximian.com Tue Aug 5 02:23:20 2008 From: massi at ximian.com (Massimiliano Mantione) Date: Tue, 05 Aug 2008 08:23:20 +0200 Subject: [Mono-dev] Mono preview 2.0 binary and DTrace In-Reply-To: <5C1A1789-A27F-47D1-B56F-EF7985483F76@web.de> References: <5C1A1789-A27F-47D1-B56F-EF7985483F76@web.de> Message-ID: <1217917400.4829.131.camel@Matrix.site> On Sun, 2008-08-03 at 21:57 +0200, Andreas F?rber wrote: > What I will be looking into next is method-enter/method-exit probes > for tracing managed function flow, but it seems more complicated (the > JIT would need to always emit a call to a helper function, supplying > it the data to conditionally pass out - otherwise the dynamic part of > DTrace wouldn't work) and thus cannot be on by default for performance > reasons, just like in Java. IMO, the correct way of doing this would be to implement it in a profiler module, and it's amazingly easy doing so. But actually the logging profiler does just that if you invoke it with the "c" option: it logs all method enter and exit events. It uses per-thread buffers (periodically flushed) to minimize overhead and locking, each event takes between 2 and 5 bytes in the log file (including the full timestamp!), and even this way the overhead is really high. I doubt dtrace could be any faster... but if it is I'd like to know how it does it :-) What the profiler misses, in this case, is a GUI that is oriented towards "browsing the log", maybe with a timeline, showing the threads in parallel, and with a filter and fast search functions... The data is all in the log, the problem is those log files can take several hundreds of Mb on disk (with the events compacted that way), so IMO keeping all the data in RAM in the GUI would be the wrong approach (because each event would take much more than 5 bytes!). This is the main reason why this kind of tool has not yet been written: doing it well for the general case (a typical program run during more than ten minutes) is not trivial. But if you need only one line in a text file for each method enter-exit, take the Mono.Profiler code, put a couple of WriteLine inside MethodEnter and MethodExit in the EventProcessor, be sure to print also "stack.Depth", and you have your trace :-) As a bonus, if you want to be able to distinguish threads, also print "stack.ThreadId". It is worse than "mono --trace" because you don't have the method arguments, but it is much more efficient during execution so there are more cases when this is actually doable. I *know* this is not dtrace, it does not profile the whole system but only Mono... but this works also on Linux. Ciao, Massi From massi at ximian.com Tue Aug 5 02:41:32 2008 From: massi at ximian.com (Massimiliano Mantione) Date: Tue, 05 Aug 2008 08:41:32 +0200 Subject: [Mono-dev] Embedding Mono. In-Reply-To: <75495c6e.1c8f6a1.81b6bdc.5af1@gmail.com> References: <75495c6e.1c8f6a1.81b6bdc.5af1@gmail.com> Message-ID: <1217918492.4829.140.camel@Matrix.site> On Tue, 2008-08-05 at 04:17 +0200, BaSS wrote: > When using mono.dll for scripting/embedding purposes, the only way to > get ?scrip code? into the compiler is to use a ?native? .net assembly > and move the script code into the managed world first? AFAIK, yes. The rationale is that Mono provides a .NET runtime, and a plain .NET runtime does not contain a compiler-interpreter for an arbitrary scripting language... it just allows you to execute managed code from existing assemblies. > Or is there some obvious exported method somewhere in the dll where I > can directly inject ?(script) code to be executed? into the JIT (and > execute it)? If you provide a managed DLL containing your interpreter-compiler, you can invoke its methods from unmanaged code using the embedding API. This would be a "single invocation that executes a script". Otherwise you could try to use a methodbuilder from unmanaged code, but I don't know if it can work and I doubt it would be worth the effort... My 2c, Massi From atsushi at ximian.com Tue Aug 5 02:56:58 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Tue, 05 Aug 2008 15:56:58 +0900 Subject: [Mono-dev] call for implementation: native FileSystemWatcher on win32 Message-ID: <4897F9BA.6030400@ximian.com> Hello, I was reading this bug report on FileSystemWatcher on win32 https://bugzilla.novell.com/show_bug.cgi?id=394422 ... and thought that implementing Renamed event in DefaultWatcher is not likely safe or preferable, and we had better replace it on win32 with some native winapi based one. http://msdn.microsoft.com/en-us/library/aa365261(VS.85).aspx Anyone volunteer to implement it? :) That'd be great. Atsushi Eno From robertj at gmx.net Tue Aug 5 04:03:53 2008 From: robertj at gmx.net (Robert Jordan) Date: Tue, 05 Aug 2008 10:03:53 +0200 Subject: [Mono-dev] call for implementation: native FileSystemWatcher on win32 In-Reply-To: <4897F9BA.6030400@ximian.com> References: <4897F9BA.6030400@ximian.com> Message-ID: Atsushi Eno wrote: > Hello, > > I was reading this bug report on FileSystemWatcher on win32 > https://bugzilla.novell.com/show_bug.cgi?id=394422 > > ... and thought that implementing Renamed event in DefaultWatcher > is not likely safe or preferable, and we had better replace it on > win32 with some native winapi based one. > http://msdn.microsoft.com/en-us/library/aa365261(VS.85).aspx > > Anyone volunteer to implement it? :) That'd be great. I'll try this for Mono 2.1. Robert From andreas.faerber at web.de Tue Aug 5 06:26:40 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Tue, 5 Aug 2008 12:26:40 +0200 Subject: [Mono-dev] Mono preview 2.0 binary and DTrace In-Reply-To: <1217917400.4829.131.camel@Matrix.site> References: <5C1A1789-A27F-47D1-B56F-EF7985483F76@web.de> <1217917400.4829.131.camel@Matrix.site> Message-ID: <7A551B44-C072-4983-B82B-60124A55A185@web.de> Ciao Massi, Am 05.08.2008 um 08:23 schrieb Massimiliano Mantione: > > On Sun, 2008-08-03 at 21:57 +0200, Andreas F?rber wrote: >> What I will be looking into next is method-enter/method-exit probes >> for tracing managed function flow, but it seems more complicated (the >> JIT would need to always emit a call to a helper function, supplying >> it the data to conditionally pass out - otherwise the dynamic part of >> DTrace wouldn't work) and thus cannot be on by default for >> performance >> reasons, just like in Java. > > IMO, the correct way of doing this would be to implement it in a > profiler module, and it's amazingly easy doing so. Although not really familiar with it, I am aware of the existing cross- platform tracing and profiling mechanisms in Mono. (The JIT profiling DTrace probes mostly match Mono's own hooks except that I reported some profiler hooks were missing for generic sharing and when some optimizations were not run - I got no reply to that, maybe you want to check on that.) DTrace is a different paradigm... > But actually the logging profiler does just that if you invoke it with > the "c" option: it logs all method enter and exit events. > It uses per-thread buffers (periodically flushed) to minimize overhead > and locking, each event takes between 2 and 5 bytes in the log file > (including the full timestamp!), and even this way the overhead is > really high. > I doubt dtrace could be any faster... but if it is I'd like to know > how > it does it :-) ...currently, having to start mono with the DTrace tool as documented is an intermediate step - the final goal is to deploy a runtime with DTrace compiled in, no probes activated at startup. Then when something goes wrong, e.g. while running ASP.NET with mod_mono, you connect to the mono pid (or to all running mono instances) and see what's going on. What DTrace is doing afaik is it pre-compiles the D script to bytecode and it has per-CPU buffers. Unless I activate a certain probe, no data gets collected for it. Even if activated (i.e., called and data passed into), the script can use predicates to minimize the data collected to that of interest (e.g., only profile compilation of method starting with A), and built-in aggregation functions can further reduce the amount of data actually kept (e.g., a histogram). So this means that the actual "if (enabled)" needs to be different, and I wouldn't want to mess with the semantics of the cross-platform mechanism. Personally, I have used DTrace for my thesis on H.264 SVC streaming, and being under great time pressure DTrace has allowed me to get the statistics I wanted with a minimum of work - for absolute numbers I got histograms directly in GNUplot format, for a cumulative distribution function I postprocessed the output with an existing Mono tool of mine (probably there's an easier way too but I'm no expert). http://www.informatik.uni-mannheim.de/pi4/publications/Faerber2008a (pp. 14ff) Anyway, believing that DTrace will be slightly faster, I have taken care to place the DTrace probes enclosed by Mono's hooks (e.g., start profiler hook, start DTrace probe, whatever, end DTrace probe, end profiler hook) and would ask that we stick with this order. It should not have any influence when DTrace is not compiled in (e.g., Linux) as my macros become no-op then. I don't wish to replace or belittle your profiler work. I think the two have different scopes and different use cases and can live side by side, even benefitting from increased review. Andreas From andreas.faerber at web.de Tue Aug 5 07:43:17 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Tue, 5 Aug 2008 13:43:17 +0200 Subject: [Mono-dev] [PATCH] Fix autogen.sh warnings In-Reply-To: <295e750a0808041400k3f4ed40by42ce9aa710b9f007@mail.gmail.com> References: <4BA282FE-4C08-47A6-8DA6-45782CA37845@web.de> <295e750a0808041400k3f4ed40by42ce9aa710b9f007@mail.gmail.com> Message-ID: Done, in r109666. Since the libgc/ChangeLog appeared to have differing line endings, I took the freedom to set EOL style to native for both libgc/ChangeLog and eglib/ChangeLog (./ChangeLog already had it). Andreas Am 04.08.2008 um 23:00 schrieb Zoltan Varga: > Hi, > > Looks ok to me. > > Zoltan > > 2008/8/4 Andreas F?rber : >> Hello, >> >> The attached patch suppresses an autogen.sh warning when run with >> NOCONFIGURE=1. >> >> Currently, autogen.sh claims to run configure without arguments, >> even when >> invoked in such a way as to not run configure at all. Such an >> invocation is >> necessary for VPATH builds. >> >> Please review the change and let me know if it's okay to apply on >> trunk. >> >> Andreas >> >> >> >> >> _______________________________________________ >> 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 massi at ximian.com Tue Aug 5 08:32:22 2008 From: massi at ximian.com (Massimiliano Mantione) Date: Tue, 05 Aug 2008 14:32:22 +0200 Subject: [Mono-dev] Mono preview 2.0 binary and DTrace In-Reply-To: <7A551B44-C072-4983-B82B-60124A55A185@web.de> References: <5C1A1789-A27F-47D1-B56F-EF7985483F76@web.de> <1217917400.4829.131.camel@Matrix.site> <7A551B44-C072-4983-B82B-60124A55A185@web.de> Message-ID: <1217939542.4829.164.camel@Matrix.site> On Tue, 2008-08-05 at 12:26 +0200, Andreas F?rber wrote: > > IMO, the correct way of doing this would be to implement it in a > > profiler module, and it's amazingly easy doing so. > [...] > I don't wish to replace or belittle your profiler work. I think the > two have different scopes and different use cases and can live side by > side, even benefitting from increased review. Don't worry, I did not take your post that way. I *know* dtrace is a different thing, even if I have never used it. I was trying to say the following: [1] If you want dtrace hooks for every enter-exit method, the easiest way to ?implement them is inside a profiler module that uses the existing enter-exit profiling hooks. This has its downsides: you must start the runtime enabling this "dtrace profiler module", and at this point the overhead is not zero. However it seems so easy to do that it could be useful anyway if you need the feature "now" instead of in a few weeks or months. [2] Anyway, if you want to extend the JIT to insert enter and exit "empty dtrace hooks" to every method, it's very likely that you should reuse (and extend) the existing prologue-epilogue instrumentation code instead of trying to reinvent it. [3] As nice as dtrace can be, we don't have it on Linux, and our main focus is Linux. Here, the easiest way you have to log all enter-exit events efficiently is the "c" option of the logging profiler, so I explained how to use it for that purpose in case somebody needed it now. Of course the logging profiler is not dtrace :-) And of course there's place for both in the world... My points [1] and [2] are suggestions on how to get those dtrace hooks into Mono, point [3] is about how to get something similar without using dtrace. Anyway, I get your point that dtrace hooks are conditional, and the conditions can be given dynamically as D scripts. This is something we miss in Mono-land, and can cut the event bandwidth significantly. So, to answer my question, maybe dtrace would be slower than the logging profiler in logging individual enter-exit events, but typically when using dtrace you will never ask the system to log *all* of them, you will select them with a D script, so the resulting event bandwidth will be much slower and the performance acceptable. Did I get it right? Thanks! Massi From grendel at twistedcode.net Tue Aug 5 09:15:24 2008 From: grendel at twistedcode.net (Marek Habersack) Date: Tue, 5 Aug 2008 15:15:24 +0200 Subject: [Mono-dev] [PATCH] Cross-compiling mono for Windows on Linux, using Mingw In-Reply-To: <1217536911.4398.102.camel@linux-1p3a.site> References: <20080731150801.4a59bd92@twistedcode.net> <20080731185308.60723f9a@twistedcode.net> <1217536911.4398.102.camel@linux-1p3a.site> Message-ID: <20080805151524.6e43d9b0@twistedcode.net> On Thu, 31 Jul 2008 16:41:51 -0400 Miguel de Icaza wrote: > This looks like a good patch. I've committed it to trunk in revision 109671. The resulting mono works fine on Windows - all one needs to do is to unpack the generated zip file in the root directory of a Windows drive and add the bin subdirectory to the PATH variable. > > But I would like to see the relevant Wiki pages updated with > instructions and with details. The instructions are at http://mono-project.com/Compiling_Mono#Cross-compiling_on_Linux_using_MinGW best, marek From lunchtimemama at gmail.com Tue Aug 5 22:42:23 2008 From: lunchtimemama at gmail.com (Scott Peterson) Date: Wed, 6 Aug 2008 14:42:23 +1200 Subject: [Mono-dev] BitVector32 patch Message-ID: I happened across a mention of the BitVector32 class the yesterday and it piqued my interest. I thought I'd take a look at Mono's implementation and ended up spending some time giving the type a once-over. I made several minor changes (style issues, removing duplicate code between the Section.ToString overrides, simplified Section.GetHashCode, code sharing between the BitVector32 constructors, &c.), I got rid of the NumberOfSetBits since it is only every being used on bit masks which are always one less than a power of two so HighestSetBit can be used instead, and lastly I changed the HighestSetBit algorithm to something simpler. Patch is attached and inline. Notes are welcome. Index: class/System/System.Collections.Specialized/ChangeLog =================================================================== --- class/System/System.Collections.Specialized/ChangeLog (revision 109665) +++ class/System/System.Collections.Specialized/ChangeLog (working copy) @@ -1,3 +1,9 @@ +2008-08-06 Scott Peterson + + * BitVector32.cs: Cleanup and improved a number of things. Simpler + HighestSetBit algorithm, got rid of NumberOfSetBits (using + HighestSetBit works just fine) and some misc. other stuff. + 2008-07-31 Jb Evain * StringDictionary.cs: remove ComponentModel bits for NET_2_1. Index: class/System/System.Collections.Specialized/BitVector32.cs =================================================================== --- class/System/System.Collections.Specialized/BitVector32.cs (revision 109665) +++ class/System/System.Collections.Specialized/BitVector32.cs (working copy) @@ -34,10 +34,10 @@ namespace System.Collections.Specialized { - public struct BitVector32 { - int bits; - - public struct Section { + public struct BitVector32 + { + public struct Section + { private short mask; private short offset; @@ -74,7 +74,7 @@ #endif public override bool Equals (object o) { - if (! (o is Section)) + if (!(o is Section)) return false; Section section = (Section) o; @@ -84,14 +84,12 @@ public override int GetHashCode () { - return (((Int16) mask).GetHashCode () << 16) + - ((Int16) offset).GetHashCode (); + return mask << offset; } public override string ToString () { - return "Section{0x" + Convert.ToString(mask, 16) + - ", 0x" + Convert.ToString(offset, 16) + "}"; + return ToString(this); } public static string ToString (Section value) @@ -106,12 +104,14 @@ return b.ToString (); } } + + int bits; // Constructors public BitVector32 (BitVector32 source) + : this (source.bits) { - bits = source.bits; } public BitVector32 (int init) @@ -184,9 +184,8 @@ if (maxValue < 1) throw new ArgumentException ("maxValue"); - int bit = HighestSetBit(maxValue) + 1; - int mask = (1 << bit) - 1; - int offset = previous.Offset + NumberOfSetBits (previous.Mask); + int mask = (1 << HighestSetBit(maxValue)) - 1; + int offset = previous.Offset + HighestSetBit(previous.Mask); if (offset > 32) { throw new ArgumentException ("Sections cannot exceed 32 bits in total"); @@ -197,10 +196,7 @@ public override bool Equals (object o) { - if (!(o is BitVector32)) - return false; - - return bits == ((BitVector32) o).bits; + return (o is BitVector32) && bits == ((BitVector32) o).bits; } public override int GetHashCode () @@ -218,7 +214,7 @@ StringBuilder b = new StringBuilder (); b.Append ("BitVector32{"); long mask = (long) 0x80000000; - while (mask > 0) { + while (mask != 0) { b.Append (((value.bits & mask) == 0) ? '0' : '1'); mask >>= 1; } @@ -227,27 +223,12 @@ } // Private utilities - private static int NumberOfSetBits (int i) + private static int HighestSetBit (int i) { int count = 0; - for (int bit = 0; bit < 32; bit++) { - int mask = 1 << bit; - if ((i & mask) != 0) - count++; - } + while(i >> count != 0) + count++; return count; } - - private static int HighestSetBit (int i) - { - for (int bit = 31; bit >= 0; bit--) { - int mask = 1 << bit; - if ((mask & i) != 0) { - return bit; - } - } - - return -1; - } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080806/3dbe2a2c/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bitvector32.patch Type: text/x-diff Size: 3622 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080806/3dbe2a2c/attachment-0001.bin From kumpera at gmail.com Wed Aug 6 10:01:47 2008 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Wed, 6 Aug 2008 11:01:47 -0300 Subject: [Mono-dev] BitVector32 patch In-Reply-To: References: Message-ID: <8cca42d80808060701n449b3429x64b79272c948cca9@mail.gmail.com> Hi Scott, Mixing different kinds of changes together in the same patch makes the reviewing process hard. And even if the patch was ok, the mantainer would have to split it anyway to make easier in the future to track down changes. If you could, please, split up your patches it would be nice. About your patch, I left some comments inline. Thanks, Rodrigo 2008/8/5 Scott Peterson > @@ -84,14 +84,12 @@ > > public override int GetHashCode () > { > - return (((Int16) mask).GetHashCode () << 16) + > - ((Int16) offset).GetHashCode (); > + return mask << offset; > } > > What is the possible range of offset? Can't it be bigger than 16 and discard even more bits of entropy from mask? > > @@ -184,9 +184,8 @@ > if (maxValue < 1) > throw new ArgumentException ("maxValue"); > > - int bit = HighestSetBit(maxValue) + 1; > - int mask = (1 << bit) - 1; > - int offset = previous.Offset + NumberOfSetBits > (previous.Mask); > + int mask = (1 << HighestSetBit(maxValue)) - 1; > + int offset = previous.Offset + HighestSetBit(previous.Mask); > > if (offset > 32) { > throw new ArgumentException ("Sections cannot exceed 32 > bits in total"); > Shouldn't it be "int mask = (1 << (HighestSetBit(maxValue) + 1)) - 1;"? Besides that, I think the bit searching function should use a binary search which has better performance. Cheers, Rodrigo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080806/e9ba10ce/attachment.html From lunchtimemama at gmail.com Wed Aug 6 11:24:19 2008 From: lunchtimemama at gmail.com (Scott Peterson) Date: Thu, 7 Aug 2008 03:24:19 +1200 Subject: [Mono-dev] BitVector32 patch In-Reply-To: <8cca42d80808060701n449b3429x64b79272c948cca9@mail.gmail.com> References: <8cca42d80808060701n449b3429x64b79272c948cca9@mail.gmail.com> Message-ID: Thanks Rodrigo. I'll split the patch up tomorrow (almost my bed time). My replies are inline. @@ -84,14 +84,12 @@ >> >> public override int GetHashCode () >> { >> - return (((Int16) mask).GetHashCode () << 16) + >> - ((Int16) offset).GetHashCode (); >> + return mask << offset; >> } >> >> > > What is the possible range of offset? Can't it be bigger than 16 and > discard even more bits > of entropy from mask? > Sections are only instantiated in BitVector32.CreateSection which enforces that the size of the bitmask plus the offset never exceeds 32. This means that mask << offset will never truncate information in mask and will be unique for any legal combination of mask and offset. > @@ -184,9 +184,8 @@ >> if (maxValue < 1) >> throw new ArgumentException ("maxValue"); >> >> - int bit = HighestSetBit(maxValue) + 1; >> - int mask = (1 << bit) - 1; >> - int offset = previous.Offset + NumberOfSetBits >> (previous.Mask); >> + int mask = (1 << HighestSetBit(maxValue)) - 1; >> + int offset = previous.Offset + HighestSetBit(previous.Mask); >> >> if (offset > 32) { >> throw new ArgumentException ("Sections cannot exceed 32 >> bits in total"); >> > > Shouldn't it be "int mask = (1 << (HighestSetBit(maxValue) + 1)) - 1;"? > > Besides that, I think the bit searching function should use a binary search > which has better > performance. > The new HighestSetBit algorithm returns what the old algorithm returned, plus one. The new algorithm is actually more correct. The old algorithm, if pass the number 1, would return 0. Obviously, one bit is set in the binary reprisentation of the number 1. As for a binary search, I did consider it but opted instead for the four-line algorithm. The most loops the alogrithm will make is 31 (when passed 2,147,483,647; negative numbers are not allowed). The smaller the number, the fewer loops (or rather, the fewer bits used to represent the nubmer, the fewer the loops). I imagine most people using BitVector32 are going to pass relatively small maxValues since it is commonly used as a compact store for bool and enum variables. At the very least, I think this is a performance improvement over the old algorithm. Not only is it simpler, but the old algorithm made two loops when passed 2,147,483,647 and 32 loops when passed 1. I'm a fan of binary search, but I think it's overkill for this situation. But I'm happy to be proven wrong :) Cheers, - Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080807/70985c29/attachment.html From debackerl at gmail.com Wed Aug 6 13:55:15 2008 From: debackerl at gmail.com (Debacker) Date: Wed, 6 Aug 2008 19:55:15 +0200 Subject: [Mono-dev] BitVector32 patch In-Reply-To: References: <8cca42d80808060701n449b3429x64b79272c948cca9@mail.gmail.com> Message-ID: <75751ca80808061055u76828b71w97f057b2f524a7a0@mail.gmail.com> Hi Please note that I don't know much about BitVector32, but I do think that there is a better algorithm (if I understand correctly what you want to accomplish): Basically you want to do "int mask = (1 << HighestSetBit(maxValue)) - 1;" where your HighestSetBit method has a loop... well, what about this: private int MostSignificantBit(int x) { x |= (x >> 1); x |= (x >> 2); x |= (x >> 4); x |= (x >> 8); x |= (x >> 16); return(x & ~(x >> 1)); } and then just do "int mask = MostSignificantBit(maxValue) - 1" The algorithm comes from http://aggregate.org/MAGIC/#Most%20Significant%201%20Bit No loop, no branch miss-predictions, looks fine to me. Laurent Debacker. 2008/8/6 Scott Peterson > Thanks Rodrigo. I'll split the patch up tomorrow (almost my bed time). My > replies are inline. > > > @@ -84,14 +84,12 @@ >>> >>> public override int GetHashCode () >>> { >>> - return (((Int16) mask).GetHashCode () << 16) + >>> - ((Int16) offset).GetHashCode (); >>> + return mask << offset; >>> } >>> >>> >> >> What is the possible range of offset? Can't it be bigger than 16 and >> discard even more bits >> of entropy from mask? >> > > Sections are only instantiated in BitVector32.CreateSection which enforces > that the size of the bitmask plus the offset never exceeds 32. This means > that mask << offset will never truncate information in mask and will be > unique for any legal combination of mask and offset. > > >> @@ -184,9 +184,8 @@ >>> if (maxValue < 1) >>> throw new ArgumentException ("maxValue"); >>> >>> - int bit = HighestSetBit(maxValue) + 1; >>> - int mask = (1 << bit) - 1; >>> - int offset = previous.Offset + NumberOfSetBits >>> (previous.Mask); >>> + int mask = (1 << HighestSetBit(maxValue)) - 1; >>> + int offset = previous.Offset + HighestSetBit(previous.Mask); >>> >>> if (offset > 32) { >>> throw new ArgumentException ("Sections cannot exceed 32 >>> bits in total"); >>> >> >> Shouldn't it be "int mask = (1 << (HighestSetBit(maxValue) + 1)) - 1;"? >> >> Besides that, I think the bit searching function should use a binary >> search which has better >> performance. >> > > The new HighestSetBit algorithm returns what the old algorithm returned, > plus one. The new algorithm is actually more correct. The old algorithm, if > pass the number 1, would return 0. Obviously, one bit is set in the binary > reprisentation of the number 1. > > As for a binary search, I did consider it but opted instead for the > four-line algorithm. The most loops the alogrithm will make is 31 (when > passed 2,147,483,647; negative numbers are not allowed). The smaller the > number, the fewer loops (or rather, the fewer bits used to represent the > nubmer, the fewer the loops). I imagine most people using BitVector32 are > going to pass relatively small maxValues since it is commonly used as a > compact store for bool and enum variables. At the very least, I think this > is a performance improvement over the old algorithm. Not only is it simpler, > but the old algorithm made two loops when passed 2,147,483,647 and 32 loops > when passed 1. I'm a fan of binary search, but I think it's overkill for > this situation. But I'm happy to be proven wrong :) > > Cheers, > - Scott > > _______________________________________________ > 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/20080806/14f39d88/attachment.html From tsalvagno at gmail.com Wed Aug 6 14:47:03 2008 From: tsalvagno at gmail.com (linuxfreak@uy) Date: Wed, 6 Aug 2008 11:47:03 -0700 (PDT) Subject: [Mono-dev] VisualwebGUI 6.0.4, Framework 2.0 working with Linux + Mono. In-Reply-To: <18847490.post@talk.nabble.com> References: <18816346.post@talk.nabble.com> <18847490.post@talk.nabble.com> Message-ID: <18857274.post@talk.nabble.com> Stephanus van Staden wrote: > > > We have been using it in SLES 10 and mono 1.9 for quite a while now. Only > the ASP.net part and not the Silverlight stuff... not yet. > > There is a small problem with 64bit SLES 10 SP that we are trying to > solve... Have not tried it on the Mono 2.0 preview yet. > > see my posts to VWG about the 64bit problem here > http://www.visualwebgui.com/Forums/tabid/364/forumid/27/threadid/11378/scope/posts/Default.aspx > VWG 6.1 on SLES 64 bit and Mono 1.9.1 give Invalid IL code > Maybe you have a solution for it.. > > Maybe you can post your WebGUI Howto here on the mono forum? (If thats > allowed) > Stephanus, finally a successfull story. I want to put all the useful information I have, what I found and some workaround however I'm not quite satisfied with it and will try to find maybe another way to make things work. I will try to do further tests in this matter and I will take a look at the problem you just described perhaps I could find something. Finally I've tested once or twice VWG 6.1.2 on Linux and found that it's generating an exception at Gizmox.WebGUI.Server assembly but since it's currently an unstable release I will wait til it's stable. At last Silverlight it's another different story, I've also tested very little and I couldn't get it work in any environment. My environment Configuration: #Server base OpenSuSe 11.0 (32 bits) + Apache2 (2.2.8-28.1) + Mono (1.9.1-6.1) + mod_mono apache2 module (1.9-20.1) #Development base Windows XP , Visual Studio 2005, VisualwebGUI 6.0.4 for framework 2.0 Problem found (some background): Originally the apache2 mod_mono module uses "mod-mono-server" (/usr/bin/mod-mono-server) which is a script that finally calls THE "mod-mono-server.exe" that is the actual interpreter of all the ASP.NET stuff. There is also a version 2 of the "mod-mono-server" called "mod-mono-server2". Finally there is two more scripts, "xsp" and "xsp2" which both are a Mono ASP.NET Web Server implementation. Basically the problem is that with "mod-mono-server" or "xsp" a VisualwebGUI application won't work because none of the "servers" can't load assemblies for the .NET framework 2.0 but is only loads assemblies for the .NET framework 1.0. There is also another problem, the "mod-mono-server2" can load the framework 2.0 and works fine with any regular ASP.NET but not with VisualwebGUI. But there is a light at the end of the tunnel, according to my tests using the "xsp2" a VisualwebGUI runs without problems. Deploy : This a basic solution and at first glance not recomended for a production server but it's a start. 1. not use apache2 + mono to use with VisualwebGUI 2. use XSP2 to run the VisualWebGUI app See documentation but a simple example would be: /usr/bin/xsp2 --port 80 --root /srv/www/htdocs Copy all the application needed files to /srv/www/htdocs and simply http://server/Form1.wgx 3. Modification to "Web.config" To make it work you must make a simple change in the web.config file Original setting: Modified setting: You must also strip the ' ' from the name of the project/solution in this case, 'WebGUIApplication1'. NOTE1: This modification works fine also with IIS or Visual Studio dev web server. NOTE2: I could noticed that apparently this modification is not needed when using Visual Studio 2008. 4. Web Explorers tests Works fine for me with Firefox 3.0 (from KDE 3 and Windows) and with IE7 (notably slower than the Firefox at least with VisualWebGUI, not trying to start any discussion about this matter... :) ) -- View this message in context: http://www.nabble.com/VisualwebGUI-6.0.4%2C-Framework-2.0-working-with-Linux-%2B-Mono.-tp18816346p18857274.html Sent from the Mono - Dev mailing list archive at Nabble.com. From sqlite_list at bcsft.com Wed Aug 6 17:38:12 2008 From: sqlite_list at bcsft.com (Robert Simpson) Date: Wed, 6 Aug 2008 14:38:12 -0700 Subject: [Mono-dev] System.Data.SQLite changes that may interest Mono users Message-ID: <00b701c8f80c$ba7fe8e0$2f7fbaa0$@com> I just posted version 1.0.55.0 of the System.Data.SQLite provider here: http://sqlite.phxsoftware.com Included in this update is an option to recompile the managed provider portion of the code with a SQLITE_STANDARD preprocessor symbol defined. If set, the provider will compile as managed only and p/invoke against the stock "sqlite3" library with about 99% functionality of my modified version. I also added the URI connection string from Marek's mono modifications. I *think* that at this point all you'd have to do is rename the namespace and re-case the class names to get my provider sync'd up to the Mono.Data.Sqlite provider. If anyone's interested in working on that and giving me feedback, I'd be happy to make any other changes needed in my version to help keep the mono edition as easy to maintain for you guys as possible. One major caveat: Dr. Hipp only just this version (3.6.1) added precompiled binary support for several metadata API functions. The Mono.Data.Sqlite provider was p/invoking these functions already, but the default binary from sqlite.org did not export them. They included sqlite3_table_column_metadata(), sqlite3_column_orig(), and several other metadata-related functions. As such, the only version of System.Data.SQLite (and in fact any version of the Mono.Data.Sqlite provider) that will pass a complete round of unit tests is when backed to SQLite 3.6.1. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080806/6184def0/attachment.html From debackerl at gmail.com Wed Aug 6 18:35:21 2008 From: debackerl at gmail.com (Debacker) Date: Thu, 7 Aug 2008 00:35:21 +0200 Subject: [Mono-dev] BitVector32 patch In-Reply-To: <75751ca80808061055u76828b71w97f057b2f524a7a0@mail.gmail.com> References: <8cca42d80808060701n449b3429x64b79272c948cca9@mail.gmail.com> <75751ca80808061055u76828b71w97f057b2f524a7a0@mail.gmail.com> Message-ID: <75751ca80808061535s5cd53588tfb137e71910b0f89@mail.gmail.com> Sorry I copy & pasted the bug of Scott, the suggestion made by Rodrigo would become int mask = MostSignificantBit(maxValue); mask |= mask - 1; Or just "int mask = (MostSignificantBit(maxValue) << 1) - 1" depending how the JIT optimizes the former. Laurent. On Wed, Aug 6, 2008 at 7:55 PM, Debacker wrote: > Hi > > Please note that I don't know much about BitVector32, but I do think that > there is a better algorithm (if I understand correctly what you want to > accomplish): > > Basically you want to do "int mask = (1 << HighestSetBit(maxValue)) - 1;" > where your HighestSetBit method has a loop... well, what about this: > > private int MostSignificantBit(int x) > { > x |= (x >> 1); > x |= (x >> 2); > x |= (x >> 4); > x |= (x >> 8); > x |= (x >> 16); > return(x & ~(x >> 1)); > > } > > and then just do "int mask = MostSignificantBit(maxValue) - 1" > > The algorithm comes from > http://aggregate.org/MAGIC/#Most%20Significant%201%20Bit > > No loop, no branch miss-predictions, looks fine to me. > > Laurent Debacker. > > 2008/8/6 Scott Peterson > >> Thanks Rodrigo. I'll split the patch up tomorrow (almost my bed time). My >> replies are inline. >> >> >> @@ -84,14 +84,12 @@ >>>> >>>> public override int GetHashCode () >>>> { >>>> - return (((Int16) mask).GetHashCode () << 16) + >>>> - ((Int16) offset).GetHashCode (); >>>> + return mask << offset; >>>> } >>>> >>>> >>> >>> What is the possible range of offset? Can't it be bigger than 16 and >>> discard even more bits >>> of entropy from mask? >>> >> >> Sections are only instantiated in BitVector32.CreateSection which enforces >> that the size of the bitmask plus the offset never exceeds 32. This means >> that mask << offset will never truncate information in mask and will be >> unique for any legal combination of mask and offset. >> >> >>> @@ -184,9 +184,8 @@ >>>> if (maxValue < 1) >>>> throw new ArgumentException ("maxValue"); >>>> >>>> - int bit = HighestSetBit(maxValue) + 1; >>>> - int mask = (1 << bit) - 1; >>>> - int offset = previous.Offset + NumberOfSetBits >>>> (previous.Mask); >>>> + int mask = (1 << HighestSetBit(maxValue)) - 1; >>>> + int offset = previous.Offset + >>>> HighestSetBit(previous.Mask); >>>> >>>> if (offset > 32) { >>>> throw new ArgumentException ("Sections cannot exceed 32 >>>> bits in total"); >>>> >>> >>> Shouldn't it be "int mask = (1 << (HighestSetBit(maxValue) + 1)) - 1;"? >>> >>> Besides that, I think the bit searching function should use a binary >>> search which has better >>> performance. >>> >> >> The new HighestSetBit algorithm returns what the old algorithm returned, >> plus one. The new algorithm is actually more correct. The old algorithm, if >> pass the number 1, would return 0. Obviously, one bit is set in the binary >> reprisentation of the number 1. >> >> As for a binary search, I did consider it but opted instead for the >> four-line algorithm. The most loops the alogrithm will make is 31 (when >> passed 2,147,483,647; negative numbers are not allowed). The smaller the >> number, the fewer loops (or rather, the fewer bits used to represent the >> nubmer, the fewer the loops). I imagine most people using BitVector32 are >> going to pass relatively small maxValues since it is commonly used as a >> compact store for bool and enum variables. At the very least, I think this >> is a performance improvement over the old algorithm. Not only is it simpler, >> but the old algorithm made two loops when passed 2,147,483,647 and 32 loops >> when passed 1. I'm a fan of binary search, but I think it's overkill for >> this situation. But I'm happy to be proven wrong :) >> >> Cheers, >> - Scott >> >> _______________________________________________ >> 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/20080807/46474e92/attachment.html From lunchtimemama at gmail.com Wed Aug 6 22:27:20 2008 From: lunchtimemama at gmail.com (Scott Peterson) Date: Thu, 7 Aug 2008 14:27:20 +1200 Subject: [Mono-dev] BitVector32 patch In-Reply-To: <75751ca80808061535s5cd53588tfb137e71910b0f89@mail.gmail.com> References: <8cca42d80808060701n449b3429x64b79272c948cca9@mail.gmail.com> <75751ca80808061055u76828b71w97f057b2f524a7a0@mail.gmail.com> <75751ca80808061535s5cd53588tfb137e71910b0f89@mail.gmail.com> Message-ID: OK kids, bad news. There's a bug in the BitVector32 code. The real problem is, it's buggy in .NET too. Here's a test case: using System; using System.Collections.Specialized; class MainClass { public static void Main (string[] args) { var section1 = BitVector32.CreateSection (32767); var section2 = BitVector32.CreateSection (32767, section1); var section3 = BitVector32.CreateSection (128, section2); var vector = new BitVector32 (0); vector[section3] = 128; Console.WriteLine(vector[section3]); } } The output of this program on Mono and .NET is '0'. Obviously this should throw an exception at the third CreateSection call. If we decides to keep the buggy behavior for compatibility, we can use a method similar to the one Laurent mentioned. If we decide to fix the bug, we won't be able to use it since we'll need to know the length of the mask. I vote for fixing, but I don't know the protocol for these sorts of things. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080807/a09b1dce/attachment.html From olh at suse.de Thu Aug 7 10:23:58 2008 From: olh at suse.de (Olaf Hering) Date: Thu, 7 Aug 2008 16:23:58 +0200 Subject: [Mono-dev] [PATCH] use gcc 4.1 atomic built-ins Message-ID: <20080807142358.GA24345@suse.de> While trying to get mono running on powerpc64, I experienced a hang in GC_lock on my POWER6 test system. This was caused by incorrect powerpc64 locking code in libgc. With this change, the binary got a bit further. But it still fails for other unrelated reasons. gcc 4.1 has helper functions for atomic operations: http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html Please review. --- a/libgc/include/private/gc_locks.h +++ b/libgc/include/private/gc_locks.h @@ -88,6 +88,18 @@ /* acquisition and release. We need this for correct operation of the */ /* incremental GC. */ # ifdef __GNUC__ +#if __GNUC__ >= 4 && __GNUC_MINOR__ >= 1 +static inline int GC_test_and_set(volatile unsigned int *addr) +{ +#define GC_TEST_AND_SET_DEFINED + return (int)__sync_lock_test_and_set(addr, 1); +} +static inline void GC_clear(volatile unsigned int *addr) +{ +#define GC_CLEAR_DEFINED + __sync_lock_test_and_set(addr, 0); +} +#else /* ! __GNUC__ 4.1+ */ # if defined(I386) inline static int GC_test_and_set(volatile unsigned int *addr) { int oldval; @@ -288,6 +300,7 @@ return ret; } # endif +# endif /* !__GNUC__ 4.1+ */ # endif /* __GNUC__ */ # if (defined(ALPHA) && !defined(__GNUC__)) # ifndef OSF1 --- a/mono/io-layer/atomic.h +++ b/mono/io-layer/atomic.h @@ -14,6 +14,39 @@ #include "mono/io-layer/wapi.h" +#if defined(__GNUC__) && __GNUC__ >= 4 && __GNUC_MINOR__ >= 1 +/* requires gcc 4.1 for atomic built-ins */ +#define WAPI_ATOMIC_ASM +static inline gint32 InterlockedCompareExchange(volatile gint32 *dest, gint32 exch, gint32 comp) +{ + return __sync_val_compare_and_swap(dest, exch, comp); +} +static inline gpointer InterlockedCompareExchangePointer(volatile gpointer *dest, gpointer exch, gpointer comp) +{ + return __sync_val_compare_and_swap(dest, exch, comp); +} +static inline gint32 InterlockedIncrement(volatile gint32 *dest) +{ + return __sync_fetch_and_add(dest, 1) + 1; +} +static inline gint32 InterlockedDecrement(volatile gint32 *dest) +{ + return __sync_fetch_and_sub(dest, 1) - 1; +} +static inline gint32 InterlockedExchange(volatile gint32 *dest, gint32 exch) +{ + return __sync_lock_test_and_set(dest, exch); +} +static inline gpointer InterlockedExchangePointer(volatile gpointer *dest, gpointer exch) +{ + return __sync_lock_test_and_set(dest, exch); +} +static inline gint32 InterlockedExchangeAdd(volatile gint32 *dest, gint32 add) +{ + return __sync_fetch_and_add(dest, add); +} +#else /* !__GNUC__ 4.1+ */ + #if defined(__i386__) || defined(__x86_64__) #define WAPI_ATOMIC_ASM @@ -1025,4 +1058,6 @@ extern gint32 InterlockedExchangeAdd(vol #endif +#endif /* !__GNUC__ 4.1+ */ + #endif /* _WAPI_ATOMIC_H_ */ From andreas.faerber at web.de Thu Aug 7 12:39:13 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Thu, 7 Aug 2008 18:39:13 +0200 Subject: [Mono-dev] [PATCH] use gcc 4.1 atomic built-ins In-Reply-To: <20080807142358.GA24345@suse.de> References: <20080807142358.GA24345@suse.de> Message-ID: <9C2A25CE-5E71-4D8A-B57F-7FDBD8B3D610@web.de> Hello, Am 07.08.2008 um 16:23 schrieb Olaf Hering: > While trying to get mono running on powerpc64, I experienced a hang in > GC_lock on my POWER6 test system. This was caused by incorrect > powerpc64 > locking code in libgc. Usually, random changes to libgc are not allowed. You can either download and use an up-to-date Boehm GC (e.g., 7.1) or disable the GC completely while porting (--with-gc=none). If it's not in the latest Boehm GC it would be a good idea to submit it upstream. Andreas > With this change, the binary got a bit further. But it still fails for > other unrelated reasons. > > gcc 4.1 has helper functions for atomic operations: > http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html > > > Please review. > > --- a/libgc/include/private/gc_locks.h > +++ b/libgc/include/private/gc_locks.h > @@ -88,6 +88,18 @@ > /* acquisition and release. We need this for correct operation of > the */ > /* incremental GC. */ > # ifdef __GNUC__ > +#if __GNUC__ >= 4 && __GNUC_MINOR__ >= 1 > +static inline int GC_test_and_set(volatile unsigned int *addr) > +{ > +#define GC_TEST_AND_SET_DEFINED > + return (int)__sync_lock_test_and_set(addr, 1); > +} > +static inline void GC_clear(volatile unsigned int *addr) > +{ > +#define GC_CLEAR_DEFINED > + __sync_lock_test_and_set(addr, 0); > +} > +#else /* ! __GNUC__ 4.1+ */ > # if defined(I386) > inline static int GC_test_and_set(volatile unsigned int > *addr) { > int oldval; > @@ -288,6 +300,7 @@ > return ret; > } > # endif > +# endif /* !__GNUC__ 4.1+ */ > # endif /* __GNUC__ */ > # if (defined(ALPHA) && !defined(__GNUC__)) > # ifndef OSF1 > --- a/mono/io-layer/atomic.h > +++ b/mono/io-layer/atomic.h > @@ -14,6 +14,39 @@ > > #include "mono/io-layer/wapi.h" > > +#if defined(__GNUC__) && __GNUC__ >= 4 && __GNUC_MINOR__ >= 1 > +/* requires gcc 4.1 for atomic built-ins */ > +#define WAPI_ATOMIC_ASM > +static inline gint32 InterlockedCompareExchange(volatile gint32 > *dest, gint32 exch, gint32 comp) > +{ > + return __sync_val_compare_and_swap(dest, exch, comp); > +} > +static inline gpointer InterlockedCompareExchangePointer(volatile > gpointer *dest, gpointer exch, gpointer comp) > +{ > + return __sync_val_compare_and_swap(dest, exch, comp); > +} > +static inline gint32 InterlockedIncrement(volatile gint32 *dest) > +{ > + return __sync_fetch_and_add(dest, 1) + 1; > +} > +static inline gint32 InterlockedDecrement(volatile gint32 *dest) > +{ > + return __sync_fetch_and_sub(dest, 1) - 1; > +} > +static inline gint32 InterlockedExchange(volatile gint32 *dest, > gint32 exch) > +{ > + return __sync_lock_test_and_set(dest, exch); > +} > +static inline gpointer InterlockedExchangePointer(volatile gpointer > *dest, gpointer exch) > +{ > + return __sync_lock_test_and_set(dest, exch); > +} > +static inline gint32 InterlockedExchangeAdd(volatile gint32 *dest, > gint32 add) > +{ > + return __sync_fetch_and_add(dest, add); > +} > +#else /* !__GNUC__ 4.1+ */ > + > #if defined(__i386__) || defined(__x86_64__) > #define WAPI_ATOMIC_ASM > > @@ -1025,4 +1058,6 @@ extern gint32 InterlockedExchangeAdd(vol > > #endif > > +#endif /* !__GNUC__ 4.1+ */ > + > #endif /* _WAPI_ATOMIC_H_ */ > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From andreas.faerber at web.de Thu Aug 7 13:50:09 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Thu, 7 Aug 2008 19:50:09 +0200 Subject: [Mono-dev] [PATCH] Fix Apple sysctl argument Message-ID: <14E6EE43-6B80-4C88-B7DF-2C116CF93A03@web.de> Hello, The attached patch fixes a 64-bit OSX-only compilation error for sysctl in mini-ppc.c. sysctl on v10.5 has a "size_t *oldlenp" argument, not "int *oldlenp". Same on v10.3.9. Patch extracted from my series at https://bugzilla.novell.com/show_bug.cgi?id=324134 Compiles okay on ppc and ppc64. Please approve for trunk. Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: ppc64-sysctl.diff Type: application/octet-stream Size: 376 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080807/124e49b0/attachment.obj -------------- next part -------------- From olh at suse.de Thu Aug 7 14:44:53 2008 From: olh at suse.de (Olaf Hering) Date: Thu, 7 Aug 2008 20:44:53 +0200 Subject: [Mono-dev] [PATCH] use gcc 4.1 atomic built-ins In-Reply-To: <9C2A25CE-5E71-4D8A-B57F-7FDBD8B3D610@web.de> References: <20080807142358.GA24345@suse.de> <9C2A25CE-5E71-4D8A-B57F-7FDBD8B3D610@web.de> Message-ID: <20080807184453.GA31507@suse.de> On Thu, Aug 07, Andreas F?rber wrote: > Hello, > > Am 07.08.2008 um 16:23 schrieb Olaf Hering: > >> While trying to get mono running on powerpc64, I experienced a hang in >> GC_lock on my POWER6 test system. This was caused by incorrect powerpc64 >> locking code in libgc. > > Usually, random changes to libgc are not allowed. You can either download > and use an up-to-date Boehm GC (e.g., 7.1) or disable the GC completely > while porting (--with-gc=none). > > If it's not in the latest Boehm GC it would be a good idea to submit it > upstream. What about the io-layer part? From andreas.faerber at web.de Thu Aug 7 14:53:53 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Thu, 7 Aug 2008 20:53:53 +0200 Subject: [Mono-dev] [PATCH] use gcc 4.1 atomic built-ins In-Reply-To: <20080807184453.GA31507@suse.de> References: <20080807142358.GA24345@suse.de> <9C2A25CE-5E71-4D8A-B57F-7FDBD8B3D610@web.de> <20080807184453.GA31507@suse.de> Message-ID: <33F96FA5-C41B-4399-9FCB-60510CB23758@web.de> Am 07.08.2008 um 20:44 schrieb Olaf Hering: > On Thu, Aug 07, Andreas F?rber wrote: > >> Hello, >> >> Am 07.08.2008 um 16:23 schrieb Olaf Hering: >> >>> While trying to get mono running on powerpc64, I experienced a >>> hang in >>> GC_lock on my POWER6 test system. This was caused by incorrect >>> powerpc64 >>> locking code in libgc. >> >> Usually, random changes to libgc are not allowed. You can either >> download >> and use an up-to-date Boehm GC (e.g., 7.1) or disable the GC >> completely >> while porting (--with-gc=none). >> >> If it's not in the latest Boehm GC it would be a good idea to >> submit it >> upstream. > > What about the io-layer part? OSX uses gcc 4.0.1, so I can't test gcc 4.1 optimizations there, and we will need my no-gcc-4.1+ppc64 version as well. Yours looks interesting though. Andreas From olh at suse.de Thu Aug 7 14:59:09 2008 From: olh at suse.de (Olaf Hering) Date: Thu, 7 Aug 2008 20:59:09 +0200 Subject: [Mono-dev] [PATCH] fix libtool usage in configure.in Message-ID: <20080807185909.GA31914@suse.de> Don't use libtool before it is created. Fixes error like this: ./configure: line 2874: ./libtool: No such file or directory --- configure.in | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/configure.in +++ b/configure.in @@ -49,8 +49,6 @@ libmono_cflags="" libmono_ldflags="" AC_SUBST(libmono_cflags) AC_SUBST(libmono_ldflags) -export_ldflags=`(./libtool --config; echo eval echo \\$export_dynamic_flag_spec) | sh` -AC_SUBST(export_ldflags) # Variable to have relocatable .pc files (lib, or lib64) reloc_libdir=`basename ${libdir}` @@ -303,6 +301,10 @@ AM_PROG_LIBTOOL # Use dolt (http://dolt.freedesktop.org/) instead of libtool for building. DOLT +m4_ifdef([LT_OUTPUT], [LT_OUTPUT]) +export_ldflags=`(./libtool --config; echo eval echo \\$export_dynamic_flag_spec) | sh` +AC_SUBST(export_ldflags) + # Test whenever ld supports -version-script AC_PROG_LD AC_PROG_LD_GNU From trofimich at gmail.com Fri Aug 8 06:46:22 2008 From: trofimich at gmail.com (sasha) Date: Fri, 08 Aug 2008 13:46:22 +0300 Subject: [Mono-dev] Mono 2.0 Preview 1 is out!! In-Reply-To: <489396D0.6020509@novell.com> References: <489396D0.6020509@novell.com> Message-ID: Paint.NET 3.30 not working with mono 2.0 I've started it in --debug mode, but there are too many bugs in WinForms implementation :-( From kumpera at gmail.com Fri Aug 8 18:25:43 2008 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Fri, 8 Aug 2008 19:25:43 -0300 Subject: [Mono-dev] Arm overflow arithmetic Message-ID: <8cca42d80808081525u78947acfj74237ee00905abde@mail.gmail.com> Hey guys, I just got myself into a roadblock today while fixing overflow arithmetic under ARM. The issue is that the emitted IR cannot be properly translated to native code. The ARM ISA has the oddity that carry/borrow works in the opposite way. Add with carry do a +1 if the carry bit is set, but Sub with borrow do a -1 if the carry bit is not set. Then we have mono_decompose_opcode that use the same condition for both add and sub: case OP_IADD_OVF: ins->opcode = OP_IADDCC; MONO_EMIT_NEW_COND_EXC (cfg, IOV, "OverflowException"); break; case OP_ISUB_OVF: ins->opcode = OP_ISUBCC; MONO_EMIT_NEW_COND_EXC (cfg, IOV, "OverflowException"); break; I cannot fix that in the arm back-end as it should not reason about previous instructions. My idea is to either move the SUB opcodes to arch specific code or add an #if MONO_ARCH_SUB_INVERTED_CARRY_FLAG. What do you guys think about this? Cheers, Rodrigo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080808/7ccccd14/attachment.html From vargaz at gmail.com Fri Aug 8 18:28:35 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Sat, 9 Aug 2008 00:28:35 +0200 Subject: [Mono-dev] Arm overflow arithmetic In-Reply-To: <8cca42d80808081525u78947acfj74237ee00905abde@mail.gmail.com> References: <8cca42d80808081525u78947acfj74237ee00905abde@mail.gmail.com> Message-ID: <295e750a0808081528s4124c20la44021fd80126b8a@mail.gmail.com> Hi, I would vote for adding a flag, as it is simpler. Zoltan On Sat, Aug 9, 2008 at 12:25 AM, Rodrigo Kumpera wrote: > Hey guys, > > I just got myself into a roadblock today while fixing overflow arithmetic > under ARM. The issue is that the emitted IR > cannot be properly translated to native code. > > The ARM ISA has the oddity that carry/borrow works in the opposite way. Add > with carry do a +1 if the carry bit is set, > but Sub with borrow do a -1 if the carry bit is not set. > > Then we have mono_decompose_opcode that use the same condition for both add > and sub: > > case OP_IADD_OVF: > ins->opcode = OP_IADDCC; > MONO_EMIT_NEW_COND_EXC (cfg, IOV, "OverflowException"); > break; > case OP_ISUB_OVF: > ins->opcode = OP_ISUBCC; > MONO_EMIT_NEW_COND_EXC (cfg, IOV, "OverflowException"); > break; > > > I cannot fix that in the arm back-end as it should not reason about previous > instructions. > My idea is to either move the SUB opcodes to arch specific code or add an > #if MONO_ARCH_SUB_INVERTED_CARRY_FLAG. > > What do you guys think about this? > > Cheers, > Rodrigo > > > From kumpera at gmail.com Fri Aug 8 18:59:59 2008 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Fri, 8 Aug 2008 19:59:59 -0300 Subject: [Mono-dev] Unused MONO_ARCH define Message-ID: <8cca42d80808081559j7448ebd7g5ba40348738124b0@mail.gmail.com> Hi Zoltan, method-to-ir.c has a misspelled define. MONO_ARCH_NO_EMULATE_LONG_SHIFT_OPTS instead of MONO_ARCH_NO_EMULATE_LONG_SHIFT_OPS as in mini.c I guess changing this will pop up some errors in mono_decompose_long_opts. Cheers, Rodrigo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080808/6a8ee32a/attachment.html From buhochileno at gmail.com Fri Aug 8 20:59:37 2008 From: buhochileno at gmail.com (buhochileno at gmail.com) Date: Fri, 08 Aug 2008 20:59:37 -0400 Subject: [Mono-dev] shared library wrapper question In-Reply-To: <8cca42d80808081559j7448ebd7g5ba40348738124b0@mail.gmail.com> References: <8cca42d80808081559j7448ebd7g5ba40348738124b0@mail.gmail.com> Message-ID: <489CEBF9.3010802@gmail.com> Hi guys: I'm trying to write a basic Festival tts wrapper, but I get System.DllNotFoundException: libFestival and I think that may be is related to that any festival C API code need to be compiled using links to other shared speechtools libs (libestbase, libeststring....), Any program that use the festival C API have to be compiled like: g++32 -o festivalsimpletest festivalsimpletest.c -I/usr/include/festival -I/usr/src/tar/speech_tools/include -lFestival -lestools -lestbase -leststring -Wno-deprecated My wrapper code is like: [DllImport("libFestival")] public static extern void festival_initialize(int load_init_files,int heap_size); where festival_initialize is defined as: void festival_initialize(int load_init_files,int heap_size); from C the function is used simple like: festival_initialize(1,210000); of course libFestival.so exist and work... So, may be is related to that a program that need libFestival.so also need libestbase,so, etc?, how can I check where is the problems..?, inea ideas?, directions? Thanks Mauricio From jacobgladish at yahoo.com Fri Aug 8 21:11:51 2008 From: jacobgladish at yahoo.com (Jacob Gladish) Date: Fri, 8 Aug 2008 18:11:51 -0700 (PDT) Subject: [Mono-dev] shared library wrapper question Message-ID: <305914.55448.qm@web39503.mail.mud.yahoo.com> Try removing the lib from libFestival 'Festival' and make sure that the .so is in your LD_LIBRARY_PATH ----- Original Message ---- From: "buhochileno at gmail.com" To: Mono devel list Cc: Zoltan Varga Sent: Friday, August 8, 2008 8:59:37 PM Subject: [Mono-dev] shared library wrapper question Hi guys: I'm trying to write a basic Festival tts wrapper, but I get System.DllNotFoundException: libFestival and I think that may be is related to that any festival C API code need to be compiled using links to other shared speechtools libs (libestbase, libeststring....), Any program that use the festival C API have to be compiled like: g++32 -o festivalsimpletest festivalsimpletest.c -I/usr/include/festival -I/usr/src/tar/speech_tools/include -lFestival -lestools -lestbase -leststring -Wno-deprecated My wrapper code is like: [DllImport("libFestival")] public static extern void festival_initialize(int load_init_files,int heap_size); where festival_initialize is defined as: void festival_initialize(int load_init_files,int heap_size); from C the function is used simple like: festival_initialize(1,210000); of course libFestival.so exist and work... So, may be is related to that a program that need libFestival.so also need libestbase,so, etc?, how can I check where is the problems..?, inea ideas?, directions? Thanks Mauricio _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From buhochileno at gmail.com Fri Aug 8 21:50:53 2008 From: buhochileno at gmail.com (buhochileno at gmail.com) Date: Fri, 08 Aug 2008 21:50:53 -0400 Subject: [Mono-dev] shared library wrapper question In-Reply-To: <305914.55448.qm@web39503.mail.mud.yahoo.com> References: <305914.55448.qm@web39503.mail.mud.yahoo.com> Message-ID: <489CF7FD.2070006@gmail.com> Jacob Gladish wrote: > Try removing the lib from libFestival 'Festival' and make sure that the .so is in your LD_LIBRARY_PATH > > remove the "lib" part?, whay? the library is called libFestival.so, like in the libm.so example, the wrapper use the name "libm", well anyway I remove the "lib" part but same error and yes the libFestival.so is in LD_LIBRAY_PATH and working, becouse other test C programs can used adding -lFestival to the compilation ...) other ideas?, tests? thanks > > > > > ----- Original Message ---- > From: "buhochileno at gmail.com" > To: Mono devel list > Cc: Zoltan Varga > Sent: Friday, August 8, 2008 8:59:37 PM > Subject: [Mono-dev] shared library wrapper question > > Hi guys: > > I'm trying to write a basic Festival tts wrapper, but I get > System.DllNotFoundException: libFestival and I think that may be is > related to that any festival C API code need to be compiled using links > to other shared speechtools libs (libestbase, libeststring....), > Any program that use the festival C API have to be compiled like: > g++32 -o festivalsimpletest festivalsimpletest.c > -I/usr/include/festival -I/usr/src/tar/speech_tools/include -lFestival > -lestools -lestbase -leststring -Wno-deprecated > > My wrapper code is like: > [DllImport("libFestival")] > public static extern void festival_initialize(int load_init_files,int > heap_size); > > where festival_initialize is defined as: void festival_initialize(int > load_init_files,int heap_size); from C the function is used simple like: > festival_initialize(1,210000); > of course libFestival.so exist and work... > > So, may be is related to that a program that need libFestival.so also > need libestbase,so, etc?, how can I check where is the problems..?, inea > ideas?, directions? > > Thanks > > Mauricio > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > From buhochileno at gmail.com Sat Aug 9 00:50:05 2008 From: buhochileno at gmail.com (buhochileno at gmail.com) Date: Sat, 09 Aug 2008 00:50:05 -0400 Subject: [Mono-dev] Festival TTS Wrapper In-Reply-To: <4DB1FFA6-D027-465E-A5BC-D1B293567E35@monkeypox.org> References: <47266A26.5080206@gmail.com> <4DB1FFA6-D027-465E-A5BC-D1B293567E35@monkeypox.org> Message-ID: <489D21FD.7000306@gmail.com> Hi: recently I discover that the swig proyect help a lot generating most of the wrapper code, so I try with flite headers and create my a compilation set of .cs files, but at runing time I'm getting errors, but may be is worth to try it, or may be use it to traslate the freetts java code to c# to have a complete managed tts engine on mono, but i think that traslate freetts can be hard, the java source even interact with the sound card directly..is posible to use other voices with flite (like festival ones or mbrola voices.)... Cheers, Mauricio R. Tyler Ballance wrote: > > On Oct 29, 2007, at 4:17 PM, buhochileno at gmail.com wrote: > >> Sorry to disapoint you, but my wrapper is not even a "server" call to >> the festival TTS, is more cheating :-), is only a wrapper for a C >> shared library that send the correct "echo $MESSAGE | festival --tts" >> :-) , I also see the posibility to try a more sofisticate wrapper, >> but as you say is to much complicate, so this is a working approach :-) > > A novel approach to say the least, but I agree, it's not great, but > it's a start :) > >> I attach the C shared library and the C# wraper with a simple test >> program. >> >> May be we can work in a better wrapper. > > I also agree on this :) > > I think we should consider approaching "managed text-to-speech" from > the side of Flite instead of Festival (I think lupus actually > suggested this when I was first discussing it on #mono, but I > foolishly went ahead with trying for Festival anyways). The one core > thing I started to do with my wrapper (from here out referred to as > Tao.Festival) was provide support for both a server-oriented Festival > interface, i.e. connecting on the Festival's port (1234 I believe) and > then performing the commands, or using a C#->C->C++ wrapper I had > written to take advantage of libFestival.a which is usually installed > on most Linux systems when the Festival package is added. I had not > started on the server-oriented code yet, but had the wrappers in place > for relying on libFestival which proved to be "a stupid idea" and > will/would cause the entire Mono process to SIGSEGV every single time > because of some of the intricacies to native platform interop with > code that's *so* expectant on being statically linked *always* as > Festival is. I can upload the code to my anonymous Subversion > repository, but I think it's only worth it from a "research" > perspective in seeing why exactly Festival is a bad route to go with :) > > Our end goal is easy to define I think, ideally we would want to > provide developers with the following calls: > Mono.Speech.SayText("Hello Monkeys!"); > Mono.Speech.SayText("Hello Monkeys!", FileStream, > Mono.Speech.WaveFileType); > > I suggest you look at the following for an idea on why Flite will be > far easier: > http://www.speech.cs.cmu.edu/flite/doc/flite_7.html#SEC17 > > I will try to port my existing design of Tao.Festival over to > something more Flite-based this weekend, at the very least to evaluate > whether or not Flite will truly be a better option than Festival, and > to evaluate whether the concept will *actually* work. > > As much as I would love to be able to provide compatibility with > Microsoft's new System.Speech.Synthesis API, I just don't think that's > ever going to be possible given the state of open source speech > synthe