From kostat at mainsoft.com Tue May 1 02:40:39 2007 From: kostat at mainsoft.com (Konstantin Triger) Date: Mon, 30 Apr 2007 23:40:39 -0700 Subject: [Mono-dev] [PATCH] System.Xml: Fix exception type in XmlNode.ReplaceChild Message-ID: Hello all, Attached a patch and a test case for a small fix for type of an exception thrown. Please review. Regards, Konstantin Triger -------------- next part -------------- A non-text attachment was scrubbed... Name: replacechildexception.patch Type: application/octet-stream Size: 1217 bytes Desc: replacechildexception.patch Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070430/15a5530b/attachment.obj From andreas.faerber at web.de Tue May 1 09:30:00 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Tue, 1 May 2007 15:30:00 +0200 Subject: [Mono-dev] Mono on Windows/x64 In-Reply-To: <17c2d80b0704260900g3b11ca2eo133514248c698e67@mail.gmail.com> References: <001901c784f6$4209fac0$0100a8c0@kornelpal.hu> <17c2d80b0704231022s57088b44xf3f200eb6cb1d375@mail.gmail.com> <4F1A5396F3238F43BB5A5358C48CCAB80404E4@Server1.jerris.local> <17c2d80b0704231044i14596a1atafe8b1846c43a224@mail.gmail.com> <4F1A5396F3238F43BB5A5358C48CCAB80404E5@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404E8@Server1.jerris.local> <1177359731.21140.211.camel@mirrors.mathematik.uni-bielefeld.de> <4F1A5396F3238F43BB5A5358C48CCAB80404EB@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404EC@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404EF@Server1.jerris.local> <17c2d80b0704260900g3b11ca2eo133514248c698e67@mail.gmail.com> Message-ID: Hey, Looking at SVN head you have ignored my g_strndup patch and introduced a bug in your alternative implementation. Please look at it, we need to alloc n+1 bytes, not n, or jay and genmdesc etc. will produce garbage. Also, in glib the g* types should be used. Andreas From joncham at gmail.com Tue May 1 09:50:52 2007 From: joncham at gmail.com (Jonathan Chambers) Date: Tue, 1 May 2007 09:50:52 -0400 Subject: [Mono-dev] Mono on Windows/x64 In-Reply-To: References: <001901c784f6$4209fac0$0100a8c0@kornelpal.hu> <17c2d80b0704231044i14596a1atafe8b1846c43a224@mail.gmail.com> <4F1A5396F3238F43BB5A5358C48CCAB80404E5@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404E8@Server1.jerris.local> <1177359731.21140.211.camel@mirrors.mathematik.uni-bielefeld.de> <4F1A5396F3238F43BB5A5358C48CCAB80404EB@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404EC@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404EF@Server1.jerris.local> <17c2d80b0704260900g3b11ca2eo133514248c698e67@mail.gmail.com> Message-ID: <17c2d80b0705010650l70029c9r5126b9086e110f3c@mail.gmail.com> Andreas, Sorry, I didn't intentionally ignore your patch. The one from Michael was so large I didn't try to merge the two. I'll merge in your changes you submitted and repost unless someone else gets to it first. Thanks, Jonathan On 5/1/07, Andreas F?rber wrote: > > Hey, > > Looking at SVN head you have ignored my g_strndup patch and > introduced a bug in your alternative implementation. Please look at > it, we need to alloc n+1 bytes, not n, or jay and genmdesc etc. will > produce garbage. Also, in glib the g* types should be used. > > Andreas > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070501/a57db7fd/attachment.html From andreas.faerber at web.de Tue May 1 10:12:49 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Tue, 1 May 2007 16:12:49 +0200 Subject: [Mono-dev] Mono on Windows/x64 In-Reply-To: <17c2d80b0705010650l70029c9r5126b9086e110f3c@mail.gmail.com> References: <001901c784f6$4209fac0$0100a8c0@kornelpal.hu> <17c2d80b0704231044i14596a1atafe8b1846c43a224@mail.gmail.com> <4F1A5396F3238F43BB5A5358C48CCAB80404E5@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404E8@Server1.jerris.local> <1177359731.21140.211.camel@mirrors.mathematik.uni-bielefeld.de> <4F1A5396F3238F43BB5A5358C48CCAB80404EB@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404EC@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404EF@Server1.jerris.local> <17c2d80b0704260900g3b11ca2eo133514248c698e67@mail.gmail.com> <17c2d80b0705010650l70029c9r5126b9086e110f3c@mail.gmail.com> Message-ID: <30E1D1D9-5871-4459-BB92-98DF6091BA1D@web.de> Jonathan, > Sorry, I didn't intentionally ignore your patch. The one from > Michael was so large I didn't try to merge the two. I'll merge in > your changes you submitted and repost unless someone else gets to > it first. This is not personal, it's just about the results: it appears the review process isn't working so well here ... a correct implementation gets rejected due to the lack of autoconf magic and an incorrect implementation (potentially dropping the last char) that uses autoconf gets in... Anyway, this way you made me aware of a bug in my original patch not specially treating a NULL argument. See attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: conf-eglib64.sh Type: application/octet-stream Size: 450 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070501/f5f841fa/attachment.obj -------------- next part -------------- Please review and let me know whether this is fully correct now and whether or not errno should be set (Linux' strndup does according to documentation, but does eglib need it?) so that I can commit the fix and avoid further conflicts. For the rest of my patches at http://bugzilla.ximian.com/show_bug.cgi? id=81456 I am still struggling with configure not detecting the presence of the iconv library. Andreas From wasabi at larvalstage.net Tue May 1 22:12:00 2007 From: wasabi at larvalstage.net (Jerry Haltom) Date: Tue, 01 May 2007 21:12:00 -0500 Subject: [Mono-dev] compiler bug Message-ID: <1178071920.6712.4.camel@localhost.localdomain> I have been assured the following code compiles correctly on MS.Net. However, I don't have a box at the time to verify it. It doesn't compile on Mono 1.2.3... and it appears it should. I will post a more formal bug report shortly. using System; namespace MonoBug { class MainClass { public static void Main(string[] args) { Console.WriteLine("Hello World!"); GenericType g = new GenericType(true); if (g) Console.WriteLine("true"); if (g == true) Console.WriteLine("true"); } } public class GenericType { private T value; public GenericType(T value) { this.value = value; } public static implicit operator T(GenericType o) { return o.value; } } } From tomba at bat.org Wed May 2 07:37:20 2007 From: tomba at bat.org (Tomi Valkeinen) Date: Wed, 2 May 2007 14:37:20 +0300 (EEST) Subject: [Mono-dev] Monoco update Message-ID: Hi, I updated Monoco (http://www.bat.org/~tomba/monoco.html) to work with svn head of Mono. Behaviour of GC had changed a bit and it broke the continuations (GC didn't follow an IntPtr in a managed object). I also updated the naive benchmarks on the web page. While fixing the bug I started to think about how the continuations would work with the new precice GC. I've understood that in the first phase the new GC will scan stack conservatively. Is precise stack scanning something that may happen in the distant future, or something that will definitely come? The same information that the GC uses to do a precise stack scan could possibly be used to serialize continuations. Also currently the whole area reserved for continuation's stack is scanned, even if it is known that only part of the area contains real data. This is also something that I hope I will get fixed with the new GC. Tomi From dick at ximian.com Wed May 2 08:17:12 2007 From: dick at ximian.com (Dick Porter) Date: Wed, 02 May 2007 13:17:12 +0100 Subject: [Mono-dev] File accesses in ported applications Message-ID: <1178108232.28417.30.camel@hagbard.apathetic.discordia.org.uk> Wed May 02 11:32:40 <@grendel> Dick: do you think it would be possible to write a file analyzer? Wed May 02 11:32:43 <@grendel> file access analyzer Wed May 02 11:33:18 <@Dick> how about an aspx-lint that checks for this sort of thing? Wed May 02 11:33:37 <@grendel> Dick: the lint would have to be either a monitor app or inside Mono Wed May 02 11:33:42 <@grendel> it's not aspx-specific, IMHO Wed May 02 11:33:48 <@Dick> i was thinking separate app Wed May 02 11:33:52 <@grendel> it can affect WF apps too Wed May 02 11:33:59 <@Dick> anyway, what would your file access analyzer do? Wed May 02 11:34:26 <@grendel> it would check for cases when an app is inconsistently accessing a file with the same case-insensitive name Wed May 02 11:34:35 <@grendel> e.g. someFile.txt, somefIle.txt etc Wed May 02 11:34:41 <@Dick> hmm Wed May 02 11:34:46 <@Dick> that could be handy Wed May 02 11:34:46 <@grendel> and would warn about the method, file, line where it happened Wed May 02 11:34:52 <@grendel> and output a report Wed May 02 11:34:59 <@grendel> it would be a great aid in porting Wed May 02 11:35:08 <@Dick> yeah Wed May 02 11:35:21 <@grendel> it could also look at the disk and check if there are files of the same flatten names in the same dir Wed May 02 11:35:22 <@Dick> i wonder if it would fit inside gendarme? Wed May 02 11:35:26 <@grendel> and make that a critical working Wed May 02 11:35:27 <@Dick> or moma Wed May 02 11:35:42 <@grendel> hm, moma would be a better choice I think Wed May 02 11:36:02 <@grendel> Dick: although I'm inclined to think it would just as well be a good thing to put in the runtime Wed May 02 11:36:08 <@grendel> and enable it along with IOMAP Wed May 02 11:36:22 <@Dick> yeah, thats definitely possible Wed May 02 11:36:30 <@grendel> it would take care of all the cases Wed May 02 11:36:50 <@grendel> you could output the diags to console on *nix and to the event sink on windows Wed May 02 11:36:54 <@Dick> the problem would be noticing the output if its was stuck there Wed May 02 11:37:22 <@grendel> yeah, but you can't do much about it Wed May 02 11:37:29 <@grendel> people must know the feature exists and where to find it Wed May 02 11:37:35 <@grendel> we put it in the docs and that's it Wed May 02 11:37:56 <@Dick> personally i'd put it in moma first and the runtime second Wed May 02 11:37:57 <@grendel> you could even enable it conditionally Wed May 02 11:38:08 <@grendel> Dick: that might be a good idea for testing, yeah Wed May 02 11:38:19 <@Dick> it would have to be conditional, saving all the filenames would be time and memory consuming Wed May 02 11:38:30 <@grendel> true Wed May 02 11:38:55 * Dick wonders if miguel or jpobst|gone is going to notice this Wed May 02 11:39:13 <@grendel> Dick: cut-n-paste and mail to them? :) Wed May 02 11:39:26 <@Dick> hopefully they might notice their names light up :) Wed May 02 11:39:41 <@Dick> sending it to xml or mono-devel would be good though Wed May 02 11:39:50 <@grendel> miguel: read what's above this line :) Wed May 02 11:39:56 <@grendel> jpobst|gone: read what's above this line :) Wed May 02 11:40:21 <@grendel> Dick: that's true -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070502/441247af/attachment.bin From jb at nurv.fr Wed May 2 08:50:29 2007 From: jb at nurv.fr (Jb Evain) Date: Wed, 2 May 2007 09:50:29 -0300 Subject: [Mono-dev] File accesses in ported applications In-Reply-To: <1178108232.28417.30.camel@hagbard.apathetic.discordia.org.uk> References: <1178108232.28417.30.camel@hagbard.apathetic.discordia.org.uk> Message-ID: <69f7d8470705020550w3f2cb8e5meedd18fb2e4b1e@mail.gmail.com> I think that both MoMa and Gendarme could benefit from the idea. What if MoMa ships with the Gendarme framework and a subset of useful rules? Jb On 5/2/07, Dick Porter wrote: > Wed May 02 11:32:40 <@grendel> Dick: do you think it would be possible to write a file analyzer? > Wed May 02 11:32:43 <@grendel> file access analyzer > Wed May 02 11:33:18 <@Dick> how about an aspx-lint that checks for this sort of thing? > Wed May 02 11:33:37 <@grendel> Dick: the lint would have to be either a monitor app or inside Mono > Wed May 02 11:33:42 <@grendel> it's not aspx-specific, IMHO > Wed May 02 11:33:48 <@Dick> i was thinking separate app > Wed May 02 11:33:52 <@grendel> it can affect WF apps too > Wed May 02 11:33:59 <@Dick> anyway, what would your file access analyzer do? > Wed May 02 11:34:26 <@grendel> it would check for cases when an app is inconsistently accessing a file with the same case-insensitive name > Wed May 02 11:34:35 <@grendel> e.g. someFile.txt, somefIle.txt etc > Wed May 02 11:34:41 <@Dick> hmm > Wed May 02 11:34:46 <@Dick> that could be handy > Wed May 02 11:34:46 <@grendel> and would warn about the method, file, line where it happened > Wed May 02 11:34:52 <@grendel> and output a report > Wed May 02 11:34:59 <@grendel> it would be a great aid in porting > Wed May 02 11:35:08 <@Dick> yeah > Wed May 02 11:35:21 <@grendel> it could also look at the disk and check if there are files of the same flatten names in the same dir > Wed May 02 11:35:22 <@Dick> i wonder if it would fit inside gendarme? > Wed May 02 11:35:26 <@grendel> and make that a critical working > Wed May 02 11:35:27 <@Dick> or moma > Wed May 02 11:35:42 <@grendel> hm, moma would be a better choice I think > Wed May 02 11:36:02 <@grendel> Dick: although I'm inclined to think it would just as well be a good thing to put in the runtime > Wed May 02 11:36:08 <@grendel> and enable it along with IOMAP > Wed May 02 11:36:22 <@Dick> yeah, thats definitely possible > Wed May 02 11:36:30 <@grendel> it would take care of all the cases > Wed May 02 11:36:50 <@grendel> you could output the diags to console on *nix and to the event sink on windows > Wed May 02 11:36:54 <@Dick> the problem would be noticing the output if its was stuck there > Wed May 02 11:37:22 <@grendel> yeah, but you can't do much about it > Wed May 02 11:37:29 <@grendel> people must know the feature exists and where to find it > Wed May 02 11:37:35 <@grendel> we put it in the docs and that's it > Wed May 02 11:37:56 <@Dick> personally i'd put it in moma first and the runtime second > Wed May 02 11:37:57 <@grendel> you could even enable it conditionally > Wed May 02 11:38:08 <@grendel> Dick: that might be a good idea for testing, yeah > Wed May 02 11:38:19 <@Dick> it would have to be conditional, saving all the filenames would be time and memory consuming > Wed May 02 11:38:30 <@grendel> true > Wed May 02 11:38:55 * Dick wonders if miguel or jpobst|gone is going to notice this > Wed May 02 11:39:13 <@grendel> Dick: cut-n-paste and mail to them? :) > Wed May 02 11:39:26 <@Dick> hopefully they might notice their names light up :) > Wed May 02 11:39:41 <@Dick> sending it to xml or mono-devel would be good though > Wed May 02 11:39:50 <@grendel> miguel: read what's above this line :) > Wed May 02 11:39:56 <@grendel> jpobst|gone: read what's above this line :) > Wed May 02 11:40:21 <@grendel> Dick: that's true > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > -- Jb From sebastien.pouliot at gmail.com Wed May 2 09:05:37 2007 From: sebastien.pouliot at gmail.com (Sebastien Pouliot) Date: Wed, 02 May 2007 09:05:37 -0400 Subject: [Mono-dev] File accesses in ported applications In-Reply-To: <1178108232.28417.30.camel@hagbard.apathetic.discordia.org.uk> References: <1178108232.28417.30.camel@hagbard.apathetic.discordia.org.uk> Message-ID: <1178111138.3881.106.camel@poupou.home> While it wouldn't be too hard to make a Gendarme rule, it would not give results as good as a runtime-based solution. The main reason being that all string/Path API being used to construct a file + user input would make any rule miss *a lot* of cases and also reports some (but probably not much) false positives. Of course the best is to have both (rule & runtime support ;-) On Wed, 2007-05-02 at 13:17 +0100, Dick Porter wrote: > Wed May 02 11:32:40 <@grendel> Dick: do you think it would be possible to write a file analyzer? > Wed May 02 11:32:43 <@grendel> file access analyzer > Wed May 02 11:33:18 <@Dick> how about an aspx-lint that checks for this sort of thing? > Wed May 02 11:33:37 <@grendel> Dick: the lint would have to be either a monitor app or inside Mono > Wed May 02 11:33:42 <@grendel> it's not aspx-specific, IMHO > Wed May 02 11:33:48 <@Dick> i was thinking separate app > Wed May 02 11:33:52 <@grendel> it can affect WF apps too > Wed May 02 11:33:59 <@Dick> anyway, what would your file access analyzer do? > Wed May 02 11:34:26 <@grendel> it would check for cases when an app is inconsistently accessing a file with the same case-insensitive name > Wed May 02 11:34:35 <@grendel> e.g. someFile.txt, somefIle.txt etc > Wed May 02 11:34:41 <@Dick> hmm > Wed May 02 11:34:46 <@Dick> that could be handy > Wed May 02 11:34:46 <@grendel> and would warn about the method, file, line where it happened > Wed May 02 11:34:52 <@grendel> and output a report > Wed May 02 11:34:59 <@grendel> it would be a great aid in porting > Wed May 02 11:35:08 <@Dick> yeah > Wed May 02 11:35:21 <@grendel> it could also look at the disk and check if there are files of the same flatten names in the same dir > Wed May 02 11:35:22 <@Dick> i wonder if it would fit inside gendarme? > Wed May 02 11:35:26 <@grendel> and make that a critical working > Wed May 02 11:35:27 <@Dick> or moma > Wed May 02 11:35:42 <@grendel> hm, moma would be a better choice I think > Wed May 02 11:36:02 <@grendel> Dick: although I'm inclined to think it would just as well be a good thing to put in the runtime > Wed May 02 11:36:08 <@grendel> and enable it along with IOMAP > Wed May 02 11:36:22 <@Dick> yeah, thats definitely possible > Wed May 02 11:36:30 <@grendel> it would take care of all the cases > Wed May 02 11:36:50 <@grendel> you could output the diags to console on *nix and to the event sink on windows > Wed May 02 11:36:54 <@Dick> the problem would be noticing the output if its was stuck there > Wed May 02 11:37:22 <@grendel> yeah, but you can't do much about it > Wed May 02 11:37:29 <@grendel> people must know the feature exists and where to find it > Wed May 02 11:37:35 <@grendel> we put it in the docs and that's it > Wed May 02 11:37:56 <@Dick> personally i'd put it in moma first and the runtime second > Wed May 02 11:37:57 <@grendel> you could even enable it conditionally > Wed May 02 11:38:08 <@grendel> Dick: that might be a good idea for testing, yeah > Wed May 02 11:38:19 <@Dick> it would have to be conditional, saving all the filenames would be time and memory consuming > Wed May 02 11:38:30 <@grendel> true > Wed May 02 11:38:55 * Dick wonders if miguel or jpobst|gone is going to notice this > Wed May 02 11:39:13 <@grendel> Dick: cut-n-paste and mail to them? :) > Wed May 02 11:39:26 <@Dick> hopefully they might notice their names light up :) > Wed May 02 11:39:41 <@Dick> sending it to xml or mono-devel would be good though > Wed May 02 11:39:50 <@grendel> miguel: read what's above this line :) > Wed May 02 11:39:56 <@grendel> jpobst|gone: read what's above this line :) > Wed May 02 11:40:21 <@grendel> Dick: that's true > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Sebastien Pouliot Blog: http://pages.infinit.net/ctech/ From kostat at mainsoft.com Wed May 2 10:50:42 2007 From: kostat at mainsoft.com (Konstantin Triger) Date: Wed, 2 May 2007 07:50:42 -0700 Subject: [Mono-dev] [PATCH] System:HybridDictionary should make ordinal string comparison Message-ID: Hello all, Please review the attached patch. Regards, Konstantin Triger -------------- next part -------------- A non-text attachment was scrubbed... Name: hdordinal.patch Type: application/octet-stream Size: 1488 bytes Desc: hdordinal.patch Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070502/f76aca38/attachment.obj From joncham at gmail.com Wed May 2 13:52:53 2007 From: joncham at gmail.com (Jonathan Chambers) Date: Wed, 2 May 2007 13:52:53 -0400 Subject: [Mono-dev] System.Runtime.Remoting.RemotingConfiguration Configure Patch Message-ID: <17c2d80b0705021052n5cc9008cx9f604096b4351cee@mail.gmail.com> Hello, Attached is patch to add 2.0 overload of Configure method in System.Runtime.Remoting.RemotingConfiguration. This was done the same way as System.Runtime.Remoting.Channels.ChannelServices.RegisterChannel. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070502/ef63cc7a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: remotingconfiguration.diff Type: text/x-patch Size: 1494 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070502/ef63cc7a/attachment.bin From andreas.faerber at web.de Wed May 2 14:00:22 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Wed, 2 May 2007 20:00:22 +0200 Subject: [Mono-dev] Mono on Windows/x64 In-Reply-To: <30E1D1D9-5871-4459-BB92-98DF6091BA1D@web.de> References: <001901c784f6$4209fac0$0100a8c0@kornelpal.hu> <17c2d80b0704231044i14596a1atafe8b1846c43a224@mail.gmail.com> <4F1A5396F3238F43BB5A5358C48CCAB80404E5@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404E8@Server1.jerris.local> <1177359731.21140.211.camel@mirrors.mathematik.uni-bielefeld.de> <4F1A5396F3238F43BB5A5358C48CCAB80404EB@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404EC@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404EF@Server1.jerris.local> <17c2d80b0704260900g3b11ca2eo133514248c698e67@mail.gmail.com> <17c2d80b0705010650l70029c9r5126b9086e110f3c@mail.gmail.com> <30E1D1D9-5871-4459-BB92-98DF6091BA1D@web.de> Message-ID: Another eglib issue in SVN head: It appears g_error has been modified to take two arguments, which unfortunately breaks mono-logger.c. Building with glib works fine. Any thoughts on how to fix this? Andreas From lluis at ximian.com Wed May 2 15:07:00 2007 From: lluis at ximian.com (Lluis Sanchez) Date: Wed, 02 May 2007 21:07:00 +0200 Subject: [Mono-dev] System.Runtime.Remoting.RemotingConfiguration Configure Patch In-Reply-To: <17c2d80b0705021052n5cc9008cx9f604096b4351cee@mail.gmail.com> References: <17c2d80b0705021052n5cc9008cx9f604096b4351cee@mail.gmail.com> Message-ID: <1178132821.4755.28.camel@portador.site> Please commit. Thanks! Lluis. El dc 02 de 05 del 2007 a les 13:52 -0400, en/na Jonathan Chambers va escriure: > Hello, > Attached is patch to add 2.0 overload of Configure method in > System.Runtime.Remoting.RemotingConfiguration. This was done the same > way as > System.Runtime.Remoting.Channels.ChannelServices.RegisterChannel. > > Thanks, > Jonathan > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From joncham at gmail.com Wed May 2 15:57:42 2007 From: joncham at gmail.com (Jonathan Chambers) Date: Wed, 2 May 2007 15:57:42 -0400 Subject: [Mono-dev] System.Threading.Thread.ApartmentState Patch Message-ID: <17c2d80b0705021257k74df423csa698218cc3e41da4@mail.gmail.com> Hello, Here is a patch to implement Thread.ApartmentState related methods/properties. The methods/properties behave correctly on all platforms, but only call CoInitialize on Windows. I will also commit the change detailed in bug 80798 before/with this patch else the error described in the bug becomes much more frequent on windows (the change may fix bug 77075). Please review. All changes contributed under MIT/X11 license. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070502/4462fb89/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: apartmentstate.diff Type: text/x-patch Size: 8719 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070502/4462fb89/attachment.bin From andreas.faerber at web.de Wed May 2 15:59:28 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Wed, 2 May 2007 21:59:28 +0200 Subject: [Mono-dev] Mono on Windows/x64 In-Reply-To: References: <001901c784f6$4209fac0$0100a8c0@kornelpal.hu> <17c2d80b0704231044i14596a1atafe8b1846c43a224@mail.gmail.com> <4F1A5396F3238F43BB5A5358C48CCAB80404E5@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404E8@Server1.jerris.local> <1177359731.21140.211.camel@mirrors.mathematik.uni-bielefeld.de> <4F1A5396F3238F43BB5A5358C48CCAB80404EB@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404EC@Server1.jerris.local> <4F1A5396F3238F43BB5A5358C48CCAB80404EF@Server1.jerris.local> <17c2d80b0704260900g3b11ca2eo133514248c698e67@mail.gmail.com> <17c2d80b0705010650l70029c9r5126b9086e110f3c@mail.gmail.com> <30E1D1D9-5871-4459-BB92-98DF6091BA1D@web.de> Message-ID: <99940458-1743-4179-A0BB-38820CD9555C@web.de> > Another eglib issue in SVN head: It appears g_error has been modified > [...] which unfortunately breaks mono-logger.c. > Building with glib works fine. Any thoughts on how to fix this? http://bugzilla.ximian.com/show_bug.cgi?id=81520 From gert.driesen at telenet.be Wed May 2 16:14:30 2007 From: gert.driesen at telenet.be (Gert Driesen) Date: Wed, 2 May 2007 22:14:30 +0200 Subject: [Mono-dev] System.Threading.Thread.ApartmentState Patch In-Reply-To: <17c2d80b0705021257k74df423csa698218cc3e41da4@mail.gmail.com> Message-ID: <20070502201432.63CBA2200B0@assei1bl6.telenet-ops.be> Jonathan, Does this mean we can enable the fix for bug #78455, and remove the extra check in WaitHandle.IsSTAThread ? Gert ________________________________ From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Jonathan Chambers Sent: woensdag 2 mei 2007 21:58 To: mono-devel Subject: [Mono-dev] System.Threading.Thread.ApartmentState Patch Hello, Here is a patch to implement Thread.ApartmentState related methods/properties. The methods/properties behave correctly on all platforms, but only call CoInitialize on Windows. I will also commit the change detailed in bug 80798 before/with this patch else the error described in the bug becomes much more frequent on windows (the change may fix bug 77075). Please review. All changes contributed under MIT/X11 license. Thanks, Jonathan From joncham at gmail.com Wed May 2 16:21:47 2007 From: joncham at gmail.com (Jonathan Chambers) Date: Wed, 2 May 2007 16:21:47 -0400 Subject: [Mono-dev] System.Threading.Thread.ApartmentState Patch In-Reply-To: <20070502201432.63CBA2200B0@assei1bl6.telenet-ops.be> References: <17c2d80b0705021257k74df423csa698218cc3e41da4@mail.gmail.com> <20070502201432.63CBA2200B0@assei1bl6.telenet-ops.be> Message-ID: <17c2d80b0705021321u6f7e47b3x11c5002583215f99@mail.gmail.com> Gert, Yes, with this patch you should be able to just check Thread.CurrentThread.ApartmentState. Jonathan On 5/2/07, Gert Driesen wrote: > > Jonathan, > > Does this mean we can enable the fix for bug #78455, and remove the extra > check in WaitHandle.IsSTAThread ? > > Gert > > ________________________________ > > From: mono-devel-list-bounces at lists.ximian.com > [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Jonathan > Chambers > Sent: woensdag 2 mei 2007 21:58 > To: mono-devel > Subject: [Mono-dev] System.Threading.Thread.ApartmentState Patch > > > Hello, > Here is a patch to implement Thread.ApartmentState related > methods/properties. The methods/properties behave correctly on all > platforms, but only call CoInitialize on Windows. I will also commit the > change detailed in bug 80798 before/with this patch else the error > described > in the bug becomes much more frequent on windows (the change may fix bug > 77075). Please review. > > All changes contributed under MIT/X11 license. > > Thanks, > Jonathan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070502/c815f993/attachment.html From vargaz at gmail.com Wed May 2 17:41:15 2007 From: vargaz at gmail.com (Zoltan Varga) Date: Wed, 2 May 2007 23:41:15 +0200 Subject: [Mono-dev] System.Threading.Thread.ApartmentState Patch In-Reply-To: <17c2d80b0705021257k74df423csa698218cc3e41da4@mail.gmail.com> References: <17c2d80b0705021257k74df423csa698218cc3e41da4@mail.gmail.com> Message-ID: <295e750a0705021441i414138e1xb23e05656e41bcb5@mail.gmail.com> Hi, There is a mono_custom_attrs_has_attr () function for detecting whenever there is a custom attr of the given type without actually constructing anything. Zoltan On 5/2/07, Jonathan Chambers wrote: > Hello, > Here is a patch to implement Thread.ApartmentState related > methods/properties. The methods/properties behave correctly on all > platforms, but only call CoInitialize on Windows. I will also commit the > change detailed in bug 80798 before/with this patch else the error described > in the bug becomes much more frequent on windows (the change may fix bug > 77075). Please review. > > All changes contributed under MIT/X11 license. > > Thanks, > Jonathan > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > From gpakosz at yahoo.fr Wed May 2 17:42:41 2007 From: gpakosz at yahoo.fr (=?ISO-8859-1?Q?Gr=E9gory_Pakosz?=) Date: Wed, 02 May 2007 23:42:41 +0200 Subject: [Mono-dev] Reflection: invoking an unsafe constructor/method that declares pointer parameter types Message-ID: <463905D1.3090406@yahoo.fr> hello, on the windows platform, building a .NET facade to a complex SDK coded in C, i once had good reasons to use reflection in order to invoke an unsafe constructor that takes a void* parameter: public unsafe class SomeClass { public SomeClass(void* handle) { this.handle = handle; } private void* handle; } public static void Main(string[] args) { ConstructorInfo constructor = SomeClass.GetConstructor(BindingFlags.Instance|BindingFlags.ExactBinding,null,new Type[]{typeof(void*)},null); SomeClass instance = constructor.Invoke(new Object[]{(IntPtr)0}); } to achieve that, as you can see, i used to use the IntPtr class when creating the Object[] parameter array that has to be passed to the ConstructorInfo::Invoke method. now, i'm trying to achieve the same behavior in Mono: and i get an ArgumentException because the constructor parameter's do not match; indeed it seems that IntPtr differs too much from void*. i know that declaring the constructor as SomeClass(IntPtr handle) would be an acceptable workaround/solution. however, i was wondering whether or not Mono should be able to handle such a code, since Microsoft's .NET accepts it. more generally, i tried to use google but did not find much information related to using reflection to invoke unsafe methods that declare pointers as parameters. how is it supposed to be achieved ? is this legal ? etc ... regards, thanks in advance for any help. gregory. From mbd at dbc.dk Thu May 3 01:57:32 2007 From: mbd at dbc.dk (Mads Bondo Dydensborg) Date: Thu, 3 May 2007 07:57:32 +0200 Subject: [Mono-dev] Sybase ASA Odbc, timestamp, fractional seconds, possible bug in mono Odbc stack? In-Reply-To: <200704301323.30224.mbd@dbc.dk> References: <200704240836.43551.mbd@dbc.dk> <200704301323.30224.mbd@dbc.dk> Message-ID: <200705030757.32931.mbd@dbc.dk> mandag 30 april 2007 13:23 skrev Mads Bondo Dydensborg: > tirsdag 24 april 2007 08:36 skrev Mads Bondo Dydensborg: > > Hi there > > Hi again. > > Just a repost - does nobody know anything about these issues? And another one :-) Is there a person doing the ODBC work, that I should talk directly to? Regards, Mads > > Regards, > > Mads > > > > > I am using Linux/Mono to access a Sybase ASA server (on Windows), using > > Unixodbc (and possibly FreeTDS - I am actually not quite sure). > > > > Most things appear to work fine, however, when retrieving > DateTimes/Timestamps > > from the sybase server, it seems that it returns the fractional value of a > > second, as _billonths_ of a second. Mono appears to expect this in > > milliseconds: > > > > ENTER: System.DateTime:.ctor (int,int,int,int,int,int,int) (value:0xbf8b53b0, > > 2007, 4 > > , 17, 14, 10, 50, 340000000, ) > > . ENTER: System.DateTime:DaysInMonth (int,int)(2007, 4, ) > > . . ENTER: System.DateTime:IsLeapYear (int)(2007, ) > > . . LEAVE: System.DateTime:IsLeapYear (int)FALSE > > . LEAVE: System.DateTime:DaysInMonth (int,int)result=30 > > EXCEPTION handling: ArgumentOutOfRangeException > > > > The value 340000000 should be in milliseconds (says DateTime constructor), > but > > apperantly is in billionths of a second (nanoseconds, says ODBC). > > > > Looking at OdbcDataReader.GetValue, I find the following code: > > > > case OdbcType.Timestamp: > > case OdbcType.DateTime: > > case OdbcType.Date: > > case OdbcType.Time: > > OdbcTimestamp ts_data = new OdbcTimestamp(); > > ret = libodbc.SQLGetData (hstmt, ColIndex, col.SqlCType, ref ts_data, 0, > > ref outsize); > > if (outsize!=-1) // This means SQL_NULL_DATA > > DataValue = new > > DateTime(ts_data.year,ts_data.month,ts_data.day,ts_data.hour, > > ts_data.minute,ts_data.second,Convert.ToInt32(ts_data.fraction)); > > break; > > > > OdbcTimestamp.fraction is declared as a long. SQLGetData is an extern > method - > > looks like it is just supposed to fill in the binary values? I find it a bit > > puzzling, perhaps even suspiciuos, that ts_data.fraction is converted to an > > int 32 from a long in the call to DateTime - disregarding (perhaps?) the > > scale of the fraction? > > > > I am a bit confused about this. Before looking into it further, I would > > appreciate a comment on wheter this could potentially be a bug in the Mono > > ODBC stack? Also, where values are "set", that is, if wanting to update a > > timestamp from mono - where the conversion takes place (there are quite many > > Odbc related files :-). > > > > The same code runs without problems under Windows/MS. Of course, that is not > > to say it is correct, only that the data returned is as expected. > > > > Regards, > > > > Mads > > > > -- > > Med venlig hilsen/Regards > > > > Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo > Dydensborg > > Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 > 34 > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > -- > Med venlig hilsen/Regards > > Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg > Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 From lbaudio at uchoanet.com.br Thu May 3 05:26:29 2007 From: lbaudio at uchoanet.com.br (LB Audio Uchoa NET) Date: Thu, 3 May 2007 06:26:29 -0300 Subject: [Mono-dev] UTF-8 in Read Text Files Message-ID: <000c01c78d65$21973740$0201010a@home> Public Class Form1 Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click 'Bot?es.txt = 'Ma??, Mel?o, Fusc?o, Man?, 'Works Windows and Linux more 'Return ERROR Ma, Melo, Fusco, Man, Dim textFile As String = "Bot?es.txt" Dim enc As System.Text.Encoding = System.Text.Encoding.GetEncoding("UTF-8") Dim str As String = System.IO.File.ReadAllText(textFile, enc) 'Works in Windows no Works in Linux 'Return OK Ma??, Mel?o, Fusc?o, Man?, Dim AllText As String Dim LineOfText As String FileOpen(1, "Bot?es.txt", OpenMode.Input) Do Until EOF(1) LineOfText = LineInput(1) AllText = AllText & LineOfText & ControlChars.CrLf Loop FileClose(1) Text1.Text = AllText End Sub End Class Thanks For Help. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070503/10cb1ebb/attachment.html From =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= Thu May 3 05:30:23 2007 From: =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?=) Date: Thu, 03 May 2007 11:30:23 +0200 Subject: [Mono-dev] System.Runtime.Remoting.RemotingConfiguration Configure Patch In-Reply-To: <17c2d80b0705021052n5cc9008cx9f604096b4351cee@mail.gmail.com> References: <17c2d80b0705021052n5cc9008cx9f604096b4351cee@mail.gmail.com> Message-ID: <4639ABAF.1000609@gmail.com> Jonathan Chambers escribi?: > Attached is patch to add 2.0 overload of Configure method in > System.Runtime.Remoting.RemotingConfiguration. This was done the same > way as System.Runtime.Remoting.Channels.ChannelServices.RegisterChannel. Shouldn't that MonoTODO be converted into a FIXME? That one is not giving much information for a potential MoMA user. Regards, Andr?s [ knocte ] -- From joncham at gmail.com Thu May 3 07:36:00 2007 From: joncham at gmail.com (Jonathan Chambers) Date: Thu, 3 May 2007 07:36:00 -0400 Subject: [Mono-dev] System.Runtime.Remoting.RemotingConfiguration Configure Patch In-Reply-To: <4639ABAF.1000609@gmail.com> References: <17c2d80b0705021052n5cc9008cx9f604096b4351cee@mail.gmail.com> <4639ABAF.1000609@gmail.com> Message-ID: <17c2d80b0705030436q6f28419du3e22105ad98481d5@mail.gmail.com> Perhaps I should use a more specific MonoTODOAttribute; MonoNotSupportedAttribute perhaps? - Jonathan On 5/3/07, "Andr?s G. Aragoneses [ knocte ]" wrote: > > Jonathan Chambers escribi?: > > Attached is patch to add 2.0 overload of Configure method in > > System.Runtime.Remoting.RemotingConfiguration. This was done the same > > way as System.Runtime.Remoting.Channels.ChannelServices.RegisterChannel. > > Shouldn't that MonoTODO be converted into a FIXME? That one is not > giving much information for a potential MoMA user. > > Regards, > > Andr?s [ knocte ] > > -- > > _______________________________________________ > 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/20070503/8c62a84a/attachment.html From dick at ximian.com Thu May 3 08:47:54 2007 From: dick at ximian.com (Dick Porter) Date: Thu, 03 May 2007 13:47:54 +0100 Subject: [Mono-dev] System.Threading.Thread.ApartmentState Patch In-Reply-To: <17c2d80b0705021257k74df423csa698218cc3e41da4@mail.gmail.com> References: <17c2d80b0705021257k74df423csa698218cc3e41da4@mail.gmail.com> Message-ID: <1178196474.28417.54.camel@hagbard.apathetic.discordia.org.uk> On Wed, 2007-05-02 at 15:57 -0400, Jonathan Chambers wrote: > Hello, > Here is a patch to implement Thread.ApartmentState related > methods/properties. The methods/properties behave correctly on all > platforms, but only call CoInitialize on Windows. I will also commit > the change detailed in bug 80798 before/with this patch else the error > described in the bug becomes much more frequent on windows (the change > may fix bug 77075). Please review. Both patches look fine to me. - Dick -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070503/d8590db0/attachment.bin From lluis at ximian.com Thu May 3 10:53:18 2007 From: lluis at ximian.com (Lluis Sanchez) Date: Thu, 03 May 2007 16:53:18 +0200 Subject: [Mono-dev] COM Interop Remoting Patch In-Reply-To: <17c2d80b0704021112u55858afepb642538814811f65@mail.gmail.com> References: <17c2d80b0704021112u55858afepb642538814811f65@mail.gmail.com> Message-ID: <1178203998.4044.66.camel@portador.site> > Hello, > Attached is a patch to fix remoting involving COM Interop types. > I had previsouly broken this unintentionally. COM Interop uses > transparent proxies, and there was lots of places that didn't > distinguish between a remoting transparent proxy and a COM Interop > transparent proxy. To distinguish I check to see if the real proxy > associated with the transparent proxy is a COM Interop proxy. > > The main cases I needed to handle was the casting of transparent proxy > objects, method calls, and field access. For the casting of > transparent proxies, I added a new field to the MonoRemoteClass for > the COM Interop vtable. I was previously overwriting the > default_vtable. For method calls, and probably the most important > thing to notice, is that I added another check to > mono_marshal_get_remoting_invoke_with_check to see if a transparent > proxy is used for COM Interop. This does add some overhead to > remoting; the overhead should always be emitting a method that simply > loads all the arguments and calls the wrapped method on the underlying > managed object the proxy wraps. No real COM Interop code or > marshalling code should unless the type has a ComImport attribute. > Unless COM is used the method should never be called, only emitted. > > The field access was done via checks in mono_load_remote_field, > mono_load_remote_field_new, mono_store_remote_field, and > mono_store_remote_field_new. This avoids emitting any additional > checks or methods for remoting wrappers. > > Please make any suggestions if my changes could be done in a better > way; especially if my changes related to methods should be more like > the ones for fields, or vice versa. The patch looks in general ok to me. I only have a couple of comments: > Index: mono/mono/metadata/object.c > =================================================================== > --- mono/mono/metadata/object.c (revision 75279) > +++ mono/mono/metadata/object.c (working copy) > @@ -2589,6 +2598,15 @@ > return obj; > } else { > /* obj must be already unboxed if needed */ > + if (obj && mono_object_class(obj) == > mono_defaults.transparent_proxy_class) { > + /* Get wrapper method if object is a > transparent proxy for com interop. > + * There was no check here for a remoting > transparent proxy, so I assume that case does > + * not happen... > + */ This branch of the condition is executed when calling a method which is not a constructor. I think that it does happen for remote methods, so it would be good to really check it. Maybe you are adding this com check in the wrong place. > + MonoTransparentProxy* transparent_proxy = > (MonoTransparentProxy*)obj; > + if > (transparent_proxy->rp->object.vtable->klass == > mono_defaults.com_interop_proxy_class) > + method = > mono_marshal_get_cominterop_invoke (method->slot == -1 ? method : > method->klass->vtable [method->slot]); > + } > return mono_runtime_invoke (method, obj, pa, exc); > } > } > @@ -4103,8 +4121,12 @@ > } > > if (target && target->vtable->klass == > mono_defaults.transparent_proxy_class) { > + MonoTransparentProxy* transparent_proxy = > (MonoTransparentProxy*)target; > g_assert (method); > - method = mono_marshal_get_remoting_invoke (method); > + if (transparent_proxy->rp->object.vtable->klass == > mono_defaults.com_interop_proxy_class) > + method = mono_marshal_get_cominterop_invoke > (method); > + else > + method = mono_marshal_get_remoting_invoke > (method); Since this check is done in several places, maybe it would be good to introduce a new method which takes the proxy and the method as parameters, and returns the correct wrapper method depending on the proxy type. > delegate->method_ptr = mono_compile_method (method); > MONO_OBJECT_SETREF (delegate, target, target); > } else if (mono_method_signature (method)->hasthis && > method->klass->valuetype) { > @@ -4284,6 +4306,12 @@ > g_assert (this->vtable->klass == > mono_defaults.transparent_proxy_class); > g_assert (res != NULL); > > + if (tp->rp->object.vtable->klass == > mono_defaults.com_interop_proxy_class) { Would it make sense to define a macro for checking if a transparent proxy is a com object? it is being used in several places. Thanks, Lluis. From lupus at ximian.com Thu May 3 11:47:57 2007 From: lupus at ximian.com (Paolo Molaro) Date: Thu, 3 May 2007 17:47:57 +0200 Subject: [Mono-dev] Monoco update In-Reply-To: References: Message-ID: <20070503154757.GD14037@debian.org> On 05/02/07 Tomi Valkeinen wrote: > I updated Monoco (http://www.bat.org/~tomba/monoco.html) to work with svn > head of Mono. Behaviour of GC had changed a bit and it broke the > continuations (GC didn't follow an IntPtr in a managed object). I Yes, we are more strict now even with the conservative GC. > While fixing the bug I started to think about how the continuations would > work with the new precice GC. I've understood that in the first phase the > new GC will scan stack conservatively. Is precise stack scanning something > that may happen in the distant future, or something that will > definitely come? It will definitely come, though it won't be fully precise for a while. At the beginning stack locations will be identified as: 1) precise reference (reference local vars allocated on the stack) 2) definitely non-references (non-reference local vars, ABI-specific stack locations that can't contain managed references etc) 3) unknown (will be considered containing potentially pinning pointers, this will include registers, spilling locations etc) With time we'll reduce the amount of unknown locations further (especially by tracking register contents). > The same information that the GC uses to do a precise stack scan could > possibly be used to serialize continuations. Also currently the whole area Proper serialization needs a lot more data than that. Serialization as "save the stack data and keep the GC happy" would work. I made you use mono_gc_alloc_fixed() so that your code would work also on the moving GC unchanged. Tracking the precise info will allow better GC behaviour with the moving GC, but it will also be somewhat slower at saving coroutine state. > reserved for continuation's stack is scanned, even if it is known that > only part of the area contains real data. This is also something that I > hope I will get fixed with the new GC. Yeah, for a while I wanted to add a GC description that keeps track also of a pointer to a length, so at GC time the length of the memory area is read from the pointer and only that area is scanned. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Thu May 3 11:25:58 2007 From: lupus at ximian.com (Paolo Molaro) Date: Thu, 3 May 2007 17:25:58 +0200 Subject: [Mono-dev] Reflection: invoking an unsafe constructor/method that declares pointer parameter types In-Reply-To: <463905D1.3090406@yahoo.fr> References: <463905D1.3090406@yahoo.fr> Message-ID: <20070503152558.GB14037@debian.org> On 05/02/07 Gr?gory Pakosz wrote: > on the windows platform, building a .NET facade to a complex SDK coded > in C, i once had good reasons to use reflection in order to invoke an > unsafe constructor that takes a void* parameter: > > public unsafe class SomeClass > { > public SomeClass(void* handle) > { > this.handle = handle; > } > > private void* handle; > > } > > public static void Main(string[] args) > { > ConstructorInfo constructor = > SomeClass.GetConstructor(BindingFlags.Instance|BindingFlags.ExactBinding,null,new > Type[]{typeof(void*)},null); > > SomeClass instance = constructor.Invoke(new Object[]{(IntPtr)0}); > } > [...] > more generally, i tried to use google but did not find much information > related to using reflection to invoke unsafe methods that declare > pointers as parameters. how is it supposed to be achieved ? is this > legal ? etc ... Could you please file a bug in bugzilla with a complete test case? Thanks. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Thu May 3 11:24:50 2007 From: lupus at ximian.com (Paolo Molaro) Date: Thu, 3 May 2007 17:24:50 +0200 Subject: [Mono-dev] System.Threading.Thread.ApartmentState Patch In-Reply-To: <17c2d80b0705021257k74df423csa698218cc3e41da4@mail.gmail.com> References: <17c2d80b0705021257k74df423csa698218cc3e41da4@mail.gmail.com> Message-ID: <20070503152450.GA14037@debian.org> On 05/02/07 Jonathan Chambers wrote: > Index: mono/mono/metadata/threads.c > =================================================================== > --- mono/mono/metadata/threads.c (revision 76569) > +++ mono/mono/metadata/threads.c (working copy) [...] > +void mono_thread_set_apartment_state () > +{ should be: void mono_thread_set_apartment_state (void) It may also be better to name the function mono_thread_apply_apartment_state. > Index: mono/mono/metadata/object.c > =================================================================== > --- mono/mono/metadata/object.c (revision 76569) > +++ mono/mono/metadata/object.c (working copy) > @@ -2387,6 +2387,7 @@ [...] > + cinfo = mono_custom_attrs_from_method (method); > + if (cinfo) { > + static MonoClass *stathread_attribute = NULL; > + MonoThread* thread = mono_thread_current (); > + MonoObject* stathread_object; > + if (!stathread_attribute) > + stathread_attribute = mono_class_from_name (mono_defaults.corlib, "System", "STAThreadAttribute"); > + mono_custom_attrs_get_attr (cinfo, stathread_attribute); As zoltan said, use mono_custom_attrs_has_attr(). > Index: mono/mono/metadata/object-internals.h > =================================================================== > --- mono/mono/metadata/object-internals.h (revision 76569) > +++ mono/mono/metadata/object-internals.h (working copy) > @@ -274,7 +274,7 @@ > MonoBoolean thread_dump_requested; > gpointer end_stack; /* This is only used when running in the debugger. */ > MonoBoolean thread_interrupt_requested; > - gpointer unused4; > + guint32 apartment_state; Since you need just 2 bits, please use a guint8 type. Thanks! lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Thu May 3 11:27:51 2007 From: lupus at ximian.com (Paolo Molaro) Date: Thu, 3 May 2007 17:27:51 +0200 Subject: [Mono-dev] [PATCH] System:HybridDictionary should make ordinal string comparison In-Reply-To: References: Message-ID: <20070503152750.GC14037@debian.org> On 05/02/07 Konstantin Triger wrote: > Please review the attached patch. Please also provide a test case that can be added to the test suite to check for this issue. Thanks. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From joncham at gmail.com Thu May 3 14:06:02 2007 From: joncham at gmail.com (Jonathan Chambers) Date: Thu, 3 May 2007 14:06:02 -0400 Subject: [Mono-dev] System.Threading.Thread.ApartmentState Patch In-Reply-To: <20070503152450.GA14037@debian.org> References: <17c2d80b0705021257k74df423csa698218cc3e41da4@mail.gmail.com> <20070503152450.GA14037@debian.org> Message-ID: <17c2d80b0705031106k2dff5ec0u25c210553236329e@mail.gmail.com> Attached is new patch (hopefully) addressing all previous issues. I renamed methods to mono_thread_init_apartment_state and mono_thread_cleanup_apartment_state. Thanks, Jonathan On 5/3/07, Paolo Molaro wrote: > > On 05/02/07 Jonathan Chambers wrote: > > Index: mono/mono/metadata/threads.c > > =================================================================== > > --- mono/mono/metadata/threads.c (revision 76569) > > +++ mono/mono/metadata/threads.c (working copy) > [...] > > +void mono_thread_set_apartment_state () > > +{ > > should be: > > void > mono_thread_set_apartment_state (void) > > It may also be better to name the function > mono_thread_apply_apartment_state. > > > Index: mono/mono/metadata/object.c > > =================================================================== > > --- mono/mono/metadata/object.c (revision 76569) > > +++ mono/mono/metadata/object.c (working copy) > > @@ -2387,6 +2387,7 @@ > [...] > > + cinfo = mono_custom_attrs_from_method (method); > > + if (cinfo) { > > + static MonoClass *stathread_attribute = NULL; > > + MonoThread* thread = mono_thread_current (); > > + MonoObject* stathread_object; > > + if (!stathread_attribute) > > + stathread_attribute = mono_class_from_name > (mono_defaults.corlib, "System", "STAThreadAttribute"); > > + mono_custom_attrs_get_attr (cinfo, stathread_attribute); > > As zoltan said, use mono_custom_attrs_has_attr(). > > > Index: mono/mono/metadata/object-internals.h > > =================================================================== > > --- mono/mono/metadata/object-internals.h (revision 76569) > > +++ mono/mono/metadata/object-internals.h (working copy) > > @@ -274,7 +274,7 @@ > > MonoBoolean thread_dump_requested; > > gpointer end_stack; /* This is only used when running in the > debugger. */ > > MonoBoolean thread_interrupt_requested; > > - gpointer unused4; > > + guint32 apartment_state; > > Since you need just 2 bits, please use a guint8 type. > > Thanks! > > lupus > > -- > ----------------------------------------------------------------- > lupus at debian.org debian/rules > lupus at ximian.com Monkeys do it better > _______________________________________________ > 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/20070503/dea51290/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: apartmentstate.diff Type: text/x-patch Size: 12209 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070503/dea51290/attachment.bin From anagappan at novell.com Fri May 4 04:56:21 2007 From: anagappan at novell.com (A Nagappan) Date: Fri, 04 May 2007 02:56:21 -0600 Subject: [Mono-dev] Sybase ASA Odbc, timestamp, fractional seconds, possible bug in mono Odbc stack? In-Reply-To: <200705030757.32931.mbd@dbc.dk> References: <200704240836.43551.mbd@dbc.dk> <200704301323.30224.mbd@dbc.dk> <200705030757.32931.mbd@dbc.dk> Message-ID: <463B4341.11BB.0044.0@novell.com> Hi, Could you please send me a test.cs file to reproduce this bug ? Regarding Odbc, You can either contact me or send your queries to the list. Thanks Nagappan Nagappan A Linux Desktop Testing Project - http://ldtp.freedesktop.org http://nagappanal.blogspot.com Novell, Inc. SUSE* Linux Enterprise 10 Your Linux is ready* http://www.novell.com/linux >>> On Thu, May 3, 2007 at 11:27 AM, in message <200705030757.32931.mbd at dbc.dk>, Mads Bondo Dydensborg wrote: > mandag 30 april 2007 13:23 skrev Mads Bondo Dydensborg: >> tirsdag 24 april 2007 08:36 skrev Mads Bondo Dydensborg: >> > Hi there >> >> Hi again. >> >> Just a repost - does nobody know anything about these issues? > > And another one :- ) > > Is there a person doing the ODBC work, that I should talk directly to? > > Regards, > > Mads > >> >> Regards, >> >> Mads >> >> > >> > I am using Linux/Mono to access a Sybase ASA server (on Windows), using >> > Unixodbc (and possibly FreeTDS - I am actually not quite sure). >> > >> > Most things appear to work fine, however, when retrieving >> DateTimes/Timestamps >> > from the sybase server, it seems that it returns the fractional value of a >> > second, as _billonths_ of a second. Mono appears to expect this in >> > milliseconds: >> > >> > ENTER: System.DateTime:.ctor (int,int,int,int,int,int,int) > (value:0xbf8b53b0, >> > 2007, 4 >> > , 17, 14, 10, 50, 340000000, ) >> > . ENTER: System.DateTime:DaysInMonth (int,int)(2007, 4, ) >> > . . ENTER: System.DateTime:IsLeapYear (int)(2007, ) >> > . . LEAVE: System.DateTime:IsLeapYear (int)FALSE >> > . LEAVE: System.DateTime:DaysInMonth (int,int)result=30 >> > EXCEPTION handling: ArgumentOutOfRangeException >> > >> > The value 340000000 should be in milliseconds (says DateTime constructor), >> but >> > apperantly is in billionths of a second (nanoseconds, says ODBC). >> > >> > Looking at OdbcDataReader.GetValue, I find the following code: >> > >> > case OdbcType.Timestamp: >> > case OdbcType.DateTime: >> > case OdbcType.Date: >> > case OdbcType.Time: >> > OdbcTimestamp ts_data = new OdbcTimestamp(); >> > ret = libodbc.SQLGetData (hstmt, ColIndex, col.SqlCType, ref ts_data, > 0, >> > ref outsize); >> > if (outsize!=- 1) // This means SQL_NULL_DATA >> > DataValue = new >> > DateTime(ts_data.year,ts_data.month,ts_data.day,ts_data.hour, >> > ts_data.minute,ts_data.second,Convert.ToInt32(ts_data.fraction)); >> > break; >> > >> > OdbcTimestamp.fraction is declared as a long. SQLGetData is an extern >> method - >> > looks like it is just supposed to fill in the binary values? I find it a > bit >> > puzzling, perhaps even suspiciuos, that ts_data.fraction is converted to > an >> > int 32 from a long in the call to DateTime - disregarding (perhaps?) the >> > scale of the fraction? >> > >> > I am a bit confused about this. Before looking into it further, I would >> > appreciate a comment on wheter this could potentially be a bug in the Mono >> > ODBC stack? Also, where values are "set", that is, if wanting to update a >> > timestamp from mono - where the conversion takes place (there are quite > many >> > Odbc related files :- ). >> > >> > The same code runs without problems under Windows/MS. Of course, that is > not >> > to say it is correct, only that the data returned is as expected. >> > >> > Regards, >> > >> > Mads >> > >> > -- >> > Med venlig hilsen/Regards >> > >> > Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo >> Dydensborg >> > Dansk BiblioteksCenter A/S, Tempovej 7- 11, 2750 Ballerup, Tlf. +45 44 86 > 77 >> 34 >> > _______________________________________________ >> > Mono- devel- list mailing list >> > Mono- devel- list at lists.ximian.com >> > http://lists.ximian.com/mailman/listinfo/mono- devel- list >> > >> > >> >> -- >> Med venlig hilsen/Regards >> >> Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo > Dydensborg >> Dansk BiblioteksCenter A/S, Tempovej 7- 11, 2750 Ballerup, Tlf. +45 44 86 77 > 34 >> _______________________________________________ >> Mono- devel- list mailing list >> Mono- devel- list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono- devel- list >> >> From mbd at dbc.dk Fri May 4 08:45:27 2007 From: mbd at dbc.dk (Mads Bondo Dydensborg) Date: Fri, 4 May 2007 14:45:27 +0200 Subject: [Mono-dev] Sybase ASA Odbc, timestamp, fractional seconds, possible bug in mono Odbc stack? In-Reply-To: <463B4341.11BB.0044.0@novell.com> References: <200704240836.43551.mbd@dbc.dk> <200705030757.32931.mbd@dbc.dk> <463B4341.11BB.0044.0@novell.com> Message-ID: <200705041445.27847.mbd@dbc.dk> fredag 04 maj 2007 10:56 skrev A Nagappan: > Hi, > > Could you please send me a test.cs file to reproduce this bug ? Please find it attached. Running "select PublishedTime from PublishingJob" from isql returns: 2007-05-03 10:57:15.000 2007-05-03 10:57:15.920 2007-05-03 10:57:15.000 2007-05-03 10:57:15.000 And, the output from the test.cs program is: $ mono --debug test.exe Creating connection Opening connection Executing command Reading data Column 0: 5/3/2007 10:57:15 AM Unhandled Exception: System.ArgumentOutOfRangeException: Argument is out of range. Parameter name: Parameters describe an unrepresentable DateTime. at System.DateTime..ctor (Int32 year, Int32 month, Int32 day, Int32 hour, Int32 minute, Int32 second, Int32 millisecond) [0x00000] at System.Data.Odbc.OdbcDataReader.GetValue (Int32 ordinal) [0x00415] in /home/compile/Compile/Mono/mcs/class/System.Data/System.Data.Odbc/OdbcDataReader.cs:730 at System.Data.Odbc.OdbcDataReader.get_Item (Int32 index) [0x00000] in /home/compile/Compile/Mono/mcs/class/System.Data/System.Data.Odbc/OdbcDataReader.cs:153 at Test.OdbcTest.OdbcTest.Main (System.String[] args) [0x00057] in /home/madsdyd/Tests/OdbcDateTime/test.cs:26 So, the first row is correctly made into a DateTime, the next is not. Stripping the fractional of all dates in the database works, but is not really what I want :-) Regards & thanks in advance for your help. Mads -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 -------------- next part -------------- A non-text attachment was scrubbed... Name: test.cs Type: text/x-objcsrc Size: 1142 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070504/fd8d4b53/attachment.bin From lbaudio at uchoanet.com.br Fri May 4 10:37:13 2007 From: lbaudio at uchoanet.com.br (LB Audio Uchoa NET) Date: Fri, 4 May 2007 11:37:13 -0300 Subject: [Mono-dev] GetAddrOf mono-basic vb.net Message-ID: <001001c78e59$b4e860b0$0201010a@home> It is in VB6. Public Declare Function GetAddrOf Lib "kernel32" Alias "MulDiv" (nNumber As Any, Optional ByVal nNumerator As Long = 1, Optional ByVal nDenominator As Long = 1) As Long -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070504/7c9d77ce/attachment.html From kornelpal at gmail.com Fri May 4 13:49:51 2007 From: kornelpal at gmail.com (=?iso-8859-1?B?S29ybulsIFDhbA==?=) Date: Fri, 4 May 2007 19:49:51 +0200 Subject: [Mono-dev] GetAddrOf mono-basic vb.net References: <001001c78e59$b4e860b0$0201010a@home> Message-ID: <004501c78e74$9e88bb60$0100a8c0@kornelpal.hu> Hi, >It is in VB6. >Public Declare Function GetAddrOf Lib "kernel32" Alias "MulDiv" (nNumber As >Any, Optional ByVal nNumerator As Long = 1, Optional ByVal nDenominator As >Long = 1) As Long I don't know the exact reason mentioning this, but this solution should be avoided. I suggest to use GCHandle.AddrOfPinnedObject that ensures that the pointer is pinned and is platform independent as well. Korn?l From andreas.faerber at web.de Fri May 4 15:59:27 2007 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Fri, 4 May 2007 21:59:27 +0200 Subject: [Mono-dev] monoburg and eglib Message-ID: <8E340A94-0496-46D1-81C7-5506B8D7FE55@web.de> Hello, I'm wondering why monoburg uses a nonstandard way of building? Instead of declaring the usual automake variables noinst_PROGRAMS and ..._SOURCES it invokes $CC_FOR_BUILD to build monoburg $BUILD_EXEEXT. Is this to allow cross-compiling? Unfortunately this way of building breaks on Mac OS X when using eglib because gcc is directly being passed eglib's .la file in place of the usual -lglib-2.0 flag. How should this be fixed? Andreas From mcastro at mcsoft.com.br Sat May 5 12:26:37 2007 From: mcastro at mcsoft.com.br (Marco Castro) Date: Sat, 5 May 2007 13:26:37 -0300 Subject: [Mono-dev] Problem with Mono in Fedora 6 Message-ID: <9175a3e305f6f340ddc5973d2eac904e@crm.mcsoft.com.br> Hi,    I was using Mono in Fedora 3 and it was working fine. I Need to upgrade it to Fedora 6 and mono doens't works anymore. Can you help me? I dont find any error message in the log records. All I have is a 500 internal error error message.    I have installed Apache 2.2.3 and mono version 1.2.3.1 (JIT). Mono was recompiled as mod_mono so far.    I have no clues to help where can I find the error.    mod_mono.conf is like this:     LoadModule mono_module /usr/lib/httpd/modules/mod_mono.so     AddType application/x-asp-net .aspx     AddType application/x-asp-net .asmx     AddType application/x-asp-net .ashx     AddType application/x-asp-net .asax     AddType application/x-asp-net .ascx     AddType application/x-asp-net .soap     AddType application/x-asp-net .rem     AddType application/x-asp-net .axd     AddType application/x-asp-net .cs     AddType application/x-asp-net .config     AddType application/x-asp-net .Config     AddType application/x-asp-net .dll     DirectoryIndex index.aspx     DirectoryIndex Default.aspx     DirectoryIndex default.aspx Alias /aspNFD32 "/home/paginas/mcsoft/wwwroot/aspNFD32" MonoApplications "/aspNFD32:/home/paginas/mcsoft/wwwroot/aspNFD32"   SetHandler mono    Thanks for any help.    Marco Castro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070505/ad0a2313/attachment.html From Cullen at LinnLogistics.com Sat May 5 11:48:17 2007 From: Cullen at LinnLogistics.com (Cullen Linn) Date: Sat, 05 May 2007 08:48:17 -0700 Subject: [Mono-dev] Problem with Mono in Fedora 6 In-Reply-To: <9175a3e305f6f340ddc5973d2eac904e@crm.mcsoft.com.br> References: <9175a3e305f6f340ddc5973d2eac904e@crm.mcsoft.com.br> Message-ID: <463CA741.9040707@LinnLogistics.com> Can you post the apache server logs for one of your sessions that are yielding the 500 error? That may help us determine some possible causes. Marco Castro wrote: > Hi, > > I was using Mono in Fedora 3 and it was working fine. I Need to > upgrade it to Fedora 6 and mono doens't works anymore. Can you help me? > I dont find any error message in the log records. All I have is a 500 > internal error error message. > > I have installed Apache 2.2.3 and mono version 1.2.3.1 (JIT). Mono > was recompiled as mod_mono so far. > > I have no clues to help where can I find the error. > > mod_mono.conf is like this: > > > LoadModule mono_module /usr/lib/httpd/modules/mod_mono.so > > AddType application/x-asp-net .aspx > AddType application/x-asp-net .asmx > AddType application/x-asp-net .ashx > AddType application/x-asp-net .asax > AddType application/x-asp-net .ascx > AddType application/x-asp-net .soap > AddType application/x-asp-net .rem > AddType application/x-asp-net .axd > AddType application/x-asp-net .cs > AddType application/x-asp-net .config > AddType application/x-asp-net .Config > AddType application/x-asp-net .dll > DirectoryIndex index.aspx > DirectoryIndex Default.aspx > DirectoryIndex default.aspx > > Alias /aspNFD32 "/home/paginas/mcsoft/wwwroot/aspNFD32" > MonoApplications "/aspNFD32:/home/paginas/mcsoft/wwwroot/aspNFD32" > > > SetHandler mono > > Thanks for any help. > > Marco Castro > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list -- ---------------------------------- | Cullen Linn | Linn Logistics LLC | | (928) 279-8620 office | (866) 882-1526 fax | | Cullen at LinnLogistics.com | | http://www.LinnLogistics.com ---------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: Cullen.vcf Type: text/x-vcard Size: 252 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070505/ab3e289e/attachment.vcf From rolflists at ya.com Fri May 4 11:00:16 2007 From: rolflists at ya.com (Rolf Bjarne Kvinge) Date: Fri, 4 May 2007 17:00:16 +0200 Subject: [Mono-dev] GetAddrOf mono-basic vb.net In-Reply-To: <001001c78e59$b4e860b0$0201010a@home> References: <001001c78e59$b4e860b0$0201010a@home> Message-ID: <001e01c78e5c$ecfabfe0$c6f03fa0$@com> >From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of LB Audio Uchoa NET >Sent: viernes, 04 de mayo de 2007 16:37 >To: mono-devel-list at lists.ximian.com >Subject: [Mono-dev] GetAddrOf mono-basic vb.net > >It is in VB6. >Public Declare Function GetAddrOf Lib "kernel32" Alias "MulDiv" (nNumber As Any, Optional ByVal nNumerator As Long = 1, Optional ByVal nDenominator As Long = 1) As Long The VB.Net version should be something like Public Declare Function GetAddrOf Lib "kernel32" Alias "MulDiv" (ByVal nNumber As Integer, Optional ByVal Numerator As Integer = 1, Optional ByVal Denominator As Integer = 1) As Integer At least according to the declaration of MulDiv in MSDN. Now why do you rename a function called MulDiv to GetAddrOf? Rolf From slava at cyberwang.net Sat May 5 13:47:27 2007 From: slava at cyberwang.net (Slava Shirokov) Date: Sat, 05 May 2007 13:47:27 -0400 Subject: [Mono-dev] Mono 1.2.3.1 SO_REUSEPORT / System.Net.Sockets.SocketOptionName.ReusePort Patch Message-ID: <463CC32F.6030702@cyberwang.net> This patch adds the ability to set the SO_REUSEPORT socket option using System.Net.Sockets.SocketOptionName.ReusePort in mono 1.2.3.1 Patch also available here: http://slava.cyberwang.net/files/Code/Mono/mono-1.2.3.1-ReusePort.patch Patch follows: --- mcs/class/System/System.Net.Sockets/SocketOptionName.cs Wed Jul 5 17:58:46 2006 +++ ../mono-1.2.3.1-new/mcs/class/System/System.Net.Sockets/SocketOptionName.cs Fri May 4 17:47:49 2007 @@ -52,6 +52,10 @@ /// /// + ReusePort = 512, + + /// + /// KeepAlive = 8, /// --- mono/metadata/socket-io.c Thu Jan 25 01:11:15 2007 +++ ../mono-1.2.3.1-new/mono/metadata/socket-io.c Fri May 4 17:12:36 2007 @@ -331,6 +331,11 @@ case SocketOptionName_ReuseAddress: *system_name = SO_REUSEADDR; break; +#ifdef SO_REUSEPORT + case SocketOptionName_ReusePort: + *system_name = SO_REUSEPORT; + break; +#endif case SocketOptionName_KeepAlive: *system_name = SO_KEEPALIVE; break; --- mono/metadata/socket-io.h Thu Jan 25 01:11:15 2007 +++ ../mono-1.2.3.1-new/mono/metadata/socket-io.h Fri May 4 17:12:02 2007 @@ -94,6 +94,7 @@ SocketOptionName_Debug=1, SocketOptionName_AcceptConnection=2, SocketOptionName_ReuseAddress=4, + SocketOptionName_ReusePort=512, SocketOptionName_KeepAlive=8, SocketOptionName_DontRoute=16, SocketOptionName_Broadcast=32, From miguel at ximian.com Sat May 5 08:24:18 2007 From: miguel at ximian.com (Miguel de Icaza) Date: Sat, 05 May 2007 08:24:18 -0400 Subject: [Mono-dev] Silverlight early implementation thoughts. Message-ID: <1178367858.4259.5.camel@erandi.dom> Hey folks, This is a repost from an internal email that really should have been public. ---- Apologies for not sharing with the team my thoughts on Silverlight as the conference was unwrapping. I think folks found out about my interest on Silverlight from Martin LaMonica's blog entry. Silverlight 1.1 is obviously very aligned with the work that we are doing, and if someone is going to implement that it is a natural fit for our team to do so. For one, the majority of the work are the upgrades to the 3.5 libraries (System.Core.dll, completing generics, C# 3). Today our main goal is to allow a smooth migration of developers from Windows to Linux (ok, it is not smooth at all right now, you kind of have to be a Unix user to do the transition at all). Silverlight brings another component into the equation: a lack of Linux/Silverlight will prevent the Linux desktop from getting some content. Whether it will be a big or small issue is yet to be debated, but regardless of this, it seems that Silverlight is a lot of fun to implement. WPF is too big, and there is very little gain, at least in the next 3-4 years, because there is no migration strategy for every ISV that has invested in Winforms, so the only usage scenarios for WPF were new applications, or people that were willing to throw out their investments and pretty much start from scratch. On the other hand, Silverlight is a tiny subset of WPF, relatively easy to implement (a weekend hack, two at most as it has been pointed out by some of you) and it will be used to spice up existing web-based applications as opposed to rewriting an application. Now, we have a bunch of challenges ahead of us, and it is not clear when we should start work on a Mono-based Silverlight, I think we should but we must: * Ship MonoDevelop 1.0, and continue improving it as we wont be a kick-ass development platform until we move beyond Makefiles and debugging with gdb and mdb on the command line. We keep saying Mono is a better development platform, but it wont be for the unwashed massed until we get this. * Ship Windows.Forms and ASP.NET 2.0: there are hundreds of people trying to move their applications to Mono today, and we are going to need to complete both of these before we can enable the next wave of migrations. Which is sadly the majority of applications. (caveat: I rather have Mainsoft do Webparts that doing it ourselves) Implicit in the above is completing the 2.0 profile, and determine what we can implement, and what we can postpone. * Visual Studio integration: we are going to have to come up with a strategy to get VS developers to deploy on Linux. A major blocker for the VS integration is that it wont be a great experience today until we finish Winforms and ASP. In a way, am ok with the lack of a Visual Studio plugin today if only because we would not look very good to Windows developers in our current conditions. Once we finish 2.0, it would be good to have the plugin ready. Andreia started a bit of a specification here: http://www.mono-project.com/Visual_Studio_Integration But it is a bit of a how-to. I would want to figure out instead *what* is that we want to achieve, what kind of experience people will get, and then discuss how we get there. Considering the above, am not sure when and how we could start work on Silverlight. That being said, am obviously excited, and I have done some early research on the various areas that will need work, I have posted the details here: http://www.mono-project.com/Moonlight The name was suggested by Sebastien (who also has done some research that I hope he will post into that wiki page as well). Miguel. From 2a5gjx302 at sneakemail.com Sat May 5 14:20:00 2007 From: 2a5gjx302 at sneakemail.com (Jonathan Gilbert) Date: Sat, 05 May 2007 13:20:00 -0500 Subject: [Mono-dev] GetAddrOf mono-basic vb.net In-Reply-To: <001e01c78e5c$ecfabfe0$c6f03fa0$@com> References: <001001c78e59$b4e860b0$0201010a@home> <001001c78e59$b4e860b0$0201010a@home> Message-ID: <11824-39628@sneakemail.com> At 05:00 PM 5/4/2007 +0200, Rolf Bjarne wrote: > >>It is in VB6. >>Public Declare Function GetAddrOf Lib "kernel32" Alias "MulDiv" (nNumber As >>Any, Optional ByVal nNumerator As Long = 1, Optional ByVal nDenominator As >>Long = 1) As Long > >The VB.Net version should be something like >Public Declare Function GetAddrOf Lib "kernel32" Alias "MulDiv" (ByVal >nNumber As Integer, Optional ByVal Numerator As Integer = 1, Optional ByVal >Denominator As Integer = 1) As Integer > >At least according to the declaration of MulDiv in MSDN. > >Now why do you rename a function called MulDiv to GetAddrOf? What it is is an ingenious use of an API function to achieve something the original author thought VB didn't have built-in. (The original author should be directed to the help file pages for VarPtr, StrPtr and ObjPtr.) Note that in the original VB6 declaration, the nNumber parameter is not declared correctly as a ByVal Long, but rather is left "As Any". When the parameter is "As Any", VB6 will pass it ByRef unless you explicitly ask it not to in the call. This means the caller receives a pointer on the stack. Note that the MulDiv API function expects the actual value on the stack. What then happens if you, say, call GetAddrOf(my_local_variable), is that the Optional parameters default to one, and you end up asking the OS to take the memory address of my_local_variable, multiply it by 1, and then divide it by 1. Obviously this returns simply the memory address, unchanged. (Why is there an API function just to multiply and then divide a number? So that programming languages that cannot easily work with 64-bit values can scale a 32-bit value by a fraction where the intermediate value, multiplied by the numerator but not yet divided, does not fit into 32 bits.) In VB6, as I mentioned, there is a built-in function to do this: VarPtr (or StrPtr if you want the string data of a String (which is just a BSTR in VB6), or ObjPtr if you want a pointer to the interface you have selected for a given object reference). In VB.NET, the idiom is, for the most part, completely unneeded, especially if you are hoping to write code that runs both on Windows and on other platforms in Mono. The only situation I can think of where you would directly need the memory address of data is where you have an unmanaged structure which has a member that points at the data, a structure which you would then pass into some system-specific API function. I'm no VB.NET expert; in C#, you would simply write an unsafe code block and use the address-of operator '&' to get your pointer (using 'fixed' for arrays). Perhaps there is a better way, but if you *really* need to pass a value by its memory address in VB.NET, all that comes to my mind would be to use Marshal.AllocHGlobal, store the resulting IntPtr in the unmanaged structure, and then use Marshal.WriteInt32 (or one of its friends) to fill the data at the memory address you just allocated. Of course, if all you need is to pass a local variable directly into an API function ByRef, then instead of declaring that function with a ByVal memory address, declare it with a ByRef parameter of the actual data type and .NET's P/Invoke marshalling will automatically give the API a pointer. I'd be academically interested to know if there's a better way in VB.NET, but that just about sums up what this GetAddrOf is all about. Jonathan Gilbert From olivier.duff at free.fr Sat May 5 14:25:20 2007 From: olivier.duff at free.fr (olivier.duff at free.fr) Date: Sat, 05 May 2007 20:25:20 +0200 Subject: [Mono-dev] where is the moonlight svn In-Reply-To: References: Message-ID: <1178389520.463ccc109282e@imp.free.fr> Hi, the question is in the title? I want to help on it but found nothing on svn... is there a special SVN for incubator project? Thanks bye duff From robertj at gmx.net Sat May 5 14:25:41 2007 From: robertj at gmx.net (Robert Jordan) Date: Sat, 05 May 2007 20:25:41 +0200 Subject: [Mono-dev] Mono 1.2.3.1 SO_REUSEPORT / System.Net.Sockets.SocketOptionName.ReusePort Patch In-Reply-To: <463CC32F.6030702@cyberwang.net> References: <463CC32F.6030702@cyberwang.net> Message-ID: Slava Shirokov wrote: > This patch adds the ability to set the SO_REUSEPORT socket option using System.Net.Sockets.SocketOptionName.ReusePort in > mono 1.2.3.1 > > Patch also available here: http://slava.cyberwang.net/files/Code/Mono/mono-1.2.3.1-ReusePort.patch Since there is no SocketOptionName.ReusePort in MS.NET 1.1 or 2.0, this patch cannot be accepted. Robert From miguel at novell.com Sat May 5 15:40:42 2007 From: miguel at novell.com (Miguel de Icaza) Date: Sat, 05 May 2007 15:40:42 -0400 Subject: [Mono-dev] where is the moonlight svn In-Reply-To: <1178389520.463ccc109282e@imp.free.fr> References: <1178389520.463ccc109282e@imp.free.fr> Message-ID: <1178394042.4259.49.camel@erandi.dom> Hello, > the question is in the title? > I want to help on it but found nothing on svn... > is there a special SVN for incubator project? Well, the various pieces are part of different namespaces already covered by Mono. See the web page with details about it, but basically we need to setup the API-corcompare framework to find out what we are missing (am working on it). The modules will be mcs and olive for now (and unmanaged code will likely go elsewhere, like we do today with libgdiplus). Miguel. From slava at cyberwang.net Sat May 5 17:33:43 2007 From: slava at cyberwang.net (Slava Shirokov) Date: Sat, 05 May 2007 17:33:43 -0400 Subject: [Mono-dev] Mono 1.2.3.1 SO_REUSEPORT / System.Net.Sockets.SocketOptionName.ReusePort Patch In-Reply-To: References: <463CC32F.6030702@cyberwang.net> Message-ID: <463CF837.6030900@cyberwang.net> I understand that, but without the SO_REUSEPORT socket option certain applications will not function properly under FreeBSD. So either the option needs to be added to mono conditionally at compile time, or there needs to be a mechanism to easily set the option. Would setting SO_REUSEPORT when SO_REUSEADDR is set be more acceptable? Robert Jordan wrote: > Slava Shirokov wrote: >> This patch adds the ability to set the SO_REUSEPORT socket option using System.Net.Sockets.SocketOptionName.ReusePort in >> mono 1.2.3.1 >> >> Patch also available here: http://slava.cyberwang.net/files/Code/Mono/mono-1.2.3.1-ReusePort.patch > > Since there is no SocketOptionName.ReusePort in MS.NET 1.1 or 2.0, this > patch cannot be accepted. > > Robert > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From jit at occams.info Sat May 5 18:09:28 2007 From: jit at occams.info (Joshua Tauberer) Date: Sat, 05 May 2007 18:09:28 -0400 Subject: [Mono-dev] Silverlight early implementation thoughts. In-Reply-To: <1178367858.4259.5.camel@erandi.dom> References: <1178367858.4259.5.camel@erandi.dom> Message-ID: <463D0098.8010100@occams.info> Miguel wrote: > Silverlight brings another component into the equation: Hey, I don't think I usually chime in on these things, but this time I figured I would. IMO, the Mono community/project tends to spread itself very thin. Lots of things get started but not polished up and finished very well. I don't think that's always a bad thing --- in fact, the renewed enthusiasm that tends to follow new APIs from MS, for instance, is really nice to see. And it's certainly not without exception -- MonoDevelop is polished, and impressively so despite the fact that it continues to undergo significant progress. But the unpolished things include: Debugging (MD integration, or *some* GUI debugger) mod_mono (configuration is very awkward, problems are hard to diagnose, restarting the Mono process is still strange) Class library documentation Doc tools for independent libraries (we need a proper editor GUI) (Some may know that I've taken small stabs at improving the last three over the years, and I'm guilty for leaving things in unpolished states.) Other random things that I think are important: The new GC Runtime performance Was CAS ever finished? AOT on 2.0 assemblies (at least for non-generic types) Internal testing of the Web pipelines, by having mono-project.com run on the Mono stack And that's just what comes to mind right now. (SWF, ASP.NET 2.0, and finishing the existing APIs go without saying.) There are a lot of parts of Mono that I've never even touched that I'm sure have unpolished aspects too. Anyway, I'm definitely of the mentality that if you want something done in an open source project that's not getting done, you should do it yourself. So I'm not trying to sound like I have expectations that all of these things should somehow magically just get done. OTOH, since there are people being paid to work on Mono, it doesn't hurt to suggest what I think their priorities should involve---namely, polishing existing parts of the project. And, besides that, before Mono hackers get too involved with an entirely new API that may very well flop, I think it would be useful to consider whether there are existing parts of the project that need polishing that you'd also enjoy working on. My two cents. -- - Josh Tauberer http://razor.occams.info "Yields falsehood when preceded by its quotation! Yields falsehood when preceded by its quotation!" Achilles to Tortoise (in "G?del, Escher, Bach" by Douglas Hofstadter) Miguel de Icaza wrote: > Hey folks, > > This is a repost from an internal email that really should have been > public. > > ---- > > Apologies for not sharing with the team my thoughts on Silverlight > as the conference was unwrapping. I think folks found out about my > interest on Silverlight from Martin LaMonica's blog entry. > > Silverlight 1.1 is obviously very aligned with the work that we are > doing, and if someone is going to implement that it is a natural fit for > our team to do so. For one, the majority of the work are the upgrades > to the 3.5 libraries (System.Core.dll, completing generics, C# 3). > > Today our main goal is to allow a smooth migration of developers > from Windows to Linux (ok, it is not smooth at all right now, you kind > of have to be a Unix user to do the transition at all). > > Silverlight brings another component into the equation: a lack of > Linux/Silverlight will prevent the Linux desktop from getting some > content. Whether it will be a big or small issue is yet to be debated, > but regardless of this, it seems that Silverlight is a lot of fun to > implement. > > WPF is too big, and there is very little gain, at least in the next > 3-4 years, because there is no migration strategy for every ISV that has > invested in Winforms, so the only usage scenarios for WPF were new > applications, or people that were willing to throw out their investments > and pretty much start from scratch. > > On the other hand, Silverlight is a tiny subset of WPF, relatively > easy to implement (a weekend hack, two at most as it has been pointed > out by some of you) and it will be used to spice up existing web-based > applications as opposed to rewriting an application. > > > Now, we have a bunch of challenges ahead of us, and it is not clear > when we should start work on a Mono-based Silverlight, I think we should > but we must: > > * Ship MonoDevelop 1.0, and continue improving it as we wont be > a kick-ass development platform until we move beyond > Makefiles and debugging with gdb and mdb on the command line. > > We keep saying Mono is a better development platform, but it > wont be for the unwashed massed until we get this. > > * Ship Windows.Forms and ASP.NET 2.0: there are hundreds of > people trying to move their applications to Mono today, and > we are going to need to complete both of these before we can > enable the next wave of migrations. Which is sadly the > majority of applications. > > (caveat: I rather have Mainsoft do Webparts that doing it > ourselves) > > Implicit in the above is completing the 2.0 profile, and > determine what we can implement, and what we can postpone. > > * Visual Studio integration: we are going to have to come up > with a strategy to get VS developers to deploy on Linux. > > A major blocker for the VS integration is that it wont be > a great experience today until we finish Winforms and ASP. > > In a way, am ok with the lack of a Visual Studio plugin today > if only because we would not look very good to Windows > developers in our current conditions. > > Once we finish 2.0, it would be good to have the plugin ready. > > Andreia started a bit of a specification here: > > http://www.mono-project.com/Visual_Studio_Integration > > But it is a bit of a how-to. I would want to figure out > instead *what* is that we want to achieve, what kind of > experience people will get, and then discuss how we get there. > > Considering the above, am not sure when and how we could start work > on Silverlight. > > That being said, am obviously excited, and I have done some early > research on the various areas that will need work, I have posted the > details here: > > http://www.mono-project.com/Moonlight > > The name was suggested by Sebastien (who also has done some research > that I hope he will post into that wiki page as well). > > Miguel. > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From m.j.hutchinson at gmail.com Sat May 5 19:03:00 2007 From: m.j.hutchinson at gmail.com (Michael Hutchinson) Date: Sun, 6 May 2007 00:03:00 +0100 Subject: [Mono-dev] Silverlight early implementation thoughts. In-Reply-To: <463D0098.8010100@occams.info> References: <1178367858.4259.5.camel@erandi.dom> <463D0098.8010100@occams.info> Message-ID: On 5/5/07, Joshua Tauberer wrote: > But the unpolished things include: Most of these are addressed in the upcoming Google Summer of Code... > > Debugging (MD integration, or *some* GUI debugger) MonoDevelop Debugger http://code.google.com/soc/mono/appinfo.html?csaid=F894C9ED094FC38 > mod_mono (configuration is very awkward, problems are hard to > diagnose, restarting the Mono process is still strange) FastCGI ASP.NET Server http://code.google.com/soc/mono/appinfo.html?csaid=7D9BFE2E183364B9 > Class library documentation > Doc tools for independent libraries (we need a proper editor GUI) WYSIWYG Editor for Monodoc and MonoDevelop http://code.google.com/soc/mono/appinfo.html?csaid=69D5900719093384 -- Michael Hutchinson http://mjhutchinson.com From robertj at gmx.net Sat May 5 19:05:01 2007 From: robertj at gmx.net (Robert Jordan) Date: Sun, 06 May 2007 01:05:01 +0200 Subject: [Mono-dev] Mono 1.2.3.1 SO_REUSEPORT / System.Net.Sockets.SocketOptionName.ReusePort Patch In-Reply-To: <463CF837.6030900@cyberwang.net> References: <463CC32F.6030702@cyberwang.net> <463CF837.6030900@cyberwang.net> Message-ID: Slava Shirokov wrote: > I understand that, but without the SO_REUSEPORT socket option certain > applications will not function properly under FreeBSD. > > So either the option needs to be added to mono conditionally at > compile time, or there needs to be a mechanism to easily set the > option. Would setting SO_REUSEPORT when SO_REUSEADDR is set be more > acceptable? Well, this introduces a security issue on BSD and it will also break applications that expect bind() to fail. Can you elaborate which operations on what kind of sockets are failing on BSD? Robert > > Robert Jordan wrote: >> Slava Shirokov wrote: >>> This patch adds the ability to set the SO_REUSEPORT socket option >>> using > System.Net.Sockets.SocketOptionName.ReusePort in >>> mono 1.2.3.1 >>> >>> Patch also available here: >>> http://slava.cyberwang.net/files/Code/Mono/mono-1.2.3.1-ReusePort.patch >>> >> >> Since there is no SocketOptionName.ReusePort in MS.NET 1.1 or 2.0, >> this patch cannot be accepted. >> >> Robert >> >> _______________________________________________ Mono-devel-list >> mailing list Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list From pascalfresnay at free.fr Sat May 5 18:41:21 2007 From: pascalfresnay at free.fr (Pascal Fresnay) Date: Sun, 06 May 2007 00:41:21 +0200 Subject: [Mono-dev] NHibernate 1.2 problem on mono 1.2.4 preview Message-ID: <1178404881.24780.6.camel@patate.fbx.proxad.net> Hi, It seems that the new NHibernate major release (1.2 - 3 may 2007) can't be used on mono, a method is missing that throw a NotImplementedException ( http://bugzilla.ximian.com/show_bug.cgi?id=78637 ) in auto-generated proxies. Any chance to have a fix in 1.2.4 release ? Thanks, Pascal From pablosantosluac at terra.es Sat May 5 19:54:23 2007 From: pablosantosluac at terra.es (pablosantosluac) Date: Sun, 6 May 2007 01:54:23 +0200 Subject: [Mono-dev] Debugger Message-ID: <006501c78f70$b4f89e90$0202a8c0@beardtongue> Hi, What is the debugger current status? Pablo From jonpryor at vt.edu Sat May 5 20:23:10 2007 From: jonpryor at vt.edu (Jonathan Pryor) Date: Sat, 05 May 2007 20:23:10 -0400 Subject: [Mono-dev] Silverlight early implementation thoughts. In-Reply-To: <463D0098.8010100@occams.info> References: <1178367858.4259.5.camel@erandi.dom> <463D0098.8010100@occams.info> Message-ID: <1178410992.14748.283.camel@melchior.magi> On Sat, 2007-05-05 at 18:09 -0400, Joshua Tauberer wrote: > Miguel wrote: > > Silverlight brings another component into the equation: > > IMO, the Mono community/project tends to spread itself very thin. Lots > of things get started but not polished up and finished very well. For the most part, agreed -- there's just too much that fits within the current Mono umbrella and not enough resources (paid Novell developers and contributors combined) to cover them all. I'm not entirely sure that this is a bad thing per-se, it just requires that we prioritize things appropriately. > And, besides that, before Mono hackers get too involved with an entirely > new API that may very well flop, I think it would be useful to consider > whether there are existing parts of the project that need polishing that > you'd also enjoy working on. The thing to keep in mind is that the "entirely new API" is fairly minimal here. Most of it is a trimmed down .NET 2.0 API + Linq -- most of which we already have or need to do anyway. The new API portions are fairly minimal in the grand scheme of things -- we already have the JIT, GC, 90%+ of the needed class libraries (or more). So what this mostly amounts to is a new use of existing code, which can lead to additional polish/completion of existing APIs that need to be done anyway (i.e. add missing .NET 2.0 methods), which can only be a good thing. (There's also the question of how best to create the stripped down v2.1.0.0 assemblies, and one of the suggestions is to use Cecil to write a subset generator, which can result in only more polish to Cecil and similar libraries. It's all good. :-) The implementation of new API and a browser plugin may be a diversion of resources, but it's a diversion that will mostly add polish (and users) to what we already have. From this perspective, how can we NOT do it? :-) - Jon From mcastro at mcsoft.com.br Sun May 6 01:30:27 2007 From: mcastro at mcsoft.com.br (McSoft) Date: Sun, 6 May 2007 02:30:27 -0300 Subject: [Mono-dev] FW: Problem with Mono in Fedora 6 Message-ID: Hi,   The erro messege is not of a big help. Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, webmail at mcsoft.com.br> More information about this error may be available in the server error log. Apache/2.2.3 (Fedora) Server at www3.mcsoft.com.br>   Thanks,   Marco Castro > De: Marco Castro > Data de Envio: > Para: mono-devel-list at lists.ximian.com > Assunto: Problem with Mono in Fedora 6 > > Hi, >    I was using Mono in Fedora 3 and it was working fine. I Need to > upgrade it to Fedora 6 and mono doens't works anymore. Can you help me? I > dont find any error message in the log records. All I have is a 500 internal > error error message. >    I have installed Apache 2.2.3 and mono version 1.2.3.1 (JIT). > Mono was recompiled as mod_mono so far. >    I have no clues to help where can I find the error. >    mod_mono.conf is like this: >     LoadModule mono_module /usr/lib/httpd/modules/mod_mono.so >     AddType application/x-asp-net .aspx >     AddType application/x-asp-net .asmx >     AddType application/x-asp-net .ashx >     AddType application/x-asp-net .asax >     AddType application/x-asp-net .ascx >     AddType application/x-asp-net .soap >     AddType application/x-asp-net .rem >     AddType application/x-asp-net .axd >     AddType application/x-asp-net .cs >     AddType application/x-asp-net .config >     AddType application/x-asp-net .Config >     AddType application/x-asp-net .dll >     DirectoryIndex index.aspx >     DirectoryIndex Default.aspx >     DirectoryIndex default.aspx > Alias /aspNFD32 '/home/paginas/mcsoft/wwwroot/aspNFD32' > MonoApplications '/aspNFD32:/home/paginas/mcsoft/wwwroot/aspNFD32' > aspNFD32> >   SetHandler mono >    Thanks for any help. >    Marco Castro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070506/527fd87b/attachment.html From miguel at novell.com Sun May 6 00:31:01 2007 From: miguel at novell.com (Miguel de Icaza) Date: Sun, 06 May 2007 00:31:01 -0400 Subject: [Mono-dev] Silverlight early implementation thoughts. In-Reply-To: <463D0098.8010100@occams.info> References: <1178367858.4259.5.camel@erandi.dom> <463D0098.8010100@occams.info> Message-ID: <1178425861.4259.101.camel@erandi.dom> Hello Joshua, > IMO, the Mono community/project tends to spread itself very thin. Lots > of things get started but not polished up and finished very well. I > don't think that's always a bad thing --- in fact, the renewed > enthusiasm that tends to follow new APIs from MS, for instance, is > really nice to see. And it's certainly not without exception -- > MonoDevelop is polished, and impressively so despite the fact that it > continues to undergo significant progress. I agree with you. There are certain projects that we have abandoned or that we have outright decided not to implement due to this nature (the various WSE attempts for example, some of the EnterpriseServices projects, maintenance of third-party libraries). > But the unpolished things include: > > Debugging (MD integration, or *some* GUI debugger) Yes, the issue here is that the debugger has only recently became complete enough to debug applications, and even then, it is still missing support for certain features (some people report issues with AppDomain debugging). It is now possible to build some integration with it, but it was impossible before we had the debugger working. > mod_mono (configuration is very awkward, problems are hard to > diagnose, restarting the Mono process is still strange) Mod_mono configuration is the area I hate the most about Mono, for one I can never remember how it works and I *always* have to look up the manual pages myself. I guess that part of the problem here is that we never defined a clear goal in terms of what the end-user experience was. Auto-hosting was a step in that direction, but am not sure that we have explored all the areas here (recently I had some issues, but I forgot to take notes, and I can no longer remember what was it that annoyed me so much about it, but I know things annoyed me). > Class library documentation > Doc tools for independent libraries (we need a proper editor GUI) Yes, I wish we had one. Maybe one will come out of the Summer of Code, but you never know. In general, I have tried to get people to write documentation when they write their code (inside my team). Some people do not like writing docs, but also there is the fact that although docs are important, we always have someone screaming for an urgent task to be fixed. So urgent tends to trump important. > (Some may know that I've taken small stabs at improving the last three > over the years, and I'm guilty for leaving things in unpolished states.) And am incredibly thankful for this work. > Other random things that I think are important: > > The new GC It continues to be under development, although Paolo has been pulled into a few projects every once in a while, so this has slowed down progress. For a while we only had Paolo and Massi working on the JIT, a situation that is changing as Zoltan joins the team again, and two new JIT developers start in May and June. > Runtime performance This is not for lack of trying. A few months ago we got a major boost from the work that Massi did for almost six months. There are large projects underway, Zoltan's linear-il branch will be the future base for optimizations and Massi was working on a new register allocator for it, but we changed directions during Massi's research. I wish for one that Massi blogged more often, because the tale of what happened ended up merely on a discussion in our internal mailing lists and our internal emails. And as Jon Udell was saying a few days ago, this is not a good way of maximizing keystrokes, this should have been blogged or posted. But the story goes like this: Massi was working on the new register allocator (the major source of pain for the extra spills/reloads in our code generator) and noticed that a lot of passes could be avoided if we just made our JIT work only with SSA-based representations. He consulted with me, the performance loss was not significant, so I told him to keep working on it. Then we discovered that JIT time although not an issue for large systems would be a big issue for embedded devices (things like the Zing) so we reset the work to go with the original plan, loosing the SSA-only setup (the whole story is more interesting, but am trying to keep this short). Anyways, Massi was doing this, when we realized that people were adopting GMCS in droves even if it is not supported, and a problem here was that Arrays were creating thousands of interfaces (because of all the implicit interfaces implemented). In an app like Banshee, 1 meg gets JITed and 1 meg ends up being allocated for vtables! (vtables were basically empty). So Massi has gone to implement a way of compressing the vtables as this has much higher priority than improving the performance. But these are not one-week hacks, these are multi-week changes, and the register allocator is a six month effort for example; The linear-ir branch is probably going to take a year before it can be rolled out. Nothing visible immediately. Anyways, it is a world of small tasks like this. > Was CAS ever finished? No, it has not. And we do not have right now plans for when this will be finished. The CAS was too hard to use (even in .NET) so we might end up first implementing the Silverlight-like security system before we get around to doing CAS. > AOT on 2.0 assemblies (at least for non-generic types) This is a wish-list item at this point, it would be nice, but am not sure when we will get to it. > Internal testing of the Web pipelines, by having mono-project.com run > on the Mono stack If someone writes a MediaWiki replacement that is *compatible* with the MediaWiki database and rendering interface, am fine switching to it. > And that's just what comes to mind right now. (SWF, ASP.NET 2.0, and > finishing the existing APIs go without saying.) There are a lot of parts > of Mono that I've never even touched that I'm sure have unpolished > aspects too. I agree, and they are being worked on. There are currently six engineers working on it (Sebastien is working on GDI+/System.Drawing, but mostly because of System.Windows.Forms). > OTOH, since there are people being paid to work on Mono, it doesn't hurt > to suggest what I think their priorities should involve---namely, > polishing existing parts of the project. Which is exactly what we are doing. But am considering that we will likely cut pieces or re-arrange the schedule and roadmap for the sake of Silverlight, for one because a lack of Silverlight in Linux would prevent us one day from useful content. But its still up in the air. I know what am going to be spending my weekends on ;-) > And, besides that, before Mono hackers get too involved with an entirely > new API that may very well flop, I think it would be useful to consider > whether there are existing parts of the project that need polishing that > you'd also enjoy working on. > > My two cents. Silverlight could go both ways though: it could flop or it could change the way we build Web applications entirely. Miguel. From miguel at novell.com Sun May 6 00:33:00 2007 From: miguel at novell.com (Miguel de Icaza) Date: Sun, 06 May 2007 00:33:00 -0400 Subject: [Mono-dev] Debugger In-Reply-To: <006501c78f70$b4f89e90$0202a8c0@beardtongue> References: <006501c78f70$b4f89e90$0202a8c0@beardtongue> Message-ID: <1178425980.4259.103.camel@erandi.dom> Hello, > What is the debugger current status? It is working, and we hope that people test it with real code, send us feedback and help us improve it. We have reached the point where we think it is usable, but the only way of knowing if it is, is if people give us feedback. Miguel. > Pablo > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From pablosantosluac at terra.es Sun May 6 02:46:11 2007 From: pablosantosluac at terra.es (pablosantosluac) Date: Sun, 6 May 2007 08:46:11 +0200 Subject: [Mono-dev] Debugger References: <006501c78f70$b4f89e90$0202a8c0@beardtongue> <1178425980.4259.103.camel@erandi.dom> Message-ID: <007b01c78faa$3d958590$0202a8c0@beardtongue> Thanks Miguel, Is it installed with the latest prerelease? I will try it asap. ----- Original Message ----- From: "Miguel de Icaza" To: "pablosantosluac" Cc: Sent: Sunday, May 06, 2007 6:33 AM Subject: Re: [Mono-dev] Debugger > Hello, > >> What is the debugger current status? > > It is working, and we hope that people test it with real code, send us > feedback and help us improve it. > > We have reached the point where we think it is usable, but the only way > of knowing if it is, is if people give us feedback. > > Miguel. >> Pablo >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list From eyala at mainsoft.com Sun May 6 05:06:59 2007 From: eyala at mainsoft.com (Eyal Alaluf) Date: Sun, 6 May 2007 02:06:59 -0700 Subject: [Mono-dev] System.Runtime.Remoting.RemotingConfigurationConfigure Patch In-Reply-To: <17c2d80b0705030436q6f28419du3e22105ad98481d5@mail.gmail.com> Message-ID: Hi, Jonathan. MonoNotSupported denotes the fact that the API is completely unimplemented. I propose that you use MonoLimitation in this case, instead. MonoLimitaion denotes the fact that the API is partially implemented. The text is displayed by documentation tools (am not sure about NUMA). Eyal. ________________________________ From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Jonathan Chambers Sent: 03 May 2007 13:36 To: Andr?s G. Aragoneses [ knocte ] Cc: mono-devel-list at lists.ximian.com Subject: Re: [Mono-dev] System.Runtime.Remoting.RemotingConfigurationConfigure Patch Perhaps I should use a more specific MonoTODOAttribute; MonoNotSupportedAttribute perhaps? - Jonathan On 5/3/07, "Andr?s G. Aragoneses [ knocte ]" wrote: Jonathan Chambers escribi?: > Attached is patch to add 2.0 overload of Configure method in > System.Runtime.Remoting.RemotingConfiguration. This was done the same > way as System.Runtime.Remoting.Channels.ChannelServices.RegisterChannel . Shouldn't that MonoTODO be converted into a FIXME? That one is not giving much information for a potential MoMA user. Regards, Andr?s [ knocte ] -- _______________________________________________ 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/20070506/ab7f0912/attachment.html From marek.sieradzki at gmail.com Sun May 6 05:39:34 2007 From: marek.sieradzki at gmail.com (Marek Sieradzki) Date: Sun, 06 May 2007 11:39:34 +0200 Subject: [Mono-dev] [PATCH] AssemblyName.ctor () can't parse ProcessorArchitecture. Message-ID: <1178444374.2130.4.camel@k5m10marek.cl.wroc.pl> I know that AssemblyName.ProcessorArchitecture isn't used in Mono but I'm using AssemblyName.ctor in xbuild (to build AssemblyName from string) and current version throws exception when it sees "ProcessorArchitecture=something". Here's a patch that makes it assign correct values to new field in MonoAssemblyName. -- Marek Sieradzki -------------- next part -------------- A non-text attachment was scrubbed... Name: mono.diff Type: text/x-patch Size: 3099 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070506/6eca24e5/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: mcs.diff Type: text/x-patch Size: 1312 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070506/6eca24e5/attachment-0001.bin From marcoscobena at gmail.com Sun May 6 07:20:29 2007 From: marcoscobena at gmail.com (=?UTF-8?Q?Marcos_Cobe=C3=B1a_Mori=C3=A1n?=) Date: Sun, 6 May 2007 13:20:29 +0200 Subject: [Mono-dev] Silverlight early implementation thoughts. In-Reply-To: <1178425861.4259.101.camel@erandi.dom> References: <1178367858.4259.5.camel@erandi.dom> <463D0098.8010100@occams.info> <1178425861.4259.101.camel@erandi.dom> Message-ID: <67c29c7c0705060420w7753f0dfq4a0c2352a7821470@mail.gmail.com> Hello, Although I agree on those challenges as important goals for Mono platform, Moonlight (BTW, really good idea for this codename) shouldn't wait so much at the wardrobe. In the next months, if everything goes fine for Silverlight development, it may become a really powerful tool for Web developers. Once 1.0 is out, or 1.1 some months later, there could be two hypothetical options: 1. Mono has no support for it. If Silverlight success, there could be a large switching from ASP.NET 2.0 model to Silverlight (probably similar to Flash movement), but Mono will continue one step behind. ASP.NET 2.0 may lose all the weight it currently has. 2. Mono has support for it, at least for rendering content, not own tools for designing, etc. If Silverlight success, GNU/Linux users will take part in their platform deployment from the very beginning. Web developers, when deploying their Silverlight applications will realize it's possible to work also on GNU/Linux, for sure acquiring interest in it. A big goal for Mono. I haven't forgotten the possibility of Silverlight not succeeding, but if it happens, most of the work done will just be reused into another project, like LINQ, SandBox, etc. It's currently quite difficult to determine whether what developers will like to work with from now to a year or two but, honestly, after Flex 2, Silverlight, and so on, it looks like a big switch is happening. It's been very exciting to see these entries at Monologue talking about this baby-project. :-) My two bits. Regards, One who wants Moonlight to become real. ;-) 2007/5/6, Miguel de Icaza : > Hello Joshua, > > > IMO, the Mono community/project tends to spread itself very thin. Lots > > of things get started but not polished up and finished very well. I > > don't think that's always a bad thing --- in fact, the renewed > > enthusiasm that tends to follow new APIs from MS, for instance, is > > really nice to see. And it's certainly not without exception -- > > MonoDevelop is polished, and impressively so despite the fact that it > > continues to undergo significant progress. > > I agree with you. > > There are certain projects that we have abandoned or that we have > outright decided not to implement due to this nature (the various WSE > attempts for example, some of the EnterpriseServices projects, > maintenance of third-party libraries). > > > But the unpolished things include: > > > > Debugging (MD integration, or *some* GUI debugger) > > Yes, the issue here is that the debugger has only recently became > complete enough to debug applications, and even then, it is still > missing support for certain features (some people report issues with > AppDomain debugging). > > It is now possible to build some integration with it, but it was > impossible before we had the debugger working. > > > mod_mono (configuration is very awkward, problems are hard to > > diagnose, restarting the Mono process is still strange) > > Mod_mono configuration is the area I hate the most about Mono, for one I > can never remember how it works and I *always* have to look up the > manual pages myself. > > I guess that part of the problem here is that we never defined a clear > goal in terms of what the end-user experience was. Auto-hosting was a > step in that direction, but am not sure that we have explored all the > areas here (recently I had some issues, but I forgot to take notes, and > I can no longer remember what was it that annoyed me so much about it, > but I know things annoyed me). > > > Class library documentation > > Doc tools for independent libraries (we need a proper editor GUI) > > Yes, I wish we had one. Maybe one will come out of the Summer of Code, > but you never know. > > In general, I have tried to get people to write documentation when they > write their code (inside my team). Some people do not like writing > docs, but also there is the fact that although docs are important, we > always have someone screaming for an urgent task to be fixed. So urgent > tends to trump important. > > > (Some may know that I've taken small stabs at improving the last three > > over the years, and I'm guilty for leaving things in unpolished states.) > > And am incredibly thankful for this work. > > > Other random things that I think are important: > > > > The new GC > > It continues to be under development, although Paolo has been pulled > into a few projects every once in a while, so this has slowed down > progress. > > For a while we only had Paolo and Massi working on the JIT, a situation > that is changing as Zoltan joins the team again, and two new JIT > developers start in May and June. > > > Runtime performance > > This is not for lack of trying. > > A few months ago we got a major boost from the work that Massi did for > almost six months. There are large projects underway, Zoltan's > linear-il branch will be the future base for optimizations and Massi was > working on a new register allocator for it, but we changed directions > during Massi's research. > > I wish for one that Massi blogged more often, because the tale of what > happened ended up merely on a discussion in our internal mailing lists > and our internal emails. And as Jon Udell was saying a few days ago, > this is not a good way of maximizing keystrokes, this should have been > blogged or posted. > > But the story goes like this: Massi was working on the new register > allocator (the major source of pain for the extra spills/reloads in our > code generator) and noticed that a lot of passes could be avoided if we > just made our JIT work only with SSA-based representations. He > consulted with me, the performance loss was not significant, so I told > him to keep working on it. > > Then we discovered that JIT time although not an issue for large systems > would be a big issue for embedded devices (things like the Zing) so we > reset the work to go with the original plan, loosing the SSA-only setup > (the whole story is more interesting, but am trying to keep this short). > > Anyways, Massi was doing this, when we realized that people were > adopting GMCS in droves even if it is not supported, and a problem here > was that Arrays were creating thousands of interfaces (because of all > the implicit interfaces implemented). In an app like Banshee, 1 meg > gets JITed and 1 meg ends up being allocated for vtables! (vtables were > basically empty). > > So Massi has gone to implement a way of compressing the vtables as this > has much higher priority than improving the performance. But these are > not one-week hacks, these are multi-week changes, and the register > allocator is a six month effort for example; The linear-ir branch is > probably going to take a year before it can be rolled out. Nothing > visible immediately. > > Anyways, it is a world of small tasks like this. > > > Was CAS ever finished? > > No, it has not. And we do not have right now plans for when this will > be finished. The CAS was too hard to use (even in .NET) so we might > end up first implementing the Silverlight-like security system before we > get around to doing CAS. > > > AOT on 2.0 assemblies (at least for non-generic types) > > This is a wish-list item at this point, it would be nice, but am not > sure when we will get to it. > > > Internal testing of the Web pipelines, by having mono-project.com run > > on the Mono stack > > If someone writes a MediaWiki replacement that is *compatible* with the > MediaWiki database and rendering interface, am fine switching to it. > > > And that's just what comes to mind right now. (SWF, ASP.NET 2.0, and > > finishing the existing APIs go without saying.) There are a lot of parts > > of Mono that I've never even touched that I'm sure have unpolished > > aspects too. > > I agree, and they are being worked on. There are currently six > engineers working on it (Sebastien is working on GDI+/System.Drawing, > but mostly because of System.Windows.Forms). > > > OTOH, since there are people being paid to work on Mono, it doesn't hurt > > to suggest what I think their priorities should involve---namely, > > polishing existing parts of the project. > > Which is exactly what we are doing. > > But am considering that we will likely cut pieces or re-arrange the > schedule and roadmap for the sake of Silverlight, for one because a lack > of Silverlight in Linux would prevent us one day from useful content. > > But its still up in the air. I know what am going to be spending my > weekends on ;-) > > > And, besides that, before Mono hackers get too involved with an entirely > > new API that may very well flop, I think it would be useful to consider > > whether there are existing parts of the project that need polishing that > > you'd also enjoy working on. > > > > My two cents. > > Silverlight could go both ways though: it could flop or it could change > the way we build Web applications entirely. > > Miguel. > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Marcos - http://www.youcannoteatbits.org From paul at all-the-johnsons.co.uk Sun May 6 08:16:31 2007 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Sun, 6 May 2007 12:16:31 +0000 Subject: [Mono-dev] Problem with Mono in Fedora 6 In-Reply-To: <9175a3e305f6f340ddc5973d2eac904e@crm.mcsoft.com.br> References: <9175a3e305f6f340ddc5973d2eac904e@crm.mcsoft.com.br> Message-ID: <20070506121631.M19383@all-the-johnsons.co.uk> Hi, > I was using Mono in Fedora 3 and it was working fine. I > Need to upgrade it to Fedora 6 and mono doens't works anymore. > Can you help me? Are you using the Fedora packages or the have you compiled them yourself? TTFN Paul Fedora packager -- Get your free @ukpost.com account now http://www.ukpost.com/ From sebastien.pouliot at gmail.com Sun May 6 08:19:21 2007 From: sebastien.pouliot at gmail.com (Sebastien Pouliot) Date: Sun, 06 May 2007 08:19:21 -0400 Subject: [Mono-dev] Silverlight early implementation thoughts. In-Reply-To: <463D0098.8010100@occams.info> References: <1178367858.4259.5.camel@erandi.dom> <463D0098.8010100@occams.info> Message-ID: <1178453961.3881.260.camel@poupou.home> Hello Joshua, You raise some good and valid points. Of course I see them as "good and valid" because I share them ;-) but my conclusions don't match yours. On Sat, 2007-05-05 at 18:09 -0400, Joshua Tauberer wrote: > Miguel wrote: > > Silverlight brings another component into the equation: > > Hey, > > I don't think I usually chime in on these things, but this time I > figured I would. as do I ;-) > IMO, the Mono community/project tends to spread itself very thin. Lots > of things get started but not polished up and finished very well. I > don't think that's always a bad thing --- in fact, the renewed > enthusiasm that tends to follow new APIs from MS, for instance, is > really nice to see. I don't think 3.0 and 3.5, even together, showed much enthusiasm compared to 1.0 and 2.0. At least Silverlight seems to beat that. > And it's certainly not without exception -- > MonoDevelop is polished, and impressively so despite the fact that it > continues to undergo significant progress. > > But the unpolished things include: > > Debugging (MD integration, or *some* GUI debugger) > mod_mono (configuration is very awkward, problems are hard to > diagnose, restarting the Mono process is still strange) > Class library documentation > Doc tools for independent libraries (we need a proper editor GUI) I think the previous emails answered most of them. > (Some may know that I've taken small stabs at improving the last three > over the years, and I'm guilty for leaving things in unpolished states.) > > Other random things that I think are important: > > The new GC > Runtime performance True, but both tasks are, in large parts, unrelated to the API being targeted. Interestingly the related parts may make those tasks easier (to do or to prioritize) in a smaller subsystem. > Was CAS ever finished? No. Lots of interdependent reasons for that. Without stealing the thread subject (there's been enough email about it) I think we can quickly generalize most of them under the "Lack of interest" category. E.g. of all attendees to last October Mono meeting only a single person had used (well tried) the --security option, namely Paolo (I excluded myself from the count ;-). No, I'm not blaming anyone over that. Reality shows that people expect desktop applications running with FullTrust and that other solutions exists for web apps (otherwise a lot of other environments, like PHP, would never have risen). However I don't put much believe in the fact that "people waits for full CAS" to explain this, CAS always existed under MS runtimes and the situation there isn't very different. Perhaps one of the hardest thing to do is coming with a *useful* multi-step implementation plan. It's hard to see intermediate states, between the current code and a fully functional CAS implementation, that would be useful to many. E.g. MWF required a lot of work (several people, several years) to get many existing Windows applications working without changes. Even then it can be useful with a subset of all controls (e.g. WebControl). CAS without File permissions (or Sockets, unmanaged code, verifier checks) wouldn't be useful at all. This makes it hard to invest into the "next step" knowing the dividends are far and away - and I'm not just talking about Novell here, same applies to individual contributors. As you stated there is so much things that would get more immediate, and positive, results. Now back to the original subject, Silverlight, may be providing a useful step. From the (very) little I've seen so far I don't believe it's very different from CAS (there's not many ways to run untrusted code). This translates to: - less work than a full CAS implementation (i.e. quicker dividends) - a smaller Fx would requires a smaller audit (still a big task, but a smaller big task ;-) - something potentially useful to many Mono users (and Linux desktop users); and - we get a step closer to the real CAS :-) > AOT on 2.0 assemblies (at least for non-generic types) > Internal testing of the Web pipelines, by having mono-project.com run > on the Mono stack > > And that's just what comes to mind right now. (SWF, ASP.NET 2.0, and > finishing the existing APIs go without saying.) There are a lot of parts > of Mono that I've never even touched that I'm sure have unpolished > aspects too. There's no contradiction here. A lot of unfinished API, including CAS related classes, would need to be completed, tested and audited for Moonlight. We are too thin to focus on the whole Fx simultaneously, but defining a subset (like we do today when fixing 1.x before adding 2.0 stuff) will "shine" thru every Mono profiles. > Anyway, I'm definitely of the mentality that if you want something done > in an open source project that's not getting done, you should do it > yourself. So I'm not trying to sound like I have expectations that all > of these things should somehow magically just get done. > > OTOH, since there are people being paid to work on Mono, it doesn't hurt > to suggest what I think their priorities should involve---namely, > polishing existing parts of the project. True. Most of us works where contributions are scarce (check libgdiplus ChangeLogs ;-) > And, besides that, before Mono hackers get too involved with an entirely > new API that may very well flop, I think it would be useful to consider > whether there are existing parts of the project that need polishing that > you'd also enjoy working on. Thi