From robertj at gmx.net Sun Apr 1 08:37:46 2007 From: robertj at gmx.net (Robert Jordan) Date: Sun, 01 Apr 2007 14:37:46 +0200 Subject: [Mono-dev] completionPortThreads in threadpool.c not used? In-Reply-To: <460F2133.8090205@wsu.edu> References: <460F2133.8090205@wsu.edu> Message-ID: John Hurliman wrote: > I'm writing a UDP client that attempts to detect when there are no more > available threads in the ThreadPool for doing packet processing with > Begin/EndReceiveFrom(), and I noticed in > http://svn.myrealbox.com/viewcvs/trunk/mono/mono/metadata/threadpool.c?rev=73042&view=markup > that the completionPortThread argument is always set to zero or not used > in all of the static ThreadPool members. Does Mono handle things > differently, and how can I find out if there are available threads to > process additional packets? I was going to ask about the status of > ThreadPool.SetMaxThreads but it may not be relevant if Mono is not using > the completionPortThread argument. > > John Hurliman > libsecondlife Developer (http://www.libsecondlife.org/) The required infos are already available but they were not exposed by ThreadPool.GetMin|MaxThreads and SetMaxThreads was not implemented. The attached patches should fix that (up to the MonoTODO issues). Robert -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ThreadPool.cs.diff Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070401/a16ef941/attachment.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: threadpool.c.diff Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070401/a16ef941/attachment-0001.pl From bonsouere at gmail.com Sun Apr 1 11:28:51 2007 From: bonsouere at gmail.com (Matthieu =?iso-8859-15?q?Barth=E9lemy?=) Date: Sun, 1 Apr 2007 17:28:51 +0200 Subject: [Mono-dev] completionPortThreads in threadpool.c not used? In-Reply-To: References: <460F2133.8090205@wsu.edu> Message-ID: <200704011728.51929.bonsouere@gmail.com> Hello, On Sunday 01 April 2007 14:37, Robert Jordan wrote: > The required infos are already available but they were not exposed > by ThreadPool.GetMin|MaxThreads and SetMaxThreads was not implemented. > > The attached patches should fix that (up to the MonoTODO issues). Wow... I was prepairing exactly the same patch today, it would have been my first Mono contribution... Next time I'll be faster, thinking that somebody else could just be doing the same thing :-) Matt From robertj at gmx.net Sun Apr 1 11:45:52 2007 From: robertj at gmx.net (Robert Jordan) Date: Sun, 01 Apr 2007 17:45:52 +0200 Subject: [Mono-dev] completionPortThreads in threadpool.c not used? In-Reply-To: <200704011728.51929.bonsouere@gmail.com> References: <460F2133.8090205@wsu.edu> <200704011728.51929.bonsouere@gmail.com> Message-ID: Matthieu Barth?lemy wrote: > Hello, > > On Sunday 01 April 2007 14:37, Robert Jordan wrote: >> The required infos are already available but they were not exposed >> by ThreadPool.GetMin|MaxThreads and SetMaxThreads was not implemented. >> >> The attached patches should fix that (up to the MonoTODO issues). > Wow... I was prepairing exactly the same patch today, it would have been my > first Mono contribution... Next time I'll be faster, thinking that somebody > else could just be doing the same thing :-) ... and I forgot attach half of the patch: the icall defs ;-) Robert -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SetMinThreads-icall.diff Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070401/e5441e50/attachment.pl From jhurliman at wsu.edu Sun Apr 1 18:16:36 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sun, 01 Apr 2007 15:16:36 -0700 Subject: [Mono-dev] completionPortThreads in threadpool.c not used? In-Reply-To: References: <460F2133.8090205@wsu.edu> <200704011728.51929.bonsouere@gmail.com> Message-ID: <46102F44.70302@wsu.edu> Robert Jordan wrote: > Matthieu Barth?lemy wrote: >> Hello, >> >> On Sunday 01 April 2007 14:37, Robert Jordan wrote: >>> The required infos are already available but they were not exposed >>> by ThreadPool.GetMin|MaxThreads and SetMaxThreads was not implemented. >>> >>> The attached patches should fix that (up to the MonoTODO issues). >> Wow... I was prepairing exactly the same patch today, it would have >> been my first Mono contribution... Next time I'll be faster, thinking >> that somebody else could just be doing the same thing :-) > > ... and I forgot attach half of the patch: the icall defs ;-) > > Robert That is great, thank you for the patch. I will look in to compiling Mono myself with this patch merged in which should make my own server run well, but the other users of our library (libsecondlife, http://www.libsecondlife.org/) will likely have to wait until this makes it in to svn or a release. I know the 1.2.3 release wasn't too long ago, is there a timeline on pushing out the next release? John Hurliman From lupus at ximian.com Mon Apr 2 06:08:17 2007 From: lupus at ximian.com (Paolo Molaro) Date: Mon, 2 Apr 2007 12:08:17 +0200 Subject: [Mono-dev] completionPortThreads in threadpool.c not used? In-Reply-To: References: <460F2133.8090205@wsu.edu> <200704011728.51929.bonsouere@gmail.com> Message-ID: <20070402100817.GK7975@debian.org> On 04/01/07 Robert Jordan wrote: > --- mono/metadata/icall-def.h (revision 72713) > +++ mono/metadata/icall-def.h (working copy) > @@ -804,6 +804,7 @@ > ICALL(THREADP_2, "GetMaxThreads", ves_icall_System_Threading_ThreadPool_GetMaxThreads) > ICALL(THREADP_3, "GetMinThreads", ves_icall_System_Threading_ThreadPool_GetMinThreads) > ICALL(THREADP_4, "SetMinThreads", ves_icall_System_Threading_ThreadPool_SetMinThreads) > +ICALL(THREADP_5, "SetMaxThreads", ves_icall_System_Threading_ThreadPool_SetMaxThreads) Did you test this? It should warn about the wrong alphabetic order of the icalls? lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Mon Apr 2 06:12:12 2007 From: lupus at ximian.com (Paolo Molaro) Date: Mon, 2 Apr 2007 12:12:12 +0200 Subject: [Mono-dev] Porting runtime - where to start? In-Reply-To: <1175343288.460e50b806e89@imp.free.fr> References: <1175288498.460d7ab22559a@imp.free.fr> <1175291637.7270.95.camel@mirrors.mathematik.uni-bielefeld.de> <1175343288.460e50b806e89@imp.free.fr> Message-ID: <20070402101212.GL7975@debian.org> On 03/31/07 virgile.bello at free.fr wrote: > The problem of AOT is that it only generates .so (or .dll on Win32 platform I > guess). Nevertheless, XBOX executable format, .xex, has to go through their > special compilator. So, no other way that I know than getting C++ code to > compile. Don't they provide some tool to create an executable from assembly code? If that is possible you could tweak the code to use that. Or, if the file format is documented or easy to understand, you could change the binary writer AOT code to emit it directly. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Mon Apr 2 06:28:16 2007 From: lupus at ximian.com (Paolo Molaro) Date: Mon, 2 Apr 2007 12:28:16 +0200 Subject: [Mono-dev] Porting runtime - where to start? In-Reply-To: <1175288498.460d7ab22559a@imp.free.fr> References: <1175288498.460d7ab22559a@imp.free.fr> Message-ID: <20070402102816.GM7975@debian.org> On 03/30/07 virgile.bello at free.fr wrote: > Just to let you know since I did something very similiar for XBOX360 : > Even if I was able to make glib and then mono compile on XBOX360 (it was a bit > painful but doable) and it generated valid code to execute at runtime, > nevertheless memory protection against execution of user allocated area totally > prevented me to continue (you can check the blog post I did about that on > http://dev.kalimdor.org/entropia/). Was anyone able to determine if the old XBOX (x86) emulator or the xbox 360 CLR runtime do any jitting? It would be very surprising if they didn't do it and if they did, the European Commission is very likely interested in how they do it (hint, hint:-). In the blob you talk about the xbox 360 changes and about a mono debugger. Can you tell us more about that? Are you able to contribute those changes for inclusion in mono? Thanks! lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Mon Apr 2 10:53:45 2007 From: lupus at ximian.com (Paolo Molaro) Date: Mon, 2 Apr 2007 16:53:45 +0200 Subject: [Mono-dev] Need help tracking this bug... In-Reply-To: <117799f00703291852j56448cb4y77721e5cc33937c5@mail.gmail.com> References: <117799f00703290912p7eacb88fp26f061642594385e@mail.gmail.com> <117799f00703291840i6bd67234oe7f7235155043c21@mail.gmail.com> <117799f00703291852j56448cb4y77721e5cc33937c5@mail.gmail.com> Message-ID: <20070402145345.GN7975@debian.org> On 03/30/07 Alan McGovern wrote: > type=System.MonoType 2826 542.8M 201403.8 0.6 > > Half a gigabyte of System.MonoType's? What causes these to be allocated, and > what can i do to stop this? That data must be incorrect. MonoType is fixed-size (16 bytes on 32 bit systems), so the data is inconsistent. Having 2826 instances is reasonable (though it's a hint that you or somebody else is doing GeTypes() on the assemblies and that should be avoided). The 543 MB for MonoType is totally bogus. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From a_grigonis at mail333.com Mon Apr 2 12:40:40 2007 From: a_grigonis at mail333.com (Aurimas) Date: 02 Apr 2007 18:40:40 +0200 Subject: [Mono-dev] (no subject) Message-ID: <1175532039.2599.6.camel@incognito.incognito> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070402/8a58924a/attachment.html From miguel at novell.com Mon Apr 2 12:11:26 2007 From: miguel at novell.com (Miguel de Icaza) Date: Mon, 02 Apr 2007 12:11:26 -0400 Subject: [Mono-dev] System.Net.NetworkInformation.Ping In-Reply-To: <1174952787.21840.100.camel@melchior.magi> References: <200703250157.07719.bonsouere@gmail.com> <1174803297.5469.218.camel@mirrors.mathematik.uni-bielefeld.de> <1174952787.21840.100.camel@melchior.magi> Message-ID: <1175530286.6955.117.camel@mirrors.mathematik.uni-bielefeld.de> Hello, > > We do not have plans of implementing the Ping method at this point. On > > Unix issuing Ping requires root privileges. For making this work, we > > would have to write a setuid program and launch it every time this call > > is made. > > Couldn't we just create a System.Diagnostics.Process instance > around /bin/ping (which is already setuid root) and interpret the > output? Ping arguments and output vary from OS to OS. But if someone wants to do it, we are taking patches. Miguel. From joncham at gmail.com Mon Apr 2 14:12:18 2007 From: joncham at gmail.com (Jonathan Chambers) Date: Mon, 2 Apr 2007 14:12:18 -0400 Subject: [Mono-dev] COM Interop Remoting Patch Message-ID: <17c2d80b0704021112u55858afepb642538814811f65@mail.gmail.com> 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. This patch allows anyone one using COM Interop to remote those objects. This obviously would be much more likely to occur on windows, but an example use of this on other platforms would be accessing the Mozilla DOM cross process in the ASP.Net designer. Code is contributed under MIT/X11 license. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070402/bb5b5fce/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: remoting_cominterop.diff Type: text/x-patch Size: 17331 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070402/bb5b5fce/attachment.bin From virgile.bello at free.fr Mon Apr 2 21:49:10 2007 From: virgile.bello at free.fr (virgile.bello at free.fr) Date: Tue, 03 Apr 2007 03:49:10 +0200 Subject: [Mono-dev] Porting runtime - where to start? In-Reply-To: <20070402101212.GL7975@debian.org> References: <1175288498.460d7ab22559a@imp.free.fr> <1175291637.7270.95.camel@mirrors.mathematik.uni-bielefeld.de> <1175343288.460e50b806e89@imp.free.fr> <20070402101212.GL7975@debian.org> Message-ID: <1175564950.4611b2965920b@imp.free.fr> Quoting Paolo Molaro : > On 03/31/07 virgile.bello at free.fr wrote: > > The problem of AOT is that it only generates .so (or .dll on Win32 platform > I > > guess). Nevertheless, XBOX executable format, .xex, has to go through their > > special compilator. So, no other way that I know than getting C++ code to > > compile. > > Don't they provide some tool to create an executable from assembly code? > If that is possible you could tweak the code to use that. > Or, if the file format is documented or easy to understand, you could > change the binary writer AOT code to emit it directly. > > lupus Ok, I took a look at all that. There is a tool to convert PE executable (with PPC code) in their .xex format. However, there were issues : 1/ AOT is working only on x86 right now, according to http://tirania.org/blog/archive/2006/Aug-17.html 2/ And even if it's ok, the more important problem is that according to the same post, it still need JIT at some place. 3/ When working on it, I tried to produce PE file with PE PPC Big endian target with binutils, and it was really painful, it's not really supported anymore (I speak of PE format only of course, it's well supported in other cases). From virgile.bello at free.fr Mon Apr 2 21:56:09 2007 From: virgile.bello at free.fr (virgile.bello at free.fr) Date: Tue, 03 Apr 2007 03:56:09 +0200 Subject: [Mono-dev] Porting runtime - where to start? In-Reply-To: <20070402102816.GM7975@debian.org> References: <1175288498.460d7ab22559a@imp.free.fr> <20070402102816.GM7975@debian.org> Message-ID: <1175565369.4611b439303e4@imp.free.fr> Quoting Paolo Molaro : > On 03/30/07 virgile.bello at free.fr wrote: > > Just to let you know since I did something very similiar for XBOX360 : > > Even if I was able to make glib and then mono compile on XBOX360 (it was a > bit > > painful but doable) and it generated valid code to execute at runtime, > > nevertheless memory protection against execution of user allocated area > totally > > prevented me to continue (you can check the blog post I did about that on > > http://dev.kalimdor.org/entropia/). > > Was anyone able to determine if the old XBOX (x86) emulator or the xbox > 360 CLR runtime do any jitting? It would be very surprising if they > didn't do it and if they did, the European Commission is very likely > interested in how they do it (hint, hint:-). I think the XBOX 360 CLR runtime does JITing, but well, Microsoft got a better access to console internal than us. > > In the blob you talk about the xbox 360 changes and about a mono > debugger. Can you tell us more about that? Are you able to contribute > those changes for inclusion in mono? > Thanks! > > lupus The XBOX360 changes are pointless since it seems not possible to make it working. About the debugger, it's more a prototype right now, but I will probably work on it again if the code to get my monobind wrapper working is included in mono source tree (I posted the patch at http://lists.ximian.com/pipermail/mono-devel-list/2007-March/022949.html, I dunno if it was the right place for that). Nevertheless, if it never happens, I might drop the sources of that prototype as a base (I nearly managed to do singlestepping and variable inspection with class definition extracted from runtime context). From guus.leeuw at guusleeuwit.com Tue Apr 3 01:13:58 2007 From: guus.leeuw at guusleeuwit.com (Guus Leeuw jr.) Date: Tue, 3 Apr 2007 06:13:58 +0100 Subject: [Mono-dev] Mod-mono & XSP from SVN: different versions. Message-ID: Hiya, I?m trying to bind XPS2 into Apache, having problems with the different versions between mod-mono-server2 and xsp2. Now, running xps2 by hand works nicely for my application, so the problem was not that. Then I tried mod-mono-server2 by hand, and voila, the report comes: ?mod_mono and xsp have different versions.?? Looking at xsp/src/ModMonoRequest.cs, this comes because in GetInitialData() the first byte read is not 6. The big questions is: How come it should be 6, and where is getting set to 6? (I am more than willing to patch this for svn, but then again, I?m not sure how mod_mono and xsp work together? (XSP by itself comes to pass this ?awkward? check ;)) Regards, Guus -- No virus found in this outgoing message. Checked by AVG. Version: 7.5.448 / Virus Database: 268.18.24/742 - Release Date: 01/04/2007 20:49 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070403/682e2c7f/attachment.html From lupus at ximian.com Tue Apr 3 05:11:40 2007 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 3 Apr 2007 11:11:40 +0200 Subject: [Mono-dev] Porting runtime - where to start? In-Reply-To: <1175564950.4611b2965920b@imp.free.fr> References: <1175288498.460d7ab22559a@imp.free.fr> <1175291637.7270.95.camel@mirrors.mathematik.uni-bielefeld.de> <1175343288.460e50b806e89@imp.free.fr> <20070402101212.GL7975@debian.org> <1175564950.4611b2965920b@imp.free.fr> Message-ID: <20070403091140.GU7975@debian.org> On 04/03/07 virgile.bello at free.fr wrote: > There is a tool to convert PE executable (with PPC code) in their .xex format. > However, there were issues : > 1/ AOT is working only on x86 right now, according to > http://tirania.org/blog/archive/2006/Aug-17.html It also works on amd64. support for ppc would need to be added, but it is not a big issue. > 2/ And even if it's ok, the more important problem is that according to the same > post, it still need JIT at some place. Yes: we'd need a few changes to avoid jitting at all, but it is doable. > 3/ When working on it, I tried to produce PE file with PE PPC Big endian target > with binutils, and it was really painful, it's not really supported anymore (I > speak of PE format only of course, it's well supported in other cases). Currently the PE format would be generated by the assembler/linker. You'd need to write some code to be able to generate directly the PE binary file. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From jamie.cansdale at testdriven.net Tue Apr 3 05:40:26 2007 From: jamie.cansdale at testdriven.net (Jamie Cansdale) Date: Tue, 3 Apr 2007 10:40:26 +0100 Subject: [Mono-dev] ANN: TestDriven.NET 2.5 Beta + Visual Studio Express In-Reply-To: <583d4c740704030237u1df8be8co30a86f9486505834@mail.gmail.com> References: <583d4c740704030237u1df8be8co30a86f9486505834@mail.gmail.com> Message-ID: <583d4c740704030240n4c1532a1l63c525ccef9b6aed@mail.gmail.com> Hi Folks, I have just released a version of TestDriven.NET that works with the Visual Studio 2005 Express Editions. It has been tested with C#, VB, C++ and J# Express. For more information about using this feature, please read the following post: http://weblogs.asp.net/nunitaddin/archive/2007/04/02/express-sku-support.aspx This version comes packaged with NUnit 2.4 Final and NUnit 2.2.10. If you have Mono installed a 'Test With... Mono' option will appear. This has been confirmed to work with Mono 1.2.3 and should work with future versions. Best regards, Jamie. -- http://www.testdriven.net http://weblogs.asp.net/nunitaddin From virgile.bello at free.fr Tue Apr 3 06:24:28 2007 From: virgile.bello at free.fr (virgile.bello at free.fr) Date: Tue, 03 Apr 2007 12:24:28 +0200 Subject: [Mono-dev] Porting runtime - where to start? In-Reply-To: <20070403091140.GU7975@debian.org> References: <1175288498.460d7ab22559a@imp.free.fr> <1175291637.7270.95.camel@mirrors.mathematik.uni-bielefeld.de> <1175343288.460e50b806e89@imp.free.fr> <20070402101212.GL7975@debian.org> <1175564950.4611b2965920b@imp.free.fr> <20070403091140.GU7975@debian.org> Message-ID: <1175595868.46122b5c82d48@imp.free.fr> Quoting Paolo Molaro : > On 04/03/07 virgile.bello at free.fr wrote: > > There is a tool to convert PE executable (with PPC code) in their .xex > format. > > However, there were issues : > > 1/ AOT is working only on x86 right now, according to > > http://tirania.org/blog/archive/2006/Aug-17.html > > It also works on amd64. support for ppc would need to be added, but it > is not a big issue. > > > 2/ And even if it's ok, the more important problem is that according to the > same > > post, it still need JIT at some place. > > Yes: we'd need a few changes to avoid jitting at all, but it is doable. It would really be nice ! Don't hesitate to let me know as soon as those two points are done and I'll give it a try. > > > 3/ When working on it, I tried to produce PE file with PE PPC Big endian > target > > with binutils, and it was really painful, it's not really supported anymore > (I > > speak of PE format only of course, it's well supported in other cases). > > Currently the PE format would be generated by the assembler/linker. > You'd need to write some code to be able to generate directly the PE > binary file. Yep, anyway I think code is more or less done, it would just require some time to reactivate it. ReactOS project could be of some help here as they did the same thing (they had a binutils patch for ppc-pe). From lupus at ximian.com Tue Apr 3 06:00:41 2007 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 3 Apr 2007 12:00:41 +0200 Subject: [Mono-dev] Porting runtime - where to start? In-Reply-To: <1175565369.4611b439303e4@imp.free.fr> References: <1175288498.460d7ab22559a@imp.free.fr> <20070402102816.GM7975@debian.org> <1175565369.4611b439303e4@imp.free.fr> Message-ID: <20070403100041.GV7975@debian.org> On 04/03/07 virgile.bello at free.fr wrote: > > Was anyone able to determine if the old XBOX (x86) emulator or the xbox > > 360 CLR runtime do any jitting? It would be very surprising if they > > didn't do it and if they did, the European Commission is very likely > > interested in how they do it (hint, hint:-). > > I think the XBOX 360 CLR runtime does JITing, but well, Microsoft got a better > access to console internal than us. Sure, that's a good reason for the European commission to investigate why they still adopt anti-competitive practices. If they do jitting, other people developing for the platform should be allowed to have the info do it as well. Hopefully the game industry will pressure them as well. > The XBOX360 changes are pointless since it seems not possible to make it > working. There is definitely interest and it is likely possible to make it work using the AOT backend and the PE file converter you mentioned, so I don't think the changes are pointless: they will enable other interested people to help you with your efforts. If you have other reasons that prevent you from contributing the code that's understandable. > About the debugger, it's more a prototype right now, but I will probably work on > it again if the code to get my monobind wrapper working is included in mono > source tree (I posted the patch at > http://lists.ximian.com/pipermail/mono-devel-list/2007-March/022949.html, I > dunno if it was the right place for that). I'll review it in a bit, I was on vacation the last few days. > Nevertheless, if it never happens, I might drop the sources of that prototype as > a base (I nearly managed to do singlestepping and variable inspection with class > definition extracted from runtime context). Did you check the mono*describe* functions in metadata/class-internals.h? lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From lupus at ximian.com Tue Apr 3 06:31:04 2007 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 3 Apr 2007 12:31:04 +0200 Subject: [Mono-dev] MonoBind - C++ bindings library [include Mono Patch] In-Reply-To: <1175117088.460add207e145@imp.free.fr> References: <1175117088.460add207e145@imp.free.fr> Message-ID: <20070403103104.GW7975@debian.org> On 03/28/07 virgile.bello at free.fr wrote: > As I worked on a C++ binding library for mono, very close to > boost::python/luabind syntax, I had few minor modification to do in Mono > sources. The patch is attached. > > I was wondering if it was possible to include them in mono. > The missing thing was the possibility to bind a pointer argument to an internal > call. It is required in order to make all the C++ wrapper/proxy statically > linked through template metaprogramming. [...] > Later, I would like the registration code to auto-generate C# header. I think auto-generation is the only option, unless this is supposed to be used for very few classes. Anyway, I took a look at the code, but I don't see a reason why the core of mono would need changes for this, you can do it all without any mono changes. What you basically are doing is that, given a icall method declaration, to actually call a function with a different signature. Why not use the correct signature in the first place? [C code (or C-representation of the C++ ABI?)] void icall (void *this_ptr, void *hidden_arg, int a); [Old C# code: mono core changes needed because the signature is incorrect] [MethodImplAttribute(MethodImplOptions.InternalCall)] extern public void Test (int a); [New C# code: no core mono changes needed] [MethodImplAttribute(MethodImplOptions.InternalCall)] extern void Test (IntPtr hidden_arg, int a); static readonly IntPtr Test_hidden_arg; public void Test (int a) { Test (Test_hidden_arg, a); } And you will initialize Test_hidden_arg as part of the binding startup code with the embedding API or even with an icall in C#: static readonly IntPtr Test_hidden_arg = MonoBind.CreateSig ("vi"); where "vi" means void for the return type and i is the first argument of type int, though there are also other options, like (using params arrays): static readonly IntPtr Test_hidden_arg = MonoBind.CreateSig (null, typeof (int)); This makes it much more flexible and also much easier to deal with if you automatically generate the C# side. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From virgile.bello at free.fr Tue Apr 3 06:42:43 2007 From: virgile.bello at free.fr (virgile.bello at free.fr) Date: Tue, 03 Apr 2007 12:42:43 +0200 Subject: [Mono-dev] Porting runtime - where to start? In-Reply-To: <20070403100041.GV7975@debian.org> References: <1175288498.460d7ab22559a@imp.free.fr> <20070402102816.GM7975@debian.org> <1175565369.4611b439303e4@imp.free.fr> <20070403100041.GV7975@debian.org> Message-ID: <1175596963.46122fa302e00@imp.free.fr> Quoting Paolo Molaro : > On 04/03/07 virgile.bello at free.fr wrote: > > > Was anyone able to determine if the old XBOX (x86) emulator or the xbox > > > 360 CLR runtime do any jitting? It would be very surprising if they > > > didn't do it and if they did, the European Commission is very likely > > > interested in how they do it (hint, hint:-). > > > > I think the XBOX 360 CLR runtime does JITing, but well, Microsoft got a > better > > access to console internal than us. > > Sure, that's a good reason for the European commission to investigate > why they still adopt anti-competitive practices. If they do jitting, > other people developing for the platform should be allowed to have the > info do it as well. Hopefully the game industry will pressure them as > well. By the way, I sent yesterday a mail to MS in that sense. But well, we all know how it will end :) > > > The XBOX360 changes are pointless since it seems not possible to make it > > working. > > There is definitely interest and it is likely possible to make it work > using the AOT backend and the PE file converter you mentioned, so I > don't think the changes are pointless: they will enable other interested > people to help you with your efforts. If you have other reasons that > prevent you from contributing the code that's understandable. > No, that's no problem for me to release it (still it would need some polishing before doing so). However, I also had to port glibc first, so it's kinda messy. What I dont know is if it's legal to release code using this xdk, since it's not available for public... (even headers). I'll ask and let you know. > > About the debugger, it's more a prototype right now, but I will probably > work on > > it again if the code to get my monobind wrapper working is included in mono > > source tree (I posted the patch at > > http://lists.ximian.com/pipermail/mono-devel-list/2007-March/022949.html, I > > dunno if it was the right place for that). > > I'll review it in a bit, I was on vacation the last few days. > > > Nevertheless, if it never happens, I might drop the sources of that > prototype as > > a base (I nearly managed to do singlestepping and variable inspection with > class > > definition extracted from runtime context). > > Did you check the mono*describe* functions in > metadata/class-internals.h? Yes, that's what I use if I remember right. Introspection is done with mono api itself (and that's why it is nice ! ;p). From virgile.bello at free.fr Tue Apr 3 06:47:49 2007 From: virgile.bello at free.fr (virgile.bello at free.fr) Date: Tue, 03 Apr 2007 12:47:49 +0200 Subject: [Mono-dev] MonoBind - C++ bindings library [include Mono Patch] In-Reply-To: <20070403103104.GW7975@debian.org> References: <1175117088.460add207e145@imp.free.fr> <20070403103104.GW7975@debian.org> Message-ID: <1175597269.461230d573f40@imp.free.fr> Quoting Paolo Molaro : > On 03/28/07 virgile.bello at free.fr wrote: > > As I worked on a C++ binding library for mono, very close to > > boost::python/luabind syntax, I had few minor modification to do in Mono > > sources. The patch is attached. > > > > I was wondering if it was possible to include them in mono. > > The missing thing was the possibility to bind a pointer argument to an > internal > > call. It is required in order to make all the C++ wrapper/proxy statically > > linked through template metaprogramming. > [...] > > Later, I would like the registration code to auto-generate C# header. > > I think auto-generation is the only option, unless this is supposed to > be used for very few classes. > > Anyway, I took a look at the code, but I don't see a reason why the core > of mono would need changes for this, you can do it all without any > mono changes. > What you basically are doing is that, given a icall method declaration, > to actually call a function with a different signature. Why not use the > correct signature in the first place? > > [C code (or C-representation of the C++ ABI?)] > void icall (void *this_ptr, void *hidden_arg, int a); > > [Old C# code: mono core changes needed because the signature is incorrect] > [MethodImplAttribute(MethodImplOptions.InternalCall)] > extern public void Test (int a); > > [New C# code: no core mono changes needed] > [MethodImplAttribute(MethodImplOptions.InternalCall)] > extern void Test (IntPtr hidden_arg, int a); > > static readonly IntPtr Test_hidden_arg; > > public void Test (int a) { > Test (Test_hidden_arg, a); > } > > And you will initialize Test_hidden_arg as part of the binding startup > code with the embedding API or even with an icall in C#: > > static readonly IntPtr Test_hidden_arg = MonoBind.CreateSig ("vi"); > > where "vi" means void for the return type and i is the first argument of > type int, though there are also other options, like (using params arrays): > > static readonly IntPtr Test_hidden_arg = MonoBind.CreateSig (null, typeof > (int)); > > This makes it much more flexible and also much easier to deal with if > you automatically generate the C# side. Yes you're right, that's the first approach I took. It's just I felt it was cleaner to do it the other way. But well, since those definitions are auto-generated I suppose it's not a big deal doubling everything. Thanks for the review. From dban at dako.ro Tue Apr 3 10:06:31 2007 From: dban at dako.ro (dban at dako.ro) Date: Tue, 03 Apr 2007 17:06:31 +0300 Subject: [Mono-dev] Problems with the Session_end event Message-ID: <1175609191.46125f67ed50b@webmail.dako.ro> Hello, I'm having problems with the Session_End event being raised multiple times for the same sessionID. I've also reported a bug related to this issue, bug #81140. Can anybody help me with this? I would work on the problem, but I don't know where to start. Some ideas would be appreciated. Thanks. From dban at dako.ro Tue Apr 3 10:25:38 2007 From: dban at dako.ro (dban at dako.ro) Date: Tue, 03 Apr 2007 17:25:38 +0300 Subject: [Mono-dev] ChangePassword patch Message-ID: <1175610338.461263e2edaad@webmail.dako.ro> Hello, Attached is a patch for ChangePassword control. The ProcessChangePasswordEvent is calling MembershipProviderInternal.ChangePassword method which is throwing ArgumentException in different situations - "Password too short", "Password does not match regular expresion" etc. Instead of allowing the exception to propagate, the ProcessChangePasswordEvent should catch it, call the OnChangePasswordError and set the failure message according to the exception message. Best regards, Dumi. -------------- next part -------------- A non-text attachment was scrubbed... Name: ChangePassword_75341.patch Type: text/x-patch Size: 2052 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070403/a81aa695/attachment.bin From joelwreed at gmail.com Tue Apr 3 22:09:43 2007 From: joelwreed at gmail.com (joel reed) Date: Tue, 03 Apr 2007 22:09:43 -0400 Subject: [Mono-dev] [PATCH] ActiveDirectoryMembershipProvider Message-ID: <461308E7.8070608@gmail.com> The patch below enhances the usefulness of ActiveDirectoryMembershipProvider under mono, but may not be acceptable for inclusion in svn. I'm posting this in case some one else runs into a similar problem as I encountered. We have a Membership Provider that derives from ActiveDirectoryMembershipProvider and then overrides Initialize and ValidateUser. Our ValidateUser method looks in web.config and either does an validation against AD or our legacy authentication scheme. This works on mono (if configured to not use AD), as long as the Initialize method in ActiveDirectoryMembershipProvider calls base.Initialize. Calling base.Initialize is important as this is how ProviderBase sets the Name property which lets the Provider be put into a ProviderCollection. Without the Name, Adding the provider to the collection fails with a ArgumentNullException. Currently ActiveDirectoryMembershipProvider just does a "throw NotImplemented". If instead we said: mcs/class/System.Web/System.Web.Security/ActiveDirectoryMembershipProvider.cs.orig 2007-04-03 20:59:32.000000000 -0400 +++ mcs/class/System.Web/System.Web.Security/ActiveDirectoryMembershipProvider.cs 2007-04-03 20:59:50.000000000 -0400 @@ -118,7 +118,7 @@ namespace System.Web.Security { [MonoTODO("Not implemented")] public override void Initialize (string name, NameValueCollection config) { - throw new NotImplementedException (); + base.Initialize(name, config); } [MonoTODO("Not implemented")] The class would be slightly more useful in the above scenario. Probably this circumvents some policy about MonoTODOs, but again just want to post this info somewhere for others to google. It might even improve things just by calling base.Initialize and then throwing, as you could catch that exception and still be in business. Thoughts? jr From cjcollier at colliertech.org Wed Apr 4 01:12:13 2007 From: cjcollier at colliertech.org (C.J. Adams-Collier) Date: Tue, 03 Apr 2007 22:12:13 -0700 Subject: [Mono-dev] prebuild review Message-ID: <1175663533.8673.8.camel@cjcoll-laptop> Hey all, Could someone with spare time do a review on the diff between the trunk of dnpb/Prebuild and dnpb/Prebuild-cjac? I think I'm ready to merge my changes into trunk. The code's not pretty, but it works and most of the use cases have been tested. I expect I'll gag when I actually learn xslt and come back to look at this, but as I said, it's working. http://dnpb.svn.sourceforge.net/svnroot/dnpb/branches/Prebuild/ vs http://dnpb.svn.sourceforge.net/svnroot/dnpb/branches/Prebuild-cjac/ This is a nearly complete re-write of the Autotools target which is used to create an autotools build system from a prebuild.xml file and associated sources, assemblies, icons, resources, etc. The two major files that need review are these: http://dnpb.svn.sourceforge.net/svnroot/dnpb/branches/Prebuild-cjac/src/Core/Targets/AutotoolsTarget.cs and http://dnpb.svn.sourceforge.net/svnroot/dnpb/branches/Prebuild-cjac/src/data/autotools.xml The former is used to create the autotools directory layout, copy associated files, and gather the information needed to generate the various autotools files including: solution/autogen.sh solution/configure.ac solution/Makefile.am solution/project/autogen.sh solution/project/configure.ac solution/project/Makefile.am solution/project/project.in solution/project/autogen.pc.in The latter is a set of xslt templates that are filled in by the former. Cheers, C.J. From martin at ximian.com Wed Apr 4 07:06:37 2007 From: martin at ximian.com (Martin Baulig) Date: Wed, 04 Apr 2007 13:06:37 +0200 Subject: [Mono-dev] [PATCH] mdb, frame selection using f command In-Reply-To: <69f7d8470703290205h26bc27e9meda68b4de0b537f2@mail.gmail.com> References: <69f7d8470703271420y69e3c4a8r8fafb8bf6d3f9909@mail.gmail.com> <1175033849.5469.502.camel@mirrors.mathematik.uni-bielefeld.de> <1175087837.6241.21.camel@gondor.trier.ximian.com> <69f7d8470703290205h26bc27e9meda68b4de0b537f2@mail.gmail.com> Message-ID: <1175684797.3577.10.camel@gondor.trier.ximian.com> Hi, your patch was incorrect since it didn't solve the underlying problem: recomputing the backtrace when it's not necessary to do so. I fixed that in SVN. Martin On Thu, 2007-03-29 at 11:05 +0200, Jb Evain wrote: > Hi Martin, > > On 3/28/07, Martin Baulig wrote: > > > > Btw, it seems that when the "bt" command is used, the current frame is > > > > re-initialized to 0, is it the desired behavior? > > > > > > Sounds like an unintended side effect. > > > > No, there's a reason for that: the `bt' command computes a new backtrace > > so your current frame is gone after that. > > > > We can change that to check whether we already have a backtrace and only > > reset the frame when we compute a new one. > > Here is a patch not to change the current frame when the ?bt? command > is used. Let me know if it's ok to go in, or if there is a better way > to achieve this. > > Jb -- Martin Baulig - martin at novell.com Novell GmbH, D?sseldorf GF: Volker Smid, Djamel Souici; HRB 21108 (AG D?sseldorf) From js at hotfeet.ch Wed Apr 4 09:10:25 2007 From: js at hotfeet.ch (Juraj Skripsky) Date: Wed, 04 Apr 2007 15:10:25 +0200 Subject: [Mono-dev] [PATCH] Regression in System.Web.Security.FormsAuthenticationModule Message-ID: <1175692225.3039.62.camel@leonardo.hotfeet.ch> Hello, The follow commit caused a regression in NET_1_1: Session_End in global.asax is never called. The cause is an NullReferenceException in FormsAuthenticationModule.Init() as "app.Context" is null (only in this method and only when a session is about to be terminated). 2007-03-21 Vladimir Krasnov * FormsAuthenticationModule.cs: refactored configuration section to be a member of a class My patch moves the initialization of _config out of the Init method. Please review. - Juraj -------------- next part -------------- A non-text attachment was scrubbed... Name: FormsAuthenticationModule.patch Type: text/x-patch Size: 1511 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070404/4aa2a4e6/attachment.bin From js at hotfeet.ch Wed Apr 4 09:25:32 2007 From: js at hotfeet.ch (Juraj Skripsky) Date: Wed, 04 Apr 2007 15:25:32 +0200 Subject: [Mono-dev] [PATCH] Regression in System.Web.Security.FormsAuthenticationModule In-Reply-To: <1175692225.3039.62.camel@leonardo.hotfeet.ch> References: <1175692225.3039.62.camel@leonardo.hotfeet.ch> Message-ID: <1175693132.3039.64.camel@leonardo.hotfeet.ch> I was stupid enough to make a few last-second changes. Sorry about that, the attached patch now actually compiles and works. On Wed, 2007-04-04 at 15:10 +0200, Juraj Skripsky wrote: > Hello, > > The follow commit caused a regression in NET_1_1: Session_End in > global.asax is never called. The cause is an NullReferenceException in > FormsAuthenticationModule.Init() as "app.Context" is null (only in this > method and only when a session is about to be terminated). > > 2007-03-21 Vladimir Krasnov > > * FormsAuthenticationModule.cs: refactored configuration section to be > a member of a class > > > My patch moves the initialization of _config out of the Init method. > > Please review. > > - Juraj -------------- next part -------------- A non-text attachment was scrubbed... Name: FormsAuthenticationModule.patch Type: text/x-patch Size: 1525 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070404/dac24100/attachment.bin From js at hotfeet.ch Wed Apr 4 10:10:47 2007 From: js at hotfeet.ch (Juraj Skripsky) Date: Wed, 04 Apr 2007 16:10:47 +0200 Subject: [Mono-dev] [PATCH] System.Web.HttpApplicationFactory: App_End in global.asax called multiple times Message-ID: <1175695847.3039.74.camel@leonardo.hotfeet.ch> Hello, Most of the time, Application_End in global.asax is called multiple times for a single ending application. The problem is in HttpApplicationFactory.OnFileChanged: the lock guards the method against multiple _concurrent_ shutdowns only. It can still execute multiple times sequentially (FileSystemWatcher emits multiple events when global.asax is changed). The attached patch fixes that. Please review. - Juraj -------------- next part -------------- A non-text attachment was scrubbed... Name: HttpApplicationFactory.patch Type: text/x-patch Size: 823 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070404/1de2870f/attachment.bin From joelwreed at gmail.com Wed Apr 4 10:27:24 2007 From: joelwreed at gmail.com (joel reed) Date: Wed, 04 Apr 2007 10:27:24 -0400 Subject: [Mono-dev] [PATCH] ActiveDirectoryMembershipProvider In-Reply-To: <461308E7.8070608@gmail.com> References: <461308E7.8070608@gmail.com> Message-ID: <4613B5CC.8030806@gmail.com> By the way, here's what the exception looks like without this change: System.TypeInitializationException: An exception was thrown by the type initializer for System.Web.Security.Membership ---> System.ArgumentNullException: Argument cannot be null. at System.Configuration.Provider.ProviderCollection.Add (System.Configuration.Provider.ProviderBase provider) [0x00000] at System.Web.Security.MembershipProviderCollection.Add (System.Configuration.Provider.ProviderBase provider) [0x00000] at System.Web.Configuration.ProvidersHelper.InstantiateProviders (System.Configuration.ProviderSettingsCollection configProviders, System.Configuration.Provider.ProviderCollection providers, System.Type providerType) [0x00000] at System.Web.Security.Membership..cctor () [0x00000] --- End of inner exception stack trace --- jr joel reed wrote: > The patch below enhances the usefulness of > ActiveDirectoryMembershipProvider under mono, but may not be acceptable > for inclusion in svn. I'm posting this in case some one else runs into a > similar problem as I encountered. > > We have a Membership Provider that derives from > ActiveDirectoryMembershipProvider and then overrides Initialize and > ValidateUser. Our ValidateUser method looks in web.config and either > does an validation against AD or our legacy authentication scheme. > > This works on mono (if configured to not use AD), as long as the > Initialize method in ActiveDirectoryMembershipProvider calls > base.Initialize. Calling base.Initialize is important as this is how > ProviderBase sets the Name property which lets the Provider be put into > a ProviderCollection. Without the Name, Adding the provider to the > collection fails with a ArgumentNullException. > > Currently ActiveDirectoryMembershipProvider just does a "throw > NotImplemented". > > If instead we said: > > mcs/class/System.Web/System.Web.Security/ActiveDirectoryMembershipProvider.cs.orig > 2007-04-03 20:59:32.000000000 -0400 > +++ > mcs/class/System.Web/System.Web.Security/ActiveDirectoryMembershipProvider.cs > 2007-04-03 20:59:50.000000000 -0400 > @@ -118,7 +118,7 @@ namespace System.Web.Security { > [MonoTODO("Not implemented")] > public override void Initialize (string name, > NameValueCollection config) > { > - throw new NotImplementedException (); > + base.Initialize(name, config); > } > > [MonoTODO("Not implemented")] > > The class would be slightly more useful in the above scenario. Probably > this circumvents some policy about MonoTODOs, but again just want to > post this info somewhere for others to google. It might even improve > things just by calling base.Initialize and then throwing, as you could > catch that exception and still be in business. Thoughts? > > jr > From grendello at gmail.com Wed Apr 4 10:12:58 2007 From: grendello at gmail.com (Marek Habersack) Date: Wed, 4 Apr 2007 16:12:58 +0200 Subject: [Mono-dev] [PATCH] System.Web.HttpApplicationFactory: App_End in global.asax called multiple times In-Reply-To: <1175695847.3039.74.camel@leonardo.hotfeet.ch> References: <1175695847.3039.74.camel@leonardo.hotfeet.ch> Message-ID: <20070404161258.5767dfe3@beowulf.thanes.org> On Wed, 04 Apr 2007 16:10:47 +0200, Juraj Skripsky scribbled: > Hello, Hello, > Most of the time, Application_End in global.asax is called multiple > times for a single ending application. The problem is in > HttpApplicationFactory.OnFileChanged: the lock guards the method against > multiple _concurrent_ shutdowns only. It can still execute multiple > times sequentially (FileSystemWatcher emits multiple events when > global.asax is changed). > > The attached patch fixes that. Please commit, thanks! regards, marek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070404/2ea978c1/attachment.bin From grendello at gmail.com Wed Apr 4 10:10:07 2007 From: grendello at gmail.com (Marek Habersack) Date: Wed, 4 Apr 2007 16:10:07 +0200 Subject: [Mono-dev] Need help with bug #81175 (data bound controls) Message-ID: <20070404161007.00f7c088@beowulf.thanes.org> Hello folks, I need help solving http://bugzilla.ximian.com/show_bug.cgi?id=81175. I'm positive the logic behind RequiresDataBinding in svn head is correct, but I can't find the reason why the code attached to the bug goes into endless recursion if any GridView property that requires data binding is assigned from within the ObjectDataSourceView OnSelecting even handler. I would appreciate any input from folks familiar with the data bound controls in Mono... :) thanks in advance, marek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070404/e9fe3631/attachment.bin From miguel at ximian.com Wed Apr 4 11:15:31 2007 From: miguel at ximian.com (Miguel de Icaza) Date: Wed, 04 Apr 2007 11:15:31 -0400 Subject: [Mono-dev] Race to Linux, second race. Message-ID: <1175699731.3879.41.camel@mirrors.mathematik.uni-bielefeld.de> Hey folks, I have been asked that I could post this. As long as you are not a Novell/Mainsoft employee, you can participate. The Race to Linux #2 is still open. The challenge is to port a blog starter kit to Linux using Mono, Mainsoft's Grasshopper, or another method. You can get details about the Race to Linux and enter the race at: http://www.devx.com/racetolinux/Door/33508 There will be three winners in each race. The fastest entry overall will win a Wii and US $200 for Wii games and accessories. The first correct entry in each race that uses Mono, and the first correct entry that uses Grasshopper 2.0, will also win a Wii. From miguel at novell.com Wed Apr 4 11:49:27 2007 From: miguel at novell.com (Miguel de Icaza) Date: Wed, 04 Apr 2007 11:49:27 -0400 Subject: [Mono-dev] [PATCH] ActiveDirectoryMembershipProvider In-Reply-To: <461308E7.8070608@gmail.com> References: <461308E7.8070608@gmail.com> Message-ID: <1175701767.3879.86.camel@mirrors.mathematik.uni-bielefeld.de> Hello, > The class would be slightly more useful in the above scenario. Probably > this circumvents some policy about MonoTODOs, but again just want to > post this info somewhere for others to google. It might even improve > things just by calling base.Initialize and then throwing, as you could > catch that exception and still be in business. Thoughts? Your patch looks correct, and since the MonoTODO is kept there, it will be useful as a reference to others in the future. Miguel. From spigaz at gmail.com Wed Apr 4 20:05:03 2007 From: spigaz at gmail.com (=?ISO-8859-1?Q?Jos=E9?= Alexandre Antunes Faria) Date: Thu, 05 Apr 2007 01:05:03 +0100 Subject: [Mono-dev] File LastModified Message-ID: <1175731503.7362.43.camel@localhost.localdomain> Hi there guys, One of my apps uses a great deal of files and check their lastmodified timestamps, as I guess many other do. When I was profiling it, I noticed that it was taking a great deal of time, getting the lastmodified attribute, so I gave it a look. And I found out that internally mono uses UTC time, meaning the libs always get the LastWriteTime in UTC. Then they convert it to LocalTime before any usage. Meaning that if the required is UTC, its converted back to UTC. That is two unnecessary conversions. I have run some tests (100000000 times getting the LastWriteTimeUtc), and have found out, that it wastes about 10% converting back to LocalTime. I don't have a number on the conversion from utc to localtime, but I seen that you use some tricks on the DateTime.Now, so I would guess that it isn't that light either. I know that an optimization of 20% is close to nothing on things are are very little used, like file manipulation. I don't know if this was intentional ou its simply a mistake, as it in fact allows to simplify the implementation, but why isn't utc used instead of local? The same happens with the other GetLast*Time and SetLast*. I haven't proposed a patch, because I don't know it makes sense to fix this or not. I would appreciate your comment on this. Thanks, SpigaZ out. PS: Here are some snippets of the code in question. //// File.cs: public static DateTime GetLastWriteTime (string path) { MonoIOStat stat; MonoIOError error; CheckPathExceptions (path); if (!MonoIO.GetFileStat (path, out stat, out error)) { #if NET_2_0 if (error == MonoIOError.ERROR_PATH_NOT_FOUND || error == MonoIOError.ERROR_FILE_NOT_FOUND) return _defaultLocalFileTime; else throw new IOException (path); #else throw new IOException (path); #endif } return DateTime.FromFileTime (stat.LastWriteTime); } public static DateTime GetLastWriteTimeUtc (string path) { return GetLastWriteTime (path).ToUniversalTime (); } // DateTime.cs public static DateTime FromFileTime (long fileTime) { if (fileTime < 0) throw new ArgumentOutOfRangeException ("fileTime", "< 0"); return new DateTime (w32file_epoch + fileTime).ToLocalTime (); } #if NET_1_1 public static DateTime FromFileTimeUtc (long fileTime) { if (fileTime < 0) throw new ArgumentOutOfRangeException ("fileTime", "< 0"); return new DateTime (w32file_epoch + fileTime); } #endif From igorz at mainsoft.com Thu Apr 5 07:03:11 2007 From: igorz at mainsoft.com (Igor Zelmanovich) Date: Thu, 5 Apr 2007 04:03:11 -0700 Subject: [Mono-dev] Need help with bug #81175 (data bound controls) In-Reply-To: <20070404161007.00f7c088@beowulf.thanes.org> References: <20070404161007.00f7c088@beowulf.thanes.org> Message-ID: Hello, The bug has been fixed in r75422 Igor -----Original Message----- From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Marek Habersack Sent: Wednesday, April 04, 2007 4:10 PM To: Mono Development List Subject: [Mono-dev] Need help with bug #81175 (data bound controls) Hello folks, I need help solving http://bugzilla.ximian.com/show_bug.cgi?id=81175. I'm positive the logic behind RequiresDataBinding in svn head is correct, but I can't find the reason why the code attached to the bug goes into endless recursion if any GridView property that requires data binding is assigned from within the ObjectDataSourceView OnSelecting even handler. I would appreciate any input from folks familiar with the data bound controls in Mono... :) thanks in advance, marek From grendello at gmail.com Thu Apr 5 07:34:28 2007 From: grendello at gmail.com (Marek Habersack) Date: Thu, 5 Apr 2007 13:34:28 +0200 Subject: [Mono-dev] Need help with bug #81175 (data bound controls) In-Reply-To: References: <20070404161007.00f7c088@beowulf.thanes.org> Message-ID: <20070405133428.4a923c99@beowulf.thanes.org> On Thu, 5 Apr 2007 04:03:11 -0700, "Igor Zelmanovich" scribbled: > Hello, Hey Igor, > The bug has been fixed in r75422 Thanks a lot :) - somehow I couldn't bite that one... :) regards, marek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070405/25c0a13f/attachment.bin From btimothy at gmail.com Thu Apr 5 16:37:00 2007 From: btimothy at gmail.com (Boyd Timothy) Date: Thu, 5 Apr 2007 14:37:00 -0600 Subject: [Mono-dev] Patch to install gnome-keyring-sharp into the GAC Message-ID: If anyone cares to update gnome-keyring-sharp... Attached are the files needed to patch gnome-keyring-sharp so it will install itself into the GAC when doing a make install. Copy the Gnome.Keyring.key file to the root of the project, apply the patch, and you'll be good to go. -Boyd -------------- next part -------------- A non-text attachment was scrubbed... Name: Gnome.Keyring-gacutil.patch Type: text/x-patch Size: 2498 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070405/31018b62/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Gnome.Keyring.key Type: application/octet-stream Size: 596 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070405/31018b62/attachment.obj From iain.jackson at memex.com Thu Apr 5 04:30:45 2007 From: iain.jackson at memex.com (Iain Jackson) Date: Thu, 5 Apr 2007 09:30:45 +0100 Subject: [Mono-dev] Segmentation Fault on Solaris 10 Build (mono 1.2.3.1) Message-ID: <20070405085730.143E27003A@herald.ximian.com> Hi, I'm currently having an issue with building mono 1.2.3.1 on Solaris 10 06/06 on SPARC. The build process gets as far as executing the mcs compiler where the mono runtime crashes with a segmentation fault. How I'm building it: export PATH=/usr/local/bin:/usr/sfw/bin:/usr/ccs/bin:/usr/bin export PKG_CONFIG_PATH=/opt/mono/lib/pkgconfig export LD_LIBRARY_PATH=/opt/mono/lib:/usr/local/lib ./configure --prefix="/opt/mono" gmake get-monolite-latest gmake To compile it I'm using gcc 3.4.4 which I've installed in /usr/local/bin. I've compiled my own copy of glib2 (2.12.11) into /opt/mono. I've attached logs from configure and make in case these are of any use. I took a stack trace from the crashed process and it receives the signal in GC_read_dirty() when it initialises the garbage collector. Has anyone seen this problem before? Is there a flag or option that needs to be set when building on Solaris? Thanks, Iain --- Iain Jackson Software Engineer Memex Technology Ltd. Tel: +44 (0)1355 233804 Fax: +44 (0)1355 239767 www.memex.co.uk Memex Technology Ltd. Registered in: Scotland Company number: SC215165 Registered Office: 2 Redwood Court, Peel Park, East Kilbride, G74 5PF Confidentiality and Proprietary Rights Notice: ----------------------------------------------- The information contained in this e-mail message, including any and all attachments, is for the sole use of the intended recipient(s) and contains information that Memex Technology Ltd. and Memex, Inc. consider confidential and proprietary. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070405/feaf83a7/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.gz Type: application/octet-stream Size: 25069 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070405/feaf83a7/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: mono-build.log.gz Type: application/octet-stream Size: 40307 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070405/feaf83a7/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: mono-configure.log.gz Type: application/octet-stream Size: 3709 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070405/feaf83a7/attachment-0002.obj -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: stack_trace.txt Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070405/feaf83a7/attachment.txt From mark at ijbema.xs4all.nl Tue Apr 3 13:30:03 2007 From: mark at ijbema.xs4all.nl (Mark IJbema) Date: Tue, 3 Apr 2007 19:30:03 +0200 Subject: [Mono-dev] Using the System.Linq library Message-ID: <20070403173003.GM6671@ijbema.xs4all.nl> Hi, I'm trying to use the System.Linq library, but i don't know how. It's in System.Core, so i used: gmcs -langversion:linq -r:System.Core Bla.cs gmcs -langversion:linq -r:/home/mark/local/lib/mono/2.0/System.Core.dll Bla.cs On the file: http://ijbema.home.fmf.nl/Bla.cs Can anyone tell me how to compile this file so i can use the provided extension methods in Enumerable.cs? Regards, Mark PS. I've already asked on IRC and tried to google it, but both to no avail From olivier.duff at free.fr Tue Apr 3 15:52:26 2007 From: olivier.duff at free.fr (olivier.duff at free.fr) Date: Tue, 03 Apr 2007 21:52:26 +0200 Subject: [Mono-dev] Binding navigator patch Message-ID: <1175629946.4612b07a95196@imp.free.fr> Hi, For my second patch, I have take the first class missing in mono winforms ;). I have try to fit to coding guideline. If there are still issue, make a feed back... I have issue on winforms test project because Eventlogger is not recognize. So I can not compile it and launch test. So maybe my test do not pass on windows dlls. So, if someone know how fix that, I will test it and resend the patch. regards, From mhabersack at novell.com Wed Apr 4 09:22:23 2007 From: mhabersack at novell.com (Marek Habersack) Date: Wed, 4 Apr 2007 15:22:23 +0200 Subject: [Mono-dev] [PATCH] Regression in System.Web.Security.FormsAuthenticationModule In-Reply-To: <1175692225.3039.62.camel@leonardo.hotfeet.ch> References: <1175692225.3039.62.camel@leonardo.hotfeet.ch> Message-ID: <20070404152223.01f032e3@beowulf.thanes.org> On Wed, 04 Apr 2007 15:10:25 +0200, Juraj Skripsky scribbled: > Hello, Hello, > The follow commit caused a regression in NET_1_1: Session_End in > global.asax is never called. The cause is an NullReferenceException in > FormsAuthenticationModule.Init() as "app.Context" is null (only in this > method and only when a session is about to be terminated). > > 2007-03-21 Vladimir Krasnov > > * FormsAuthenticationModule.cs: refactored configuration section to be > a member of a class > > > My patch moves the initialization of _config out of the Init method. > > Please review. Please commit, thanks! regards, marek From monkey at jpobst.com Thu Apr 5 20:44:26 2007 From: monkey at jpobst.com (Jonathan Pobst) Date: Thu, 05 Apr 2007 19:44:26 -0500 Subject: [Mono-dev] Binding navigator patch In-Reply-To: <1175629946.4612b07a95196@imp.free.fr> References: <1175629946.4612b07a95196@imp.free.fr> Message-ID: <461597EA.9040804@jpobst.com> Often times we don't keep the VS projects in sync with the .sources file used to build mono. Generally you already have the file from SVN, you just need to add it to your project. In this case, the file should be EventLogger.cs. Jon olivier.duff at free.fr wrote: > Hi, > > For my second patch, I have take the first class missing in mono winforms ;). > I have try to fit to coding guideline. If there are still issue, make a feed > back... > I have issue on winforms test project because Eventlogger is not recognize. So I > can not compile it and launch test. So maybe my test do not pass on windows > dlls. > So, if someone know how fix that, I will test it and resend the patch. > regards, > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From miguel at novell.com Thu Apr 5 20:47:48 2007 From: miguel at novell.com (Miguel de Icaza) Date: Thu, 05 Apr 2007 20:47:48 -0400 Subject: [Mono-dev] Patch to install gnome-keyring-sharp into the GAC In-Reply-To: References: Message-ID: <1175820468.3945.98.camel@mirrors.mathematik.uni-bielefeld.de> Hello, > Attached are the files needed to patch gnome-keyring-sharp so it will > install itself into the GAC when doing a make install. Copy the > Gnome.Keyring.key file to the root of the project, apply the patch, > and you'll be good to go. Gonzalo is the developer for Gnome Keyring # and he has left Novell. The only issue with installing stuff into the GAC is that once we commit to install things into the GAC, we have to preserve its API, we can not remove/change any APIs that are there. I do not mind adding the patch, but I would like for someone to step up and take over maintenance. Miguel. From antonello at deveel.com Fri Apr 6 03:04:18 2007 From: antonello at deveel.com (Antonello Provenzano) Date: Fri, 6 Apr 2007 09:04:18 +0200 Subject: [Mono-dev] Using the System.Linq library In-Reply-To: <20070403173003.GM6671@ijbema.xs4all.nl> References: <20070403173003.GM6671@ijbema.xs4all.nl> Message-ID: Mark, LINQ functions are under the profile 2.0 (I don't know why still don't have 3.0): to compile it you just have to add the PROFILE=net_2_0 directive to the compilation. Cheers. Antonello On 4/3/07, Mark IJbema wrote: > Hi, > > I'm trying to use the System.Linq library, but i don't know how. It's in > System.Core, so i used: > > gmcs -langversion:linq -r:System.Core Bla.cs > gmcs -langversion:linq -r:/home/mark/local/lib/mono/2.0/System.Core.dll Bla.cs > > On the file: > > http://ijbema.home.fmf.nl/Bla.cs > > Can anyone tell me how to compile this file so i can use the provided > extension methods in Enumerable.cs? > > Regards, > > Mark > > PS. I've already asked on IRC and tried to google it, but both to no > avail > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From atsushi at ximian.com Fri Apr 6 03:29:17 2007 From: atsushi at ximian.com (Atsushi Eno) Date: Fri, 06 Apr 2007 16:29:17 +0900 Subject: [Mono-dev] Using the System.Linq library In-Reply-To: References: <20070403173003.GM6671@ijbema.xs4all.nl> Message-ID: <4615F6CD.2040402@ximian.com> No, you don't have to add something special either in the source or in the compiler options. The command line should be fine (even -r might not be required). Make sure that the method you are going to use is already implemented. I believe that we don't need extraneous 3.0 build loop until we are ready to start .NET 3.5 compatibility stack (which involves changes to existing libraries). Atsushi Eno Antonello Provenzano wrote: > Mark, > > LINQ functions are under the profile 2.0 (I don't know why still don't > have 3.0): to compile it you just have to add the PROFILE=net_2_0 > directive to the compilation. > > Cheers. > Antonello > > > On 4/3/07, Mark IJbema wrote: > >> Hi, >> >> I'm trying to use the System.Linq library, but i don't know how. It's in >> System.Core, so i used: >> >> gmcs -langversion:linq -r:System.Core Bla.cs >> gmcs -langversion:linq -r:/home/mark/local/lib/mono/2.0/System.Core.dll Bla.cs >> >> On the file: >> >> http://ijbema.home.fmf.nl/Bla.cs >> >> Can anyone tell me how to compile this file so i can use the provided >> extension methods in Enumerable.cs? >> >> Regards, >> >> Mark >> >> PS. I've already asked on IRC and tried to google it, but both to no >> avail >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From antonello at deveel.com Fri Apr 6 03:56:58 2007 From: antonello at deveel.com (Antonello Provenzano) Date: Fri, 6 Apr 2007 09:56:58 +0200 Subject: [Mono-dev] Using the System.Linq library In-Reply-To: <4615F6CD.2040402@ximian.com> References: <20070403173003.GM6671@ijbema.xs4all.nl> <4615F6CD.2040402@ximian.com> Message-ID: Atsushi, > No, you don't have to add something special either in the source or in the > compiler options. The command line should be fine (even -r might not > be required). Personally when I try to build some library referencing System.Core or System.Data.Linq I have to define the profile 2.0 (PROFILE=net_2_0), otherwise it is not able to compile. On 4/6/07, Atsushi Eno wrote: > No, you don't have to add something special either in the source or in the > compiler options. The command line should be fine (even -r might not > be required). > > Make sure that the method you are going to use is already implemented. > > I believe that we don't need extraneous 3.0 build loop until we are ready > to start .NET 3.5 compatibility stack (which involves changes to existing > libraries). > > Atsushi Eno > > > Antonello Provenzano wrote: > > Mark, > > > > LINQ functions are under the profile 2.0 (I don't know why still don't > > have 3.0): to compile it you just have to add the PROFILE=net_2_0 > > directive to the compilation. > > > > Cheers. > > Antonello > > > > > > On 4/3/07, Mark IJbema wrote: > > > >> Hi, > >> > >> I'm trying to use the System.Linq library, but i don't know how. It's in > >> System.Core, so i used: > >> > >> gmcs -langversion:linq -r:System.Core Bla.cs > >> gmcs -langversion:linq -r:/home/mark/local/lib/mono/2.0/System.Core.dll Bla.cs > >> > >> On the file: > >> > >> http://ijbema.home.fmf.nl/Bla.cs > >> > >> Can anyone tell me how to compile this file so i can use the provided > >> extension methods in Enumerable.cs? > >> > >> Regards, > >> > >> Mark > >> > >> PS. I've already asked on IRC and tried to google it, but both to no > >> avail > >> _______________________________________________ > >> Mono-devel-list mailing list > >> Mono-devel-list at lists.ximian.com > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > >> > >> > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From atsushi at ximian.com Fri Apr 6 04:11:17 2007 From: atsushi at ximian.com (Atsushi Eno) Date: Fri, 06 Apr 2007 17:11:17 +0900 Subject: [Mono-dev] Using the System.Linq library In-Reply-To: References: <20070403173003.GM6671@ijbema.xs4all.nl> <4615F6CD.2040402@ximian.com> Message-ID: <461600A5.2070303@ximian.com> I don't think this issue is about how to build System.Core.dll itself. It does not apply to *users* of the linq libraries. PROFILE=net_2_0 is only about how to build assemblies in mcs, so that's really irrelevant once you built and installe mono and mcs successfully. (If the build and install were unsuccessful, the -r option would be regarded as invalid and it will be reported in prior to nonexistent members.) Atsushi Eno Antonello Provenzano wrote: > Atsushi, > >> No, you don't have to add something special either in the source or >> in the >> compiler options. The command line should be fine (even -r might not >> be required). > > Personally when I try to build some library referencing System.Core or > System.Data.Linq I have to define the profile 2.0 (PROFILE=net_2_0), > otherwise it is not able to compile. > > > On 4/6/07, Atsushi Eno wrote: >> No, you don't have to add something special either in the source or >> in the >> compiler options. The command line should be fine (even -r might not >> be required). >> >> Make sure that the method you are going to use is already implemented. >> >> I believe that we don't need extraneous 3.0 build loop until we are >> ready >> to start .NET 3.5 compatibility stack (which involves changes to >> existing >> libraries). >> >> Atsushi Eno >> >> >> Antonello Provenzano wrote: >> > Mark, >> > >> > LINQ functions are under the profile 2.0 (I don't know why still don't >> > have 3.0): to compile it you just have to add the PROFILE=net_2_0 >> > directive to the compilation. >> > >> > Cheers. >> > Antonello >> > >> > >> > On 4/3/07, Mark IJbema wrote: >> > >> >> Hi, >> >> >> >> I'm trying to use the System.Linq library, but i don't know how. >> It's in >> >> System.Core, so i used: >> >> >> >> gmcs -langversion:linq -r:System.Core Bla.cs >> >> gmcs -langversion:linq >> -r:/home/mark/local/lib/mono/2.0/System.Core.dll Bla.cs >> >> >> >> On the file: >> >> >> >> http://ijbema.home.fmf.nl/Bla.cs >> >> >> >> Can anyone tell me how to compile this file so i can use the provided >> >> extension methods in Enumerable.cs? >> >> >> >> Regards, >> >> >> >> Mark >> >> >> >> PS. I've already asked on IRC and tried to google it, but both to no >> >> avail >> >> _______________________________________________ >> >> Mono-devel-list mailing list >> >> Mono-devel-list at lists.ximian.com >> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> >> >> >> > _______________________________________________ >> > Mono-devel-list mailing list >> > Mono-devel-list at lists.ximian.com >> > http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > >> > >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > From antonello at deveel.com Fri Apr 6 04:19:46 2007 From: antonello at deveel.com (Antonello Provenzano) Date: Fri, 6 Apr 2007 10:19:46 +0200 Subject: [Mono-dev] Using the System.Linq library In-Reply-To: <461600A5.2070303@ximian.com> References: <20070403173003.GM6671@ijbema.xs4all.nl> <4615F6CD.2040402@ximian.com> <461600A5.2070303@ximian.com> Message-ID: Atsushi, Thank you for the explanation: I've never tried using those references outside the mcs compiling context (I'm writing a System.Data.Linq.Design and I needed both, but I was int the project context), so I didn't know it wasn't a non-needed definition outside. Cheers. Antonello On 4/6/07, Atsushi Eno wrote: > I don't think this issue is about how to build System.Core.dll itself. > It does not > apply to *users* of the linq libraries. PROFILE=net_2_0 is only about how > to build assemblies in mcs, so that's really irrelevant once you built and > installe mono and mcs successfully. > > (If the build and install were unsuccessful, the -r option would be regarded > as invalid and it will be reported in prior to nonexistent members.) > > Atsushi Eno > > Antonello Provenzano wrote: > > Atsushi, > > > >> No, you don't have to add something special either in the source or > >> in the > >> compiler options. The command line should be fine (even -r might not > >> be required). > > > > Personally when I try to build some library referencing System.Core or > > System.Data.Linq I have to define the profile 2.0 (PROFILE=net_2_0), > > otherwise it is not able to compile. > > > > > > On 4/6/07, Atsushi Eno wrote: > >> No, you don't have to add something special either in the source or > >> in the > >> compiler options. The command line should be fine (even -r might not > >> be required). > >> > >> Make sure that the method you are going to use is already implemented. > >> > >> I believe that we don't need extraneous 3.0 build loop until we are > >> ready > >> to start .NET 3.5 compatibility stack (which involves changes to > >> existing > >> libraries). > >> > >> Atsushi Eno > >> > >> > >> Antonello Provenzano wrote: > >> > Mark, > >> > > >> > LINQ functions are under the profile 2.0 (I don't know why still don't > >> > have 3.0): to compile it you just have to add the PROFILE=net_2_0 > >> > directive to the compilation. > >> > > >> > Cheers. > >> > Antonello > >> > > >> > > >> > On 4/3/07, Mark IJbema wrote: > >> > > >> >> Hi, > >> >> > >> >> I'm trying to use the System.Linq library, but i don't know how. > >> It's in > >> >> System.Core, so i used: > >> >> > >> >> gmcs -langversion:linq -r:System.Core Bla.cs > >> >> gmcs -langversion:linq > >> -r:/home/mark/local/lib/mono/2.0/System.Core.dll Bla.cs > >> >> > >> >> On the file: > >> >> > >> >> http://ijbema.home.fmf.nl/Bla.cs > >> >> > >> >> Can anyone tell me how to compile this file so i can use the provided > >> >> extension methods in Enumerable.cs? > >> >> > >> >> Regards, > >> >> > >> >> Mark > >> >> > >> >> PS. I've already asked on IRC and tried to google it, but both to no > >> >> avail > >> >> _______________________________________________ > >> >> Mono-devel-list mailing list > >> >> Mono-devel-list at lists.ximian.com > >> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > >> >> > >> >> > >> > _______________________________________________ > >> > Mono-devel-list mailing list > >> > Mono-devel-list at lists.ximian.com > >> > http://lists.ximian.com/mailman/listinfo/mono-devel-list > >> > > >> > > >> > >> _______________________________________________ > >> Mono-devel-list mailing list > >> Mono-devel-list at lists.ximian.com > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > >> > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From marek.safar at seznam.cz Fri Apr 6 05:42:03 2007 From: marek.safar at seznam.cz (=?us-ascii?Q?marek=20safar?=) Date: Fri, 06 Apr 2007 11:42:03 +0200 (CEST) Subject: [Mono-dev] Using the System.Linq library In-Reply-To: <20070403173003.GM6671@ijbema.xs4all.nl> Message-ID: <915.2079-6605-1527608104-1175852523@seznam.cz> Hello Mark, > > I'm trying to use the System.Linq library, but i don't know how. It's in > System.Core, so i used: > > gmcs -langversion:linq -r:System.Core Bla.cs > gmcs -langversion:linq -r:/home/mark/local/lib/mono/2.0/System.Core.dll Bla.cs Yes, that's right syntax for code which uses C# 3.0 features. > > On the file: > > http://ijbema.home.fmf.nl/Bla.cs > > Can anyone tell me how to compile this file so i can use the provided > extension methods in Enumerable.cs? Your code is correct but you hit a bug in our compiler. Please fill a bug report in http://bugzilla.ximian.com Regards, Marek From trupill at yahoo.es Fri Apr 6 05:55:30 2007 From: trupill at yahoo.es (Alejandro Serrano) Date: Fri, 06 Apr 2007 11:55:30 +0200 Subject: [Mono-dev] Using the System.Linq library In-Reply-To: <915.2079-6605-1527608104-1175852523@seznam.cz> References: <915.2079-6605-1527608104-1175852523@seznam.cz> Message-ID: <46161912.3070504@yahoo.es> The C# compiler does not support extension methods yet. So you must call the methods directly from the Queryable class, something like: using System; using System.Linq; using System.Collections.Generic; public class Bla { public static void Main() { List first = new List(new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }); List second = new List(new int[] { 4, 5, 6, 10 }); IEnumerable q = Queryable.Except(first, second); <== here it is int x = Enumerable.Count(first); foreach (int num in q) Console.WriteLine(num); } } marek safar escribi?: > Hello Mark, > > >> I'm trying to use the System.Linq library, but i don't know how. It's in >> System.Core, so i used: >> >> gmcs -langversion:linq -r:System.Core Bla.cs >> gmcs -langversion:linq -r:/home/mark/local/lib/mono/2.0/System.Core.dll Bla.cs >> > > Yes, that's right syntax for code which uses C# 3.0 features. > > >> On the file: >> >> http://ijbema.home.fmf.nl/Bla.cs >> >> Can anyone tell me how to compile this file so i can use the provided >> extension methods in Enumerable.cs? >> > > Your code is correct but you hit a bug in our compiler. > Please fill a bug report in http://bugzilla.ximian.com > > Regards, > Marek > From mark at ijbema.xs4all.nl Fri Apr 6 06:00:49 2007 From: mark at ijbema.xs4all.nl (Mark IJbema) Date: Fri, 6 Apr 2007 12:00:49 +0200 Subject: [Mono-dev] Using the System.Linq library In-Reply-To: <46161912.3070504@yahoo.es> References: <915.2079-6605-1527608104-1175852523@seznam.cz> <46161912.3070504@yahoo.es> Message-ID: <20070406100049.GF11002@ijbema.xs4all.nl> It's a bit more complicated than that, check my updated source: http://ijbema.home.fmf.nl/Bla.cs the solution you give works, but also, if i add the extension method in my own files i can call it as an extension method. So, as far as i can see it is a bug, i filed it as well: http://bugzilla.ximian.com/show_bug.cgi?id=81324 Regards, Mark On Fri, Apr 06, 2007 at 11:55:30AM +0200, Alejandro Serrano wrote: > The C# compiler does not support extension methods yet. So you must call > the methods directly from the Queryable class, something like: > > using System; > using System.Linq; > using System.Collections.Generic; > > public class Bla { > public static void Main() { > List first = new List(new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }); > List second = new List(new int[] { 4, 5, 6, 10 }); > > IEnumerable q = Queryable.Except(first, second); <== here it is > int x = Enumerable.Count(first); > > foreach (int num in q) > Console.WriteLine(num); > } > } > > > > marek safar escribi?: > > Hello Mark, > > > > > >> I'm trying to use the System.Linq library, but i don't know how. It's in > >> System.Core, so i used: > >> > >> gmcs -langversion:linq -r:System.Core Bla.cs > >> gmcs -langversion:linq -r:/home/mark/local/lib/mono/2.0/System.Core.dll Bla.cs > >> > > > > Yes, that's right syntax for code which uses C# 3.0 features. > > > > > >> On the file: > >> > >> http://ijbema.home.fmf.nl/Bla.cs > >> > >> Can anyone tell me how to compile this file so i can use the provided > >> extension methods in Enumerable.cs? > >> > > > > Your code is correct but you hit a bug in our compiler. > > Please fill a bug report in http://bugzilla.ximian.com > > > > Regards, > > Marek > > From antonello at deveel.com Fri Apr 6 07:41:05 2007 From: antonello at deveel.com (Antonello Provenzano) Date: Fri, 6 Apr 2007 13:41:05 +0200 Subject: [Mono-dev] Using the System.Linq library In-Reply-To: <20070406100049.GF11002@ijbema.xs4all.nl> References: <915.2079-6605-1527608104-1175852523@seznam.cz> <46161912.3070504@yahoo.es> <20070406100049.GF11002@ijbema.xs4all.nl> Message-ID: That was a bug I sent to Marek some weeks ago, but it seemed to me the problem was just for the extension methods defined inside the assembly: I was working on System.Core and some internal extension methods couldn't be found by the compiler, so we thought it was just that the compiler was not able to find internal extension definitions... On 4/6/07, Mark IJbema wrote: > It's a bit more complicated than that, check my updated source: > http://ijbema.home.fmf.nl/Bla.cs > > the solution you give works, but also, if i add the extension method in > my own files i can call it as an extension method. So, as far as i can > see it is a bug, i filed it as well: > http://bugzilla.ximian.com/show_bug.cgi?id=81324 > > Regards, > > Mark > > On Fri, Apr 06, 2007 at 11:55:30AM +0200, Alejandro Serrano wrote: > > The C# compiler does not support extension methods yet. So you must call > > the methods directly from the Queryable class, something like: > > > > using System; > > using System.Linq; > > using System.Collections.Generic; > > > > public class Bla { > > public static void Main() { > > List first = new List(new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }); > > List second = new List(new int[] { 4, 5, 6, 10 }); > > > > IEnumerable q = Queryable.Except(first, second); <== here it is > > int x = Enumerable.Count(first); > > > > foreach (int num in q) > > Console.WriteLine(num); > > } > > } > > > > > > > > marek safar escribi?: > > > Hello Mark, > > > > > > > > >> I'm trying to use the System.Linq library, but i don't know how. It's in > > >> System.Core, so i used: > > >> > > >> gmcs -langversion:linq -r:System.Core Bla.cs > > >> gmcs -langversion:linq -r:/home/mark/local/lib/mono/2.0/System.Core.dll Bla.cs > > >> > > > > > > Yes, that's right syntax for code which uses C# 3.0 features. > > > > > > > > >> On the file: > > >> > > >> http://ijbema.home.fmf.nl/Bla.cs > > >> > > >> Can anyone tell me how to compile this file so i can use the provided > > >> extension methods in Enumerable.cs? > > >> > > > > > > Your code is correct but you hit a bug in our compiler. > > > Please fill a bug report in http://bugzilla.ximian.com > > > > > > Regards, > > > Marek > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From marek.safar at seznam.cz Fri Apr 6 07:56:20 2007 From: marek.safar at seznam.cz (=?us-ascii?Q?marek=20safar?=) Date: Fri, 06 Apr 2007 13:56:20 +0200 (CEST) Subject: [Mono-dev] Using the System.Linq library In-Reply-To: <20070406100049.GF11002@ijbema.xs4all.nl> Message-ID: <883.2071-20150-125773813-1175860580@seznam.cz> Hello, Mono compiler does support extension methods but our implementation has not been extensively tested yet and we definitely welcome any bug reports. > It's a bit more complicated than that, check my updated source: > http://ijbema.home.fmf.nl/Bla.cs > > the solution you give works, but also, if i add the extension method in > my own files i can call it as an extension method. So, as far as i can > see it is a bug, i filed it as well: > http://bugzilla.ximian.com/show_bug.cgi?id=81324 Thank you for the bug report. Regards, Marek > > On Fri, Apr 06, 2007 at 11:55:30AM +0200, Alejandro Serrano wrote: > > The C# compiler does not support extension methods yet. So you must call > > the methods directly from the Queryable class, something like: > > > > using System; > > using System.Linq; > > using System.Collections.Generic; > > > > public class Bla { > > public static void Main() { > > List first = new List(new int[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 > }); > > List second = new List(new int[] { 4, 5, 6, 10 > }); > > > > IEnumerable q = Queryable.Except(first, second); <== here it is > > int x = Enumerable.Count(first); > > > > foreach (int num in q) > > Console.WriteLine(num); > > } > > } > > > > > > > > marek safar escribi?: > > > Hello Mark, > > > > > > > > >> I'm trying to use the System.Linq library, but i don't know how. It's in > > >> System.Core, so i used: > > >> > > >> gmcs -langversion:linq -r:System.Core Bla.cs > > >> gmcs -langversion:linq -r:/home/mark/local/lib/mono/2.0/System.Core.dll > Bla.cs > > >> > > > > > > Yes, that's right syntax for code which uses C# 3.0 features. > > > > > > > > >> On the file: > > >> > > >> http://ijbema.home.fmf.nl/Bla.cs > > >> > > >> Can anyone tell me how to compile this file so i can use the provided > > >> extension methods in Enumerable.cs? > > >> > > > > > > Your code is correct but you hit a bug in our compiler. > > > Please fill a bug report in http://bugzilla.ximian.com > > > > > > Regards, > > > Marek > > > > > > From raphtee at gmail.com Fri Apr 6 14:37:48 2007 From: raphtee at gmail.com (Travis Miller) Date: Fri, 6 Apr 2007 11:37:48 -0700 Subject: [Mono-dev] questions about cluster computing Message-ID: <9e8b7fe0704061137k24e7eb36n55cb3a2b5e06abc5@mail.gmail.com> in a previous life as a physics postdoc, I wrote quite a bit of cluster computing code (mostly stuff for lattice quantum field theory) using MPI and C. Lately I have been revisiting some of this code using C#. I have written some simple pde solvers using c# and have been very impressed with the performance. Now I am trying to using the features in System.Runtime.Remoting to distribute the load among several machines. I can get it to work, but I have to run from machine to machine and start the code manually. In the linux cluster world (thanks to tools like rsh or ssh) you could start the executables remotely. Is there some way I can accomplish this using mono? travis miller -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070406/608d4afe/attachment.html From alexmipego at gmail.com Fri Apr 6 19:10:30 2007 From: alexmipego at gmail.com (Alexandre Gomes) Date: Fri, 6 Apr 2007 19:10:30 -0400 (EDT) Subject: [Mono-dev] Alexandre has Tagged you! :) Message-ID: <20070406231030.531AE70063@herald.ximian.com> An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070406/00f25d49/attachment.html From alexmipego at gmail.com Fri Apr 6 19:12:57 2007 From: alexmipego at gmail.com (Alexandre Gomes) Date: Fri, 6 Apr 2007 19:12:57 -0400 (EDT) Subject: [Mono-dev] Alexandre has Tagged you! :) Message-ID: <20070406231257.809CC70005@herald.ximian.com> An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070406/fba42924/attachment.html From alexmipego at gmail.com Fri Apr 6 19:25:12 2007 From: alexmipego at gmail.com (Alexandre Miguel Pedro Gomes) Date: Sat, 7 Apr 2007 00:25:12 +0100 Subject: [Mono-dev] Alexandre has Tagged you! :) In-Reply-To: <20070406231257.809CC70005@herald.ximian.com> References: <20070406231257.809CC70005@herald.ximian.com> Message-ID: <170f4a080704061625oe515671o2ab469459759a1a8@mail.gmail.com> Sorry... my bad! On 4/7/07, Alexandre Gomes wrote: > > > > > > Alexandre G, 22 > Portugal > Alexandre G has added you as a friend > Is Alexandre G your friend? > Please > respond or Alexandre may think you said no :( > > Click hereto unsubscribe from Tagged, > P.O. Box 193152 San Francisco, CA 94119-3152 > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- Alexandre Gomes, Portugal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070407/446a7b41/attachment.html From louis at fitnr.com Fri Apr 6 20:47:11 2007 From: louis at fitnr.com (Louis R. Marascio) Date: Fri, 6 Apr 2007 19:47:11 -0500 Subject: [Mono-dev] questions about cluster computing In-Reply-To: <9e8b7fe0704061137k24e7eb36n55cb3a2b5e06abc5@mail.gmail.com> References: <9e8b7fe0704061137k24e7eb36n55cb3a2b5e06abc5@mail.gmail.com> Message-ID: <20070407004711.GA25353@mindpirate.local> Travis Miller wrote: >in a previous life as a physics postdoc, I wrote quite a bit of cluster >computing code (mostly stuff for lattice quantum field theory) using MPI and >C. Lately I have been revisiting some of this code using C#. I have >written some simple pde solvers using c# and have been very impressed with >the performance. Now I am trying to using the features in >System.Runtime.Remoting to distribute the load among several machines. I >can get it to work, but I have to run from machine to machine and start the >code manually. In the linux cluster world (thanks to tools like rsh or ssh) >you could start the executables remotely. Is there some way I can >accomplish this using mono? Travis, Why can't you use ssh to start the mono application prior to attempting a remoting connection. Alternatively, I suspect you could hack together some inetd fun to start your mono process when the super server sees a connection on a given port. I've not done anything similar, but it would be no different than any other daemon. As far as I know there are no built-in facilities in mono or .NET for this, nor do I believe there should be. Best regards! Louis -- Louis R. Marascio - www.fitnr.com ... fixed in the next release ... From monoman at gmail.com Fri Apr 6 22:18:48 2007 From: monoman at gmail.com (Rafael Teixeira) Date: Fri, 6 Apr 2007 23:18:48 -0300 Subject: [Mono-dev] questions about cluster computing In-Reply-To: <20070407004711.GA25353@mindpirate.local> References: <9e8b7fe0704061137k24e7eb36n55cb3a2b5e06abc5@mail.gmail.com> <20070407004711.GA25353@mindpirate.local> Message-ID: Since 1.2 Mono has support to start "services" (daemons), that could be responsible for honoring the remoting requests. man mono-service for more details. :) On 4/6/07, Louis R. Marascio wrote: > Travis Miller wrote: > >in a previous life as a physics postdoc, I wrote quite a bit of cluster > >computing code (mostly stuff for lattice quantum field theory) using MPI and > >C. Lately I have been revisiting some of this code using C#. I have > >written some simple pde solvers using c# and have been very impressed with > >the performance. Now I am trying to using the features in > >System.Runtime.Remoting to distribute the load among several machines. I > >can get it to work, but I have to run from machine to machine and start the > >code manually. In the linux cluster world (thanks to tools like rsh or ssh) > >you could start the executables remotely. Is there some way I can > >accomplish this using mono? > > Travis, > > Why can't you use ssh to start the mono application prior to attempting > a remoting connection. Alternatively, I suspect you could hack together > some inetd fun to start your mono process when the super server sees a > connection on a given port. I've not done anything similar, but it would > be no different than any other daemon. > > As far as I know there are no built-in facilities in mono or .NET for > this, nor do I believe there should be. > > Best regards! > > Louis > > -- > Louis R. Marascio - www.fitnr.com > ... fixed in the next release ... > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Rafael "Monoman" Teixeira --------------------------------------- "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." George Bernard Shaw From cjcollier at colliertech.org Sat Apr 7 12:37:33 2007 From: cjcollier at colliertech.org (C.J. Adams-Collier) Date: Sat, 07 Apr 2007 09:37:33 -0700 Subject: [Mono-dev] Patch to install gnome-keyring-sharp into the GAC In-Reply-To: References: Message-ID: <1175963853.5297.1.camel@cjcoll-laptop> This looks good to me. On Thu, 2007-04-05 at 14:37 -0600, Boyd Timothy wrote: > If anyone cares to update gnome-keyring-sharp... > > Attached are the files needed to patch gnome-keyring-sharp so it will > install itself into the GAC when doing a make install. Copy the > Gnome.Keyring.key file to the root of the project, apply the patch, > and you'll be good to go. > > -Boyd > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From alp at atoker.com Sat Apr 7 15:43:40 2007 From: alp at atoker.com (Alp Toker) Date: Sat, 07 Apr 2007 20:43:40 +0100 Subject: [Mono-dev] Patch to install gnome-keyring-sharp into the GAC In-Reply-To: <1175820468.3945.98.camel@mirrors.mathematik.uni-bielefeld.de> References: <1175820468.3945.98.camel@mirrors.mathematik.uni-bielefeld.de> Message-ID: <4617F46C.6030408@atoker.com> Miguel de Icaza wrote: > Hello, > >> Attached are the files needed to patch gnome-keyring-sharp so it will >> install itself into the GAC when doing a make install. Copy the >> Gnome.Keyring.key file to the root of the project, apply the patch, >> and you'll be good to go. > > Gonzalo is the developer for Gnome Keyring # and he has left Novell. > > The only issue with installing stuff into the GAC is that once we commit > to install things into the GAC, we have to preserve its API, we can not > remove/change any APIs that are there. > > I do not mind adding the patch, but I would like for someone to step up > and take over maintenance. > > Miguel. I've made the last few commits to this module, and am pretty familiar with it by now. Gonzalo wrote some lovely code. I think I might be able to maintain it, but there are some things I'd want to do before committing to a long-term ABI guarantee for the GAC: * Consider using SecureString for authentication tokens. Even if this class isn't yet "secure" in Mono (I have an implementation in the works, need to check with Seb), I wouldn't be comfortable being responsible for a library that knowingly stores critical data cleartext in the heap. * Make sure all implementation details are internal. * Check with the C gnome keyring implementation to see if there have been additions/deprecations since Gnome.Keyring was written. * Try to get a public API review from the C gnome keyring authors. From chris at bluenoteweb.com Sat Apr 7 19:22:02 2007 From: chris at bluenoteweb.com (Chris Dunning) Date: Sat, 07 Apr 2007 18:22:02 -0500 Subject: [Mono-dev] Trouble installing Message-ID: <4618279A.1010709@bluenoteweb.com> I'm having an issue installing Mono on my server, hopefully someone out there can point me in the right direction. The server runs CentOS 4, kernel 2.6.9-42.0.3.ELsmp. I'm running Apache 1.3.37. I installed mono, xps and mod_mono using yum and the repository available here: http://www.go-mono.com/download-stable/rhel-4-i386 The commands I executed were pretty straightforward: yum install mono* yum install xps* yum install mod_mono Everything appeared to install with no problem. Yum dropped a conf file into /etc/httpd/conf.d which was automatically included when I restarted Apache. The restart failed with this error: Syntax error on line 8 of /etc/httpd/conf.d/mod_mono.conf: Cannot load /usr/lib/httpd/modules/mod_mono.so into server: /usr/lib/httpd/modules/mod_mono.so: undefined symbol: apr_pool_cleanup_null A quick google turned up this page: http://lists.ximian.com/pipermail/mono-devel-list/2006-August/019891.html Following that path, I upgraded apr and related packages to the latest RPMs available on the Apache mirrors. Still no go, same error. What's the next step to check? Thanks in advance to any who can help. From louis at fitnr.com Sat Apr 7 20:38:33 2007 From: louis at fitnr.com (Louis R. Marascio) Date: Sat, 7 Apr 2007 19:38:33 -0500 Subject: [Mono-dev] [PATCH] - System.IO.FileSystemWatcher Unit Tests for Events Message-ID: <20070408003833.GC14789@mindpirate.local> Hi all, Attached is a patch that adds several unit tests for FileSystemWatcher. These tests focus on verifying that the Created, Deleted, and Changed events work properly. This work was driven from my trying to track down bug #80564 wherein the Changed events don't fire properly on OS X. I tested this patch on gentoo with the a mono build from svn, revision 75497. All new tests pass on Linux. As expected, one test is failing on OS X due to bug #80564. I did not run the new tests on Windows. This is my first patch so please let me know if I've done anything wrong. Thanks, Louis -- Louis R. Marascio - www.fitnr.com ... fixed in the next release ... -------------- next part -------------- Index: FileSystemWatcherTest.cs =================================================================== --- FileSystemWatcherTest.cs (revision 75497) +++ FileSystemWatcherTest.cs (working copy) @@ -2,6 +2,7 @@ // // Authors: // Gonzalo Paniagua Javier (gonzalo at ximian.com) +// Louis R. Marascio (louis at fitnr.com) // // (C) 2004 Novell, Inc. http://www.novell.com // @@ -9,6 +10,7 @@ using NUnit.Framework; using System; using System.IO; +using System.Threading; namespace MonoTests.System.IO { @@ -81,6 +83,141 @@ FileSystemWatcher fw = new FileSystemWatcher (Path.GetTempPath (), "*"); fw.Path = "*"; } + + #region FileSystemWatcher Event Tests + + private AutoResetEvent eventFired = new AutoResetEvent (false); + private static string tempPath = Path.Combine (Path.GetTempPath(), + "MonoTests.System.IO.FileSystemWatcherTest"); + private static string tempFile = "FSWTempFile"; + private static string tempFilePath = Path.Combine (tempPath, tempFile); + + // Used to store state from each event call back + private string lastName, lastFullPath; + private WatcherChangeTypes lastChangeType; + + [Test] + public void CheckChangedEvent () + { + // Test various combinations of the Changed event. We pass in a test name, our test + // filename, a test filter, and whether we expect the event to fire or not. + DoChangedEventTest ("ChangedWildcard", tempFilePath, "*.*", true); + DoChangedEventTest ("ChangedSpecificFile", tempFilePath+"2", tempFile+"2", true); + DoChangedEventTest ("ChangedOutsideOfFilter", tempFilePath, "fooFilter", false); + DoChangedEventTest ("ChangedFilterExtGood", tempFilePath+".abc", "*.abc", true); + DoChangedEventTest ("ChangedFilterExtBad", tempFilePath+".xyz", "*.abc", false); + } + + // Test various combinations of the changed event handler. + public void DoChangedEventTest (string testName, string filename, string filter, bool eventExpected) + { + MakeTempDir (); + + // Open our temporary file and write some initial data, before we start monitoring for events. + using (StreamWriter w = new StreamWriter (filename)) { + w.WriteLine ("foo"); + } + + FileSystemWatcher fw = new FileSystemWatcher (tempPath, filter); + fw.Changed += new FileSystemEventHandler (OnFileSystemWatcherEvent); + fw.EnableRaisingEvents = true; + + // Now that we're monitoring for Changed events, write some more data to the same file. + using (StreamWriter w = new StreamWriter (filename, true)) { + w.WriteLine ("bar"); + } + + bool gotEvent = eventFired.WaitOne (1000, true); + + fw.EnableRaisingEvents = false; + fw.Dispose (); + + AssertEquals (testName+"-#15", gotEvent, eventExpected); + if (eventExpected) { + AssertEquals (testName+"-#16", filename, lastFullPath); + AssertEquals (testName+"-#17", WatcherChangeTypes.Changed, lastChangeType); + } + + lastName = lastFullPath = null; + } + + [Test] + public void CheckCreatedEvent () + { + MakeTempDir (); + + // Make sure the file isn't there before we try to create it + if (File.Exists(tempFilePath)) + File.Delete (tempFilePath); + + FileSystemWatcher fw = new FileSystemWatcher (tempPath); + fw.Created += new FileSystemEventHandler (OnFileSystemWatcherEvent); + fw.EnableRaisingEvents = true; + + // Now that we're monitoring for Created events, create the file. + File.Create (tempFilePath); + + bool gotEvent = eventFired.WaitOne (1000, true); + + fw.EnableRaisingEvents = false; + fw.Dispose (); + + AssertEquals ("#07", gotEvent, true); + AssertEquals ("#08", tempFile, lastName); + AssertEquals ("#09", tempFilePath, lastFullPath); + AssertEquals ("#10", WatcherChangeTypes.Created, lastChangeType); + + lastName = lastFullPath = null; + } + + [Test] + public void CheckDeletedEvent () + { + MakeTempDir (); + + // Make sure the file does exist before we try to delete it + if (!File.Exists(tempFilePath)) + File.Create (tempFilePath); + + FileSystemWatcher fw = new FileSystemWatcher (tempPath); + fw.Deleted += new FileSystemEventHandler (OnFileSystemWatcherEvent); + fw.EnableRaisingEvents = true; + + // Now that we're monitoring for Deleted events, remove the file. + File.Delete (tempFilePath); + + bool gotEvent = eventFired.WaitOne (1000, true); + + fw.EnableRaisingEvents = false; + fw.Dispose (); + + AssertEquals ("#11", gotEvent, true); + AssertEquals ("#12", tempFile, lastName); + AssertEquals ("#13", tempFilePath, lastFullPath); + AssertEquals ("#14", WatcherChangeTypes.Deleted, lastChangeType); + + lastName = lastFullPath = null; + } + + // One event handler for all of our tests. Just save the relevant data + // so the individual test can assert on it. + private void OnFileSystemWatcherEvent (object source, FileSystemEventArgs e) + { + lastName = e.Name; + lastFullPath = e.FullPath; + lastChangeType = e.ChangeType; + eventFired.Set (); + } + + // Helper to make sure the temporary directory is happy + private void MakeTempDir () + { + if(Directory.Exists (tempPath)) + Directory.Delete (tempPath, true); + Directory.CreateDirectory (tempPath); + } + + #endregion } } Index: ChangeLog =================================================================== --- ChangeLog (revision 75497) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2007-04-07 Louis R. Marascio + * FileSystemWatcherTest.cs: add unit tests for Created, Deleted + and Changed events. + 2004-01-16 Gonzalo Paniagua Javier * FileSystemWatcherTest.cs: new test. From andreas.faerber at web.de Sun Apr 8 17:08:16 2007 From: andreas.faerber at web.de (Andreas =?ISO-8859-1?Q?F=E4rber?=) Date: Sun, 08 Apr 2007 23:08:16 +0200 Subject: [Mono-dev] SVN commit problem Message-ID: <1176066496.1054.22.camel@sonnengoettin> Hello, When trying to commit I keep getting a timeout: Sending ChangeLog Sending configure.in Sending mono/mini/ChangeLog Sending mono/mini/mini-amd64.h Transmitting file data ....Lesen vom entfernten Host mono-cvs.ximian.com: Zeitlimit f?r Verbindung ?berschritten svn: Commit failed (details follow): svn: Connection closed unexpectedly Updating works fine. Is there some SVN setting I need to apply? Any ideas? Andreas From js at hotfeet.ch Mon Apr 9 12:17:06 2007 From: js at hotfeet.ch (Juraj Skripsky) Date: Mon, 09 Apr 2007 18:17:06 +0200 Subject: [Mono-dev] [PATCH] Optimized Dictionary`2 Message-ID: <1176135426.3780.23.camel@funnyfarm.hotfeet.ch> Hello, Attached is a zip file containing an thoroughly optimized version of Dictionary`2 along with a few performance tests. On my system, the time spent in a single test shrinks by 25%-40% (depending on the test). Extract the zip file, and run - "mono DictBench.exe 10 old" or - "mono DictBench.exe 10 new" This runs the performance test suite for about 10 seconds. The first one uses the Dictionary`2 implementation from the class libs, the second uses the new, optimized version. Please review. - Juraj -------------- next part -------------- A non-text attachment was scrubbed... Name: NewDictionary.zip Type: application/zip Size: 20286 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070409/9382a117/attachment.zip From olivier.duff at free.fr Fri Apr 6 02:00:28 2007 From: olivier.duff at free.fr (olivier.duff at free.fr) Date: Fri, 06 Apr 2007 08:00:28 +0200 Subject: [Mono-dev] Binding navigator patch In-Reply-To: <461597EA.9040804@jpobst.com> References: <1175629946.4612b07a95196@imp.free.fr> <461597EA.9040804@jpobst.com> Message-ID: <1175839228.4615e1fc74552@imp.free.fr> Ok, I think it is thanks to my version of Mono.Posix (the link was bad) because I use my own Mono.posix version. So I have compile it and fix it( missing public attribut on class + resource). So here is my new patch with test run on MS.NET. PS: I use Locale.GetText("of {0}"); So if can add it in resource files. Olivier Dufour (duff) Selon Jonathan Pobst : > Often times we don't keep the VS projects in sync with the .sources file > used to build mono. Generally you already have the file from SVN, you > just need to add it to your project. In this case, the file should be > EventLogger.cs. > > Jon > > > olivier.duff at free.fr wrote: > > Hi, > > > > For my second patch, I have take the first class missing in mono winforms > ;). > > I have try to fit to coding guideline. If there are still issue, make a > feed > > back... > > I have issue on winforms test project because Eventlogger is not recognize. > So I > > can not compile it and launch test. So maybe my test do not pass on windows > > dlls. > > So, if someone know how fix that, I will test it and resend the patch. > > regards, > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: BindingNavigator2.patch Type: application/octet-stream Size: 14572 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070406/8658baea/attachment.obj From jonpryor at vt.edu Wed Apr 11 05:41:03 2007 From: jonpryor at vt.edu (Jonathan Pryor) Date: Wed, 11 Apr 2007 05:41:03 -0400 Subject: [Mono-dev] Binding navigator patch In-Reply-To: <1175839228.4615e1fc74552@imp.free.fr> References: <1175629946.4612b07a95196@imp.free.fr> <461597EA.9040804@jpobst.com> <1175839228.4615e1fc74552@imp.free.fr> Message-ID: <1176284464.17086.32.camel@melchior.magi> On Fri, 2007-04-06 at 08:00 +0200, olivier.duff at free.fr wrote: > I think it is thanks to my version of Mono.Posix (the link was bad) because I > use my own Mono.posix version. What exactly is the change you make to Mono.Posix? If it's good, we might want to integrate it into Mono.Posix. - Jon From cornish.julia at googlemail.com Wed Apr 11 06:16:30 2007 From: cornish.julia at googlemail.com (Julia Cornish) Date: Wed, 11 Apr 2007 11:16:30 +0100 Subject: [Mono-dev] Strange behaviour when using raw sockets. Message-ID: <25dbeee20704110316u351eef52i9e2447f298525149@mail.gmail.com> Hi, I'm writing a port scanning application that sends a SYN packet to a port on a host, identifying the status of the port by whether it returns a SYN/ACK, an ACK/RST or nothing at all. In the example code below, I'm sending a SYN to port 80 and the source port of my machine is 2126. When I use a remote host (such as one of Google's IP addresses in the example below), the SYN/ACK from Google port 80 is received by my machine on port 2126, as expected. However, when I try to send a SYN packet to port 80 on my own computer using any of the available IPs that identify my machine, locSocket on port 2126 receives the packet I sent that was intended for port 80. In other words, I send a packet to port 80 on my machine and it shows up on port 2126 instead. When I use Wireshark to see what is happening in the network layer, I don't see this discrepancy - Wireshark identifies my SYN packet going from port 2126 to port 80 and the response packet going from port 80 to port 2126. Can anyone help explain what is happening - basically why my application behaves as expected when I try to scan a server half way across the globe but when I try to scan my own machine the packets aren't making their way to my application the way they should? I've attached code below showing what I'm doing with the remote endpoint. The code I've skipped deals with building a TCP SYN packet and computing its checksum. IPAddress remoteIP = IPAddress.Parse ("64.233.187.99"); IPEndPoint remoteEndPoint = new IPEndPoint (remoteIP, port); System.Net.Sockets.Socket locSocket = new System.Net.Sockets.Socket (AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Tcp); System.Net.Sockets.Socket remSocket = new System.Net.Sockets.Socket (AddressFamily.InterNetwork, SocketType.Raw, ProtocolType.Tcp); locSocket.Bind (new IPEndPoint (locIP, 2126)); /* Code to create a packet of data (byte[] datagram) goes here */ byte[] receivedPacket = new byte[96]; Console.WriteLine ("Sending packet..."); remSocket.SendTo (datagram, remoteEndPoint); Console.WriteLine ("Packet sent"); locSocket.Receive (receivedPacket); -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070411/86487caf/attachment.html From wberrier at novell.com Wed Apr 11 15:31:41 2007 From: wberrier at novell.com (Wade Berrier) Date: Wed, 11 Apr 2007 13:31:41 -0600 Subject: [Mono-dev] [Fwd: Re: [Mono-list] New anonymous subversion hostname] Message-ID: <1176319901.12994.8.camel@miniwade.site> Notice to all using the anonymous subversion repository: svn.myrealbox.com has been renamed to anonsvn.mono-project.com Wade -------------- next part -------------- An embedded message was scrubbed... From: Wade Berrier Subject: Re: [Mono-list] New anonymous subversion hostname Date: Wed, 11 Apr 2007 12:06:52 -0600 Size: 1156 Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070411/8f00c0c9/attachment.mht From mark at ijbema.xs4all.nl Thu Apr 12 03:57:43 2007 From: mark at ijbema.xs4all.nl (Mark IJbema) Date: Thu, 12 Apr 2007 09:57:43 +0200 Subject: [Mono-dev] [Fwd: Re: [Mono-list] New anonymous subversion hostname] In-Reply-To: <1176319901.12994.8.camel@miniwade.site> References: <1176319901.12994.8.camel@miniwade.site> Message-ID: <20070412075743.GU4173@ijbema.xs4all.nl> Hoping that the person maintining the svn rss feed is on this list, will it be updated to reflect this new url? Regards, Mark On Wed, Apr 11, 2007 at 01:31:41PM -0600, Wade Berrier wrote: > Notice to all using the anonymous subversion repository: > > svn.myrealbox.com has been renamed to anonsvn.mono-project.com > > Wade Content-Description: Forwarded message - Re: [Mono-list] New anonymous subversion hostname > Subject: Re: [Mono-list] New anonymous subversion hostname > From: Wade Berrier > To: mono-list at lists.ximian.com > > Wow, the dns name svn.myrealbox.com has been turned off already. That > happened much sooner than I expected. > > Sorry about the short notice, > > Wade > > On Tue, 2007-04-10 at 18:35 -0600, Wade Berrier wrote: > > On Tue, 2007-04-10 at 20:31 -0400, Joshua Tauberer wrote: > > > Wade Berrier wrote: > > > > There is a simple way to migrate existing svn repositories to use the > > > > new hostname. > > > > > > Slightly simpler :) is to use: > > > > Haha, MUCH simpler, thanks :) > > > > > > _______________________________________________ > > Mono-list maillist - Mono-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-list > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From vladimirk at mainsoft.com Thu Apr 12 07:12:10 2007 From: vladimirk at mainsoft.com (Vladimir Krasnov) Date: Thu, 12 Apr 2007 04:12:10 -0700 Subject: [Mono-dev] System.Web.HttpRequest.Params collection optimization Message-ID: Hello, Please review a performance optimization for HttpRequest.Params collection. This collection contains ServerVariables, Form, QueryString and Cookies collections merged into one and expensive to initialize if someone uses Params collection to get values from query string, for example. So it uses lazy initialization. Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: HttpParamsCollection.cs.patch Type: application/octet-stream Size: 4281 bytes Desc: HttpParamsCollection.cs.patch Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070412/aa8ab3a6/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: HttpRequest.cs.patch Type: application/octet-stream Size: 897 bytes Desc: HttpRequest.cs.patch Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070412/aa8ab3a6/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: System.Web.dll.sources.patch Type: application/octet-stream Size: 446 bytes Desc: System.Web.dll.sources.patch Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070412/aa8ab3a6/attachment-0002.obj From grendello at gmail.com Thu Apr 12 07:48:54 2007 From: grendello at gmail.com (Marek Habersack) Date: Thu, 12 Apr 2007 13:48:54 +0200 Subject: [Mono-dev] System.Web.HttpRequest.Params collection optimization In-Reply-To: References: Message-ID: <20070412134854.51ef4e81@beowulf.thanes.org> On Thu, 12 Apr 2007 04:12:10 -0700, "Vladimir Krasnov" scribbled: > Hello, Hello, > Please review a performance optimization for HttpRequest.Params > collection. This collection contains ServerVariables, Form, QueryString > and Cookies collections merged into one and expensive to initialize if > someone uses Params collection to get values from query string, for > example. So it uses lazy initialization. It looks ok, please commit. Thanks! regards, marek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070412/4ab7cd45/attachment.bin From ddobrev at crossroad.bg Thu Apr 12 10:52:45 2007 From: ddobrev at crossroad.bg (Dimiter Dobrev (Crossroad)) Date: Thu, 12 Apr 2007 17:52:45 +0300 Subject: [Mono-dev] Using Reflector File Generator Add-Ins Message-ID: Hello. I'd like to ask you if it is possible to to port .NET assemblies to Mono using the .NET Reflector file generator add-ins (http://www.codeplex.com/reflectoraddins), which can generate a project with the full source code from a disassembled assembly. I think it is quite a time saver; it is true that Reflector makes mistakes, btu they could be corrected by using ildasm. Have you ever used this? Thank you in advance for your time. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070412/cc0781c2/attachment.html From olivier.duff at free.fr Fri Apr 13 03:32:23 2007 From: olivier.duff at free.fr (olivier.duff at free.fr) Date: Fri, 13 Apr 2007 09:32:23 +0200 Subject: [Mono-dev] Binding navigator patch In-Reply-To: <1176284464.17086.32.camel@melchior.magi> References: <1175629946.4612b07a95196@imp.free.fr> <461597EA.9040804@jpobst.com> <1175839228.4615e1fc74552@imp.free.fr> <1176284464.17086.32.camel@melchior.magi> Message-ID: <1176449543.461f3207e38f0@imp.free.fr> Hi, No, I have made no modification in Mono.posix, I just use one from another project because the reference is yellow in my project. For my patch, I have sucessfully run text with MS.net. The compilation error is there because some file is missing in project file. I have send in a previous mail a patch wich contain the BindingNavigator class with the test class (and some fix since my first mail). So can you make a feed back on it to know if there is an issue on it. It is not fully implemented but I have add all member and some code when I know what I must add. bye, Olivier Dufour (Duff) Selon Jonathan Pryor : > On Fri, 2007-04-06 at 08:00 +0200, olivier.duff at free.fr wrote: > > I think it is thanks to my version of Mono.Posix (the link was bad) because > I > > use my own Mono.posix version. > > What exactly is the change you make to Mono.Posix? If it's good, we > might want to integrate it into Mono.Posix. > > - Jon > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From matthijsterwoord at gmail.com Sat Apr 14 05:30:48 2007 From: matthijsterwoord at gmail.com (Matthijs ter Woord) Date: Sat, 14 Apr 2007 11:30:48 +0200 Subject: [Mono-dev] Using Reflector File Generator Add-Ins In-Reply-To: References: Message-ID: Decompiling is not allowed. IIRC, this is a faq on the mono website... Dimiter Dobrev (Crossroad) wrote: > Hello. I?d like to ask you if it is possible to to port .NET assemblies > to Mono using the .NET Reflector file generator add-ins > (http://www.codeplex.com/reflectoraddins), which can generate a project > with the full source code from a disassembled assembly. I think it is > quite a time saver; it is true that Reflector makes mistakes, btu they > could be corrected by using ildasm. Have you ever used this? Thank you > in advance for your time. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From fn30762 at fmi.uni-sofia.bg Sun Apr 15 06:01:38 2007 From: fn30762 at fmi.uni-sofia.bg (Anton Andreev) Date: Sun, 15 Apr 2007 13:01:38 +0300 Subject: [Mono-dev] mono on nexenta Message-ID: <4621F802.8000509@fmi.uni-sofia.bg> Hi, I downloaded the source from http://mono.ximian.com/daily. I did successfully compiled it on Nexenta alpha 6, but I do not see the ASP.NET files like xsp or mod-mono? Cheers, Anton From everaldo at simios.org Sun Apr 15 06:48:15 2007 From: everaldo at simios.org (Everaldo Canuto) Date: Sun, 15 Apr 2007 07:48:15 -0300 Subject: [Mono-dev] mono on nexenta In-Reply-To: <4621F802.8000509@fmi.uni-sofia.bg> References: <4621F802.8000509@fmi.uni-sofia.bg> Message-ID: <53b944780704150348m7ae5fba1of98ad2061c5550ac@mail.gmail.com> Hey, The xsp and mod-mono is not included in daily packages. You must download xsp and mod-mono from Download page: http://www.mono-project.com/Downloads or from svn: svn co svn://anonsvn.mono-project.com/source/trunk/xsp svn co svn://anonsvn.mono-project.com/source/trunk/mod_mono Everaldo On 4/15/07, Anton Andreev wrote: > Hi, > > I downloaded the source from http://mono.ximian.com/daily. > > I did successfully compiled it on Nexenta alpha 6, but I do not see the > ASP.NET files like xsp or mod-mono? > > > Cheers, > Anton > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From ClassDevelopment at A-SoftTech.com Mon Apr 16 02:54:21 2007 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Mon, 16 Apr 2007 08:54:21 +0200 Subject: [Mono-dev] Using Reflector File Generator Add-Ins In-Reply-To: References: Message-ID: I do not see any use for this at all. Normally a .Net assembly should run unchanged when used on mono, so there is no need to do this. If it doesn't (because of e.g. pinvokes) getting source does not help because you are not allowed to disassemble/change/reassemble 3rd party libraries. And IF you are allowed (because they are OSS or you have the rights to) then you usually have the sourcecode in the first place anyways. _____ Von: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag von Dimiter Dobrev (Crossroad) Gesendet: Donnerstag, 12. April 2007 16:53 An: mono-devel-list at lists.ximian.com Betreff: [Mono-dev] Using Reflector File Generator Add-Ins Hello. I'd like to ask you if it is possible to to port .NET assemblies to Mono using the .NET Reflector file generator add-ins (http://www.codeplex.com/reflectoraddins), which can generate a project with the full source code from a disassembled assembly. I think it is quite a time saver; it is true that Reflector makes mistakes, btu they could be corrected by using ildasm. Have you ever used this? Thank you in advance for your time. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070416/f3525aa9/attachment.html From Anton.Andreev at fmi.uni-sofia.bg Mon Apr 16 02:50:56 2007 From: Anton.Andreev at fmi.uni-sofia.bg (Anton Andreev) Date: Mon, 16 Apr 2007 09:50:56 +0300 (EEST) Subject: [Mono-dev] mono on nexenta Message-ID: <34984.77.70.30.85.1176706256.squirrel@poshta.fmi.uni-sofia.bg> Hi, I have this error while trying to compile xsp on Nexenta alpha 6. Makefile:339: *** missing separator. Stop. I downloaded the source from svn on a windows machine, zip it and then send it to a Nexenta system. Could it be a problem with the lines endings? Anton From darek.lin at gmail.com Mon Apr 16 05:41:41 2007 From: darek.lin at gmail.com (darlin) Date: Mon, 16 Apr 2007 02:41:41 -0700 (PDT) Subject: [Mono-dev] Start subprogram from ASP.NET Message-ID: <10013049.post@talk.nabble.com> Hi, Can somebody advise me which way I can start/stop/check status, some Linux program witch parameters from ASP.net page based on mono? On windows I used System.Diagnostics proccess class but it don't work on mono. I received: System.ComponentModel.Win32Exception: Cannot find the specified file -- View this message in context: http://www.nabble.com/Start-subprogram-from-ASP.NET-tf3583404.html#a10013049 Sent from the Mono - Dev mailing list archive at Nabble.com. From monoman at gmail.com Mon Apr 16 09:05:49 2007 From: monoman at gmail.com (Rafael Teixeira) Date: Mon, 16 Apr 2007 10:05:49 -0300 Subject: [Mono-dev] Start subprogram from ASP.NET In-Reply-To: <10013049.post@talk.nabble.com> References: <10013049.post@talk.nabble.com> Message-ID: Are you using mod_mono? If so the user account your ASP.NET app runs under may not have permission to find/run the linux native executable... But the message you gave us