From jb at nurv.fr Thu May 1 03:30:15 2008 From: jb at nurv.fr (Jb Evain) Date: Thu, 1 May 2008 09:30:15 +0200 Subject: [Mono-dev] Mono profiles / .NET Framework versions In-Reply-To: <1209601944.5583.102.camel@frost> References: <20080430104130.1B288A0025@winston.telenet-ops.be> <1209601944.5583.102.camel@frost> Message-ID: <69f7d8470805010030j73e1ad1s13de67006980bfc@mail.gmail.com> Hey Miguel, On 5/1/08, Miguel de Icaza wrote: > The problem with this discussion is that you guys did not understand the > reason for the current split. That's not very fair, i think we do. The main point was saying that currently, for the traditional .net aware programmer, coming from windows, and being used to the Microsoft terminology and versions, it's confusing to have assemblies from the .net 3.5 release in different profiles. And we were just wondering if we could improve one that. And the small discussion we had, was mainly about finding a way to reduce the confusion. I understand that there's no way in moving Sys.Core around, which is probably the biggest source of questions, (why Sys.Core is not in the 3.5 profile), because you would simply not be able to reference it. The biggest issue I have right now with the 3.5 profile, is that I have a bunch of libraries in it that should go to the 2.0 profile if we want to be consistent (but maybe my installation folder is bloated with old stuff). > > For tools, grendel proposed to have our wrapper scripts accept a profile > > version parameter. When the parameter is not specified, the scripts would > > default to the lastest profile version. Both jb and myself liked this idea. > > > This is a horrible idea, but its understandable that you guys > entertained the idea, because you guys did not understand profiles > (which are foundations) vs packages. Somehow, this particular issue is not much related to the previous issue. This one is about the confusion of using mcs/gmcs, ilasm1/ilasm2, al1/al2, etc. One suggestion was to have shell scripts that always launch the last version installed. Like a ilasm script that would launch ilasm2 if installed, or ilasm1. I don't understand why you think it's an horrible idea, while last time I heard, you were supporting the idea of having such a script for mcs. -- Jb Evain From alan.mcgovern at gmail.com Thu May 1 04:25:50 2008 From: alan.mcgovern at gmail.com (Alan McGovern) Date: Thu, 1 May 2008 09:25:50 +0100 Subject: [Mono-dev] JIT and Inlining - why doesn't it happen? In-Reply-To: <8cca42d80804301624p8f2d457g2dc51ff88d2c8b6a@mail.gmail.com> References: <117799f00804301411o27054325xe65c3204efe46c30@mail.gmail.com> <8cca42d80804301432u63648eedgd6288cdf342257da@mail.gmail.com> <117799f00804301438n1de8d6b0p95d22cc2732d4d6c@mail.gmail.com> <8cca42d80804301624p8f2d457g2dc51ff88d2c8b6a@mail.gmail.com> Message-ID: <117799f00805010125wea17edcq75d9f243b39f49b7@mail.gmail.com> Hi, That makes sense. I was just quite surprised at the time that the methods were not being inlined as they were only simple maths operations. I checked monodis for one of the methods and it turned out to be 8 IL instructions, which is probably 24 bytes, which would explain why it wasn't inlined. Alan. On Thu, May 1, 2008 at 12:24 AM, Rodrigo Kumpera wrote: > Well, the inliner basically eliminates the penalty from using properties > and empty constructors. > > Increasing the inline threshold is tricky and might now be worthy as there > are too many situations that abort inlining. So it would significantly > increase JIT time for diminishing gains. > > > > On Wed, Apr 30, 2008 at 6:38 PM, Alan McGovern > wrote: > > > This method does not get inlined: > > > > private uint Ch (uint u, uint v, uint w) > > { > > return (u&v) ^ (~u&w); > > } > > > > If that isn't inlined then don't ask me what kind of method *could* be > > inlined by the JIT. > > > > Alan. > > > > > > On Wed, Apr 30, 2008 at 11:32 PM, Rodrigo Kumpera > > wrote: > > > > > Mono only inline very short methods. Right now methods must have a > > > body at most 20 bytes long. > > > > > > > > > > > > 2008/4/30 Alan McGovern : > > > > > > > I recently started doing a bit of optimisation work on the > > > > hashing/cryptography classes in mono. When working on the managed SHA256 > > > > class[1], i noticed that mono isn't inlining what i'd consider some *very* > > > > simple methods. > > > > > > > > The helper methods which do the bitshifting (Ro0, Ro1, Ch, Maj etc) > > > > aren't inlined! Each of these methods is only called once in the code. By > > > > manually inlining those method calls, performance increased significantly - > > > > about 70%. Why isn't mono inlining these methods? Can mono be made inline > > > > these? > > > > > > > > Alan. > > > > > > > > [1] > > > > http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/corlib/System.Security.Cryptography/SHA256Managed.cs?rev=46462&view=markup > > > > > > > > _______________________________________________ > > > > Mono-devel-list mailing list > > > > Mono-devel-list at lists.ximian.com > > > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080501/5dbef48d/attachment.html From ClassDevelopment at A-SoftTech.com Thu May 1 05:28:34 2008 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Thu, 1 May 2008 11:28:34 +0200 Subject: [Mono-dev] JIT and Inlining - why doesn't it happen? In-Reply-To: <117799f00805010125wea17edcq75d9f243b39f49b7@mail.gmail.com> References: <117799f00804301411o27054325xe65c3204efe46c30@mail.gmail.com> <8cca42d80804301432u63648eedgd6288cdf342257da@mail.gmail.com> <117799f00804301438n1de8d6b0p95d22cc2732d4d6c@mail.gmail.com> <8cca42d80804301624p8f2d457g2dc51ff88d2c8b6a@mail.gmail.com> <117799f00805010125wea17edcq75d9f243b39f49b7@mail.gmail.com> Message-ID: <008401c8ab6d$ba70f8d0$2f52ea70$@com> I just checked the R01/R02 methods and they both have 20 IL instructions with 22 bytes of IL code, so this is pretty much a corner case. However the Ch method that you mention has a mere 9 IL instructions and only 9 bytes of IL code, so this does not explain why it doesn't get inlined if the threshold is 20 bytes of IL. Greetings Andreas Von: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag von Alan McGovern Gesendet: Donnerstag, 1. Mai 2008 10:26 An: Rodrigo Kumpera Cc: mono-devel Betreff: Re: [Mono-dev] JIT and Inlining - why doesn't it happen? Hi, That makes sense. I was just quite surprised at the time that the methods were not being inlined as they were only simple maths operations. I checked monodis for one of the methods and it turned out to be 8 IL instructions, which is probably 24 bytes, which would explain why it wasn't inlined. Alan. On Thu, May 1, 2008 at 12:24 AM, Rodrigo Kumpera wrote: Well, the inliner basically eliminates the penalty from using properties and empty constructors. Increasing the inline threshold is tricky and might now be worthy as there are too many situations that abort inlining. So it would significantly increase JIT time for diminishing gains. On Wed, Apr 30, 2008 at 6:38 PM, Alan McGovern wrote: This method does not get inlined: private uint Ch (uint u, uint v, uint w) { return (u&v) ^ (~u&w); } If that isn't inlined then don't ask me what kind of method *could* be inlined by the JIT. Alan. On Wed, Apr 30, 2008 at 11:32 PM, Rodrigo Kumpera wrote: Mono only inline very short methods. Right now methods must have a body at most 20 bytes long. 2008/4/30 Alan McGovern : I recently started doing a bit of optimisation work on the hashing/cryptography classes in mono. When working on the managed SHA256 class[1], i noticed that mono isn't inlining what i'd consider some *very* simple methods. The helper methods which do the bitshifting (Ro0, Ro1, Ch, Maj etc) aren't inlined! Each of these methods is only called once in the code. By manually inlining those method calls, performance increased significantly - about 70%. Why isn't mono inlining these methods? Can mono be made inline these? Alan. [1]http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/corlib/System.Sec urity.Cryptography/SHA256Managed.cs?rev=46462 &view=markup _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080501/4fa352ab/attachment.html From vargaz at gmail.com Thu May 1 07:47:04 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Thu, 1 May 2008 13:47:04 +0200 Subject: [Mono-dev] JIT and Inlining - why doesn't it happen? In-Reply-To: <117799f00804301438n1de8d6b0p95d22cc2732d4d6c@mail.gmail.com> References: <117799f00804301411o27054325xe65c3204efe46c30@mail.gmail.com> <8cca42d80804301432u63648eedgd6288cdf342257da@mail.gmail.com> <117799f00804301438n1de8d6b0p95d22cc2732d4d6c@mail.gmail.com> Message-ID: <295e750a0805010447h2b168b13ke634a2abcfa9f279@mail.gmail.com> Hi, On my amd64 machine, that method does get inlined. You can check the output of mono -v -v -v -v for INLINE lines to see what gets inlined. Zoltan 2008/4/30 Alan McGovern : > This method does not get inlined: > > private uint Ch (uint u, uint v, uint w) > { > return (u&v) ^ (~u&w); > } > > If that isn't inlined then don't ask me what kind of method *could* be > inlined by the JIT. > > Alan. > > > > On Wed, Apr 30, 2008 at 11:32 PM, Rodrigo Kumpera wrote: > > Mono only inline very short methods. Right now methods must have a body at > most 20 bytes long. > > > > > > > > > > 2008/4/30 Alan McGovern : > > > > > > > > > > > > > > I recently started doing a bit of optimisation work on the > hashing/cryptography classes in mono. When working on the managed SHA256 > class[1], i noticed that mono isn't inlining what i'd consider some *very* > simple methods. > > > > > > The helper methods which do the bitshifting (Ro0, Ro1, Ch, Maj etc) > aren't inlined! Each of these methods is only called once in the code. By > manually inlining those method calls, performance increased significantly - > about 70%. Why isn't mono inlining these methods? Can mono be made inline > these? > > > > > > Alan. > > > > > > > [1]http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/corlib/System.Security.Cryptography/SHA256Managed.cs?rev=46462&view=markup > > > > > > _______________________________________________ > > > Mono-devel-list mailing list > > > Mono-devel-list at lists.ximian.com > > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > > > > > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From alan.mcgovern at gmail.com Thu May 1 08:19:45 2008 From: alan.mcgovern at gmail.com (Alan McGovern) Date: Thu, 1 May 2008 13:19:45 +0100 Subject: [Mono-dev] JIT and Inlining - why doesn't it happen? In-Reply-To: <295e750a0805010447h2b168b13ke634a2abcfa9f279@mail.gmail.com> References: <117799f00804301411o27054325xe65c3204efe46c30@mail.gmail.com> <8cca42d80804301432u63648eedgd6288cdf342257da@mail.gmail.com> <117799f00804301438n1de8d6b0p95d22cc2732d4d6c@mail.gmail.com> <295e750a0805010447h2b168b13ke634a2abcfa9f279@mail.gmail.com> Message-ID: <117799f00805010519i3d26193ds52b7c8c715fa0572@mail.gmail.com> Hi, The method ch does get inlined alright: INLINE START 00B23210 System.Security.Cryptography.SHA256Managed:ProcessBlock (byte[],int) -> System.Security.Cryptography.SHA256Managed:Ch (uint,uint,uint) created temp 24 of type System.UInt32 method to IR System.Security.Cryptography.SHA256Managed:Ch (uint,uint,uint) created temp 25 of type System.Security.Cryptography.SHA256Managed created temp 26 of type System.UInt32 created temp 27 of type System.UInt32 created temp 28 of type System.UInt32 INLINE END System.Security.Cryptography.SHA256Managed:ProcessBlock (byte[],int) -> System.Security.Cryptography.SHA256Managed:Ch (uint,uint,uint) However, if i manually replace: Ch(e, f, g); with ((e&f) ^ (~e&g)) I get an 10% performance boost (give or take). Surely if the method was getting inlined, that wouldn't be the case. Could it be that the temp variables (25->28) aren't being dropped and there is excess variable copying going on? Alan. On Thu, May 1, 2008 at 12:47 PM, Zoltan Varga wrote: > Hi, > > On my amd64 machine, that method does get inlined. You can check the > output of mono -v -v -v -v for INLINE lines to see what gets inlined. > > Zoltan > > 2008/4/30 Alan McGovern : > > This method does not get inlined: > > > > private uint Ch (uint u, uint v, uint w) > > { > > return (u&v) ^ (~u&w); > > } > > > > If that isn't inlined then don't ask me what kind of method *could* be > > inlined by the JIT. > > > > Alan. > > > > > > > > On Wed, Apr 30, 2008 at 11:32 PM, Rodrigo Kumpera > wrote: > > > Mono only inline very short methods. Right now methods must have a > body at > > most 20 bytes long. > > > > > > > > > > > > > > > 2008/4/30 Alan McGovern : > > > > > > > > > > > > > > > > > > > I recently started doing a bit of optimisation work on the > > hashing/cryptography classes in mono. When working on the managed SHA256 > > class[1], i noticed that mono isn't inlining what i'd consider some > *very* > > simple methods. > > > > > > > > The helper methods which do the bitshifting (Ro0, Ro1, Ch, Maj etc) > > aren't inlined! Each of these methods is only called once in the code. > By > > manually inlining those method calls, performance increased > significantly - > > about 70%. Why isn't mono inlining these methods? Can mono be made > inline > > these? > > > > > > > > Alan. > > > > > > > > > > [1] > http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/corlib/System.Security.Cryptography/SHA256Managed.cs?rev=46462&view=markup > > > > > > > > _______________________________________________ > > > > Mono-devel-list mailing list > > > > Mono-devel-list at lists.ximian.com > > > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080501/912ebd91/attachment.html From vargaz at gmail.com Thu May 1 10:12:18 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Thu, 1 May 2008 16:12:18 +0200 Subject: [Mono-dev] JIT and Inlining - why doesn't it happen? In-Reply-To: <117799f00805010519i3d26193ds52b7c8c715fa0572@mail.gmail.com> References: <117799f00804301411o27054325xe65c3204efe46c30@mail.gmail.com> <8cca42d80804301432u63648eedgd6288cdf342257da@mail.gmail.com> <117799f00804301438n1de8d6b0p95d22cc2732d4d6c@mail.gmail.com> <295e750a0805010447h2b168b13ke634a2abcfa9f279@mail.gmail.com> <117799f00805010519i3d26193ds52b7c8c715fa0572@mail.gmail.com> Message-ID: <295e750a0805010712j6dae4381l3d5483091eccc541@mail.gmail.com> Hi, > I get an 10% performance boost (give or take). Surely if the method was > getting inlined, that wouldn't be the case. Could it be that the temp > variables (25->28) aren't being dropped and there is excess variable copying > going on? Yes, the current JIT is not very good at getting rid of copies. Zoltan > > Alan. > > > > On Thu, May 1, 2008 at 12:47 PM, Zoltan Varga wrote: > > Hi, > > > > On my amd64 machine, that method does get inlined. You can check the > > output of mono -v -v -v -v for INLINE lines to see what gets inlined. > > > > Zoltan > > > > > > > > > > 2008/4/30 Alan McGovern : > > > This method does not get inlined: > > > > > > private uint Ch (uint u, uint v, uint w) > > > { > > > return (u&v) ^ (~u&w); > > > } > > > > > > If that isn't inlined then don't ask me what kind of method *could* be > > > inlined by the JIT. > > > > > > Alan. > > > > > > > > > > > > On Wed, Apr 30, 2008 at 11:32 PM, Rodrigo Kumpera > wrote: > > > > Mono only inline very short methods. Right now methods must have a > body at > > > most 20 bytes long. > > > > > > > > > > > > > > > > > > > > 2008/4/30 Alan McGovern : > > > > > > > > > > > > > > > > > > > > > > > > I recently started doing a bit of optimisation work on the > > > hashing/cryptography classes in mono. When working on the managed SHA256 > > > class[1], i noticed that mono isn't inlining what i'd consider some > *very* > > > simple methods. > > > > > > > > > > The helper methods which do the bitshifting (Ro0, Ro1, Ch, Maj etc) > > > aren't inlined! Each of these methods is only called once in the code. > By > > > manually inlining those method calls, performance increased > significantly - > > > about 70%. Why isn't mono inlining these methods? Can mono be made > inline > > > these? > > > > > > > > > > Alan. > > > > > > > > > > > > > > [1]http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/corlib/System.Security.Cryptography/SHA256Managed.cs?rev=46462&view=markup > > > > > > > > > > _______________________________________________ > > > > > 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 joncham at gmail.com Thu May 1 16:52:26 2008 From: joncham at gmail.com (Jonathan Chambers) Date: Thu, 1 May 2008 16:52:26 -0400 Subject: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows (now build with cygwin as well) In-Reply-To: <8cca42d80804281242p561e9am591b6000b266f0a4@mail.gmail.com> References: <001701c8a6b9$aa9967c0$3c43ee55@kornelpal.hu> <295e750a0804250745q2a943463h4d49bfacf3d94e75@mail.gmail.com> <002a01c8a70b$05540390$3c43ee55@kornelpal.hu> <295e750a0804280034u533b311wb2e313b8bacfc1cc@mail.gmail.com> <000b01c8a92d$0e7796c0$d9bbc5d9@kornelpal.hu> <295e750a0804280716u3834a054mf3b1628247f27162@mail.gmail.com> <003a01c8a94b$0c15dd60$3e676250@kornelpal.hu> <8cca42d80804281242p561e9am591b6000b266f0a4@mail.gmail.com> Message-ID: <17c2d80b0805011352p43241b9bn884efba0a399e853@mail.gmail.com> Hello, This patch seems to be the cause of the build failures on Win32: http://mono.ximian.com/monobuild/python/monobuild.py/packagestatus?platform=win-4-i386&package=mono&HEAD_or_RELEASE=HEAD svn rev 102051 does not seem to cause the error on my machine, while svn rev 102052 causes the crash in the buildbot. I did a bit of debugging and we crash in ves_icall_System_Reflection_Assembly_get_fullName with garbage for mass-> aname.name. The MonoAssembly itself seems ok, but the AssemblyName appears to be junk. Not sure if this is the real problem, or if it is just where we crash. Please have a look at this, or revert the patch. Thanks, Jonathan 2008/4/28 Rodrigo Kumpera : > You can add these tests to a subdir of mono/tests/ and require that such > compiler be instaled for them. > We can then ask Wade to install it on our windows build bot and add these > tests to the windows lanes. > > > > > On Mon, Apr 28, 2008 at 1:15 PM, Korn?l P?l wrote: > > > Hi, > > > > > From: Zoltan Varga > > > This looks ok to check in. > > > > Thanks. Committed as r102052. > > > > I have some mixed-mode tests but there is no open source compiler > > supporting > > compilation of mixed mode assemblies. How (source/binary/MSVC project) > > and > > where (in SVN) can I commit some mixed-mode tests? > > > > Korn?l > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080501/59493fd8/attachment.html From jacobgladish at yahoo.com Thu May 1 21:08:14 2008 From: jacobgladish at yahoo.com (Jacob Gladish) Date: Thu, 1 May 2008 18:08:14 -0700 (PDT) Subject: [Mono-dev] Socket Send/Receive Timeout patch Message-ID: <365818.27867.qm@web39501.mail.mud.yahoo.com> This fixes the problem I previously posted regrading NetworkStream Read/Write Timeout properties. Index: Socket.cs =================================================================== --- Socket.cs (revision 101631) +++ Socket.cs (working copy) @@ -1166,9 +1166,12 @@ if (disposed && closed) throw new ObjectDisposedException (GetType ().ToString ()); - return (int)GetSocketOption( + int opt = (int)GetSocketOption( SocketOptionLevel.Socket, SocketOptionName.SendTimeout); + if (opt == 0) + opt = -1; + return opt; } set { if (disposed && closed) @@ -1195,10 +1198,12 @@ get { if (disposed && closed) throw new ObjectDisposedException (GetType ().ToString ()); - - return (int)GetSocketOption( + int opt = (int)GetSocketOption( SocketOptionLevel.Socket, SocketOptionName.ReceiveTimeout); + if (opt == 0) + opt = -1; + return opt; } set { if (disposed && closed) ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From riegmann at informatik.hu-berlin.de Fri May 2 05:20:16 2008 From: riegmann at informatik.hu-berlin.de (Thomas Riegmann) Date: Fri, 02 May 2008 11:20:16 +0200 Subject: [Mono-dev] mscorlib.dll not found - Mono application on OpenMoko Message-ID: <481ADCD0.6040601@informatik.hu-berlin.de> Hello *, I tried building a simple mono application but everytime I get the error that the mscorlib.dll could not be found. (See below for the complete error message.) More precisely: The whole directory '/home/false/moko/build/tmp/staging/i686-linux/usr/lib/mono/1.0/' is missing. Could anybody tell me what is going wrong here, please? Many thanks in advance! Cheers Thomas ERROR BEGIN--> ========================================================================= NOTE: Running task 339 of 363 (ID: 7, /home/false/moko/mymoco/oe/packages/monohello/monohello.bb, do_compile) NOTE: package monohello-0.0.1+svnr9: started NOTE: package monohello-0.0.1+svnr9-r0: task do_compile: started ERROR: function do_compile failed ERROR: log data follows (/home/false/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/monohello-0.0.1+svnr9-r0/temp/log.do_compile.22707) | NOTE: make -j 4 | make[1]: Entering directory `/home/false/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/monohello-0.0.1+svnr9-r0/monohello' | Making all in monohello | make[2]: Entering directory `/home/false/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/monohello-0.0.1+svnr9-r0/monohello/monohello' | mkdir -p bin/Release/ | gmcs -noconfig -codepage:utf8 -warn:4 -optimize+ -out:bin/Release/monohello.exe -target:exe './Main.cs' './AssemblyInfo.cs' -r:System | The assembly mscorlib.dll was not found or could not be loaded. | It should have been installed in the `/home/false/moko/build/tmp/staging/i686-linux/usr/lib/mono/1.0/mscorlib.dll' directory. | make[2]: *** [bin/Release/monohello.exe] Error 1 | make[2]: Leaving directory `/home/false/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/monohello-0.0.1+svnr9-r0/monohello/monohello' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/home/false/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/monohello-0.0.1+svnr9-r0/monohello' | FATAL: oe_runmake failed NOTE: Task failed: /home/false/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/monohello-0.0.1+svnr9-r0/temp/log.do_compile.22707 NOTE: package monohello-0.0.1+svnr9-r0: task do_compile: failed ERROR: TaskFailed event exception, aborting NOTE: package monohello-0.0.1+svnr9: failed ERROR: Build of /home/false/moko/mymoco/oe/packages/monohello/monohello.bb do_compile failed ERROR: Task 7 (/home/false/moko/mymoco/oe/packages/monohello/monohello.bb, do_compile) failed NOTE: Tasks Summary: Attempted 354 tasks of which 354 didn't need to be rerun and 1 failed. ERROR: '/home/false/moko/mymoco/oe/packages/monohello/monohello.bb' failed make: *** [build-package-monohello] Error 1 ======================================================================= From andreas.faerber at web.de Fri May 2 05:42:18 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Fri, 2 May 2008 11:42:18 +0200 Subject: [Mono-dev] mscorlib.dll not found - Mono application on OpenMoko In-Reply-To: <481ADCD0.6040601@informatik.hu-berlin.de> References: <481ADCD0.6040601@informatik.hu-berlin.de> Message-ID: <25BE8C1C-0886-4877-BFED-F9F550A4B208@web.de> Hello Thomas, Am 02.05.2008 um 11:20 schrieb Thomas Riegmann: > I tried building a simple mono application but everytime I get the > error > that the mscorlib.dll could not be found. > (See below for the complete error message.) > More precisely: The whole directory > '/home/false/moko/build/tmp/staging/i686-linux/usr/lib/mono/1.0/' > is missing. > Could anybody tell me what is going wrong here, please? I can't tell what's going wrong in your case, but in general cross- compiling does not build the compilers and libraries; try copying over the missing assembly directories from your host and see if that helps. Andreas > ERROR BEGIN--> > = > = > = > ====================================================================== > NOTE: Running task 339 of 363 (ID: 7, > /home/false/moko/mymoco/oe/packages/monohello/monohello.bb, > do_compile) > NOTE: package monohello-0.0.1+svnr9: started > NOTE: package monohello-0.0.1+svnr9-r0: task do_compile: started > ERROR: function do_compile failed > ERROR: log data follows > (/home/false/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/ > monohello-0.0.1+svnr9-r0/temp/log.do_compile.22707) > > | NOTE: make -j 4 > | make[1]: Entering directory > `/home/false/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/ > monohello-0.0.1+svnr9-r0/monohello' > > | Making all in monohello > | make[2]: Entering directory > `/home/false/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/ > monohello-0.0.1+svnr9-r0/monohello/monohello' > > | mkdir -p bin/Release/ > | gmcs -noconfig -codepage:utf8 -warn:4 -optimize+ > -out:bin/Release/monohello.exe -target:exe './Main.cs' > './AssemblyInfo.cs' -r:System > | The assembly mscorlib.dll was not found or could not be loaded. > | It should have been installed in the > `/home/false/moko/build/tmp/staging/i686-linux/usr/lib/mono/1.0/ > mscorlib.dll' > directory. > | make[2]: *** [bin/Release/monohello.exe] Error 1 > | make[2]: Leaving directory > `/home/false/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/ > monohello-0.0.1+svnr9-r0/monohello/monohello' > > | make[1]: *** [all-recursive] Error 1 > | make[1]: Leaving directory > `/home/false/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/ > monohello-0.0.1+svnr9-r0/monohello' > > | FATAL: oe_runmake failed > NOTE: Task failed: > /home/false/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/ > monohello-0.0.1+svnr9-r0/temp/log.do_compile.22707 > > NOTE: package monohello-0.0.1+svnr9-r0: task do_compile: failed > ERROR: TaskFailed event exception, aborting > NOTE: package monohello-0.0.1+svnr9: failed > ERROR: Build of > /home/false/moko/mymoco/oe/packages/monohello/monohello.bb do_compile > failed > ERROR: Task 7 > (/home/false/moko/mymoco/oe/packages/monohello/monohello.bb, > do_compile) > failed > NOTE: Tasks Summary: Attempted 354 tasks of which 354 didn't need to > be > rerun and 1 failed. > ERROR: '/home/false/moko/mymoco/oe/packages/monohello/monohello.bb' > failed > make: *** [build-package-monohello] Error 1 > > = > ====================================================================== > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From kornelpal at gmail.com Fri May 2 06:07:22 2008 From: kornelpal at gmail.com (=?ISO-8859-1?B?S29ybulsIFDhbA==?=) Date: Fri, 2 May 2008 12:07:22 +0200 Subject: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows (now build with cygwin as well) References: <001701c8a6b9$aa9967c0$3c43ee55@kornelpal.hu> <295e750a0804250745q2a943463h4d49bfacf3d94e75@mail.gmail.com> <002a01c8a70b$05540390$3c43ee55@kornelpal.hu> <295e750a0804280034u533b311wb2e313b8bacfc1cc@mail.gmail.com> <000b01c8a92d$0e7796c0$d9bbc5d9@kornelpal.hu> <295e750a0804280716u3834a054mf3b1628247f27162@mail.gmail.com> <003a01c8a94b$0c15dd60$3e676250@kornelpal.hu> <8cca42d80804281242p561e9am591b6000b266f0a4@mail.gmail.com> <17c2d80b0805011352p43241b9bn884efba0a399e853@mail.gmail.com> Message-ID: <007e01c8ac3c$5168d860$83666250@kornelpal.hu> Hi, > From: "Jonathan Chambers" > This patch seems to be the cause of the build failures on Win32: > http://mono.ximian.com/monobuild/python/monobuild.py/packagestatus?platform=win-4-i386&package=mono&HEAD_or_RELEASE=HEAD I'll look into the problem. Until then please feel free to temporary disable the LoadLibrary feature in SVN: metadata/domain.c :mono_init_internal: #if defined(PLATFORM_WIN32) && !defined(_WIN64) mono_load_coree (); #endif Don't call mono_load_coree at all. Korn?l From riegmann at informatik.hu-berlin.de Fri May 2 11:45:36 2008 From: riegmann at informatik.hu-berlin.de (Thomas Riegmann) Date: Fri, 02 May 2008 17:45:36 +0200 Subject: [Mono-dev] mscorlib.dll not found - Mono application on OpenMoko In-Reply-To: <25BE8C1C-0886-4877-BFED-F9F550A4B208@web.de> References: <481ADCD0.6040601@informatik.hu-berlin.de> <25BE8C1C-0886-4877-BFED-F9F550A4B208@web.de> Message-ID: <481B3720.2000908@informatik.hu-berlin.de> >> I tried building a simple mono application but everytime I get the error >> that the mscorlib.dll could not be found. >> (See below for the complete error message.) >> More precisely: The whole directory >> '/home/false/moko/build/tmp/staging/i686-linux/usr/lib/mono/1.0/' >> is missing. >> Could anybody tell me what is going wrong here, please? > > I can't tell what's going wrong in your case, but in general > cross-compiling does not build the compilers and libraries; try > copying over the missing assembly directories from your host and see > if that helps. > > Andreas Thanks. This advice enabled me to compile my application and build an openmoko-devel-image. However the necessary assemblies of my application (e.g. System.Runtime.Remoting.dll) doesn't appear in the /usr/lib/mono directory of the image if run OpenMoko in QEMU. I used the recipe from this site http://bec-systems.com/web/content/view/87/9/ . Shouldn't the necessary dependencies (assemblies) installed automaticly or do I have to install the assemblies manually? Regards, Thomas From paul at all-the-johnsons.co.uk Fri May 2 12:54:15 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 02 May 2008 17:54:15 +0100 Subject: [Mono-dev] Stack overflow Message-ID: <1209747255.16351.25.camel@T7.Linux> Hi, I seem to have a problem with mono-1.9.1 with a stack overflow. Any ideas on what could be causing it? Stack overflow in unmanaged: IP: 0x4ea8d4, fault addr: 0x7fff4be34d60 Stack overflow: IP: 0x4ea8d4, fault addr: 0x7fff4be2cb40 At Unmanaged Stacktrace: at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_object_new_specific (intptr) <0x00045> at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_object_new_specific (intptr) <0xffffffff> at marker.MainForm..ctor () <0x00026> at (wrapper remoting-invoke-with-check) marker.MainForm..ctor () <0xffffffff> at marker.xmlhandler..ctor () <0x00036> at (wrapper remoting-invoke-with-check) marker.xmlhandler..ctor () <0xffffffff> at marker.MainForm..ctor () <0x00036> at (wrapper remoting-invoke-with-check) marker.MainForm..ctor () <0xffffffff> at marker.xmlhandler..ctor () <0x00036> at (wrapper remoting-invoke-with-check) marker.xmlhandler..ctor () <0xffffffff> (it keeps repeating this ad nauseum). TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080502/c052a0b1/attachment.bin From robertj at gmx.net Fri May 2 16:09:59 2008 From: robertj at gmx.net (Robert Jordan) Date: Fri, 02 May 2008 22:09:59 +0200 Subject: [Mono-dev] Stack overflow In-Reply-To: <1209747255.16351.25.camel@T7.Linux> References: <1209747255.16351.25.camel@T7.Linux> Message-ID: Paul wrote: > Hi, > > I seem to have a problem with mono-1.9.1 with a stack overflow. Any > ideas on what could be causing it? Well, MainForm's and xmlhandler's ctor are calling each other. This seems to be related to your own confusion posted on mono-list with the subject "Accessing one class from another". Robert > > Stack overflow in unmanaged: IP: 0x4ea8d4, fault addr: 0x7fff4be34d60 > Stack overflow: IP: 0x4ea8d4, fault addr: 0x7fff4be2cb40 > At Unmanaged > Stacktrace: > > at (wrapper managed-to-native) > System.Object.__icall_wrapper_mono_object_new_specific (intptr) > <0x00045> > at (wrapper managed-to-native) > System.Object.__icall_wrapper_mono_object_new_specific (intptr) > <0xffffffff> > at marker.MainForm..ctor () <0x00026> > at (wrapper remoting-invoke-with-check) marker.MainForm..ctor () > <0xffffffff> > at marker.xmlhandler..ctor () <0x00036> > at (wrapper remoting-invoke-with-check) marker.xmlhandler..ctor () > <0xffffffff> > at marker.MainForm..ctor () <0x00036> > at (wrapper remoting-invoke-with-check) marker.MainForm..ctor () > <0xffffffff> > at marker.xmlhandler..ctor () <0x00036> > at (wrapper remoting-invoke-with-check) marker.xmlhandler..ctor () > <0xffffffff> > > (it keeps repeating this ad nauseum). > > TTFN > > Paul > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From robert.sim at gmail.com Fri May 2 18:17:51 2008 From: robert.sim at gmail.com (Robert Sim) Date: Fri, 2 May 2008 15:17:51 -0700 Subject: [Mono-dev] Mixing multiple sync/async requests to xsp/mod_mono Message-ID: <9159b69c0805021517t1fcb7cd6s6c123c9d0687a9f0@mail.gmail.com> Hi, I'm having some difficulty getting xsp2 to manage multiple requests. I'm running xsp2 1.2.4. As I understand it, ASP.NET on windows has the limitation of 2 server threads per client connection. My client app uses one thread to continuously poll with an async request (waiting for a server event), and the other to execute synchronous calls. If I want to execute any other async requests, I can get around the limitation by instantiating a second instance of the web service in the client app, and executing the request on that instance. All of this works fine using the windows development server. Switching to mod_mono or xsp2 I can still execute a single async call simultaneously with a synchronous call, but if I create a second webservice instance in the same process and attempt another async call, any further synchronous calls on the first instance are blocked until the second call returns or times out. Any suggestions/workarounds would be most appreciated. Here's some illustrative sample code: MyClientAppMethod() { MyWebService svc1 = new MyWebService(); MyWebService svc2 = new MyWebService(); // Set up async event completion handling ... // now do some calls svc1.Method1Async(); svc1.Method2(); // this sync call works ok svc2.Method3Async(); //note the call on svc2 instead of 1. svc1.Method2(); // with Method1Async and Method3Async outstanding, this call blocks until one of the async calls times out. } From miguel at novell.com Fri May 2 19:45:56 2008 From: miguel at novell.com (Miguel de Icaza) Date: Fri, 02 May 2008 19:45:56 -0400 Subject: [Mono-dev] Socket Send/Receive Timeout patch In-Reply-To: <365818.27867.qm@web39501.mail.mud.yahoo.com> References: <365818.27867.qm@web39501.mail.mud.yahoo.com> Message-ID: <1209771956.16826.59.camel@frost> Hello, Please provide a ChangeLog and a bug number or a test case that we can use to validate that this is the intended behavior (ideally, a nunit test case would be better. On Thu, 2008-05-01 at 18:08 -0700, Jacob Gladish wrote: > return (int)GetSocketOption( > + int opt = (int)GetSocketOption( > SocketOptionLevel.Socket, > SocketOptionName.SendTimeout); > + if (opt == 0) > + opt = -1; > + return opt; From steveb at mindtouch.com Sat May 3 00:56:09 2008 From: steveb at mindtouch.com (Steve Bjorg) Date: Fri, 2 May 2008 21:56:09 -0700 Subject: [Mono-dev] Deki Wiki on IBM Z-series with Suse Linux 10.1 Message-ID: <8AEECE2C-F6D7-4204-8403-909CF839C36C@mindtouch.com> Anyone know if mono on an IBM z-series can work? http://forums.opengarden.org/showthread.php?t=2624 I know some of our illustrious users managed to get Deki Wiki running on SPARC Solaris 10. So, I think anything is possible now! :) - Steve -------------- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org From kornelpal at gmail.com Sat May 3 09:54:25 2008 From: kornelpal at gmail.com (=?iso-8859-1?B?S29ybulsIFDhbA==?=) Date: Sat, 3 May 2008 15:54:25 +0200 Subject: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows (now build with cygwin as well) References: <001701c8a6b9$aa9967c0$3c43ee55@kornelpal.hu> <295e750a0804250745q2a943463h4d49bfacf3d94e75@mail.gmail.com> <002a01c8a70b$05540390$3c43ee55@kornelpal.hu> <295e750a0804280034u533b311wb2e313b8bacfc1cc@mail.gmail.com> <000b01c8a92d$0e7796c0$d9bbc5d9@kornelpal.hu> <295e750a0804280716u3834a054mf3b1628247f27162@mail.gmail.com> <003a01c8a94b$0c15dd60$3e676250@kornelpal.hu> <8cca42d80804281242p561e9am591b6000b266f0a4@mail.gmail.com> <17c2d80b0805011352p43241b9bn884efba0a399e853@mail.gmail.com> Message-ID: <000c01c8ad25$389b34b0$0100a8c0@kornelpal.hu> Hi, > From: Jonathan Chambers > This patch seems to be the cause of the build failures on Win32: I have tracked down the issue. The problem is that "load_aot_module_from_cache" calls that calls "mono_dl_open" that calls "LoadLibrary" with just a file name without a full path. This will result in MS.NET assemblies being loaded when MS.NET is in PATH. I don't know how load_aot_module_from_cache is supposed to work but I think this is a bug in load_aot_module_from_cache. On the other hand my patch had a bug with reference counting when the image was loaded using LoadLibrary outside of image.c. Assembly name is a pointer to raw_data that was freed that caused the problems you described. This should now be fixed. Please try the attached patch. If the build is still broken please let me know. Korn?l -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: coreefix.diff.txt Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080503/541da0c8/attachment.txt From vargaz at gmail.com Sat May 3 10:00:42 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Sat, 3 May 2008 16:00:42 +0200 Subject: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows (now build with cygwin as well) In-Reply-To: <000c01c8ad25$389b34b0$0100a8c0@kornelpal.hu> References: <001701c8a6b9$aa9967c0$3c43ee55@kornelpal.hu> <295e750a0804250745q2a943463h4d49bfacf3d94e75@mail.gmail.com> <002a01c8a70b$05540390$3c43ee55@kornelpal.hu> <295e750a0804280034u533b311wb2e313b8bacfc1cc@mail.gmail.com> <000b01c8a92d$0e7796c0$d9bbc5d9@kornelpal.hu> <295e750a0804280716u3834a054mf3b1628247f27162@mail.gmail.com> <003a01c8a94b$0c15dd60$3e676250@kornelpal.hu> <8cca42d80804281242p561e9am591b6000b266f0a4@mail.gmail.com> <17c2d80b0805011352p43241b9bn884efba0a399e853@mail.gmail.com> <000c01c8ad25$389b34b0$0100a8c0@kornelpal.hu> Message-ID: <295e750a0805030700o40734dbfvd09064ad48619351@mail.gmail.com> > I have tracked down the issue. The problem is that > "load_aot_module_from_cache" calls that calls "mono_dl_open" that calls > "LoadLibrary" with just a file name without a full path. This will result in > MS.NET assemblies being loaded when MS.NET is in PATH. I don't know how > load_aot_module_from_cache is supposed to work but I think this is a bug in > load_aot_module_from_cache. > Hi, load_aot_module_from_cache is only called if the (unsupported) MONO_AOT_CACHE env var is set. Also, it calls mono_dl_open () using a full path. Zoltan From robertj at gmx.net Sat May 3 10:17:23 2008 From: robertj at gmx.net (Robert Jordan) Date: Sat, 03 May 2008 16:17:23 +0200 Subject: [Mono-dev] mono_method_get_unmanaged_thunk In-Reply-To: <80529b1a0804251455s3a295a02odb903be0bf107468@mail.gmail.com> References: <80529b1a0804251455s3a295a02odb903be0bf107468@mail.gmail.com> Message-ID: <481C73F3.4060003@gmx.net> Sebastian Good wrote: > The Embedding Mono page mentions possible future work on > mono_method_get_unmanaged_thunk. We are using the embedding (reflection) API > quite happily, writing our own marshaling for basic types (strings, arrays, > enums, etc.) but would like to avoid the overhead of going through the > generic invoke. When our wrappers initialize, it would be nice to simply JIT > all the necessary methods and then call them directly via a C function > pointer, as I think was imagined before. Exceptions are interesting; it > would be quite acceptable to generate a thunk which took a MonoObject** to > return the results of any exception. (On our wrappers we marshal the message > and re-throw it as a C++ runtime_exception but I suspect this isn't what > everyone would want to do.) > > Is this a feature on the radar for anyone soon? > There is a patch for this feature in Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=386415 You may want to give it a try if you're compiling mono yourself. Robert From kornelpal at gmail.com Sat May 3 11:16:23 2008 From: kornelpal at gmail.com (=?ISO-8859-1?B?S29ybulsIFDhbA==?=) Date: Sat, 3 May 2008 17:16:23 +0200 Subject: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows (now build with cygwin as well) References: <001701c8a6b9$aa9967c0$3c43ee55@kornelpal.hu> <295e750a0804250745q2a943463h4d49bfacf3d94e75@mail.gmail.com> <002a01c8a70b$05540390$3c43ee55@kornelpal.hu> <295e750a0804280034u533b311wb2e313b8bacfc1cc@mail.gmail.com> <000b01c8a92d$0e7796c0$d9bbc5d9@kornelpal.hu> <295e750a0804280716u3834a054mf3b1628247f27162@mail.gmail.com> <003a01c8a94b$0c15dd60$3e676250@kornelpal.hu> <8cca42d80804281242p561e9am591b6000b266f0a4@mail.gmail.com> <17c2d80b0805011352p43241b9bn884efba0a399e853@mail.gmail.com> <000c01c8ad25$389b34b0$0100a8c0@kornelpal.hu> <295e750a0805030700o40734dbfvd09064ad48619351@mail.gmail.com> Message-ID: <002a01c8ad30$a6faf840$0100a8c0@kornelpal.hu> Hi, It wasn't load_aot_module_from_cache, sorry. Command line: make[7]: Entering directory `/mono/mcs/class/System' make all-local make[8]: Entering directory `/mono/mcs/class/System' ** Warning: System.dll built without parts that depend on: System.Xml.dll make[8]: Leaving directory `/mono/mcs/class/System' make[7]: Leaving directory `/mono/mcs/class/System' make[7]: Entering directory `/mono/mcs/class/System.XML' make all-local make[8]: Entering directory `/mono/mcs/class/System.XML' MONO_PATH="../../class/lib/basic;$MONO_PATH" /mono/mono/runtime/mono-wrapper ../../class/lib/basic/mcs.exe /codepage:65001 /nologo /optimize -d:NET_1_1 -d:ONLY_1_1 -d:BOOTSTRAP_WITH_OLDLIB /debug+ /debug:full /noconfig -r:mscorlib.dll -r:System.dll -nowarn:0162,0618,0612,0642,1595 -target:library -out:System.Xml.dll `echo System.Xml.XPath/Parser.cs Mono.Xml.Xsl/PatternParser.cs Mono.Xml.Xsl/PatternTokenizer.cs | tr '/' '\\\\'` @../../build/deps/basic_System.Xml.dll.response Call stack: mono_image_basic_init (MonoReflectionAssemblyBuilder *assemblyb) -> mono_assembly_invoke_load_hook ((MonoAssembly*)assembly); -> load_aot_module (MonoAssembly *assembly, gpointer user_data) -> assembly->aot_module = mono_dl_open (aot_name, MONO_DL_LAZY, &err); The dynamic image has only file name in assembly->image->name that results in System.Xml.dll from MS.NET being loaded when MS.NET is in PATH. Korn?l ----- Original Message ----- From: "Zoltan Varga" To: "Korn?l P?l" Cc: "Jonathan Chambers" ; Sent: Saturday, May 03, 2008 4:00 PM Subject: Re: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows (now build with cygwin as well) >> I have tracked down the issue. The problem is that >> "load_aot_module_from_cache" calls that calls "mono_dl_open" that calls >> "LoadLibrary" with just a file name without a full path. This will result >> in >> MS.NET assemblies being loaded when MS.NET is in PATH. I don't know how >> load_aot_module_from_cache is supposed to work but I think this is a bug >> in >> load_aot_module_from_cache. >> > > Hi, > > load_aot_module_from_cache is only called if the (unsupported) > MONO_AOT_CACHE > env var is set. Also, it calls mono_dl_open () using a full path. > > Zoltan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: coreefix.diff.txt Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080503/fca596cf/attachment-0001.txt From vargaz at gmail.com Sat May 3 13:01:05 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Sat, 3 May 2008 19:01:05 +0200 Subject: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows (now build with cygwin as well) In-Reply-To: <002a01c8ad30$a6faf840$0100a8c0@kornelpal.hu> References: <001701c8a6b9$aa9967c0$3c43ee55@kornelpal.hu> <295e750a0804280034u533b311wb2e313b8bacfc1cc@mail.gmail.com> <000b01c8a92d$0e7796c0$d9bbc5d9@kornelpal.hu> <295e750a0804280716u3834a054mf3b1628247f27162@mail.gmail.com> <003a01c8a94b$0c15dd60$3e676250@kornelpal.hu> <8cca42d80804281242p561e9am591b6000b266f0a4@mail.gmail.com> <17c2d80b0805011352p43241b9bn884efba0a399e853@mail.gmail.com> <000c01c8ad25$389b34b0$0100a8c0@kornelpal.hu> <295e750a0805030700o40734dbfvd09064ad48619351@mail.gmail.com> <002a01c8ad30$a6faf840$0100a8c0@kornelpal.hu> Message-ID: <295e750a0805031001t76ae876cx4cb4b98aa410ae87@mail.gmail.com> Hi, This issue is now fixed in SVN. Zoltan On Sat, May 3, 2008 at 5:16 PM, Korn?l P?l wrote: > Hi, > > It wasn't load_aot_module_from_cache, sorry. > > Command line: > make[7]: Entering directory `/mono/mcs/class/System' > make all-local > make[8]: Entering directory `/mono/mcs/class/System' > ** Warning: System.dll built without parts that depend on: System.Xml.dll > make[8]: Leaving directory `/mono/mcs/class/System' > make[7]: Leaving directory `/mono/mcs/class/System' > make[7]: Entering directory `/mono/mcs/class/System.XML' > make all-local > make[8]: Entering directory `/mono/mcs/class/System.XML' > MONO_PATH="../../class/lib/basic;$MONO_PATH" > /mono/mono/runtime/mono-wrapper ../../class/lib/basic/mcs.exe > /codepage:65001 /nologo /optimize -d:NET_1_1 -d:ONLY_1_1 > -d:BOOTSTRAP_WITH_OLDLIB /debug+ /debug:full /noconfig -r:mscorlib.dll > -r:System.dll -nowarn:0162,0618,0612,0642,1595 -target:library > -out:System.Xml.dll `echo System.Xml.XPath/Parser.cs > Mono.Xml.Xsl/PatternParser.cs Mono.Xml.Xsl/PatternTokenizer.cs | tr '/' > '\\\\'` @../../build/deps/basic_System.Xml.dll.response > > Call stack: > mono_image_basic_init (MonoReflectionAssemblyBuilder *assemblyb) > -> mono_assembly_invoke_load_hook ((MonoAssembly*)assembly); > -> load_aot_module (MonoAssembly *assembly, gpointer user_data) > -> assembly->aot_module = mono_dl_open (aot_name, MONO_DL_LAZY, &err); > > The dynamic image has only file name in assembly->image->name that results > in System.Xml.dll from MS.NET being loaded when MS.NET is in PATH. > > Korn?l > > ----- Original Message ----- From: "Zoltan Varga" > To: "Korn?l P?l" > Cc: "Jonathan Chambers" ; > > Sent: Saturday, May 03, 2008 4:00 PM > > Subject: Re: [Mono-dev] [PATCH] Add mixed-mode assembly support on Windows > (now build with cygwin as well) > > > > > > > > > I have tracked down the issue. The problem is that > > > "load_aot_module_from_cache" calls that calls "mono_dl_open" that calls > > > "LoadLibrary" with just a file name without a full path. This will > result in > > > MS.NET assemblies being loaded when MS.NET is in PATH. I don't know how > > > load_aot_module_from_cache is supposed to work but I think this is a bug > in > > > load_aot_module_from_cache. > > > > > > > > > > Hi, > > > > load_aot_module_from_cache is only called if the (unsupported) > MONO_AOT_CACHE > > env var is set. Also, it calls mono_dl_open () using a full path. > > > > Zoltan > > > From miguel at novell.com Sat May 3 18:59:53 2008 From: miguel at novell.com (Miguel de Icaza) Date: Sat, 03 May 2008 18:59:53 -0400 Subject: [Mono-dev] Deki Wiki on IBM Z-series with Suse Linux 10.1 In-Reply-To: <8AEECE2C-F6D7-4204-8403-909CF839C36C@mindtouch.com> References: <8AEECE2C-F6D7-4204-8403-909CF839C36C@mindtouch.com> Message-ID: <1209855593.12589.7.camel@linux.site> Hello, > Anyone know if mono on an IBM z-series can work? > http://forums.opengarden.org/showthread.php?t=2624 Yes, Mono is distributed by Novell as part of SUSE Linux Enterprise for the IBM z-Series. SLES contains an older version of Mono; We are working on supporting both the older version as well as an add-on that will run Mono 2.0 (what we now call 1.9). From eric_albright at sil.org Sun May 4 22:39:28 2008 From: eric_albright at sil.org (Eric Albright) Date: Mon, 05 May 2008 09:39:28 +0700 Subject: [Mono-dev] assertion failed (!sig->has_type_parameters) Message-ID: <481E7360.2050304@sil.org> Hi, When running my application tests against SVN head, I consistently get the error below. Any ideas? Eric ** ** ERROR:(mini.c:4664):mono_method_to_ir: assertion failed: (!sig->has_type_parameters) Stacktrace: at WeSay.UI.GhostBinding`1.TimeForRealObject (bool) [0x0011b] in /home/eric/Projects/WeSay/src/WeSay.UI/GhostBinding.cs:232 at WeSay.UI.GhostBinding`1.TimeForRealObject (bool) [0x000ef] in /home/eric/Projects/WeSay/src/WeSay.UI/GhostBinding.cs:229 at WeSay.UI.GhostBinding`1._textBoxTarget_LostFocus (object,System.EventArgs) [0x00000] in /home/eric/Projects/WeSay/src/WeSay.UI/GhostBinding.cs:90 at (wrapper delegate-invoke) System.MulticastDelegate.invoke_void_object_EventArgs (object,System.EventArgs) <0xffffffff> at System.Windows.Forms.Control.OnLostFocus (System.EventArgs) [0x0001c] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:6213 at System.Windows.Forms.Control.WmKillFocus (System.Windows.Forms.Message&) [0x00007] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:5805 at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message&) [0x0021c] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:5350 at System.Windows.Forms.TextBoxBase.WndProc (System.Windows.Forms.Message&) [0x001ce] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextBoxBase.cs:1578 at System.Windows.Forms.TextBox.WndProc (System.Windows.Forms.Message&) [0x0002c] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextBox.cs:446 at ControlWindowTarget.OnMessage (System.Windows.Forms.Message&) [0x00000] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:227 at ControlNativeWindow.WndProc (System.Windows.Forms.Message&) [0x00000] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:208 at System.Windows.Forms.NativeWindow.WndProc (intptr,System.Windows.Forms.Msg,intptr,intptr) [0x0006a] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/NativeWindow.cs:188 at System.Windows.Forms.XplatUIX11.SendMessage (intptr,System.Windows.Forms.Msg,intptr,intptr) [0x0008d] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs:4982 at System.Windows.Forms.XplatUIX11.SetFocus (intptr) [0x00059] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs:5217 at System.Windows.Forms.XplatUI.SetFocus (intptr) [0x00000] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUI.cs:987 at System.Windows.Forms.ContainerControl.SendControlFocus (System.Windows.Forms.Control) [0x0000b] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ContainerControl.cs:236 at System.Windows.Forms.ContainerControl.set_ActiveControl (System.Windows.Forms.Control) [0x0021e] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ContainerControl.cs:184 at System.Windows.Forms.Control.Select (System.Windows.Forms.Control) [0x00021] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:1444 at System.Windows.Forms.Control.FocusInternal (bool) [0x00039] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:3813 at System.Windows.Forms.Control.Focus () [0x00000] in /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:3807 at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control.Focus () <0xffffffff> at WeSay.LexicalTools.Tests.DictionaryControlTests.FillInTheGhostMeaning () [0x00086] in /home/eric/Projects/WeSay/src/LexicalTools.Tests/DictionaryControlTests.cs:748 at WeSay.LexicalTools.Tests.DictionaryControlTests.GhostField_Trigger_RegressionTest () [0x00014] in /home/eric/Projects/WeSay/src/LexicalTools.Tests/DictionaryControlTests.cs:717 at (wrapper runtime-invoke) System.Object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[],System.Exception&) <0x00004> at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[],System.Exception&) <0xffffffff> at System.Reflection.MonoMethod.Invoke (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) [0x00057] in /home/eric/mcs/class/corlib/System.Reflection/MonoMethod.cs:157 at System.Reflection.MethodBase.Invoke (object,object[]) [0x00000] in /home/eric/mcs/class/corlib/System.Reflection/MethodBase.cs:90 at NUnit.Core.Reflect.InvokeMethod (System.Reflection.MethodInfo,object) [0x00006] in /home/eric/mcs/nunit20/core/Reflect.cs:373 at NUnit.Core.TemplateTestCase.doTestCase (NUnit.Core.TestCaseResult) [0x00000] in /home/eric/mcs/nunit20/core/TemplateTestCase.cs:155 at NUnit.Core.TemplateTestCase.doRun (NUnit.Core.TestCaseResult) [0x00011] in /home/eric/mcs/nunit20/core/TemplateTestCase.cs:113 at NUnit.Core.TemplateTestCase.Run (NUnit.Core.TestCaseResult) [0x0006b] in /home/eric/mcs/nunit20/core/TemplateTestCase.cs:76 at NUnit.Core.TestCase.Run (NUnit.Core.EventListener) [0x0001d] in /home/eric/mcs/nunit20/core/TestCase.cs:68 at NUnit.Core.TestCase.Run (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x00000] in /home/eric/mcs/nunit20/core/TestCase.cs:58 at NUnit.Core.TestSuite.RunAllTests (NUnit.Core.TestSuiteResult,NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0008c] in /home/eric/mcs/nunit20/core/TestSuite.cs:259 at NUnit.Core.TestSuite.Run (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0003c] in /home/eric/mcs/nunit20/core/TestSuite.cs:213 at NUnit.Core.TestSuite.RunAllTests (NUnit.Core.TestSuiteResult,NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0008c] in /home/eric/mcs/nunit20/core/TestSuite.cs:259 at NUnit.Core.TestSuite.Run (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0003c] in /home/eric/mcs/nunit20/core/TestSuite.cs:213 at NUnit.Core.TestSuite.RunAllTests (NUnit.Core.TestSuiteResult,NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0008c] in /home/eric/mcs/nunit20/core/TestSuite.cs:259 at NUnit.Core.TestSuite.Run (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0003c] in /home/eric/mcs/nunit20/core/TestSuite.cs:213 at NUnit.Core.TestSuite.RunAllTests (NUnit.Core.TestSuiteResult,NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0008c] in /home/eric/mcs/nunit20/core/TestSuite.cs:259 at NUnit.Core.TestSuite.Run (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0003c] in /home/eric/mcs/nunit20/core/TestSuite.cs:213 at NUnit.Core.TestSuite.RunAllTests (NUnit.Core.TestSuiteResult,NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0008c] in /home/eric/mcs/nunit20/core/TestSuite.cs:259 at NUnit.Core.TestSuite.Run (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0003c] in /home/eric/mcs/nunit20/core/TestSuite.cs:213 at NUnit.Core.AssemblyTestSuite.Run (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x00028] in /home/eric/mcs/nunit20/core/TestAssembly.cs:67 at NUnit.Core.RemoteTestRunner.Run (NUnit.Core.EventListener,NUnit.Core.Test[]) [0x00116] in /home/eric/mcs/nunit20/core/RemoteTestRunner.cs:411 at NUnit.Core.RemoteTestRunner.Run (NUnit.Core.EventListener,NUnit.Core.Test) [0x0000b] in /home/eric/mcs/nunit20/core/RemoteTestRunner.cs:355 at NUnit.Core.RemoteTestRunner.Run (NUnit.Core.EventListener) [0x00000] in /home/eric/mcs/nunit20/core/RemoteTestRunner.cs:292 at (wrapper remoting-invoke-with-check) NUnit.Core.RemoteTestRunner.Run (NUnit.Core.EventListener) <0xffffffff> at (wrapper xdomain-dispatch) NUnit.Core.RemoteTestRunner.Run (object,byte[]&,byte[]&) <0xffffffff> at (wrapper xdomain-invoke) NUnit.Core.RemoteTestRunner.Run (NUnit.Core.EventListener) <0xffffffff> at NUnit.Util.TestDomain.Run (NUnit.Core.EventListener) <0x00067> at NUnit.Console.ConsoleUi.Execute (NUnit.Util.ConsoleOptions) <0x0039f> at NUnit.Console.ConsoleUi.Main (string[]) <0x00121> at (wrapper runtime-invoke) NUnit.Console.ConsoleUi.runtime_invoke_int_string[] (object,intptr,intptr,intptr) <0xffffffff> Native stacktrace: /usr/local/bin/mono [0x81a27fa] [0xb7f04440] /lib/tls/i686/cmov/libc.so.6(abort+0x101) [0xb7ccea01] /usr/lib/libglib-2.0.so.0(g_assertion_message+0x121) [0xb7e983e1] /usr/lib/libglib-2.0.so.0 [0xb7e9893d] /usr/local/bin/mono [0x816c8d1] /usr/local/bin/mono [0x818d7cf] /usr/local/bin/mono [0x818f3f8] /usr/local/bin/mono [0x806ba4a] [0xb7b2f774] [0xb40c7d35] [0xb48dbb49] [0xb40f4d61] [0xb40f4d06] [0xb51d7d4d] [0xb48e5b03] [0xb48e57fb] [0xb51d7a15] [0xb51d79f3] [0xb51d7571] [0xb51d73e1] [0xb40f233e] [0xb40f2296] [0xb40f226a] [0xb40f15d4] [0xb40f4c4b] [0xb40f4b0e] [0xb40f4a99] [0xb40f4a57] [0xb40a64a8] [0xb40a5fcf] [0xb6bb5f09] /usr/local/bin/mono(mono_runtime_invoke_array+0x433) [0x811ee43] /usr/local/bin/mono [0x80dcd21] [0xb6bc3030] [0xb6aebe9f] [0xb6b7639b] [0xb6aebd66] [0xb5b4630b] [0xb5d0b9eb] [0xb5d0b70c] [0xb5d0b204] [0xb5d0b122] [0xb6aeb6d4] [0xb6aea0d6] [0xb6aeb6d4] [0xb6aea0d6] [0xb6aeb6d4] [0xb6aea0d6] [0xb6aeb6d4] [0xb6aea0d6] [0xb6aeb6d4] [0xb6aea0d6] [0xb6ae9fa2] [0xb6ae7667] [0xb6ae7271] [0xb6ae7214] [0xb6ae71d2] [0xb6ae5a3c] [0xb6aef34f] [0xb6af8248] [0xb6ee1840] [0xb767a37a] [0xb767a1b4] /usr/local/bin/mono(mono_runtime_exec_main+0x160) [0x8120f10] /usr/local/bin/mono(mono_runtime_run_main+0x173) [0x81211b3] /usr/local/bin/mono(mono_main+0x6be) [0x805b20e] /usr/local/bin/mono [0x805a5e2] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7cb8450] /usr/local/bin/mono [0x805a551] Debug info from gdb: [Thread debugging using libthread_db enabled] [New Thread 0xb7c60960 (LWP 1787)] [New Thread 0xb5c64b90 (LWP 1918)] [New Thread 0xb7286b90 (LWP 1789)] [New Thread 0xb72aab90 (LWP 1788)] 0xb7f04410 in __kernel_vsyscall () 4 Thread 0xb72aab90 (LWP 1788) 0xb7f04410 in __kernel_vsyscall () 3 Thread 0xb7286b90 (LWP 1789) 0xb7f04410 in __kernel_vsyscall () 2 Thread 0xb5c64b90 (LWP 1918) 0xb7f04410 in __kernel_vsyscall () 1 Thread 0xb7c60960 (LWP 1787) 0xb7f04410 in __kernel_vsyscall () Thread 4 (Thread 0xb72aab90 (LWP 1788)): #0 0xb7f04410 in __kernel_vsyscall () #1 0xb7e23196 in nanosleep () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0812ead1 in collection_thread (unused=0x0) at collection.c:34 #3 0xb7e1b4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb7d78e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (Thread 0xb7286b90 (LWP 1789)): #0 0xb7f04410 in __kernel_vsyscall () #1 0xb7e1faa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0813114f in timedwait_signal_poll_cond (cond=0x82a26fc, mutex=0x82a26e4, timeout=0x80, alertable=0) at handles.c:1492 #3 0x08133e99 in _wapi_handle_timedwait_signal_handle (handle=0x404, timeout=0x0, alertable=0) at handles.c:1572 #4 0x08133f0c in _wapi_handle_wait_signal_handle (handle=0x404, alertable=0) at handles.c:1532 #5 0x08134b9d in WaitForSingleObjectEx (handle=0x404, timeout=4294967295, alertable=0) at wait.c:200 #6 0x080cf7aa in finalizer_thread (unused=0x0) at gc.c:894 #7 0x080f650f in start_wrapper (data=0x829cd28) at threads.c:587 #8 0x081391e2 in thread_start_routine (args=0x82a296c) at threads.c:285 #9 0x08151f95 in GC_start_routine (arg=0x35f40) at pthread_support.c:1369 #10 0xb7e1b4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #11 0xb7d78e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (Thread 0xb5c64b90 (LWP 1918)): #0 0xb7f04410 in __kernel_vsyscall () #1 0xb7e23196 in nanosleep () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x08137d28 in SleepEx (ms=0, alertable=1) at threads.c:1037 #3 0x080f5b56 in ves_icall_System_Threading_Thread_Sleep_internal (ms=1000) at threads.c:986 #4 0xb5c711c6 in ?? () #5 0x000003e8 in ?? () #6 0x09563980 in ?? () #7 0x01203560 in ?? () #8 0x018bd4f8 in ?? () #9 0x018bd5a0 in ?? () #10 0x0155ddc8 in ?? () #11 0x000003e8 in ?? () #12 0x01892c38 in ?? () #13 0xb5c6419c in ?? () #14 0xb5c711a4 in ?? () #15 0xb5c641ac in ?? () #16 0xb5c71166 in ?? () #17 0x000003e8 in ?? () #18 0x015fba68 in ?? () #19 0xb5c641b8 in ?? () #20 0xb5c7113c in ?? () #21 0x000003e8 in ?? () #22 0xb5c641e4 in ?? () #23 0xb5c71101 in ?? () #24 0x000003e8 in ?? () #25 0x00000000 in ?? () Thread 1 (Thread 0xb7c60960 (LWP 1787)): #0 0xb7f04410 in __kernel_vsyscall () #1 0xb7e2299b in read () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x081a2971 in mono_handle_native_sigsegv (signal=6, ctx=0xbff72e0c) at mini-exceptions.c:1182 #3 #4 0xb7f04410 in __kernel_vsyscall () #5 0xb7ccd085 in raise () from /lib/tls/i686/cmov/libc.so.6 #6 0xb7ccea01 in abort () from /lib/tls/i686/cmov/libc.so.6 #7 0xb7e983e1 in g_assertion_message () from /usr/lib/libglib-2.0.so.0 #8 0xb7e9893d in g_assertion_message_expr () from /usr/lib/libglib-2.0.so.0 #9 0x0816c8d1 in mono_method_to_ir (cfg=0xa109868, method=0x9aadcfc, start_bblock=0x0, end_bblock=0x0, locals_offset=7, return_var=0x0, dont_inline=0x0, inline_args=0x0, inline_offset=0, is_virtual_call=0) at mini.c:4664 #10 0x0818d7cf in mini_method_compile (method=0x9aadcfc, opts=13724159, domain=0x34a50, run_cctors=, compile_aot=, parts=0) at mini.c:11777 #11 0x0818f3f8 in mono_jit_compile_method (method=0x9aadcfc) at mini.c:12246 #12 0x0806ba4a in mono_delegate_trampoline (regs=0xbff7398c, code=0xb40c7f36 "\203?\034h\020\020\t", klass=0x9a9b628, tramp=0x0) at mini-trampolines.c:470 #13 0xb7b2f774 in ?? () #14 0xbff7398c in ?? () #15 0xb40c7f36 in ?? () #16 0x09a9b628 in ?? () #17 0x00000000 in ?? () #0 0xb7f04410 in __kernel_vsyscall () ================================================================= Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= From kumpera at gmail.com Mon May 5 00:13:05 2008 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Mon, 5 May 2008 01:13:05 -0300 Subject: [Mono-dev] assertion failed (!sig->has_type_parameters) In-Reply-To: <481E7360.2050304@sil.org> References: <481E7360.2050304@sil.org> Message-ID: <8cca42d80805042113h6dd8614p8e454037f36f834a@mail.gmail.com> Hi Eric, Please, fill a bug report with a reproducible test case and we'll take a look. http://www.mono-project.com/Bugs Mark, the assert is related to generic sharing. Mind giving some light on how to troubleshoot it? Thanks, Rodrigo On Sun, May 4, 2008 at 11:39 PM, Eric Albright wrote: > Hi, > > When running my application tests against SVN head, I consistently get > the error below. > Any ideas? > > Eric > > ** > ** ERROR:(mini.c:4664):mono_method_to_ir: assertion failed: > (!sig->has_type_parameters) > Stacktrace: > > at WeSay.UI.GhostBinding`1.TimeForRealObject (bool) [0x0011b] in > /home/eric/Projects/WeSay/src/WeSay.UI/GhostBinding.cs:232 > at WeSay.UI.GhostBinding`1.TimeForRealObject (bool) [0x000ef] in > /home/eric/Projects/WeSay/src/WeSay.UI/GhostBinding.cs:229 > at WeSay.UI.GhostBinding`1._textBoxTarget_LostFocus > (object,System.EventArgs) [0x00000] in > /home/eric/Projects/WeSay/src/WeSay.UI/GhostBinding.cs:90 > at (wrapper delegate-invoke) > System.MulticastDelegate.invoke_void_object_EventArgs > (object,System.EventArgs) <0xffffffff> > at System.Windows.Forms.Control.OnLostFocus (System.EventArgs) > [0x0001c] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:6213 > at System.Windows.Forms.Control.WmKillFocus > (System.Windows.Forms.Message&) [0x00007] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:5805 > at System.Windows.Forms.Control.WndProc > (System.Windows.Forms.Message&) [0x0021c] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:5350 > at System.Windows.Forms.TextBoxBase.WndProc > (System.Windows.Forms.Message&) [0x001ce] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextBoxBase.cs:1578 > at System.Windows.Forms.TextBox.WndProc > (System.Windows.Forms.Message&) [0x0002c] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextBox.cs:446 > at ControlWindowTarget.OnMessage (System.Windows.Forms.Message&) > [0x00000] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:227 > at ControlNativeWindow.WndProc (System.Windows.Forms.Message&) > [0x00000] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:208 > at System.Windows.Forms.NativeWindow.WndProc > (intptr,System.Windows.Forms.Msg,intptr,intptr) [0x0006a] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/NativeWindow.cs:188 > at System.Windows.Forms.XplatUIX11.SendMessage > (intptr,System.Windows.Forms.Msg,intptr,intptr) [0x0008d] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs:4982 > at System.Windows.Forms.XplatUIX11.SetFocus (intptr) [0x00059] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs:5217 > at System.Windows.Forms.XplatUI.SetFocus (intptr) [0x00000] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUI.cs:987 > at System.Windows.Forms.ContainerControl.SendControlFocus > (System.Windows.Forms.Control) [0x0000b] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ContainerControl.cs:236 > at System.Windows.Forms.ContainerControl.set_ActiveControl > (System.Windows.Forms.Control) [0x0021e] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ContainerControl.cs:184 > at System.Windows.Forms.Control.Select (System.Windows.Forms.Control) > [0x00021] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:1444 > at System.Windows.Forms.Control.FocusInternal (bool) [0x00039] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:3813 > at System.Windows.Forms.Control.Focus () [0x00000] in > > /home/eric/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Control.cs:3807 > at (wrapper remoting-invoke-with-check) > System.Windows.Forms.Control.Focus () <0xffffffff> > at > WeSay.LexicalTools.Tests.DictionaryControlTests.FillInTheGhostMeaning () > [0x00086] in > > /home/eric/Projects/WeSay/src/LexicalTools.Tests/DictionaryControlTests.cs:748 > at > > WeSay.LexicalTools.Tests.DictionaryControlTests.GhostField_Trigger_RegressionTest > > () [0x00014] in > > /home/eric/Projects/WeSay/src/LexicalTools.Tests/DictionaryControlTests.cs:717 > at (wrapper runtime-invoke) System.Object.runtime_invoke_void > (object,intptr,intptr,intptr) <0xffffffff> > at (wrapper managed-to-native) > System.Reflection.MonoMethod.InternalInvoke > (object,object[],System.Exception&) <0x00004> > at (wrapper managed-to-native) > System.Reflection.MonoMethod.InternalInvoke > (object,object[],System.Exception&) <0xffffffff> > at System.Reflection.MonoMethod.Invoke > > (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) > > [0x00057] in > /home/eric/mcs/class/corlib/System.Reflection/MonoMethod.cs:157 > at System.Reflection.MethodBase.Invoke (object,object[]) [0x00000] in > /home/eric/mcs/class/corlib/System.Reflection/MethodBase.cs:90 > at NUnit.Core.Reflect.InvokeMethod > (System.Reflection.MethodInfo,object) [0x00006] in > /home/eric/mcs/nunit20/core/Reflect.cs:373 > at NUnit.Core.TemplateTestCase.doTestCase (NUnit.Core.TestCaseResult) > [0x00000] in /home/eric/mcs/nunit20/core/TemplateTestCase.cs:155 > at NUnit.Core.TemplateTestCase.doRun (NUnit.Core.TestCaseResult) > [0x00011] in /home/eric/mcs/nunit20/core/TemplateTestCase.cs:113 > at NUnit.Core.TemplateTestCase.Run (NUnit.Core.TestCaseResult) > [0x0006b] in /home/eric/mcs/nunit20/core/TemplateTestCase.cs:76 > at NUnit.Core.TestCase.Run (NUnit.Core.EventListener) [0x0001d] in > /home/eric/mcs/nunit20/core/TestCase.cs:68 > at NUnit.Core.TestCase.Run > (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x00000] in > /home/eric/mcs/nunit20/core/TestCase.cs:58 > at NUnit.Core.TestSuite.RunAllTests > (NUnit.Core.TestSuiteResult,NUnit.Core.EventListener,NUnit.Core.IFilter) > [0x0008c] in /home/eric/mcs/nunit20/core/TestSuite.cs:259 > at NUnit.Core.TestSuite.Run > (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0003c] in > /home/eric/mcs/nunit20/core/TestSuite.cs:213 > at NUnit.Core.TestSuite.RunAllTests > (NUnit.Core.TestSuiteResult,NUnit.Core.EventListener,NUnit.Core.IFilter) > [0x0008c] in /home/eric/mcs/nunit20/core/TestSuite.cs:259 > at NUnit.Core.TestSuite.Run > (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0003c] in > /home/eric/mcs/nunit20/core/TestSuite.cs:213 > at NUnit.Core.TestSuite.RunAllTests > (NUnit.Core.TestSuiteResult,NUnit.Core.EventListener,NUnit.Core.IFilter) > [0x0008c] in /home/eric/mcs/nunit20/core/TestSuite.cs:259 > at NUnit.Core.TestSuite.Run > (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0003c] in > /home/eric/mcs/nunit20/core/TestSuite.cs:213 > at NUnit.Core.TestSuite.RunAllTests > (NUnit.Core.TestSuiteResult,NUnit.Core.EventListener,NUnit.Core.IFilter) > [0x0008c] in /home/eric/mcs/nunit20/core/TestSuite.cs:259 > at NUnit.Core.TestSuite.Run > (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0003c] in > /home/eric/mcs/nunit20/core/TestSuite.cs:213 > at NUnit.Core.TestSuite.RunAllTests > (NUnit.Core.TestSuiteResult,NUnit.Core.EventListener,NUnit.Core.IFilter) > [0x0008c] in /home/eric/mcs/nunit20/core/TestSuite.cs:259 > at NUnit.Core.TestSuite.Run > (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x0003c] in > /home/eric/mcs/nunit20/core/TestSuite.cs:213 > at NUnit.Core.AssemblyTestSuite.Run > (NUnit.Core.EventListener,NUnit.Core.IFilter) [0x00028] in > /home/eric/mcs/nunit20/core/TestAssembly.cs:67 > at NUnit.Core.RemoteTestRunner.Run > (NUnit.Core.EventListener,NUnit.Core.Test[]) [0x00116] in > /home/eric/mcs/nunit20/core/RemoteTestRunner.cs:411 > at NUnit.Core.RemoteTestRunner.Run > (NUnit.Core.EventListener,NUnit.Core.Test) [0x0000b] in > /home/eric/mcs/nunit20/core/RemoteTestRunner.cs:355 > at NUnit.Core.RemoteTestRunner.Run (NUnit.Core.EventListener) > [0x00000] in /home/eric/mcs/nunit20/core/RemoteTestRunner.cs:292 > at (wrapper remoting-invoke-with-check) > NUnit.Core.RemoteTestRunner.Run (NUnit.Core.EventListener) <0xffffffff> > at (wrapper xdomain-dispatch) NUnit.Core.RemoteTestRunner.Run > (object,byte[]&,byte[]&) <0xffffffff> > at (wrapper xdomain-invoke) NUnit.Core.RemoteTestRunner.Run > (NUnit.Core.EventListener) <0xffffffff> > at NUnit.Util.TestDomain.Run (NUnit.Core.EventListener) <0x00067> > at NUnit.Console.ConsoleUi.Execute (NUnit.Util.ConsoleOptions) <0x0039f> > at NUnit.Console.ConsoleUi.Main (string[]) <0x00121> > at (wrapper runtime-invoke) > NUnit.Console.ConsoleUi.runtime_invoke_int_string[] > (object,intptr,intptr,intptr) <0xffffffff> > > Native stacktrace: > > /usr/local/bin/mono [0x81a27fa] > [0xb7f04440] > /lib/tls/i686/cmov/libc.so.6(abort+0x101) [0xb7ccea01] > /usr/lib/libglib-2.0.so.0(g_assertion_message+0x121) [0xb7e983e1] > /usr/lib/libglib-2.0.so.0 [0xb7e9893d] > /usr/local/bin/mono [0x816c8d1] > /usr/local/bin/mono [0x818d7cf] > /usr/local/bin/mono [0x818f3f8] > /usr/local/bin/mono [0x806ba4a] > [0xb7b2f774] > [0xb40c7d35] > [0xb48dbb49] > [0xb40f4d61] > [0xb40f4d06] > [0xb51d7d4d] > [0xb48e5b03] > [0xb48e57fb] > [0xb51d7a15] > [0xb51d79f3] > [0xb51d7571] > [0xb51d73e1] > [0xb40f233e] > [0xb40f2296] > [0xb40f226a] > [0xb40f15d4] > [0xb40f4c4b] > [0xb40f4b0e] > [0xb40f4a99] > [0xb40f4a57] > [0xb40a64a8] > [0xb40a5fcf] > [0xb6bb5f09] > /usr/local/bin/mono(mono_runtime_invoke_array+0x433) [0x811ee43] > /usr/local/bin/mono [0x80dcd21] > [0xb6bc3030] > [0xb6aebe9f] > [0xb6b7639b] > [0xb6aebd66] > [0xb5b4630b] > [0xb5d0b9eb] > [0xb5d0b70c] > [0xb5d0b204] > [0xb5d0b122] > [0xb6aeb6d4] > [0xb6aea0d6] > [0xb6aeb6d4] > [0xb6aea0d6] > [0xb6aeb6d4] > [0xb6aea0d6] > [0xb6aeb6d4] > [0xb6aea0d6] > [0xb6aeb6d4] > [0xb6aea0d6] > [0xb6ae9fa2] > [0xb6ae7667] > [0xb6ae7271] > [0xb6ae7214] > [0xb6ae71d2] > [0xb6ae5a3c] > [0xb6aef34f] > [0xb6af8248] > [0xb6ee1840] > [0xb767a37a] > [0xb767a1b4] > /usr/local/bin/mono(mono_runtime_exec_main+0x160) [0x8120f10] > /usr/local/bin/mono(mono_runtime_run_main+0x173) [0x81211b3] > /usr/local/bin/mono(mono_main+0x6be) [0x805b20e] > /usr/local/bin/mono [0x805a5e2] > /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7cb8450] > /usr/local/bin/mono [0x805a551] > > Debug info from gdb: > > [Thread debugging using libthread_db enabled] > [New Thread 0xb7c60960 (LWP 1787)] > [New Thread 0xb5c64b90 (LWP 1918)] > [New Thread 0xb7286b90 (LWP 1789)] > [New Thread 0xb72aab90 (LWP 1788)] > 0xb7f04410 in __kernel_vsyscall () > 4 Thread 0xb72aab90 (LWP 1788) 0xb7f04410 in __kernel_vsyscall () > 3 Thread 0xb7286b90 (LWP 1789) 0xb7f04410 in __kernel_vsyscall () > 2 Thread 0xb5c64b90 (LWP 1918) 0xb7f04410 in __kernel_vsyscall () > 1 Thread 0xb7c60960 (LWP 1787) 0xb7f04410 in __kernel_vsyscall () > > Thread 4 (Thread 0xb72aab90 (LWP 1788)): > #0 0xb7f04410 in __kernel_vsyscall () > #1 0xb7e23196 in nanosleep () from /lib/tls/i686/cmov/libpthread.so.0 > #2 0x0812ead1 in collection_thread (unused=0x0) at collection.c:34 > #3 0xb7e1b4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 > #4 0xb7d78e5e in clone () from /lib/tls/i686/cmov/libc.so.6 > > Thread 3 (Thread 0xb7286b90 (LWP 1789)): > #0 0xb7f04410 in __kernel_vsyscall () > #1 0xb7e1faa5 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/tls/i686/cmov/libpthread.so.0 > #2 0x0813114f in timedwait_signal_poll_cond (cond=0x82a26fc, > mutex=0x82a26e4, > timeout=0x80, alertable=0) at handles.c:1492 > #3 0x08133e99 in _wapi_handle_timedwait_signal_handle (handle=0x404, > timeout=0x0, alertable=0) at handles.c:1572 > #4 0x08133f0c in _wapi_handle_wait_signal_handle (handle=0x404, > alertable=0) > at handles.c:1532 > #5 0x08134b9d in WaitForSingleObjectEx (handle=0x404, timeout=4294967295, > alertable=0) at wait.c:200 > #6 0x080cf7aa in finalizer_thread (unused=0x0) at gc.c:894 > #7 0x080f650f in start_wrapper (data=0x829cd28) at threads.c:587 > #8 0x081391e2 in thread_start_routine (args=0x82a296c) at threads.c:285 > #9 0x08151f95 in GC_start_routine (arg=0x35f40) at pthread_support.c:1369 > #10 0xb7e1b4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 > #11 0xb7d78e5e in clone () from /lib/tls/i686/cmov/libc.so.6 > > Thread 2 (Thread 0xb5c64b90 (LWP 1918)): > #0 0xb7f04410 in __kernel_vsyscall () > #1 0xb7e23196 in nanosleep () from /lib/tls/i686/cmov/libpthread.so.0 > #2 0x08137d28 in SleepEx (ms=0, alertable=1) at threads.c:1037 > #3 0x080f5b56 in ves_icall_System_Threading_Thread_Sleep_internal > (ms=1000) > at threads.c:986 > #4 0xb5c711c6 in ?? () > #5 0x000003e8 in ?? () > #6 0x09563980 in ?? () > #7 0x01203560 in ?? () > #8 0x018bd4f8 in ?? () > #9 0x018bd5a0 in ?? () > #10 0x0155ddc8 in ?? () > #11 0x000003e8 in ?? () > #12 0x01892c38 in ?? () > #13 0xb5c6419c in ?? () > #14 0xb5c711a4 in ?? () > #15 0xb5c641ac in ?? () > #16 0xb5c71166 in ?? () > #17 0x000003e8 in ?? () > #18 0x015fba68 in ?? () > #19 0xb5c641b8 in ?? () > #20 0xb5c7113c in ?? () > #21 0x000003e8 in ?? () > #22 0xb5c641e4 in ?? () > #23 0xb5c71101 in ?? () > #24 0x000003e8 in ?? () > #25 0x00000000 in ?? () > > Thread 1 (Thread 0xb7c60960 (LWP 1787)): > #0 0xb7f04410 in __kernel_vsyscall () > #1 0xb7e2299b in read () from /lib/tls/i686/cmov/libpthread.so.0 > #2 0x081a2971 in mono_handle_native_sigsegv (signal=6, ctx=0xbff72e0c) > at mini-exceptions.c:1182 > #3 > #4 0xb7f04410 in __kernel_vsyscall () > #5 0xb7ccd085 in raise () from /lib/tls/i686/cmov/libc.so.6 > #6 0xb7ccea01 in abort () from /lib/tls/i686/cmov/libc.so.6 > #7 0xb7e983e1 in g_assertion_message () from /usr/lib/libglib-2.0.so.0 > #8 0xb7e9893d in g_assertion_message_expr () from > /usr/lib/libglib-2.0.so.0 > #9 0x0816c8d1 in mono_method_to_ir (cfg=0xa109868, method=0x9aadcfc, > start_bblock=0x0, end_bblock=0x0, locals_offset=7, return_var=0x0, > dont_inline=0x0, inline_args=0x0, inline_offset=0, is_virtual_call=0) > at mini.c:4664 > #10 0x0818d7cf in mini_method_compile (method=0x9aadcfc, opts=13724159, > domain=0x34a50, run_cctors=, > compile_aot=, parts=0) at mini.c:11777 > #11 0x0818f3f8 in mono_jit_compile_method (method=0x9aadcfc) at > mini.c:12246 > #12 0x0806ba4a in mono_delegate_trampoline (regs=0xbff7398c, > code=0xb40c7f36 "\203?\034h\020\020\t", klass=0x9a9b628, tramp=0x0) > at mini-trampolines.c:470 > #13 0xb7b2f774 in ?? () > #14 0xbff7398c in ?? () > #15 0xb40c7f36 in ?? () > #16 0x09a9b628 in ?? () > #17 0x00000000 in ?? () > #0 0xb7f04410 in __kernel_vsyscall () > > ================================================================= > Got a SIGABRT while executing native code. This usually indicates > a fatal error in the mono runtime or one of the native libraries > used by your application. > ================================================================= > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080505/3c5e0f73/attachment-0001.html From sebastian.onofrei at eyepartner.com Mon May 5 02:05:35 2008 From: sebastian.onofrei at eyepartner.com (Sebi Onofrei) Date: Mon, 05 May 2008 09:05:35 +0300 Subject: [Mono-dev] Code obfuscation application Message-ID: <481EA3AF.10302@eyepartner.com> Hello everybody, I would like to know if there are any shareware/freeware code obfuscation tools available that work with Mono generated binaries. For Windows there are many, but I can't seem to find one for Linux. P.S. I would like to apologize if I'm not supposed to ask such question at all or if I'm not supposed to address this question to the development mailing list. Thank you a lot and good luck with the project. With kind regards and respect, Sebastian Onofrei Eyepartner Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: sebastian_onofrei.vcf Type: text/x-vcard Size: 611 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080505/b0d8af1c/attachment.vcf From kornelpal at gmail.com Mon May 5 04:56:00 2008 From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=) Date: Mon, 5 May 2008 10:56:00 +0200 Subject: [Mono-dev] [PATCH] Fixes and improvements for mixed-mode assembly support Message-ID: <005801c8ae8d$d87fb910$83666250@kornelpal.hu> Hi, * domain.c: Open exe_image anyway so that it can be fixed up. Add a mono_close_exe_image function that closes exe_image. * image.c: Fix reference counting when DLL image is loaded using LoadLibrary outside of image.c. * threads.c: Add threads_initialized that enables coree.c to call mono_thread_suspend_all_other_threads at any time. * coree.c: Some improvements and add mono_set_act_ctx that loads manifest file from the main assembly when process is created from mono.exe. This is required for MSVCRT support but may be used by other assemblies as well for example for XP Visual Style support. Please review the patch and if you like it, please approve it. Jonathan, please try this patch if it fixes the issue you have reported. Korn?l -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: coreefix.diff.txt Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080505/2d0f35af/attachment-0001.txt From andreas.faerber at web.de Mon May 5 05:01:58 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Mon, 5 May 2008 11:01:58 +0200 Subject: [Mono-dev] MonoDevelop failure In-Reply-To: <48133CB2.2090502@quarter-flash.com> References: <48133CB2.2090502@quarter-flash.com> Message-ID: Hi Kenneth, Am 26.04.2008 um 16:31 schrieb Kenneth D. Weinert: > I just upgraded to Ubuntu 8.04 and now have the following error when > trying to start up MonoDevelop: > > System.TypeInitializationException: An exception was thrown by the > type > initializer for MonoDevelop.Core.Gui.Services ---> > System.InvalidOperationException: Extension node not found in path: > /MonoDevelop/Core/PlatformService I just upgraded a machine from 7.10 to 8.04 and didn't face that issue... > Any thoughts/hints/RTFMs? Looks like a MonoDevelop issue: You could try removing MonoDevelop's hidden config directory in your home dir. If that doesn't help and no one around here has a better suggestion, its developers have their own mailing list: http://www.monodevelop.org/Help_%26_Contact Andreas From alankila at bel.fi Mon May 5 05:03:08 2008 From: alankila at bel.fi (Antti S. Lankila) Date: Mon, 05 May 2008 12:03:08 +0300 Subject: [Mono-dev] Difficulties with charset on asp.net applications and mod_mono with 1.9.1, most non-ASCII chars appear as ?? Message-ID: <481ECD4C.20407@bel.fi> The short: whenever I put one of the multibyte chars into source file, be it global.asax or foobar.aspx, I get several ? (question mark) characters instead of the desired characters. An example:

?

appears in browser as

??

. I think my settings are correct: I have UTF-8 encoded source files, the tag says fileEncoding is utf-8, and it used to work with 1.2.6 and earlier. Some more symptoms: * If I put into Application_Start() 'Console.Error.WriteLine("?")', that too emits two ?? into error_log. * setting 's fileEncoding to ISO-8859-1 doubles the number of ? characters in output, as in

?

=>

????

. It is as if something was converting the two UTF-8 bytes representing ? once more to UTF-8, then seeing 4 bytes, and emitting ? for each. * this problem only seems to affect mod_mono. If I run the application through xsp2, it works. * the bug occurs with mod_mono 1.2.5+xsp 1.2.5, and mod_mono 1.9+xsp 1.9.1. My mono distribution is the current debian testing's 1.9.1. They haven't updated xsp+mod_mono so I compiled those myself to try with updated versions. Alas, it did not help. Is there any more information that I could offer to help troubleshoot this problem? I worry that this no-one else is seeing this because there are no reports of this on the web. But I get the problem on two systems for which I have set up 1.9, albeit through Debian's repositories. It'd be really helpful if people with official install could try some of those scandinavian characters and tell if they see this too. -- Antti From kornelpal at gmail.com Mon May 5 05:12:28 2008 From: kornelpal at gmail.com (=?iso-8859-2?B?UOFsIEtvcm7pbA==?=) Date: Mon, 5 May 2008 11:12:28 +0200 Subject: [Mono-dev] [PATCH] Fixes and modifications for MSVCRT support Message-ID: <006b01c8ae90$24e8a850$83666250@kornelpal.hu> Hi, These patches contain some fixes that seem to be required for MSVCRT support. Note that I wasn't able to execute even a simle Hello World application that uses MSVCRT yet but made some progress with these fixes. The most weird thing is that when the assembly is compiled as pure IL MSVC++ still uses vtfixup. But not the usual way. It uses ResolveMethodHandle along with GetFunctionPointer that is basically the same thing that vtfixup is without the marshaling. Even worse, MSVC++ assumes that static fields with and RVA point to the actual PE image. The thable it uses for resolving method is not defined properly in the CLI image but only it's start and end is defined. This even breaks ildasm-ilasm round trip but MSVC++ assumes this. The mini.c and jit-icalls.c is supposed to support this but I know that this would break other platforms maybe even x86 Windows as well. MSVC++ also generates code that marshals pointers. Korn?l -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msvcrt_partial.diff.txt Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080505/9430e4f7/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msvcrt_mcs.diff.txt Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080505/9430e4f7/attachment-0001.txt From skolima at gmail.com Mon May 5 05:33:35 2008 From: skolima at gmail.com (Leszek Ciesielski) Date: Mon, 5 May 2008 11:33:35 +0200 Subject: [Mono-dev] Code obfuscation application In-Reply-To: <481EA3AF.10302@eyepartner.com> References: <481EA3AF.10302@eyepartner.com> Message-ID: <23a15590805050233p162cecb2q7dbd905f5bb2d202@mail.gmail.com> 2008/5/5 Sebi Onofrei : > Hello everybody, > > I would like to know if there are any shareware/freeware code obfuscation > tools available that work with Mono generated binaries. For Windows there > are many, but I can't seem to find one for Linux. All those tools should work the same way on mono as they do with MS.Net. This said, about half a year a go I tried out every open source obfuscation tool I could find (wanted to check how much memory could I free by reducing namespaces, method and class names to single letters) and every one of them failed a very simple test: each one failed to work once I used it to strip itself. So good luck with your search ;-) From pablosantosluac at terra.es Mon May 5 06:35:04 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Mon, 05 May 2008 12:35:04 +0200 Subject: [Mono-dev] Code obfuscation application In-Reply-To: <23a15590805050233p162cecb2q7dbd905f5bb2d202@mail.gmail.com> References: <481EA3AF.10302@eyepartner.com> <23a15590805050233p162cecb2q7dbd905f5bb2d202@mail.gmail.com> Message-ID: <481EE2D8.2030008@terra.es> Hi, We're using dotfuscator with Mono on Mac, Solaris and Linux. It works... but it's commercial. pablo Leszek Ciesielski escribi?: > 2008/5/5 Sebi Onofrei : > >> Hello everybody, >> >> I would like to know if there are any shareware/freeware code obfuscation >> tools available that work with Mono generated binaries. For Windows there >> are many, but I can't seem to find one for Linux. >> > > All those tools should work the same way on mono as they do with > MS.Net. This said, about half a year a go I tried out every open > source obfuscation tool I could find (wanted to check how much memory > could I free by reducing namespaces, method and class names to single > letters) and every one of them failed a very simple test: each one > failed to work once I used it to strip itself. So good luck with your > search ;-) > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From sf at granit.de Mon May 5 10:42:47 2008 From: sf at granit.de (Stefan Fink) Date: Mon, 05 May 2008 16:42:47 +0200 Subject: [Mono-dev] debug mono embedded Message-ID: <481F1CE7.2040607@granit.de> hallo, i have write a small C++ example application with embedded Mono. i can execute my compiled Mono script in which i call functions from my C++ programm. but how can i debug my Mono program ??? -- Stefan Fink From contact at i-nz.net Mon May 5 11:50:23 2008 From: contact at i-nz.net (Ivan N. Zlatev) Date: Mon, 5 May 2008 16:50:23 +0100 Subject: [Mono-dev] [PATCH] TypeDescriptor In-Reply-To: References: <3db1ec7f0804281350i6be3f8c6q31e7cf74fb9fe1d0@mail.gmail.com> <3db1ec7f0804281559g1206bfafs1eaca4b5551d404c@mail.gmail.com> Message-ID: <3db1ec7f0805050850t4fbab94cra78d26e8d0d2e138@mail.gmail.com> On Wed, Apr 30, 2008 at 7:36 PM, James Fitzsimons wrote: > > > > > 2008/4/28 Ivan N. Zlatev : > > > > > > > > On Mon, Apr 28, 2008 at 11:28 PM, James Fitzsimons > > wrote: > > > > > > 2008/4/28 Ivan N. Zlatev : > > > > > > > > > > 2008/4/28 James Fitzsimons : > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > While debugging a problem with Spring.NET over the weekend I > uncovered > > > an > > > > > inconsistency in behaviour between the Mono and Microsoft > > > implementations of > > > > > the GetProperties method of the TypeDescriptor class. Basically the > > > > > Microsoft only returns properties that have a getter, however Mono > > > returns > > > > > write only properties as well. > > > > > > > > > > The attached patch contains a fix and a few more unit tests to check > > > that it > > > > > works and it doesn't break existing behaviour. > > > > > > > > > > > > > Please fix the following things and resend: > > > > > > > > 1) Reformat your patch to match our coding guidelines - > > > > http://www.mono-project.com/Coding_Guidelines > > > > 2) Add ChangeLog entries. > > > > 3) Fix the mixed indentation in the code in the tests you've added. > > > > 4) Fix the indentation in this hunk: > > > > > > > > @@ -427,6 +447,9 @@ > > > > MyComponent sitedcom = new MyComponent (new MySite ()); > > > > MyComponent nfscom = new MyComponent (new NoFilterSite > (new > > > MyContainer ())); > > > > AnotherComponent anothercom = new AnotherComponent (); > > > > + TestObject testObject = new TestObject(); > > > > + PropertyDescriptorCollection properties = > > > > TypeDescriptor.GetProperties(testObject); > > > > + > > > > > > > > [Test] > > > > public void TestICustomTypeDescriptor () > > > > > > > > Cheers, > > > > Ivan > > > > > > > > > > > > > Maybe this time? > > > > > > > Two more things: > > > > 1) Refactor all your asserts into 1 test method, say > > TestGetProperties_WriteOnly and drop the fields - use local variables > > inside. No need for PropertyDescriptorExists, just check the > > propertydescriptorcollection["property"] != null inside that test > > method like the other tests do. Number the asserts. > > > > 2) There is no need for a special TestObject - just add a single > > write-only property MyComponent and use that. You will also have to > > add it to the GetProperties_Order test > > > > Resend when those are fixed, thanks. > > Hi Ivan, > > I've done as you requested and checked all tests still pass. > I have applied your patch with a further slight modification of the tests in r102535, thanks. Ivan. From luisvill at bungie.com Mon May 5 17:08:42 2008 From: luisvill at bungie.com (Luis Villegas) Date: Mon, 5 May 2008 14:08:42 -0700 Subject: [Mono-dev] Embedded Mono question Message-ID: Hello, I have been thinking of a theoretical case for using Mono as an embedded scripting platform, where the majority of the application would be developed in C/C++ and for extensibility it would use Mono for scripting. Imagine a situation where I have a rich C++ class library, and would like to expose some of that to managed code. In the Windows World I would end up using C++\CLI for wrapping the parts I care about. How can achieve the same with Mono? After looking at the documentation for embedding it seems to me that you can expose C functions to Mono (via DllImport(Internal) or internal calls), but it is unclear to me how to expose classes. Thank you, Luis Villegas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080505/01023837/attachment.html From miguel at novell.com Mon May 5 17:38:41 2008 From: miguel at novell.com (Miguel de Icaza) Date: Mon, 05 May 2008 17:38:41 -0400 Subject: [Mono-dev] Embedded Mono question In-Reply-To: References: Message-ID: <1210023521.5421.50.camel@erandi.boston.ximian.com> Hello, > How can achieve the same with Mono? Today you have two choices, they both boil down to exposing the API in a C-friendly way. You can bind the API by hand and expose C callable methods (extern "C" { void ... }), this is what we do in Moonlight, we expose C entry points to constructors, destructors and methods that must be invoked from managed code. The other option is to generate the bindings using a tool like SWIG that is able to generate the bindings by parsing header files. Miguel. > From luisvill at bungie.com Mon May 5 18:37:46 2008 From: luisvill at bungie.com (Luis Villegas) Date: Mon, 5 May 2008 15:37:46 -0700 Subject: [Mono-dev] Embedded Mono question In-Reply-To: <1210023521.5421.50.camel@erandi.boston.ximian.com> References: <1210023521.5421.50.camel@erandi.boston.ximian.com> Message-ID: Thank you Miguel, Are you planning on having other long term alternatives for this scenario inside the Mono API? Thank you, Luis Villegas -----Original Message----- From: Miguel de Icaza [mailto:miguel at novell.com] Sent: Monday, May 05, 2008 2:39 PM To: Luis Villegas Cc: mono-devel-list at lists.ximian.com Subject: Re: [Mono-dev] Embedded Mono question Hello, > How can achieve the same with Mono? Today you have two choices, they both boil down to exposing the API in a C-friendly way. You can bind the API by hand and expose C callable methods (extern "C" { void ... }), this is what we do in Moonlight, we expose C entry points to constructors, destructors and methods that must be invoked from managed code. The other option is to generate the bindings using a tool like SWIG that is able to generate the bindings by parsing header files. Miguel. > From miguel at novell.com Mon May 5 19:44:15 2008 From: miguel at novell.com (Miguel de Icaza) Date: Mon, 05 May 2008 19:44:15 -0400 Subject: [Mono-dev] Embedded Mono question In-Reply-To: References: <1210023521.5421.50.camel@erandi.boston.ximian.com> Message-ID: <1210031055.5421.56.camel@erandi.boston.ximian.com> Hello, > Are you planning on having other long term alternatives for this scenario inside the Mono API? We currently do not have any plans to expand on that direction; Doing the C/C++ CLI approach similar to Microsoft is really outside of the scope of what our team can achieve, so we have left that aside. There are a few options for enterprising developers to pursue, like hooking up to GCC's backend and generating the stubs automatically for you, but it is not something that we are currently planning on doing as part of Mono. > From: Miguel de Icaza [mailto:miguel at novell.com] > Sent: Monday, May 05, 2008 2:39 PM > To: Luis Villegas > Cc: mono-devel-list at lists.ximian.com > Subject: Re: [Mono-dev] Embedded Mono question > > Hello, > > > How can achieve the same with Mono? > > Today you have two choices, they both boil down to exposing the API in a > C-friendly way. You can bind the API by hand and expose C callable > methods (extern "C" { void ... }), this is what we do in Moonlight, we > expose C entry points to constructors, destructors and methods that must > be invoked from managed code. > > The other option is to generate the bindings using a tool like SWIG that > is able to generate the bindings by parsing header files. > > Miguel. > > From LuisOrtiz at Verizon.Net Mon May 5 19:51:59 2008 From: LuisOrtiz at Verizon.Net (Luis F. Ortiz) Date: Mon, 05 May 2008 19:51:59 -0400 Subject: [Mono-dev] How To Convince Mono To Allocate Big Arrays Message-ID: <755C0F44-B391-4EC6-863B-06435D73AD3D@Verizon.Net> Back in September ("Big Arrays, Many Changes --- Request for Advice") I asked folks for advice on how to go about adding the capability to Mono to allocate arrays with more than Int32.MaxValue elements. After playing around with it for a few months, I'm at the point where I have an implementation that mostly works, with a couple of warts which could probably be quickly fixed by someone who knows more than I do about Mono internals. I spoke with Miguel about these patches, and he encouraged me to post them to mono-dev as soon as I got them to pass the "make check" test suite. So here I am a week later. I want to start by going over the changes themselves, what alternatives there might be to what I had done and what flaws I know to exist in the implementation. First off, though Microsoft chose for some reason NOT to implement large array allocation, the necessary APIs are in the .NET specification. For example, in the System.Array class, we find: public long GetLongLength(int dimension); public long LongLength { get; } public static Array CreateInstance(Type elementType, params long[] lengths); public Object GetValue(long index); public void SetValue(Object value, long index); ... (other overloads omitted, but there) and we find that the Newarr opcode takes a natural int or an Int32 as the length, so the bytecode level is ready too. Mono as of 1.2.6 already implemented most (all?) of the necessary interfaces in mcs/class/corlib/System/Array.cs, but they all cast down their long arguments down to integers as the underlying implementation was not there. So the first set of changes were to: mono/metadata/object.c mono/metadata/object.h mono/metadata/icall-def.h mono/metadata/icall.c mono/metadata/socket-io.c In object.h I made three changes: 1) Changed MonoArrayBounds to use gsize instead of guint32 as the type for length and lower_bound, 2) Changed MonoArray to use gsize instead of guint32 as the type of max_length, 3) Changed the prototypes for mono_array_new(), mono_array_new_full(), and mono_array_new_specific() to take gsize's instead of guint32's for their size and bounds parameters. I.e.: MonoArray* -mono_array_new (MonoDomain *domain, MonoClass *eclass, guint32 n); +mono_array_new (MonoDomain *domain, MonoClass *eclass, gsize n); MonoArray* mono_array_new_full (MonoDomain *domain, MonoClass *array_class, - guint32 *lengths, guint32 *lower_bounds); + gsize *lengths, gsize *lower_bounds); MonoArray * -mono_array_new_specific (MonoVTable *vtable, guint32 n); +mono_array_new_specific (MonoVTable *vtable, gsize n); This is the first place an alternative shows up. ?Which type is better: gsize or gssize? The unsigned type gsize better matches the type memory allocation functions use (size_t or some variant) and the existing guint32, but the signed type better matches the interface presented at the top level (i.e. CreateInstance). I chose the unsigned alternative, but an argument could be made for the signed type. Another alternative would be to create 64 bit versions of the mono_array_new(), mono_array_new_full(), and mono_array_new_specific() functions, but that seemed to be too much work. The changes in object.c add the implementations of the modified mono_array_new(), mono_array_new_full(), and mono_array_new_specific() functions. There was some confusing #defines around MYGUINT32_MAX that I did not like, but rather than replace that cruft, I extended it. The changes in icall-def.h add two new method calls to the array object, CreateInstanceImpl64() and GetLongLength(). It might be possible to avoid the CreateInstanceImpl64() definition and make it an overload of CreateInstanceImpl() with long parameters, if I was sure on how to do that. The changes to icall.c tweak the implementation of ves_icall_System_Array_CreateInstanceImpl() to change the type of the sizes array and add the implementations of ves_icall_System_Array_CreateInstanceImpl64() and ves_icall_System_Array_GetLongLength(). The change to socket-io.c was to tweak its usage of mono_array_new_full to use gssize instead of int for for the array of lengths. So all these changes get us to the point where the basic foundation is laid down, but there is still the JIT to contend with. It requires a few more files to be changed: mono/mini/mini.c mono/mini/jit-icalls.c mono/mini/exceptions.cs The changes in mini.c change the signature of mono_array_new and mono_array_new_specific to take "int" instead of "int32". The changes in jit-calls.c do the boring change of guint32's into gsize's. The changes in exceptions.cs split the test case for test_0_array_size into a 32 and 64 bit variant, because an allocation of Int32.MaxValue can succeed after these changes are applied. There was only one touch-up needed in the the C# compiler: the GetLength property code special-inlined code-generation needed to be tweaked since it is now possible to get an array length that will not fit into an I4. Changing mcs/mcs/ecore.cs and mcs/mcs/expression.cs to use OpCodes.Conv_Ovf_I4 after OpCodes.Ldlen instead of OpCodes.Conv_I4 fixed that. Oh, yeah, and ALL the long method calls in mcs/class/corlib/System/ Array.cs needed to be converted over to use CreateInstanceImpl64() and GetLongLength(). The SetValue() and GetValue() implementations still need work, but since there are no unit tests for those methods, I put them off. That gets us to the point where we can allocate a large array, but it does not let us index a large array. I changed the following files to start the process of converting the indexing operations to do bounds checking against the now 32/64 bit length of arrays and to index using a 64/32 bit index: mono/mini/inssel-amd64.brg mono/mini/mini-amd64.c mono/mini/mini-ops.h mono/mini/cpu-amd64.md In inssel-amd64.brg, I changed the macro MONO_EMIT_NEW_AMD64_ICOMPARE_MEMBASE_REG to use a new opcode OP_AMD64_COMPARE_MEMBASE_REG_I8 instead of OP_AMD64_ICOMPARE_MEMBASE_REG and hacked CEE_LDELEMA to no longer use the faster OP_X86_LEA because I was not sure how to generalize it. Perhaps MONO_EMIT_NEW_AMD64_ICOMPARE_MEMBASE_REG should be retired and explicit I4 and I8 versions substituted where appropriate. In mini-amd64.c I added the OP_AMD64_COMPARE_MEMBASE_REG_I8 opcode as being the same as OP_AMD64_ICOMPARE_MEMBASE_REG, except with an operand size of 8 bytes instead of 4. In mini-ops.h and cpu-amd64.md I added an entries for OP_AMD64_COMPARE_MEMBASE_REG_I8 and amd64_compare_membase_reg_i8. These changes seem to get 64 bit indexing working, and passed all the regression tests in 1.2.6, but in 1.9.1 a regression test called test_0_regress_75832() breaks. It could be that the changes I made in mono/mini are incorrect. I am sure the changes are incomplete, and I have not considered what to do to other architectures. Advice or assistance is greatly appreciated. Luis F. Ortiz Official Mono Modifier Interactive Supercomputing, Inc. PS: Here are the changes proper: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080505/8f8eb396/attachment-0002.html -------------- next part -------------- A non-text attachment was scrubbed... Name: BigArrays.patch Type: application/octet-stream Size: 27156 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080505/8f8eb396/attachment-0001.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080505/8f8eb396/attachment-0003.html From jonathan.oomph at gmail.com Mon May 5 22:58:16 2008 From: jonathan.oomph at gmail.com (Jonathan Thomas) Date: Mon, 5 May 2008 21:58:16 -0500 Subject: [Mono-dev] gstreamer-sharp Question Message-ID: <4d8784610805051958l737d346bw83e92c4436ebb0e7@mail.gmail.com> I am very interested in using the gstreamer bindings in a mono project, but I could really use some advice. I can't seem to find the gstreamer-sharp assembly anywhere. The only luck I've had so far is some development notes back in 2006. Do any mono up-to-date bindings exist for the gstreamer framework? Is there a better multi-media framework I should use? Ultimately, I would like to create a non-linear video editing application using C# and the mono framework. I have been told that gstreamer is the most powerful media framework in linux (at least that's what I was told). Thanks in advance! -Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080505/a8db42bf/attachment.html From m.j.hutchinson at gmail.com Tue May 6 03:06:16 2008 From: m.j.hutchinson at gmail.com (Michael Hutchinson) Date: Tue, 6 May 2008 03:06:16 -0400 Subject: [Mono-dev] gstreamer-sharp Question In-Reply-To: <4d8784610805051958l737d346bw83e92c4436ebb0e7@mail.gmail.com> References: <4d8784610805051958l737d346bw83e92c4436ebb0e7@mail.gmail.com> Message-ID: 2008/5/5 Jonathan Thomas : > I am very interested in using the gstreamer bindings in a mono project, but > I could really use some advice. I can't seem to find the gstreamer-sharp > assembly anywhere. The only luck I've had so far is some development notes > back in 2006. Do any mono up-to-date bindings exist for the gstreamer > framework? Is there a better multi-media framework I should use? Sadly, the GStreamer# bindings were never completed, and have been unmaintianed for some time. I don't know how hard it'd be to get it off the ground, though this would certainly be nice to see. > Ultimately, I would like to create a non-linear video editing application > using C# and the mono framework. I have been told that gstreamer is the > most powerful media framework in linux (at least that's what I was told). GStreamer is arguably the most powerful modular media framework on Linux, yes, and works on other platforms too. Banshee (Mono-powered media app) uses Gstreamer via P/Invoking a C wrapper library. There was some debate over whether gstreamer in its current state it's suitable for editing: http://www.mdk.org.pl/2006/12/07/state-of-diva http://blogs.gnome.org/uraeus/2006/12/08/comment-on-diva/ However, that was some time ago, and I'm pretty sure that any such issues can be fixed. I'd suggest taking a look at resurrecting Diva, a Mono based nonlinear video editing app which was widely praised, but stalled a while ago from lack of contibutions. AFAIK it also used a C library to implement the core editing features. Sadly the website seems to be down right now, but I suspect other people on this list can direct you to mirrors. -- Michael Hutchinson http://mjhutchinson.com From m.j.hutchinson at gmail.com Tue May 6 03:12:43 2008 From: m.j.hutchinson at gmail.com (Michael Hutchinson) Date: Tue, 6 May 2008 03:12:43 -0400 Subject: [Mono-dev] gstreamer-sharp Question In-Reply-To: References: <4d8784610805051958l737d346bw83e92c4436ebb0e7@mail.gmail.com> Message-ID: On Tue, May 6, 2008 at 3:06 AM, Michael Hutchinson wrote: ... > I'd suggest taking a look at resurrecting Diva, a Mono based nonlinear > video editing app which was widely praised, but stalled a while ago > from lack of contibutions. AFAIK it also used a C library to > implement the core editing features. Sadly the website seems to be > down right now, but I suspect other people on this list can direct you > to mirrors. While the website's down, SVN is still up: http://svn.diva-project.org/diva/ -- Michael Hutchinson http://mjhutchinson.com From jaebird at gmail.com Tue May 6 10:57:20 2008 From: jaebird at gmail.com (Jae Stutzman) Date: Tue, 6 May 2008 09:57:20 -0500 Subject: [Mono-dev] gstreamer-sharp Question In-Reply-To: References: <4d8784610805051958l737d346bw83e92c4436ebb0e7@mail.gmail.com> Message-ID: I believe the missing gstreamer# is a huge hole in the development stack. We also p/invoke the c lib in our apps. It would be nice to see this project revived and become a first-class citizen like gtk#. Maybe we can garner some folks together! GSoc Mono.Media is another option, perhaps. Jae -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080506/b0e3b673/attachment.html From buhochileno at gmail.com Tue May 6 12:13:55 2008 From: buhochileno at gmail.com (buhochileno at gmail.com) Date: Tue, 06 May 2008 12:13:55 -0400 Subject: [Mono-dev] gstreamer-sharp Question In-Reply-To: References: <4d8784610805051958l737d346bw83e92c4436ebb0e7@mail.gmail.com> Message-ID: <482083C3.7020506@gmail.com> Jae Stutzman wrote: > I believe the missing gstreamer# is a huge hole in the development > stack. We also p/invoke the c lib in our apps. It would be nice to see > this project revived and become a first-class citizen like gtk#. Maybe > we can garner some folks together! > Yap I agree and the gstreamer# is allready done (GSoc), only need to be revised and checked...Why to waist that effort? > GSoc Mono.Media is another option, perhaps. > > Jae Mauricio > ------------------------------------------------------------------------ > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From matte at softfusion.net Tue May 6 07:06:19 2008 From: matte at softfusion.net (matte at softfusion.net) Date: Tue, 06 May 2008 04:06:19 -0700 Subject: [Mono-dev] System.DllNotFoundException: gdiplus.dll Message-ID: <20080506040619.s5xw2zf1ackck8cw@webmail.softfusion.net> Was wondering if anyone could give me some pointers on how to troubleshoot this error. I have mono 1.9.1, mod-mono 1.9.1 and libgdiplus (not sure which version) installed. Non graphical aspx pages run fine, but when i try to run one that uses image objects, ect on it i get the error below. Running ldconfig didnt resolve it, and if i do [ldconfig -p |grep libgdiplus] it returns [libgdiplus.so.0 (libc6) => /usr/lib/libgdiplus.so.0] i have the following copies of libgdiplus on my machine. /opt/mono-1.9.1/lib/libgdiplus.so /opt/mono-1.9.1/lib/libgdiplus.so.0 /opt/mono-1.9.1/lib/libgdiplus.so.0.0.0 /usr/lib/libgdiplus.so.0 /usr/lib/libgdiplus.so.0.0.0 i found some examples on how to debug a winforms app with this error, but no example on how to debug mod-mono with it. Server Error in '/' Application gdiplus.dll Description: HTTP 500. Error processing request. Stack Trace: System.DllNotFoundException: gdiplus.dll at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&) at System.Drawing.GDIPlus..cctor () [0x00000] Version information: Mono Version: 2.0.50727.42; ASP.NET Version: 2.0.50727.42 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From usander at onlinehome.de Tue May 6 12:40:43 2008 From: usander at onlinehome.de (Uwe Sander) Date: Tue, 6 May 2008 18:40:43 +0200 Subject: [Mono-dev] System.DllNotFoundException: gdiplus.dll In-Reply-To: <20080506040619.s5xw2zf1ackck8cw@webmail.softfusion.net> References: <20080506040619.s5xw2zf1ackck8cw@webmail.softfusion.net> Message-ID: <200805061840.43407.usander@onlinehome.de> Hi, Am Dienstag, 6. Mai 2008 schrieb matte at softfusion.net: > Description: HTTP 500. Error processing request. > > Stack Trace: > > System.DllNotFoundException: gdiplus.dll > at (wrapper managed-to-native) > System.Drawing.GDIPlus:GdiplusStartup > (ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartup >Output&) at System.Drawing.GDIPlus..cctor () [0x00000] > I had to add to my config file, located in /etc/mono. Maybe it's the same for you? HIH - Uwe -- Chaos, panic & disorder - my work here is done. Jabber usander at jabber.ccc.de From m.j.hutchinson at gmail.com Tue May 6 13:05:02 2008 From: m.j.hutchinson at gmail.com (Michael Hutchinson) Date: Tue, 6 May 2008 13:05:02 -0400 Subject: [Mono-dev] gstreamer-sharp Question In-Reply-To: References: <4d8784610805051958l737d346bw83e92c4436ebb0e7@mail.gmail.com> Message-ID: 2008/5/6 Jae Stutzman : > I believe the missing gstreamer# is a huge hole in the development stack. We > also p/invoke the c lib in our apps. It would be nice to see this project > revived and become a first-class citizen like gtk#. Maybe we can garner some > folks together! > > GSoc Mono.Media is another option, perhaps. We have picked students for this year already. You want to wait till Sept 2009? :) The fundamental problems with Mono.Media at the moment are: (a) no-one spec'ed concrete use cases and requirements -- it's still a very nebulous idea (b) the are no applications that want to consume it -- people have suggested Banshee, but it has no problems with its GStreamer/C player engine, and you'd need to present a very solid case to change this (c) developing a good and sufficiently generic library from scratch like this will take a lot of time and effort IMO a good GStreamer# binding will be more useful than Mono.Media. -- Michael Hutchinson http://mjhutchinson.com From sebastien.pouliot at gmail.com Tue May 6 13:26:15 2008 From: sebastien.pouliot at gmail.com (Sebastien Pouliot) Date: Tue, 06 May 2008 13:26:15 -0400 Subject: [Mono-dev] System.DllNotFoundException: gdiplus.dll In-Reply-To: <20080506040619.s5xw2zf1ackck8cw@webmail.softfusion.net> References: <20080506040619.s5xw2zf1ackck8cw@webmail.softfusion.net> Message-ID: <1210094775.4147.52.camel@poupou.home> Hey, On Tue, 2008-05-06 at 04:06 -0700, matte at softfusion.net wrote: > Was wondering if anyone could give me some pointers on how to > troubleshoot this error. > > I have mono 1.9.1, mod-mono 1.9.1 and libgdiplus (not sure which > version) installed. First always make sure you're using the same version of libgdiplus as your mono version (otherwise you'll end up with other problems*). > Non graphical aspx pages run fine, but when i try > to run one that uses image objects, ect on it i get the error below. mod_mono is (generally) not executed under your user own account. So this means the library packaged with the installer, /opt/mono-1.9.1/, will not be available (by default) unless you update your environment variables (like LD_LIBRARY_PATH) > Running ldconfig didnt resolve it, and if i do [ldconfig -p |grep libgdiplus] > it returns [libgdiplus.so.0 (libc6) => /usr/lib/libgdiplus.so.0] > > i have the following copies of libgdiplus on my machine. > /opt/mono-1.9.1/lib/libgdiplus.so > /opt/mono-1.9.1/lib/libgdiplus.so.0 > /opt/mono-1.9.1/lib/libgdiplus.so.0.0.0 > /usr/lib/libgdiplus.so.0 > /usr/lib/libgdiplus.so.0.0.0 (*) make sure your mono, from /opt/mono-1.9.1/ is not using the last one > i found some examples on how to debug a winforms app with this error, > but no example on how to debug mod-mono with it. Just google a bit more. I used "mod_mono gdiplus.dll" and found several answers. > > > Server Error in '/' Application > gdiplus.dll > > Description: HTTP 500. Error processing request. > > Stack Trace: > > System.DllNotFoundException: gdiplus.dll > at (wrapper managed-to-native) > System.Drawing.GDIPlus:GdiplusStartup > (ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&) > at System.Drawing.GDIPlus..cctor () [0x00000] > > Version information: Mono Version: 2.0.50727.42; ASP.NET Version: 2.0.50727.42 > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From stapostol at gmail.com Tue May 6 14:25:59 2008 From: stapostol at gmail.com (stapostol) Date: Tue, 06 May 2008 21:25:59 +0300 Subject: [Mono-dev] gstreamer-sharp Question In-Reply-To: References: <4d8784610805051958l737d346bw83e92c4436ebb0e7@mail.gmail.com> Message-ID: <4820A2B7.1000100@gmail.com> Michael Hutchinson wrote: > (b) the are no applications that want to consume it -- people have > suggested Banshee, but it has no problems with its GStreamer/C player > engine, and you'd need to present a very solid case to change this > Regarding (b), and depending on its architecture, Mono.Media might be very useful as a decoding frontend to applications using the Open Toolkit or the Tao framework (the backend would then be OpenAL). There's a potentially significant "market" here, if Mono.Media comes to fruition. > IMO a good GStreamer# binding will be more useful than Mono.Media. > > > This is quite interesting, too. Does GStreamer# use an intermediate C library, like Banshee? How portable is it? From m.j.hutchinson at gmail.com Tue May 6 15:42:00 2008 From: m.j.hutchinson at gmail.com (Michael Hutchinson) Date: Tue, 6 May 2008 15:42:00 -0400 Subject: [Mono-dev] gstreamer-sharp Question In-Reply-To: <4820A2B7.1000100@gmail.com> References: <4d8784610805051958l737d346bw83e92c4436ebb0e7@mail.gmail.com> <4820A2B7.1000100@gmail.com> Message-ID: On Tue, May 6, 2008 at 2:25 PM, stapostol wrote: > Michael Hutchinson wrote: > > > (b) the are no applications that want to consume it -- people have > > suggested Banshee, but it has no problems with its GStreamer/C player > > engine, and you'd need to present a very solid case to change this > > > > > Regarding (b), and depending on its architecture, Mono.Media might be very > useful as a decoding frontend to applications using the Open Toolkit or the > Tao framework (the backend would then be OpenAL). > > There's a potentially significant "market" here, if Mono.Media comes to > fruition. I don't think anyone had brought up 3D games as a possible market for GStreamer yet :) I suspect that the use cases are different enough from desktop apps that they'd be best served by a specialised API. > > IMO a good GStreamer# binding will be more useful than Mono.Media. > > > This is quite interesting, too. Does GStreamer# use an intermediate C > library, like Banshee? How portable is it? According to their features page, GStreamer works on "Linux on i86,PPC, ARM using GCC. Solaris on x86 and SPARC using both GCC and Forte, MacOSX, Microsoft Windows using MS Visual Developer and IBM OS/400." AFAIK Banshee's C library does all the pipeline/element-building work and exposes a minimal media player engine C API. I think Banshee's Windows and Mac ports will be using GStreamer. I'd be surprised if the GStreamer# library doesn't have some C "glue" code, but it should be as crossplatform as GStreamer itself. -- Michael Hutchinson http://mjhutchinson.com From cjac at colliertech.org Tue May 6 17:02:50 2008 From: cjac at colliertech.org (C.J. Adams-Collier) Date: Tue, 06 May 2008 14:02:50 -0700 Subject: [Mono-dev] FW: [Ironruby-core] build problems (mono, gmcs from svn) In-Reply-To: <1210107528.29110.238.camel@cjac.intra.cardomain.com> References: <1210090007.29110.236.camel@cjac.intra.cardomain.com> <372109E149E8084D8E6C7D9CFD82E0632D92E58DDF@NA-EXMSG-C115.redmond.corp.microsoft.com> <1210107528.29110.238.camel@cjac.intra.cardomain.com> Message-ID: <1210107770.29110.242.camel@cjac.intra.cardomain.com> do I just create test-646.cs and dump this to it in order to add it to the regression suite for mcs? public class RuleBuilder where T : class {} public interface IDynamicObject { RuleBuilder GetRule() where T : class; } public class RubyMethod : IDynamicObject { RuleBuilder IDynamicObject.GetRule() /* where T : class */ { return new RuleBuilder(); } } Cheers, C.J. On Tue, 2008-05-06 at 13:58 -0700, C.J. Adams-Collier wrote: > On Tue, 2008-05-06 at 09:51 -0700, John Lam (IRONRUBY) wrote: > > C.J. Adams-Collier: > > > > > I believe these are new bugs that our latest revision revealed in mono. https://bugzilla.novell.com/show_bug.cgi?id=387040 > > Thanks, John. I'll ping Marek and see if he can help me fix this. If > nothing else, I'll add the test from that bug to the regression suite. > > > It's good to see that Tony's taken over the mantle of breaking mono :) > > > > Thanks, > > -John > > Cheers, > > C.J. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080506/6936b206/attachment.bin From marek.safar at seznam.cz Tue May 6 18:09:29 2008 From: marek.safar at seznam.cz (Marek Safar) Date: Tue, 06 May 2008 23:09:29 +0100 Subject: [Mono-dev] FW: [Ironruby-core] build problems (mono, gmcs from svn) In-Reply-To: <1210107770.29110.242.camel@cjac.intra.cardomain.com> References: <1210090007.29110.236.camel@cjac.intra.cardomain.com> <372109E149E8084D8E6C7D9CFD82E0632D92E58DDF@NA-EXMSG-C115.redmond.corp.microsoft.com> <1210107528.29110.238.camel@cjac.intra.cardomain.com> <1210107770.29110.242.camel@cjac.intra.cardomain.com> Message-ID: <4820D719.4060508@seznam.cz> Hello C.J. > do I just create test-646.cs and dump this to it in order to add it to > the regression suite for mcs? > No, this is generic test so it has to be gtest-xxx.cs, you also have to make it run (it has to have Main method) and then because it's a failure you have to update know-issues-[g,s]mcs with correct expected failure. Marek From stapostol at gmail.com Tue May 6 18:24:51 2008 From: stapostol at gmail.com (stapostol) Date: Wed, 07 May 2008 01:24:51 +0300 Subject: [Mono-dev] gstreamer-sharp Question In-Reply-To: References: <4d8784610805051958l737d346bw83e92c4436ebb0e7@mail.gmail.com> <4820A2B7.1000100@gmail.com> Message-ID: <4820DAB3.9060405@gmail.com> Michael Hutchinson wrote: > > I don't think anyone had brought up 3D games as a possible market for > GStreamer yet :) > > I suspect that the use cases are different enough from desktop apps > that they'd be best served by a specialised API. > These APIs power quite a few multimedia apps, too - not just games. In fact, there is little difference between a media player, a game or another multimedia app, with regard to media decoding. For example, all three categor