From buhochileno at gmail.com Sun Jun 1 01:11:05 2008 From: buhochileno at gmail.com (buhochileno at gmail.com) Date: Sun, 01 Jun 2008 01:11:05 -0400 Subject: [Mono-dev] Strange GdkSharp.PixbufDestroyNotifyWrapper error.. In-Reply-To: <1212291246.25463.45.camel@t61p.site> References: <07511CE4-3DC1-4329-956D-61A7975E583A@cogmation.com> <256a87490805160900j27ebe782k605dd491171f5649@mail.gmail.com> <5C63E892-3D6E-43D1-9B87-92BFACECAF7D@cogmation.com> <1211317482.27066.1.camel@erandi.boston.ximian.com> <48E60855-FD2F-464C-A02A-3887AE34FB7E@cogmation.com> <48406AED.4040605@gmail.com> <1212202079.25463.28.camel@t61p.site> <48420070.4010203@gmail.com> <1212291246.25463.45.camel@t61p.site> Message-ID: <48422F69.3050107@gmail.com> > On Sat, 2008-05-31 at 21:50 -0400, buhochileno at gmail.com wrote: > >>> On Fri, 2008-05-30 at 17:00 -0400, buhochileno at gmail.com wrote: >>> >>> >>> >>>> ExcObject: System.InvalidProgramException: Invalid IL code in (wrapper >>>> native-to-managed) GdkSharp.PixbufDestroyNotifyWrapper:NativeCallback >>>> (intptr,intptr): IL_0030: call 0x00000006 >>>> > > Actually, I guess this IL problem required a fix in mono, according to > Zoltan on: > > https://bugzilla.novell.com/show_bug.cgi?id=362951 > > yap I read that post ... :-S, any hpe then?, I can of confuse, the patch fix only something in gtk# but also a patch is needed for mono to make thing to work again with byte[]...? > The patch I committed yesterday fixes an exception that would have come > out if you had his fix. > > you mean use the delegate that is recomended and the your patch?, that convination finally get thing to work again? >> any alternatives?? (build the object in other way, use a temporary >> object to do..something..), I really need to fix this and checkout+patch >> and recompile all mono or gtk-sharp sources don't seems to be a easy >> solution :-S, also wait to next rpm released is kind of long time ;-) , >> sugestions?, may be is posible to use a compiled version from you? I >> would really apreciate if that is posible and fix the problem.. >> > > PibxbufLoader may have some alternatives. > I going to search about that... > Wade is building snapshot builds for gtk-sharp trunk if you are running > openSUSE: > > http://mono.ximian.com/monobuild/snapshot/download-trunk/ > > right now sadly no, using Fedora 8..may I have to change to opensuse :-S ... may be can be used in fedora8, or may be can work with a dll copy from you? :-),..if i don't find a easy solution I going to back to mono-12.6 with that version all work like a charm.. > Based on the rpm version for gtk-sharp2, it looks like the latest > snapshot is for r100145 though. > > Mike > > > Thanks again Mike.. Mauricio From buhochileno at gmail.com Sun Jun 1 17:17:16 2008 From: buhochileno at gmail.com (buhochileno at gmail.com) Date: Sun, 01 Jun 2008 17:17:16 -0400 Subject: [Mono-dev] Strange GdkSharp.PixbufDestroyNotifyWrapper error.. In-Reply-To: <1212291246.25463.45.camel@t61p.site> References: <07511CE4-3DC1-4329-956D-61A7975E583A@cogmation.com> <256a87490805160900j27ebe782k605dd491171f5649@mail.gmail.com> <5C63E892-3D6E-43D1-9B87-92BFACECAF7D@cogmation.com> <1211317482.27066.1.camel@erandi.boston.ximian.com> <48E60855-FD2F-464C-A02A-3887AE34FB7E@cogmation.com> <48406AED.4040605@gmail.com> <1212202079.25463.28.camel@t61p.site> <48420070.4010203@gmail.com> <1212291246.25463.45.camel@t61p.site> Message-ID: <484311DC.50905@gmail.com> > On Sat, 2008-05-31 at 21:50 -0400, buhochileno at gmail.com wrote: > >>> On Fri, 2008-05-30 at 17:00 -0400, buhochileno at gmail.com wrote: >>> >>> >>> >>>> ExcObject: System.InvalidProgramException: Invalid IL code in (wrapper >>>> native-to-managed) GdkSharp.PixbufDestroyNotifyWrapper:NativeCallback >>>> (intptr,intptr): IL_0030: call 0x00000006 >>>> > > Actually, I guess this IL problem required a fix in mono, according to > Zoltan on: > > https://bugzilla.novell.com/show_bug.cgi?id=362951 > > The patch I committed yesterday fixes an exception that would have come > out if you had his fix. > > >> any alternatives?? (build the object in other way, use a temporary >> object to do..something..), I really need to fix this and checkout+patch >> and recompile all mono or gtk-sharp sources don't seems to be a easy >> solution :-S, also wait to next rpm released is kind of long time ;-) , >> sugestions?, may be is posible to use a compiled version from you? I >> would really apreciate if that is posible and fix the problem.. >> > > PibxbufLoader may have some alternatives. > > PixbufLoader seems to be an option, but when I try to usit whit: Gdk.PixbufLoader pbL = new PixbufLoader(buffer, 800, 340); //buffer of byte[] type... I allways get: ExcObject: GLib.GException: Image has zero width ...same trying to use a stream for the constructor of the pixbufloader.. any idea? thanks Mike Mauricio > Wade is building snapshot builds for gtk-sharp trunk if you are running > openSUSE: > > http://mono.ximian.com/monobuild/snapshot/download-trunk/ > > Based on the rpm version for gtk-sharp2, it looks like the latest > snapshot is for r100145 though. > > Mike > > > From miguel at novell.com Sun Jun 1 19:30:13 2008 From: miguel at novell.com (Miguel de Icaza) Date: Sun, 01 Jun 2008 19:30:13 -0400 Subject: [Mono-dev] Next point release In-Reply-To: <1212009090.21566.11.camel@T7.Linux> References: <1212009090.21566.11.camel@T7.Linux> Message-ID: <1212363013.4968.69.camel@linux.site> > Has any date been set yet for the next beta or point release? Yes, the next release will be Mono 2.0, the schedule looks roughly like this now: July 14th mono-2-0 branches July 21st Second Beta for Mono 2.0 (we called 1.9 beta1) July 21th Mono 2.0 RC1 (two weeks later) Aug 4th Mono 2.0 RC2 (two weeks later) Aug 18th Mono 2.0 RC3, optional (two weeks later) Sept 9th Mono 2.0 is released. Miguel. From atsushi at ximian.com Sun Jun 1 20:50:45 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Mon, 02 Jun 2008 09:50:45 +0900 Subject: [Mono-dev] question about System.Web.Extensions unit tests Message-ID: <484343E5.2070704@ximian.com> Hello, I have been seeing NUnit test failures in Sys.Web.Extensions. It keeps the buildbot orange (warned), so today I checked the tests to see what should be expected. There I found that such lines that treats TARGET_JVM as different: -------- #if TARGET_JVM Assert.AreEqual ("$create(My.Type, null, null, {\"myName2\":\"myCompId2\",\"myName1\":\"myCompId1\"}, $get(\"Element1\"));", script); #else Assert.AreEqual ("$create(My.Type, null, null, {\"myName1\":\"myCompId1\",\"myName2\":\"myCompId2\"}, $get(\"Element1\"));", script); #endif -------- Though I see no reason to differentiate tests for GH. To my understanding from our meeting at Mono summit 2006 time, Mainsoft does not use #if TARGET_JVM without any reasonable differences, so I would like to know the reason why there are such switches all around the tests so that they can pass on GH while they will fail on Mono, if any. Actually when I ran make PROFILE=net_3_5 run-test-ondotnet, there was no error report. So if those tests are rewritten, they will fail on .NET. If it is only about behavioral difference in generic Dictinary`2, then those tests should not be conditionalized to legalize only in TARGET_JVM and rewritten to fail only on .NET. (Who cares after all?) Atsushi Eno From noaml at mainsoft.com Mon Jun 2 08:12:08 2008 From: noaml at mainsoft.com (Noam Lampert) Date: Mon, 2 Jun 2008 05:12:08 -0700 Subject: [Mono-dev] question about System.Web.Extensions unit tests In-Reply-To: References: Message-ID: Hi Atsushi, We care about .NET. Please do not rewrite the tests to fail on .NET. Passing on .NET gives strong confidence that our implementation is correct, and not only non-regressive. As you can see, the order of the members in Grasshopper and .NET is different and hence the #if. The best way to fix these tests is to have a strong comparison engine that will understand that these specific differences are not important, but this is not a small task. Perhaps a simpler workaround is to succeed on either of the strings (e.g. Assert.IsTrue(script == res1 || script == res2); ). Another alternative is to change the #if TARGET_JVM to #if !DOTNET. Noam -----Original Message----- From: Atsushi Eno [mailto:atsushi at ximian.com] Sent: Monday, June 02, 2008 3:51 AM To: mono-devel-list at lists.ximian.com Subject: [Mono-dev] question about System.Web.Extensions unit tests Hello, I have been seeing NUnit test failures in Sys.Web.Extensions. It keeps the buildbot orange (warned), so today I checked the tests to see what should be expected. There I found that such lines that treats TARGET_JVM as different: -------- #if TARGET_JVM Assert.AreEqual ("$create(My.Type, null, null, {\"myName2\":\"myCompId2\",\"myName1\":\"myCompId1\"}, $get(\"Element1\"));", script); #else Assert.AreEqual ("$create(My.Type, null, null, {\"myName1\":\"myCompId1\",\"myName2\":\"myCompId2\"}, $get(\"Element1\"));", script); #endif -------- Though I see no reason to differentiate tests for GH. To my understanding from our meeting at Mono summit 2006 time, Mainsoft does not use #if TARGET_JVM without any reasonable differences, so I would like to know the reason why there are such switches all around the tests so that they can pass on GH while they will fail on Mono, if any. Actually when I ran make PROFILE=net_3_5 run-test-ondotnet, there was no error report. So if those tests are rewritten, they will fail on .NET. If it is only about behavioral difference in generic Dictinary`2, then those tests should not be conditionalized to legalize only in TARGET_JVM and rewritten to fail only on .NET. (Who cares after all?) Atsushi Eno From sebastien.pouliot at gmail.com Mon Jun 2 08:25:37 2008 From: sebastien.pouliot at gmail.com (Sebastien Pouliot) Date: Mon, 02 Jun 2008 08:25:37 -0400 Subject: [Mono-dev] X509Certificate problem In-Reply-To: <2bac78ae.38e01496.483fcdf3.c5b66@o2.pl> References: <2bac78ae.38e01496.483fcdf3.c5b66@o2.pl> Message-ID: <1212409538.2826.30.camel@poupou.home> Hey, This should be working(*) and we have unit tests for them. Please fill a bug report and attach your PEM certificate to it. Sebastien (*) the only known issue is that the current ASN.1 decoder does not support elements with indefinite length - but this is not common for certificates. On Fri, 2008-05-30 at 11:50 +0200, paszczi wrote: > Hi guys! > > I have problems with reading certificate from PEM file. The following code works on .NET (System.Security): > > X509Certificate crt = new X509Certificate (certPath); > > but doesn't work in Mono 1.9.1 (I've tried to use both System.Security and Mono.Security + FileStream to read bytes from file). > The message I get is: > > Unhandled Exception: System.Security.Cryptography.CryptographicException: Unable to decode certificate. ---> System.Security.Cryptography.Cryptographi > cException: Input data cannot be coded as a valid certificate. ---> System.Security.Cryptography.CryptographicException: Input data cannot be coded as > a valid certificate. > at Mono.Security.X509.X509Certificate.Parse (System.Byte[] data) [0x00000] --- End of inner exception stack trace --- > > at Mono.Security.X509.X509Certificate.Parse (System.Byte[] data) [0x00000] > at Mono.Security.X509.X509Certificate..ctor (System.Byte[] data) [0x00000] > at System.Security.Cryptography.X509Certificates.X509Certificate.Import (System.Byte[] rawData, System.String password, X509KeyStorageFlags keyStora > geFlags) [0x00000] --- End of inner exception stack trace --- > > at System.Security.Cryptography.X509Certificates.X509Certificate.Import (System.Byte[] rawData, System.String password, X509KeyStorageFlags keyStora > geFlags) [0x00000] > at System.Security.Cryptography.X509Certificates.X509Certificate.Import (System.String fileName, System.String password, X509KeyStorageFlags keyStor > ageFlags) [0x00000] > at System.Security.Cryptography.X509Certificates.X509Certificate..ctor (System.String fileName) [0x00000] > at SecPL.Return.Tools.SignManifest.ManifestSigner..ctor (System.String manifestPath, System.String certPath, System.String privateKeyPath) [0x00000] > > at SecPL.Return.Tools.SignManifest.ManifestSigner.Main (System.String[] args) [0x00000] > > Any hint? > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list From vargaz at gmail.com Mon Jun 2 09:22:12 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Mon, 2 Jun 2008 15:22:12 +0200 Subject: [Mono-dev] [PATCH] VS Solution cleanup In-Reply-To: <37c5788d0805301715v4a80a4e9h3c011b9cf469146f@mail.gmail.com> References: <37c5788d0805301715v4a80a4e9h3c011b9cf469146f@mail.gmail.com> Message-ID: <295e750a0806020622m62a7e9d0gb48b1b065abe2c45@mail.gmail.com> Hi, This is ok to check in. Zoltan 2008/5/31 Bill Holmes : > In preparation of integrating Visual Studio compilation of the runtime > as part of the cygwin make process I have done some cleanup with the > solution and projects files in MSVC. > > I still have more to do as not all projects are building completely, > but they were pretty busted when I found them ;) > > The main point of this patch was to unify the output directories for > each project and configuration. > > Working : > eglib > libgc > libmono > genmdesc > monoburg > mono > > Broken and Disabled : > test-invoke > test-metadata > teste > monodiet > monodis > monograph > pedump > > test_eglib works for all eglib targets but not for the non eglib > targets. I would like to get that working with a link to the real > glib so we can have comparison tests. > > I will continue to work on the broken projects if this is approved. > Let me know if they are all still needed. > > The non-eglib targets for x64 are completely shut off simply because > we have no glib for x64. > > Please let me know if you have any suggestions. Also is the OK to commit? > > Thanks > -bill > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From vargaz at gmail.com Mon Jun 2 09:23:53 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Mon, 2 Jun 2008 15:23:53 +0200 Subject: [Mono-dev] [PATCH] Fixes for libtest.c and VS In-Reply-To: <37c5788d0805301828t2e7d34qab348ff54f7857ec@mail.gmail.com> References: <37c5788d0805301828t2e7d34qab348ff54f7857ec@mail.gmail.com> Message-ID: <295e750a0806020623w5f0d5667y5742d0ccc0e1f10b@mail.gmail.com> Hi, This is ok to check in. Zoltan 2008/5/31 Bill Holmes : > Last patch for the week. I promise. > > These changes are to make libtest.c ready to be compiled in Visual > Studio. I will be sending the patch for the new VS project and update > to the solution. > > The STDCALL statements had to be moved and I added declspec(dllexport) > statements to all methods. At least I hope I got them all. > > Sorry no ChangeLog, I will add it Monday. It is late and my wife is > calling again. Thanks all and have a good weekend. > > -bill > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From vargaz at gmail.com Mon Jun 2 09:25:43 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Mon, 2 Jun 2008 15:25:43 +0200 Subject: [Mono-dev] [PATCH] Update to Winx64 stack patch In-Reply-To: <37c5788d0805301111w77318444hfb6f50db4f1be558@mail.gmail.com> References: <37c5788d0805301111w77318444hfb6f50db4f1be558@mail.gmail.com> Message-ID: <295e750a0806020625o1fa09d53naac38c5fe132f502@mail.gmail.com> Hi, This is ok to check in too. Zoltan 2008/5/30 Bill Holmes : > I have updated this patch based off a discussion with Zoltan on IRC. > > -bill > > On Wed, May 28, 2008 at 11:00 AM, Bill Holmes wrote: >> I have a small patch that seems to have fix a bunch of issues with the >> unit tests under mono/tests for Windows x64. Please review and let me >> know if I am headed in the right direction. I am still a bit lost in >> this code but I fell that I am learning. ;) >> >> There are still a small number of tests failing that I am looking at. >> The first set I will be tackling are the ones that call into >> libtest.so (or dll.) I will be adding a build project to the VS >> solution for this dll next. >> >> I will also be doing some cleanup in the VS solution and projects to >> make the output directories more uniform. This is in preparation for >> adding a vsbuild target to the current cygwin make process that >> Jonathan and Miguel discussed in an earlier thread. >> >> -bill >> > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From nataraj.ramaswamy at wipro.com Mon Jun 2 09:11:50 2008 From: nataraj.ramaswamy at wipro.com (nataraj.ramaswamy at wipro.com) Date: Mon, 2 Jun 2008 18:41:50 +0530 Subject: [Mono-dev] MonoTests.System.MathTest.TestIEEERemainder fails in Solaris 7 sparc Message-ID: <90D6C8E4AC52DB4283864AF35A41E73F0273BE08@CHN-SNR-MBX02.wipro.com> Hi, We have been able to successfully build Mono on Solaris 7 sparc (32 bit). When we tried to execute the Class Library test suites, some of the test cases were failing. We need your expert inputs/suggestions on the following failure: Under mcs/class/corlib, MonoTests.System.MathTest.TestIEEERemainder fails with the error message: Negative Dividend expected:<-9223372036854775808> but was:<128> at MonoTests.System.MathTest.TestIEEERemainder () [0x000bf] in /mono_sol7/mono-1.9/mcs/class/corlib/Test/System/MathTest.cs:414 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0003f] in /mono_sol7/mono-1.9/mcs/class/corlib/System.Reflection/MonoMethod.cs:149 On analysing further, it is observed that: - In System/Math.cs, IEEERemainder uses InternalInt64BitsToDouble. Changing this to Int64BitsToDouble gave the expected result and the test case passed. - InternalInt64BitsToDouble() uses SwappableToDouble() under System/BitConverter.cs where it gets into (!IsLittleEndian) which fills the value in the big endian (reverse) order whereas Int64BitsToDouble uses ToDouble() which doesnot have this conversion based on endianness (!IsLittleEndian). We would like to know your valuable inputs on how to fix this issue for Solaris 7 sparc. Please let us know whether it would be a right fix to use Int64BitsToDouble instead of InternalInt64BitsToDouble (conditionally built for Solaris 7 sparc). Thanks & regards, Nataraj Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080602/b3d11dc1/attachment-0001.html From sivakumar.arumugam at wipro.com Mon Jun 2 09:38:51 2008 From: sivakumar.arumugam at wipro.com (sivakumar.arumugam at wipro.com) Date: Mon, 2 Jun 2008 19:08:51 +0530 Subject: [Mono-dev] MonoTests.Mono.Data.SqliteClient.SqliteParameterUnitTests.InsertRandomValuesWithParameter () - failed Message-ID: <438662DA48DCAA41B1DF648BD4BD76C0087F962B@CHN-SNR-MBX01.wipro.com> Test Case SqliteParameterUnitTests fails Error Message "expected:<0> but was:<1> at MonoTests.Mono.Data.SqliteClient.SqliteParameterUnitTests.InsertRandomVa luesWithParameter () [0x00187] in /mono_sol7/mono-1.9/mcs/class/Mono.Data.SqliteClient/Test/SqliteParamete rUnitTests.cs:70 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0003f] in /mono_sol7/mono-1.9/mcs/class/corlib/System.Reflection/MonoMethod.cs:149 " Component Mono.Data.SqliteClient Environment Solaris 7, Sparc My Analysis I think the command is not working as expected SqliteCommand insertCmd = new SqliteCommand(DELETE FROM t1;"INSERT INTO t1 (t, f, i, b) VALUES(:textP, :floatP, :int egerP, :blobP)", _conn); I request your help to fix this issue. Thanks. Regards Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080602/87cc2258/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 4642 bytes Desc: image002.jpg Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080602/87cc2258/attachment.jpe From atsushi at ximian.com Mon Jun 2 10:11:49 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Mon, 02 Jun 2008 23:11:49 +0900 Subject: [Mono-dev] question about System.Web.Extensions unit tests In-Reply-To: References: Message-ID: <4843FFA5.30103@ximian.com> Hello, That is very strange argument. Do you understand that your way of testing compelling Mono to fail while you guys are kept away from it INCORRECTLY because of #if TARGET_JVM THAT DOES NOT PASS ON .NET? I regard it as inappropriate practice and strongly suggest to rewrite those tests. Atsushi Eno Noam Lampert wrote: > Hi Atsushi, > > We care about .NET. Please do not rewrite the tests to fail on .NET. > Passing on .NET gives strong confidence that our implementation is > correct, and not only non-regressive. > > As you can see, the order of the members in Grasshopper and .NET is > different and hence the #if. > > The best way to fix these tests is to have a strong comparison engine > that will understand that these specific differences are not important, > but this is not a small task. > > Perhaps a simpler workaround is to succeed on either of the strings > (e.g. Assert.IsTrue(script == res1 || script == res2); ). > Another alternative is to change the #if TARGET_JVM to #if !DOTNET. > > Noam > > -----Original Message----- > From: Atsushi Eno [mailto:atsushi at ximian.com] > Sent: Monday, June 02, 2008 3:51 AM > To: mono-devel-list at lists.ximian.com > Subject: [Mono-dev] question about System.Web.Extensions unit tests > > Hello, > > I have been seeing NUnit test failures in Sys.Web.Extensions. It keeps > the buildbot orange (warned), so today I checked the tests to see > what should be expected. > > There I found that such lines that treats TARGET_JVM as different: > > -------- > #if TARGET_JVM > Assert.AreEqual ("$create(My.Type, null, null, > {\"myName2\":\"myCompId2\",\"myName1\":\"myCompId1\"}, > $get(\"Element1\"));", script); > #else > Assert.AreEqual ("$create(My.Type, null, null, > {\"myName1\":\"myCompId1\",\"myName2\":\"myCompId2\"}, > $get(\"Element1\"));", script); > #endif > -------- > > Though I see no reason to differentiate tests for GH. To my > understanding from our meeting at Mono summit 2006 time, Mainsoft > does not use #if TARGET_JVM without any reasonable differences, > so I would like to know the reason why there are such switches all > around the tests so that they can pass on GH while they will fail > on Mono, if any. > > Actually when I ran make PROFILE=net_3_5 run-test-ondotnet, there > was no error report. So if those tests are rewritten, they will > fail on .NET. > > If it is only about behavioral difference in generic Dictinary`2, > then those tests should not be conditionalized to legalize only in > TARGET_JVM and rewritten to fail only on .NET. (Who cares after all?) > > Atsushi Eno > > From noaml at mainsoft.com Mon Jun 2 10:14:37 2008 From: noaml at mainsoft.com (Noam Lampert) Date: Mon, 2 Jun 2008 07:14:37 -0700 Subject: [Mono-dev] question about System.Web.Extensions unit tests In-Reply-To: <4843FFA5.30103@ximian.com> References: <4843FFA5.30103@ximian.com> Message-ID: I agree that the tests need modification. There is no intention of compelling Mono to fail, and there are plenty of solutions that Mono should pass the tests. I described some below. However, having an #ifdef in the tests does not mean that we (Mono and Grasshopper) are "kept away from it INCORRECTLY because of #if TARGET_JVM THAT DOES NOT PASS ON .NET". On the contrary, it means that a human being reviewed the difference between Mono and .NET, clearly marked the difference in the code of the test, and decided that this difference is acceptable. It is far better than creating tests that pass on Mono and fail on .NET. Noam -----Original Message----- From: Atsushi Eno [mailto:atsushi at ximian.com] Sent: Monday, June 02, 2008 5:12 PM To: Noam Lampert Cc: mono-devel-list Subject: Re: [Mono-dev] question about System.Web.Extensions unit tests Hello, That is very strange argument. Do you understand that your way of testing compelling Mono to fail while you guys are kept away from it INCORRECTLY because of #if TARGET_JVM THAT DOES NOT PASS ON .NET? I regard it as inappropriate practice and strongly suggest to rewrite those tests. Atsushi Eno Noam Lampert wrote: > Hi Atsushi, > > We care about .NET. Please do not rewrite the tests to fail on .NET. > Passing on .NET gives strong confidence that our implementation is > correct, and not only non-regressive. > > As you can see, the order of the members in Grasshopper and .NET is > different and hence the #if. > > The best way to fix these tests is to have a strong comparison engine > that will understand that these specific differences are not important, > but this is not a small task. > > Perhaps a simpler workaround is to succeed on either of the strings > (e.g. Assert.IsTrue(script == res1 || script == res2); ). > Another alternative is to change the #if TARGET_JVM to #if !DOTNET. > > Noam > > -----Original Message----- > From: Atsushi Eno [mailto:atsushi at ximian.com] > Sent: Monday, June 02, 2008 3:51 AM > To: mono-devel-list at lists.ximian.com > Subject: [Mono-dev] question about System.Web.Extensions unit tests > > Hello, > > I have been seeing NUnit test failures in Sys.Web.Extensions. It keeps > the buildbot orange (warned), so today I checked the tests to see > what should be expected. > > There I found that such lines that treats TARGET_JVM as different: > > -------- > #if TARGET_JVM > Assert.AreEqual ("$create(My.Type, null, null, > {\"myName2\":\"myCompId2\",\"myName1\":\"myCompId1\"}, > $get(\"Element1\"));", script); > #else > Assert.AreEqual ("$create(My.Type, null, null, > {\"myName1\":\"myCompId1\",\"myName2\":\"myCompId2\"}, > $get(\"Element1\"));", script); > #endif > -------- > > Though I see no reason to differentiate tests for GH. To my > understanding from our meeting at Mono summit 2006 time, Mainsoft > does not use #if TARGET_JVM without any reasonable differences, > so I would like to know the reason why there are such switches all > around the tests so that they can pass on GH while they will fail > on Mono, if any. > > Actually when I ran make PROFILE=net_3_5 run-test-ondotnet, there > was no error report. So if those tests are rewritten, they will > fail on .NET. > > If it is only about behavioral difference in generic Dictinary`2, > then those tests should not be conditionalized to legalize only in > TARGET_JVM and rewritten to fail only on .NET. (Who cares after all?) > > Atsushi Eno > > From rajesh.raji at wipro.com Mon Jun 2 10:21:10 2008 From: rajesh.raji at wipro.com (rajesh.raji at wipro.com) Date: Mon, 2 Jun 2008 19:51:10 +0530 Subject: [Mono-dev] MonoTests.System.IO.StdioFileStreamTest.Write unit test case fails in Solaris 7 sparc Message-ID: <9CC1A1B45A081B42829F4B9D8A08BBBF016540F1@CHN-SNR-MBX02.wipro.com> Hello guys, Please assist us on the below error message: Error Message While trying to run the test suite, I was getting the following error under mcs/class/Mono.Posix directory: ------------------------------------------------------------------------ ----------------------------------------------- expected:<1> but was:<0> at MonoTests.System.IO.StdioFileStreamTest.Write () [0x000cc] in /mono_sol7/mono-1.9/mcs/class/Mono.Posix/Test/Mono.Unix/StdioFileStreamT est.cs:278 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0003f] in /mono_sol7/mono-1.9/mcs/class/corlib/System.Reflection/MonoMethod.cs:149 ------------------------------------------------------------------------ ----------------------------------------------- This test suite is working fine for Mono 1.9 on Solaris 10 (x86 architecture) as well as in Linux platforms. Component Mono.Posix Architecture Solaris 7, Sparc 32 bit Analysis On analyzing the cause for the assertion in "Test/Mono.Unix/StdioFileStreamTest.cs" under Mono.Posix directory, we observed the following: - Three write operations (stream.Write) was done to the file, after which a fread command was issued without doing a fseek. stream.Write (outbytes, 0, 7); stream.Write (outbytes, 7, 7); stream.Write (outbytes, 14, 1); stream.Read (bytes, 0, 15); - But the test suite passed, when I tweaked a fseek (stream.Seek) between the write and read operations. - I suspect this should be the problem as the 'bytes' array is filled with zero after the read operation which is not the expected case. Any idea/suggestions on this issue are appreciated! Thanks a lot in advance for the help rendered. Thanks Rajesh Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080602/e7effc7d/attachment-0001.html From atsushi at ximian.com Mon Jun 2 12:45:27 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Tue, 03 Jun 2008 01:45:27 +0900 Subject: [Mono-dev] question about System.Web.Extensions unit tests In-Reply-To: References: <4843FFA5.30103@ximian.com> Message-ID: <484423A7.2030709@ximian.com> Ok I'm glad to know that you guys recognize it as issue (though you wouldn't fix the tests). I'll simply disable those tests if there is no fix for this release-blocking issue by the time we do the next release. The release process will become clear and present danger at that time. ("#if !DOTNET" does not make sense; the conditional compilation is done at compile time, not run time. We don't have such switch anyways. See mcs/class/README for the expected switches.) Atsushi Eno Noam Lampert wrote: > I agree that the tests need modification. > There is no intention of compelling Mono to fail, and there are plenty > of solutions that Mono should pass the tests. I described some below. > > However, having an #ifdef in the tests does not mean that we (Mono and > Grasshopper) are "kept away from it INCORRECTLY because of #if > TARGET_JVM THAT DOES NOT PASS ON .NET". On the contrary, it means that a > human being reviewed the difference between Mono and .NET, clearly > marked the difference in the code of the test, and decided that this > difference is acceptable. It is far better than creating tests that pass > on Mono and fail on .NET. > > Noam > > -----Original Message----- > From: Atsushi Eno [mailto:atsushi at ximian.com] > Sent: Monday, June 02, 2008 5:12 PM > To: Noam Lampert > Cc: mono-devel-list > Subject: Re: [Mono-dev] question about System.Web.Extensions unit tests > > Hello, > > That is very strange argument. Do you understand that your way of > testing compelling Mono to fail while you guys are kept away > from it INCORRECTLY because of #if TARGET_JVM THAT DOES NOT PASS > ON .NET? I regard it as inappropriate practice and strongly suggest > to rewrite those tests. > > Atsushi Eno > > Noam Lampert wrote: >> Hi Atsushi, >> >> We care about .NET. Please do not rewrite the tests to fail on .NET. >> Passing on .NET gives strong confidence that our implementation is >> correct, and not only non-regressive. >> >> As you can see, the order of the members in Grasshopper and .NET is >> different and hence the #if. >> >> The best way to fix these tests is to have a strong comparison engine >> that will understand that these specific differences are not > important, >> but this is not a small task. >> >> Perhaps a simpler workaround is to succeed on either of the strings >> (e.g. Assert.IsTrue(script == res1 || script == res2); ). >> Another alternative is to change the #if TARGET_JVM to #if !DOTNET. >> >> Noam >> >> -----Original Message----- >> From: Atsushi Eno [mailto:atsushi at ximian.com] >> Sent: Monday, June 02, 2008 3:51 AM >> To: mono-devel-list at lists.ximian.com >> Subject: [Mono-dev] question about System.Web.Extensions unit tests >> >> Hello, >> >> I have been seeing NUnit test failures in Sys.Web.Extensions. It keeps >> the buildbot orange (warned), so today I checked the tests to see >> what should be expected. >> >> There I found that such lines that treats TARGET_JVM as different: >> >> -------- >> #if TARGET_JVM >> Assert.AreEqual ("$create(My.Type, null, null, >> {\"myName2\":\"myCompId2\",\"myName1\":\"myCompId1\"}, >> $get(\"Element1\"));", script); >> #else >> Assert.AreEqual ("$create(My.Type, null, null, >> {\"myName1\":\"myCompId1\",\"myName2\":\"myCompId2\"}, >> $get(\"Element1\"));", script); >> #endif >> -------- >> >> Though I see no reason to differentiate tests for GH. To my >> understanding from our meeting at Mono summit 2006 time, Mainsoft >> does not use #if TARGET_JVM without any reasonable differences, >> so I would like to know the reason why there are such switches all >> around the tests so that they can pass on GH while they will fail >> on Mono, if any. >> >> Actually when I ran make PROFILE=net_3_5 run-test-ondotnet, there >> was no error report. So if those tests are rewritten, they will >> fail on .NET. >> >> If it is only about behavioral difference in generic Dictinary`2, >> then those tests should not be conditionalized to legalize only in >> TARGET_JVM and rewritten to fail only on .NET. (Who cares after all?) >> >> Atsushi Eno >> >> > > From ClassDevelopment at A-SoftTech.com Mon Jun 2 14:15:42 2008 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Mon, 2 Jun 2008 20:15:42 +0200 Subject: [Mono-dev] Next part of string patch (replace). Please test. Message-ID: <000901c8c4dc$ab25a780$0170f680$@com> This time the change is much smaller ;) Adds some additional Unittests and some explanatory LAMESPECS. For additional explanation see the last String patch mail or the original mailing-list discussion. For me all Unittests (including the new ones) pass. Did not observe regressions. Happy Hacking Andreas P.S. After that only split is missing... -------------- next part -------------- A non-text attachment was scrubbed... Name: StringReplace.patch Type: application/octet-stream Size: 13094 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080602/306ca1de/attachment.obj From ssen at vmware.com Mon Jun 2 14:38:00 2008 From: ssen at vmware.com (Saurav Sen) Date: Mon, 2 Jun 2008 11:38:00 -0700 Subject: [Mono-dev] Newbie MDB question Message-ID: <6B971E939E68624CAE15D559D4CACBF2206456@PA-EXCH06.vmware.com> Hi, I have mono 1.9 installed on RHEL5. Where can I get mdb from? Also does mdb work on windows? Thanks /Saurav -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080602/eb38fea6/attachment.html From buhochileno at gmail.com Mon Jun 2 15:25:59 2008 From: buhochileno at gmail.com (buhochileno at gmail.com) Date: Mon, 02 Jun 2008 15:25:59 -0400 Subject: [Mono-dev] Strange GdkSharp.PixbufDestroyNotifyWrapper error.. In-Reply-To: <1212291246.25463.45.camel@t61p.site> References: <07511CE4-3DC1-4329-956D-61A7975E583A@cogmation.com> <256a87490805160900j27ebe782k605dd491171f5649@mail.gmail.com> <5C63E892-3D6E-43D1-9B87-92BFACECAF7D@cogmation.com> <1211317482.27066.1.camel@erandi.boston.ximian.com> <48E60855-FD2F-464C-A02A-3887AE34FB7E@cogmation.com> <48406AED.4040605@gmail.com> <1212202079.25463.28.camel@t61p.site> <48420070.4010203@gmail.com> <1212291246.25463.45.camel@t61p.site> Message-ID: <48444947.3090801@gmail.com> Mike Kestner wrote: > On Sat, 2008-05-31 at 21:50 -0400, buhochileno at gmail.com wrote: > >>> On Fri, 2008-05-30 at 17:00 -0400, buhochileno at gmail.com wrote: >>> >>> >>> >>>> ExcObject: System.InvalidProgramException: Invalid IL code in (wrapper >>>> native-to-managed) GdkSharp.PixbufDestroyNotifyWrapper:NativeCallback >>>> (intptr,intptr): IL_0030: call 0x00000006 >>>> > > Actually, I guess this IL problem required a fix in mono, according to > Zoltan on: > > https://bugzilla.novell.com/show_bug.cgi?id=362951 > > The patch I committed yesterday fixes an exception that would have come > out if you had his fix. > > I'm really confuse if this is something fixed or patially fixed, I allready update my gtk related RPm from snapshot but still the same problem..also pixbufloader allways return me a "image has zero width"..please help me with this, any sugestion to fix this would be very, vey apreciated... Mauricio >> any alternatives?? (build the object in other way, use a temporary >> object to do..something..), I really need to fix this and checkout+patch >> and recompile all mono or gtk-sharp sources don't seems to be a easy >> solution :-S, also wait to next rpm released is kind of long time ;-) , >> sugestions?, may be is posible to use a compiled version from you? I >> would really apreciate if that is posible and fix the problem.. >> > > PibxbufLoader may have some alternatives. > > Wade is building snapshot builds for gtk-sharp trunk if you are running > openSUSE: > > http://mono.ximian.com/monobuild/snapshot/download-trunk/ > > Based on the rpm version for gtk-sharp2, it looks like the latest > snapshot is for r100145 though. > > Mike > > > From vargaz at gmail.com Mon Jun 2 16:15:28 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Mon, 2 Jun 2008 22:15:28 +0200 Subject: [Mono-dev] System.Decimal performance In-Reply-To: <23a15590805290706m72bb8fcasc8fd0967b22dbb26@mail.gmail.com> References: <23a15590805290706m72bb8fcasc8fd0967b22dbb26@mail.gmail.com> Message-ID: <295e750a0806021315k46377f98kb0ec5ef3f1f7de3c@mail.gmail.com> Hi, The next mono release (2.0) will have better decimal performance, especially when doing divisions. Zoltan 2008/5/29 Leszek Ciesielski : > Hi, > > the company I work for builds finance-related software, so we use the > Decimal type a lot. And in any computation-heavy program we find that > the Mono implementation of the decimal type... well... let's just say > it's not on par with MS.Net performance ;-) . Addition, substraction > and multiplication lag a bit (2-4 times slower). However, division is > at least 10 times slower, in some cases even 50x! I don't have any > complex tests at hand right now, but a simple performance-measuring > program is attached to the mail. There's also a java version (although > BigDecimal is not a simple equivalent of System.Decimal as it has no > upper bound on available precision). From my simple test the results > are as follows: > > MS.Net 3.5 > addition 2375 ms : 2354,156132 > substraction 2140,625 ms : 2337,043868 > multiplication 1734,375 ms : 189,08461995264 > division 8468,75 ms : 29097,233616240416508043573961 > > Mono 1.9 Windows 2.0 profile > addition 4812 ms : 2354,156132 > substraction 4781 ms : 2337,043868 > multiplication 3407 ms : 189,08461995264 > division 61390 ms : 29097,233616240416508043573961 > > Mono svn-linux 2.0 profile > addition 4201.837 ms : 2354.156132 > substraction 4413.458 ms : 2337.043868 > multiplication 4489.036 ms : 189.08461995264 > division 61303.573 ms : 29097.233616240416508043573961 > > Java 1.6.0_06 > addition 4640 ms : 2354.156132 > substraction 3969 ms : 2337.043868 > multiplication 2219 ms : 189.08461995264 > division 33376 ms : 29097.233616240416508043573961 > > Has anyone done any performance tunining with the decimal type? > > Regards, > > Leszek 'skolima' Ciesielski > > -- > MS-DOS user since 5.0 > Windows user since 3.11 > Linux user since kernel 2.4 > Novell Netware user since 2.2 > WARCRAFT user since 1.0 > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From paszczi at go2.pl Mon Jun 2 16:31:15 2008 From: paszczi at go2.pl (Maciej Paszta) Date: Mon, 2 Jun 2008 22:31:15 +0200 Subject: [Mono-dev] Strange xml schema validation error Message-ID: Any hints on this strange behaviour (in one xontext the same xml is successfully validated against schema in the other - not). https://bugzilla.novell.com/show_bug.cgi?id=396514 Best regards, Maciej Paszta From paszczi at go2.pl Mon Jun 2 16:37:12 2008 From: paszczi at go2.pl (Maciej Paszta) Date: Mon, 2 Jun 2008 22:37:12 +0200 Subject: [Mono-dev] X509Certificate problem In-Reply-To: <1212409538.2826.30.camel@poupou.home> References: <2bac78ae.38e01496.483fcdf3.c5b66@o2.pl> <1212409538.2826.30.camel@poupou.home> Message-ID: On Jun 2, 2008, at 2:25 PM, Sebastien Pouliot wrote: > Hey, > > This should be working(*) and we have unit tests for them. Please > fill a > bug report and attach your PEM certificate to it. Done, to anyone interested here's the link: https://bugzilla.novell.com/show_bug.cgi?id=396486 I was also wondering, since in my project I use X509Certificate2.PrivateKey setter which throws unsupported exception (the certificate is stored in pkcs#12 along with private key, but while exporting I want to get rid of it) - it works ok on .NET. Is it incomplete API or some other kind of bug? When I export such certificate (with removed PrivateKey) from .NET to file (encoded in Base64) and then try to import it again using mono runtime I get exception that the certificate couldn't be loaded (again works on .NET). Should I report it as well? p.s. sorry for sending this mail directly to you :) Best regards, Maciej Paszta From atsushi at ximian.com Mon Jun 2 16:50:37 2008 From: atsushi at ximian.com (Atsushi Eno) Date: Tue, 03 Jun 2008 05:50:37 +0900 Subject: [Mono-dev] Strange xml schema validation error In-Reply-To: References: Message-ID: <48445D1D.8010308@ximian.com> At the time of mono 1.9 there was a couple of bugs in XLinq (well, and we may still have some bugs). I have no idea what kind of error there was, but it is already gone in svn. Atsushi Eno Maciej Paszta wrote: > Any hints on this strange behaviour (in one xontext the same xml is > successfully validated against schema in the other - not). > > https://bugzilla.novell.com/show_bug.cgi?id=396514 > > Best regards, > Maciej Paszta > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From sebastien at ximian.com Mon Jun 2 17:01:03 2008 From: sebastien at ximian.com (Sebastien Pouliot) Date: Mon, 02 Jun 2008 17:01:03 -0400 Subject: [Mono-dev] X509Certificate problem Message-ID: <1212440463.2826.56.camel@poupou.home> oops, I should have c.c. the mailing-list... -------------- next part -------------- An embedded message was scrubbed... From: Sebastien Pouliot Subject: Re: [Mono-dev] X509Certificate problem Date: Mon, 02 Jun 2008 17:00:01 -0400 Size: 1708 Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080602/6da2c1e3/attachment.mht From ClassDevelopment at A-SoftTech.com Mon Jun 2 16:53:32 2008 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Mon, 2 Jun 2008 22:53:32 +0200 Subject: [Mono-dev] System.Decimal performance In-Reply-To: <295e750a0806021315k46377f98kb0ec5ef3f1f7de3c@mail.gmail.com> References: <23a15590805290706m72bb8fcasc8fd0967b22dbb26@mail.gmail.com> <295e750a0806021315k46377f98kb0ec5ef3f1f7de3c@mail.gmail.com> Message-ID: <003101c8c4f2$b829b550$287d1ff0$@com> There are massive regressions in System.Data that seem to come from the changes in decimal.c Andreas > -----Urspr?ngliche Nachricht----- > Von: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list- > bounces at lists.ximian.com] Im Auftrag von Zoltan Varga > Gesendet: Montag, 2. Juni 2008 22:15 > An: Leszek Ciesielski > Cc: mono-devel-list > Betreff: Re: [Mono-dev] System.Decimal performance > > Hi, > > The next mono release (2.0) will have better decimal performance, > especially > when doing divisions. > > Zoltan > > 2008/5/29 Leszek Ciesielski : > > Hi, > > > > the company I work for builds finance-related software, so we use the > > Decimal type a lot. And in any computation-heavy program we find that > > the Mono implementation of the decimal type... well... let's just say > > it's not on par with MS.Net performance ;-) . Addition, substraction > > and multiplication lag a bit (2-4 times slower). However, division is > > at least 10 times slower, in some cases even 50x! I don't have any > > complex tests at hand right now, but a simple performance-measuring > > program is attached to the mail. There's also a java version > (although > > BigDecimal is not a simple equivalent of System.Decimal as it has no > > upper bound on available precision). From my simple test the results > > are as follows: > > > > MS.Net 3.5 > > addition 2375 ms : 2354,156132 > > substraction 2140,625 ms : 2337,043868 > > multiplication 1734,375 ms : 189,08461995264 > > division 8468,75 ms : 29097,233616240416508043573961 > > > > Mono 1.9 Windows 2.0 profile > > addition 4812 ms : 2354,156132 > > substraction 4781 ms : 2337,043868 > > multiplication 3407 ms : 189,08461995264 > > division 61390 ms : 29097,233616240416508043573961 > > > > Mono svn-linux 2.0 profile > > addition 4201.837 ms : 2354.156132 > > substraction 4413.458 ms : 2337.043868 > > multiplication 4489.036 ms : 189.08461995264 > > division 61303.573 ms : 29097.233616240416508043573961 > > > > Java 1.6.0_06 > > addition 4640 ms : 2354.156132 > > substraction 3969 ms : 2337.043868 > > multiplication 2219 ms : 189.08461995264 > > division 33376 ms : 29097.233616240416508043573961 > > > > Has anyone done any performance tunining with the decimal type? > > > > Regards, > > > > Leszek 'skolima' Ciesielski > > > > -- > > MS-DOS user since 5.0 > > Windows user since 3.11 > > Linux user since kernel 2.4 > > Novell Netware user since 2.2 > > WARCRAFT user since 1.0 > > > > _______________________________________________ > > 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 vargaz at gmail.com Mon Jun 2 17:40:04 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Mon, 2 Jun 2008 23:40:04 +0200 Subject: [Mono-dev] System.Decimal performance In-Reply-To: <003101c8c4f2$b829b550$287d1ff0$@com> References: <23a15590805290706m72bb8fcasc8fd0967b22dbb26@mail.gmail.com> <295e750a0806021315k46377f98kb0ec5ef3f1f7de3c@mail.gmail.com> <003101c8c4f2$b829b550$287d1ff0$@com> Message-ID: <295e750a0806021440k40666708g1e5df482e1f98c92@mail.gmail.com> Those are now fixed in SVN. Zoltan On Mon, Jun 2, 2008 at 10:53 PM, Andreas Nahr wrote: > There are massive regressions in System.Data that seem to come from the > changes in decimal.c > > Andreas > >> -----Urspr?ngliche Nachricht----- >> Von: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list- >> bounces at lists.ximian.com] Im Auftrag von Zoltan Varga >> Gesendet: Montag, 2. Juni 2008 22:15 >> An: Leszek Ciesielski >> Cc: mono-devel-list >> Betreff: Re: [Mono-dev] System.Decimal performance >> >> Hi, >> >> The next mono release (2.0) will have better decimal performance, >> especially >> when doing divisions. >> >> Zoltan >> >> 2008/5/29 Leszek Ciesielski : >> > Hi, >> > >> > the company I work for builds finance-related software, so we use the >> > Decimal type a lot. And in any computation-heavy program we find that >> > the Mono implementation of the decimal type... well... let's just say >> > it's not on par with MS.Net performance ;-) . Addition, substraction >> > and multiplication lag a bit (2-4 times slower). However, division is >> > at least 10 times slower, in some cases even 50x! I don't have any >> > complex tests at hand right now, but a simple performance-measuring >> > program is attached to the mail. There's also a java version >> (although >> > BigDecimal is not a simple equivalent of System.Decimal as it has no >> > upper bound on available precision). From my simple test the results >> > are as follows: >> > >> > MS.Net 3.5 >> > addition 2375 ms : 2354,156132 >> > substraction 2140,625 ms : 2337,043868 >> > multiplication 1734,375 ms : 189,08461995264 >> > division 8468,75 ms : 29097,233616240416508043573961 >> > >> > Mono 1.9 Windows 2.0 profile >> > addition 4812 ms : 2354,156132 >> > substraction 4781 ms : 2337,043868 >> > multiplication 3407 ms : 189,08461995264 >> > division 61390 ms : 29097,233616240416508043573961 >> > >> > Mono svn-linux 2.0 profile >> > addition 4201.837 ms : 2354.156132 >> > substraction 4413.458 ms : 2337.043868 >> > multiplication 4489.036 ms : 189.08461995264 >> > division 61303.573 ms : 29097.233616240416508043573961 >> > >> > Java 1.6.0_06 >> > addition 4640 ms : 2354.156132 >> > substraction 3969 ms : 2337.043868 >> > multiplication 2219 ms : 189.08461995264 >> > division 33376 ms : 29097.233616240416508043573961 >> > >> > Has anyone done any performance tunining with the decimal type? >> > >> > Regards, >> > >> > Leszek 'skolima' Ciesielski >> > >> > -- >> > MS-DOS user since 5.0 >> > Windows user since 3.11 >> > Linux user since kernel 2.4 >> > Novell Netware user since 2.2 >> > WARCRAFT user since 1.0 >> > >> > _______________________________________________ >> > 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 paszczi at go2.pl Tue Jun 3 05:52:21 2008 From: paszczi at go2.pl (Maciej Paszta) Date: Tue, 3 Jun 2008 11:52:21 +0200 Subject: [Mono-dev] X509Certificate problem In-Reply-To: <1212440463.2826.56.camel@poupou.home> References: <1212440463.2826.56.camel@poupou.home> Message-ID: <4B398195-CDB7-46CD-AEE1-75FF33989FE4@go2.pl> > > Yes, absolutely! And there you go :) Certificate along with examples: https://bugzilla.novell.com/show_bug.cgi?id=396620 Best regards, Maciej Paszta From kostat at gmail.com Tue Jun 3 07:37:44 2008 From: kostat at gmail.com (Konstantin Triger) Date: Tue, 3 Jun 2008 14:37:44 +0300 Subject: [Mono-dev] Next part of string patch (replace). Please test. In-Reply-To: <000901c8c4dc$ab25a780$0170f680$@com> References: <000901c8c4dc$ab25a780$0170f680$@com> Message-ID: Hello all, To my understanding, The following line: if (count <= maxValue) should be: if (count < maxValue) 2008/6/2 Andreas Nahr : > This time the change is much smaller ;) > > Adds some additional Unittests and some explanatory LAMESPECS. > For additional explanation see the last String patch mail or the original > mailing-list discussion. > For me all Unittests (including the new ones) pass. Did not observe > regressions. > > Happy Hacking > Andreas > > P.S. > After that only split is missing... > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- Regards, Konstantin Triger RSS: http://feeds.feedburner.com/ktriger -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080603/983764b0/attachment.html From vargaz at gmail.com Tue Jun 3 12:32:15 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Tue, 3 Jun 2008 18:32:15 +0200 Subject: [Mono-dev] [PATCH] Mono DTrace provider v2 In-Reply-To: <0610BF94-DE71-4CB9-80A0-EB5372694781@web.de> References: <37E99402-6F93-4D78-ABC0-2B864F05A976@web.de> <1200247959.7964.25.camel@erandi.boston.ximian.com> <295e750a0805280632g35fa2001t731608df02bf2423@mail.gmail.com> <5C7FDD33-96B5-4C08-A836-2870931AB0A1@web.de> <046E175E-9FFF-4070-AF30-11264FCC9281@unity3d.com> <0610BF94-DE71-4CB9-80A0-EB5372694781@web.de> Message-ID: <295e750a0806030932t46a05608k671e9e59fee8f08c@mail.gmail.com> Hi, Wouldn't be easier to pass the DTRACE and DTRACEFLAGS arguments to the prelink.sh script in Makefile.am as well, instead of creating it from an .in file ? Other than that, I think this is ok to check in. I still don't like the makefile changes, but at least they are inside an ifdef, so they won't break anything. Zoltan On Sat, May 31, 2008 at 12:09 AM, Andreas F?rber wrote: > Hello, > > Here's an updated version of my patch, adding initial DTrace support to the > Mono runtime. > > A new hand-crafted header file has been added, which is to be included in > place of the generated header file. It defines MONO_PROBE_* macros as > requested by Zoltan. The generated header file is then only needed iff > DTrace is enabled. > > Ugly build steps for Solaris were moved to a shell script. It extracts > object files from their library to a temporary directory, patches them and > puts them back in. This helps keep Makefiles clean and provides a one-stop > resource to fix things, should they break. Tested on OpenSolaris 2008.05 > i86. (Warning: I am not experienced in writing shell scripts.) > > It appears the problem with the gc-end probe on Solaris was due to some kind > of compiler optimization or the like. Adding a trailing sleep(0) call made > it work; I have limited this workaround to when the gc-end probe is enabled > on Solaris, to minimize the impact. Better ideas welcome. If we do stick > with it and it turns out this is needed in more void functions, we could > consider turning this into a MONO_PROBE_* macro to keep source files clean. > > Signed-off-by: Andreas Faerber > > Change Log v2: > > * dtrace-prelink.sh.in: New > Script to prevent ugly Solaris hacks in Makefiles. > > * configure.in: > Prepare support for OSX/x86_64 (untested) > Output dtrace-prelink.sh script. > > * data/mono.d: Renamed (from mono-trace.d) > Added standard Mono header. > Added generation argument to gc-{begin,end} probes. > Added explicit stability attributes. > > * mono/utils/dtrace.h: New > Wrapper around generated mono/utils/mono-dtrace.h. > Define MONO_PROBE_* macros. > > * mono/utils/Makefile.am: > We no longer need to postprocess the generated header file. > > * mono/metadata/Makefile.am, > mono/mini/Makefile.am: > Use new dtrace-prelink.sh script. > > * mono/mini/mini.c, > mono/metadata/boehm-gc.c: > Use new macros > > * mono/metadata/boehm-gc.c: > Add workaround to make gc-end probe work on Solaris. > > Andreas > > > > > > From ClassDevelopment at A-SoftTech.com Tue Jun 3 12:41:41 2008 From: ClassDevelopment at A-SoftTech.com (Andreas Nahr) Date: Tue, 3 Jun 2008 18:41:41 +0200 Subject: [Mono-dev] Next part of string patch (replace). Please test. In-Reply-To: References: <000901c8c4dc$ab25a780$0170f680$@com> Message-ID: <003001c8c598$b368cd70$1a3a6850$@com> Thanks for testing. Good catch! Fixed and added more testcases to check for that. Happy Hacking Andreas Von: Konstantin Triger [mailto:kostat at gmail.com] Gesendet: Dienstag, 3. Juni 2008 13:38 An: Andreas Nahr Cc: mono-devel-list at lists.ximian.com Betreff: Re: [Mono-dev] Next part of string patch (replace). Please test. Hello all, To my understanding, The following line: if (count <= maxValue) should be: if (count < maxValue) 2008/6/2 Andreas Nahr : This time the change is much smaller ;) Adds some additional Unittests and some explanatory LAMESPECS. For additional explanation see the last String patch mail or the original mailing-list discussion. For me all Unittests (including the new ones) pass. Did not observe regressions. Happy Hacking Andreas P.S. After that only split is missing... _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Regards, Konstantin Triger RSS: http://feeds.feedburner.com/ktriger -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080603/94026c14/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: StringReplace.patch Type: application/octet-stream Size: 13593 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080603/94026c14/attachment-0001.obj From andreas.faerber at web.de Tue Jun 3 16:49:16 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Tue, 3 Jun 2008 22:49:16 +0200 Subject: [Mono-dev] [PATCH] Mono DTrace provider v3 In-Reply-To: <295e750a0806030932t46a05608k671e9e59fee8f08c@mail.gmail.com> References: <37E99402-6F93-4D78-ABC0-2B864F05A976@web.de> <1200247959.7964.25.camel@erandi.boston.ximian.com> <295e750a0805280632g35fa2001t731608df02bf2423@mail.gmail.com> <5C7FDD33-96B5-4C08-A836-2870931AB0A1@web.de> <046E175E-9FFF-4070-AF30-11264FCC9281@unity3d.com> <0610BF94-DE71-4CB9-80A0-EB5372694781@web.de> <295e750a0806030932t46a05608k671e9e59fee8f08c@mail.gmail.com> Message-ID: <5744EE8D-68AA-4DD6-ACD0-92A2002931F7@web.de> Hi Zoltan, Thanks again for your feedback. v2 has been tested to work on Solaris 10 5/08 i86, too, in the meantime. It requires the same workaround for the gc-end probe as OpenSolaris. Am 03.06.2008 um 18:32 schrieb Zoltan Varga: > Wouldn't be easier to pass the DTRACE and DTRACEFLAGS arguments to > the > prelink.sh script in Makefile.am as well, instead of creating it from > an .in file ? Done. This eliminates calling config.status after changes to the script. > Other than that, I think this is ok to check in. Has the issue of --enable-dtrace vs. --disable-dtrace been decided? There appeared to be a disagreement between Miguel and you, and there were no further comments. One of Sun's DTrace developers writes that DTrace probes would work on earlier versions of Solaris as no-ops. http://blogs.sun.com/ahl/entry/user_land_tracing_gets_better#comment-1148081088000 I don't have access to pre-10 Solaris systems to confirm this. I verified it on OSX, by compiling a DTrace-enabled Hello World with gcc-3.3 and running it on both v10.5 and v10.3.9. So it would seem possible to enable DTrace support for the official Mono.framework 2.0, in case this was Miguel's thought. > I still don't like > the makefile changes, > but at least they are inside an ifdef, so they won't break anything. We have two options here. Either we commit the changes, allowing to improve them later. Or we commit only the Mac OS X part for now. As you like. I've added new probes for the JIT, method-compile-begin and method- compile-end. The MONO_PROBE_METHOD_COMPILE_* macros I've defined to accept a MonoMethod* argument and to translate it to the final probe arguments there. This avoids code duplication in mini.c. Note that my patch shows four returns not handled by Mono's profiler, for unsuccessful AOT generic sharing and for parts==1,2,3. Should that be fixed, or is it not necessary for some reason? Signed-off-by: Andreas Faerber ChangeLog v3: * dtrace-prelink.sh: Renamed (from dtrace-prelink.sh.in) Don't define AR, DTRACE, DTRACEFLAGS. Removed debug output. * configure.in: Don't output dtrace-prelink.sh. Move DTrace section up, to after the big-arrays section. * data/mono.d, mono/utils/dtrace.h, mono/mini/mini.c: Add new probes method-compile-{begin,end}. * mono/metadata/Makefile.am, mono/mini/Makefile.am: dtrace-prelink.sh is now in $(top_srcdir). Pass AR, DTRACE, DTRACEFLAGS as environment variables to dtrace- prelink.sh. Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: DTrace-USDT-3.diff Type: application/octet-stream Size: 15286 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080603/b4cef555/attachment.obj -------------- next part -------------- From mkestner at novell.com Tue Jun 3 17:19:28 2008 From: mkestner at novell.com (Mike Kestner) Date: Tue, 03 Jun 2008 16:19:28 -0500 Subject: [Mono-dev] gstreamer-sharp Question In-Reply-To: <1212105264.15559.39.camel@cjac.intra.cardomain.com> References: <4d8784610805051958l737d346bw83e92c4436ebb0e7@mail.gmail.com> <1210140380.5203.16.camel@linux.site> <15aef24e0805070505m1e270139kde0621fb8a169539@mail.gmail.com> <1212105264.15559.39.camel@cjac.intra.cardomain.com> Message-ID: <1212527968.25463.96.camel@t61p.site> On Thu, 2008-05-29 at 16:54 -0700, C.J. Adams-Collier wrote: > Aaron, > > Did you build this binding manually, or did you use gapi2? > > Mike, > > Is there any reason why gapi2 wouldn't work on gstreamer? My understanding is that the problem with a straight gapi binding was that there are proprietary gstreamer plugins which can't be GAPI-fied to identify all the APIs they expose, so there is need for more dynamic access to signals/events and properties of Gst.Elements. The gstreamer bindings effort undertaken during SoC a few years back was at least partially focused on this dynamic signal invocation and connection mechanism. -- Mike Kestner From vargaz at gmail.com Tue Jun 3 17:12:40 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Tue, 3 Jun 2008 23:12:40 +0200 Subject: [Mono-dev] [PATCH] Mono DTrace provider v3 In-Reply-To: <5744EE8D-68AA-4DD6-ACD0-92A2002931F7@web.de> References: <295e750a0805280632g35fa2001t731608df02bf2423@mail.gmail.com> <5C7FDD33-96B5-4C08-A836-2870931AB0A1@web.de> <046E175E-9FFF-4070-AF30-11264FCC9281@unity3d.com> <0610BF94-DE71-4CB9-80A0-EB5372694781@web.de> <295e750a0806030932t46a05608k671e9e59fee8f08c@mail.gmail.com> <5744EE8D-68AA-4DD6-ACD0-92A2002931F7@web.de> Message-ID: <295e750a0806031412n6194a82bu9ab7b0153dc7b7c9@mail.gmail.com> Hi, I think this is ok to check in. If it works out, we can enable it by default later. Zoltan On Tue, Jun 3, 2008 at 10:49 PM, Andreas F?rber wrote: > Hi Zoltan, > > Thanks again for your feedback. > > v2 has been tested to work on Solaris 10 5/08 i86, too, in the meantime. It > requires the same workaround for the gc-end probe as OpenSolaris. > > > Am 03.06.2008 um 18:32 schrieb Zoltan Varga: > >> Wouldn't be easier to pass the DTRACE and DTRACEFLAGS arguments to the >> prelink.sh script in Makefile.am as well, instead of creating it from >> an .in file ? > > Done. This eliminates calling config.status after changes to the script. > > >> Other than that, I think this is ok to check in. > > Has the issue of --enable-dtrace vs. --disable-dtrace been decided? There > appeared to be a disagreement between Miguel and you, and there were no > further comments. > > One of Sun's DTrace developers writes that DTrace probes would work on > earlier versions of Solaris as no-ops. > http://blogs.sun.com/ahl/entry/user_land_tracing_gets_better#comment-1148081088000 > I don't have access to pre-10 Solaris systems to confirm this. > I verified it on OSX, by compiling a DTrace-enabled Hello World with gcc-3.3 > and running it on both v10.5 and v10.3.9. So it would seem possible to > enable DTrace support for the official Mono.framework 2.0, in case this was > Miguel's thought. > > >> I still don't like >> the makefile changes, >> but at least they are inside an ifdef, so they won't break anything. > > We have two options here. Either we commit the changes, allowing to improve > them later. Or we commit only the Mac OS X part for now. As you like. > > > I've added new probes for the JIT, method-compile-begin and > method-compile-end. The MONO_PROBE_METHOD_COMPILE_* macros I've defined to > accept a MonoMethod* argument and to translate it to the final probe > arguments there. This avoids code duplication in mini.c. > Note that my patch shows four returns not handled by Mono's profiler, for > unsuccessful AOT generic sharing and for parts==1,2,3. Should that be fixed, > or is it not necessary for some reason? > > > Signed-off-by: Andreas Faerber > > ChangeLog v3: > > * dtrace-prelink.sh: Renamed (from dtrace-prelink.sh.in) > Don't define AR, DTRACE, DTRACEFLAGS. > Removed debug output. > > * configure.in: > Don't output dtrace-prelink.sh. > Move DTrace section up, to after the big-arrays section. > > * data/mono.d, > mono/utils/dtrace.h, > mono/mini/mini.c: > Add new probes method-compile-{begin,end}. > > * mono/metadata/Makefile.am, > mono/mini/Makefile.am: > dtrace-prelink.sh is now in $(top_srcdir). > Pass AR, DTRACE, DTRACEFLAGS as environment variables to dtrace-prelink.sh. > > Andreas > > > > > > From paszczi at go2.pl Wed Jun 4 04:04:31 2008 From: paszczi at go2.pl (Maciej Paszta) Date: Wed, 4 Jun 2008 10:04:31 +0200 Subject: [Mono-dev] Assembly lookup directory (probing) problem Message-ID: <3956EA6A-D945-4A93-9160-C6D87BC02C7F@go2.pl> Hello, I observed very strange behavior. In my app folder I have a subfolder of modules/ which contains several assemblies. I put the following lines into App.config: Not when I try to load a type from one of the assemblies stored in the folder: Type.GetType("Namespace.Class, Assembly) - it works fine, the type is correctly fetched. However when I reference the assembly from inside of the project without copying it into main app folder (leaving it in modules/ dir instead) I get error that the assembly could not be found. It seems that mono doesn't care in this case about the contest of the App.config. On .NET it works as expteced, is it a bug or a proper behavior? Best regards, Maciej Paszta From joe at unity3d.com Wed Jun 4 08:41:03 2008 From: joe at unity3d.com (Joachim Ante) Date: Wed, 4 Jun 2008 21:41:03 +0900 Subject: [Mono-dev] GC stop world stopping audio threads Message-ID: Hi, When the GC is under stress because a lot of managed allocations happen we get sound stuttering. It seems very likely that the GC is doing that when it calls Stop World on all other threads. Is there any way to make the Garbage collector only stop threads which are registered using mono_thread_attach? Best regards, Joachim Ante From skolima at gmail.com Wed Jun 4 08:59:49 2008 From: skolima at gmail.com (Leszek Ciesielski) Date: Wed, 4 Jun 2008 14:59:49 +0200 Subject: [Mono-dev] System.Decimal performance In-Reply-To: <295e750a0806021440k40666708g1e5df482e1f98c92@mail.gmail.com> References: <23a15590805290706m72bb8fcasc8fd0967b22dbb26@mail.gmail.com> <295e750a0806021315k46377f98kb0ec5ef3f1f7de3c@mail.gmail.com> <003101c8c4f2$b829b550$287d1ff0$@com> <295e750a0806021440k40666708g1e5df482e1f98c92@mail.gmail.com> Message-ID: <23a15590806040559j2e15708ra227ddd5f121a244@mail.gmail.com> On Mon, Jun 2, 2008 at 11:40 PM, Zoltan Varga wrote: > Those are now fixed in SVN. > > Zoltan > > On Mon, Jun 2, 2008 at 10:53 PM, Andreas Nahr > wrote: >> There are massive regressions in System.Data that seem to come from the >> changes in decimal.c >> >> Andreas >> >>> -----Urspr?ngliche Nachricht----- >>> Von: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list- >>> bounces at lists.ximian.com] Im Auftrag von Zoltan Varga >>> Gesendet: Montag, 2. Juni 2008 22:15 >>> An: Leszek Ciesielski >>> Cc: mono-devel-list >>> Betreff: Re: [Mono-dev] System.Decimal performance >>> >>> Hi, >>> >>> The next mono release (2.0) will have better decimal performance, >>> especially >>> when doing divisions. >>> >>> Zoltan >>> >>> 2008/5/29 Leszek Ciesielski : >>> > Hi, >>> > >>> > the company I work for builds finance-related software, so we use the >>> > Decimal type a lot. And in any computation-heavy program we find that >>> > the Mono implementation of the decimal type... well... let's just say >>> > it's not on par with MS.Net performance ;-) . Addition, substraction >>> > and multiplication lag a bit (2-4 times slower). However, division is >>> > at least 10 times slower, in some cases even 50x! I don't have any >>> > complex tests at hand right now, but a simple performance-measuring >>> > program is attached to the mail. There's also a java version >>> (although >>> > BigDecimal is not a simple equivalent of System.Decimal as it has no >>> > upper bound on available precision). From my simple test the results >>> > are as follows: >>> > >>> > MS.Net 3.5 >>> > addition 2375 ms : 2354,156132 >>> > substraction 2140,625 ms : 2337,043868 >>> > multiplication 1734,375 ms : 189,08461995264 >>> > division 8468,75 ms : 29097,233616240416508043573961 >>> > >>> > Mono 1.9 Windows 2.0 profile >>> > addition 4812 ms : 2354,156132 >>> > substraction 4781 ms : 2337,043868 >>> > multiplication 3407 ms : 189,08461995264 >>> > division 61390 ms : 29097,233616240416508043573961 >>> > >>> > Mono svn-linux 2.0 profile >>> > addition 4201.837 ms : 2354.156132 >>> > substraction 4413.458 ms : 2337.043868 >>> > multiplication 4489.036 ms : 189.08461995264 >>> > division 61303.573 ms : 29097.233616240416508043573961 >>> > >>> > Java 1.6.0_06 >>> > addition 4640 ms : 2354.156132 >>> > substraction 3969 ms : 2337.043868 >>> > multiplication 2219 ms : 189.08461995264 >>> > division 33376 ms : 29097.233616240416508043573961 >>> > >>> > Has anyone done any performance tunining with the decimal type? Same machine as before: Mono 1.9.1 linux 2.0 profile addition 4262.454 ms : 2354.156132 substraction 4274.603 ms : 2337.043868 multiplication 4194.232 ms : 189.08461995264 division 55155.252 ms : 29097.233616240416508043573961 (no changes, just a reference run) Mono /trunk/ r104850 linux 2.0 profile addition 3263.994 ms : 2354.156132 substraction 3225.994 ms : 2337.043868 multiplication 3725.557 ms : 189.08461995264 division 15559.139 ms : 29097.233616240416508043573961 Those are impressive speedups :-) MS.Net is still faster, but at least now wer'e in the same league ;-) From joe at unity3d.com Wed Jun 4 09:02:19 2008 From: joe at unity3d.com (Joachim Ante) Date: Wed, 4 Jun 2008 22:02:19 +0900 Subject: [Mono-dev] Paid mono hacking: Make AOT generate all code ahead of time Message-ID: <6343822E-B914-436A-A7CC-C4395390EE9B@unity3d.com> Hi, We are looking for a skilled mono hacker who can implement some AOT features for ARM processors for us. * Currently AOT doesn't generate dynamic libraries. Instead it generates binary files from which the AOT'ed code is loaded. We need to change AOT code so that it generates real dylib. This is because some devices completely disallow loading generated code for security reasons. Thus the only way to load mono code is to AOT it and store it in a real dylib that is loaded using dlsym or simillar functions. * We need AOT to generate all code necessary to run it. Currently there are a few functions which are not fully AOTed. For example trampolines generate JIT code. This needs to be turned into AOT'd code completely. There are most likely a few other places where JIT code is generated on the fly instead of using the AOTed code. There are some features that we don't need that simplify this task: * No need for generics * No need for pinvoke * No need for cross domain code If you are interested in working on this as a contractor, drop me a mail. Best regards, Joachim Ante From vargaz at gmail.com Wed Jun 4 09:04:47 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Wed, 4 Jun 2008 15:04:47 +0200 Subject: [Mono-dev] GC stop world stopping audio threads In-Reply-To: References: Message-ID: <295e750a0806040604re68b211mf7eb55145f9179c9@mail.gmail.com> Hi, AFAIK, the GC only stops threads which are registered with it. This can happen in the following ways: - threads started by the runtime are registered automatically - threads registered using mono_thread_attach (). - on unix, if an application includes gc.h, the header file will redefine pthread_create () etc. with gc specific versions which register threads - on windows, the gc registers all threads automatically. Under what OS you experience this ? BTW, the problem with not registering threads with the GC is that threads suspended by the GC could hold locks etc., so if another thread tries to use these locks (like the malloc lock), it will be suspended anyway. Also, if one of these unsuspended threads tries to register itself or enter the runtime while the word is suspended, various complex situations could occur. Zoltan On Wed, Jun 4, 2008 at 2:41 PM, Joachim Ante wrote: > Hi, > > When the GC is under stress because a lot of managed allocations > happen we get sound stuttering. > It seems very likely that the GC is doing that when it calls Stop > World on all other threads. > Is there any way to make the Garbage collector only stop threads > which are registered using mono_thread_attach? > > Best regards, > Joachim Ante > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > From vargaz at gmail.com Wed Jun 4 09:11:32 2008 From: vargaz at gmail.com (Zoltan Varga) Date: Wed, 4 Jun 2008 15:11:32 +0200 Subject: [Mono-dev] Paid mono hacking: Make AOT generate all code ahead of time In-Reply-To: <6343822E-B914-436A-A7CC-C4395390EE9B@unity3d.com> References: <6343822E-B914-436A-A7CC-C4395390EE9B@unity3d.com> Message-ID: <295e750a0806040611r6352b6e2kb45fec58b38e4fa4@mail.gmail.com> Hi, On Wed, Jun 4, 2008 at 3:02 PM, Joachim Ante wrote: > Hi, > > We are looking for a skilled mono hacker who can implement some AOT > features for ARM processors for us. > > * Currently AOT doesn't generate dynamic libraries. Instead it > generates binary files from which the AOT'ed code is loaded. We need > to change AOT code so that it generates real dylib. This is because > some devices completely disallow loading generated code for security > reasons. > Thus the only way to load mono code is to AOT it and store it in a > real dylib that is loaded using dlsym or simillar functions. > The current AOT code does generate shared libraries, but all the methods are in a giant array named 'methods', we resolve its address using dlsym (), then add offsets to it to get the addresses of the code for the individual methods. Is there a device were this will not work ? Zoltan From robertj at gmx.net Wed Jun 4 10:13:23 2008 From: robertj at gmx.net (Robert Jordan) Date: Wed, 04 Jun 2008 16:13:23 +0200 Subject: [Mono-dev] GC stop world stopping audio threads In-Reply-To: <295e750a0806040604re68b211mf7eb55145f9179c9@mail.gmail.com> References: <295e750a0806040604re68b211mf7eb55145f9179c9@mail.gmail.com> Message-ID: Zoltan Varga wrote: > Hi, > > AFAIK, the GC only stops threads which are registered with it. This > can happen in > the following ways: > - threads started by the runtime are registered automatically > - threads registered using mono_thread_attach (). > - on unix, if an application includes gc.h, the header file will > redefine pthread_create > () etc. with gc specific versions which register threads > - on windows, the gc registers all threads automatically. One more: - threads detected when a managed delegate is called by unmanaged code from a thread that was not already attached. These all together assure that the runtime is never executed on a non-registered thread. It also means that on unix you can have unregistered threads as long as the conditions above are never met. On Windows, only threads started after mono.dll was loaded are registered. This means that it's still possible to create unregistered threads, as long as the other conditions are never met. Robert > > Under what OS you experience this ? BTW, the problem with not > registering threads > with the GC is that threads suspended by the GC could hold locks etc., > so if another > thread tries to use these locks (like the malloc lock), it will be > suspended anyway. > Also, if one of these unsuspended threads tries to register itself or enter the > runtime while the word is suspended, various complex situations could occur. > > Zoltan > > On Wed, Jun 4, 2008 at 2:41 PM, Joachim Ante wrote: >> Hi, >> >> When the GC is under stress because a lot of managed allocations >> happen we get sound stuttering. >> It seems very likely that the GC is doing that when it calls Stop >> World on all other threads. >> Is there any way to make the Garbage collector only stop threads >> which are registered using mono_thread_attach? >> >> Best regards, >> Joachim Ante >> >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> From joe at unity3d.com Wed Jun 4 11:56:03 2008 From: joe at unity3d.com (Joachim Ante) Date: Thu, 5 Jun 2008 00:56:03 +0900 Subject: [Mono-dev] Paid mono hacking: Make AOT generate all code ahead of time In-Reply-To: <295e750a0806040611r6352b6e2kb45fec58b38e4fa4@mail.gmail.com> References: <6343822E-B914-436A-A7CC-C4395390EE9B@unity3d.com> <295e750a0806040611r6352b6e2kb45fec58b38e4fa4@mail.gmail.com> Message-ID: >> We are looking for a skilled mono hacker who can implement some AOT >> features for ARM processors for us. >> >> * Currently AOT doesn't generate dynamic libraries. Instead it >> generates binary files from which the AOT'ed code is loaded. We need >> to change AOT code so that it generates real dylib. This is because >> some devices completely disallow loading generated code for security >> reasons. >> Thus the only way to load mono code is to AOT it and store it in a >> real dylib that is loaded using dlsym or simillar functions. >> > > The current AOT code does generate shared libraries, but all the > methods are in > a giant array named 'methods', we resolve its address using dlsym > (), then > add offsets to it to get the addresses of the code for the individual > methods. Is > there a device were this will not work ? That sounds good. Thanks for the heads up. It seems like we misunderstood something in the AOT then. Best regards, Joachim Ante From slashboot at gmail.com Wed Jun 4 14:04:40 2008 From: slashboot at gmail.com (slashboot) Date: Wed, 4 Jun 2008 11:04:40 -0700 (PDT) Subject: [Mono-dev] Process.ExitCode may return an uninitlialized value Message-ID: <17635993.post@talk.nabble.com> Hello, Recently, I run into an issue where Process.ExitCode was returning numbers out of the 0-255 range which turned out to be random numbers. I was trying to figure out how this can happen and found that in ExitCode_internal (see below, this is the latest revision), no checks were made on the return value of the GetExitCodeProcess (process, &code) call which might lead to returning uninitialized exit code if GetExitCodeProcess returns FALSE. That doesn't look right to me.. For some reason that I still can't explain, GetExitCodeProcess was returning FALSE and I saw this message : "GetExitCodeProcess: Can't find process 0x1" on every process that I created (the process didn't seem to execute correctly). Is anyone aware of such kind of problem ? (I'm using an old 1.1.17-2 version). I cannot reproduce this consistently, but each time it happens, no more processes could be created going forward and I need to restart the app. -- Mahdi. //trunk/mono/mono/metadata/process.c gint32 ves_icall_System_Diagnostics_Process_ExitCode_internal (HANDLE process) { DWORD code; MONO_ARCH_SAVE_REGS; GetExitCodeProcess (process, &code); #ifdef DEBUG g_message (G_GNUC_PRETTY_FUNCTION ": process exit code is %d", code); #endif return(code); } -- View this message in context: http://www.nabble.com/Process.ExitCode-may-return-an-uninitlialized-value-tp17635993p17635993.html Sent from the Mono - Dev mailing list archive at Nabble.com. From sontek at gmail.com Wed Jun 4 15:24:40 2008 From: sontek at gmail.com (John M. Anderson) Date: Wed, 04 Jun 2008 13:24:40 -0600 Subject: [Mono-dev] SVN Debugger issues Message-ID: <1212607480.1165.6.camel@linux.site> Hey, I'm trying to get the SVN of the mono debugger working properly but at run time it crashes because of version issues, which I assume is because of the way I have my environment setup... Was wondering if anyone had any ideas how to fix it. I have svn mono and the debugger in: in /home/sontek/bin/mono I use this script to setup my environment: #!/bin/bash MONO_PREFIX=/home/sontek/bin/mono export LD_LIBRARY_PATH=$MONO_PREFIX/lib:$LD_LIBRARY_PATH export C_INCLUDE_PATH=$MONO_PREFIX/include export ACLOCAL_PATH=$MONO_PREFIX/share/aclocal export PKG_CONFIG_PATH=$MONO_PREFIX/lib/pkgconfig export MONO_GAC_PREFIX=/usr PATH=$MONO_PREFIX/bin:$PATH PS1="[mono] \w @ " and these are the errors I get when I run mdb. [mono] ~/code/oss/mono/debugger/backend @ mdb ** (/home/sontek/bin/mono//lib/mono/2.0/mdb.exe:24384): WARNING **: Symbol file /usr/lib/mono/gac/Mono.GetOptions/2.0.0.0__0738eb9f132ed756/Mono.GetOptions.dll.mdb has incorrect version (expected 41, got 39) ** (/home/sontek/bin/mono//lib/mono/2.0/mdb.exe:24384): WARNING **: Symbol file /usr/lib/mono/gac/Mono.Debugger/1.0.0.0__0738eb9f132ed756/Mono.Debugger.dll.mdb has incorrect version (expected 41, got 39) ** (/home/sontek/bin/mono//lib/mono/2.0/mdb.exe:24384): WARNING **: Symbol file /usr/lib/mono/gac/Mono.Debugger.Backend/1.0.0.0__0738eb9f132ed756/Mono.Debugger.Backend.dll.mdb has incorrect version (expected 41, got 39) ** (/home/sontek/bin/mono//lib/mono/2.0/mdb.exe:24384): WARNING **: Missing method Mono.Debugger.DebuggerOptions::get_StartXSP() in assembly /usr/lib/mono/gac/Mono.Debugger.Backend/1.0.0.0__0738eb9f132ed756/Mono.Debugger.Backend.dll, referenced in assembly /home/sontek/bin/mono/lib/mono/2.0/mdb.exe Unhandled Exception: System.MissingMethodException: Method not found: 'Mono.Debugger.DebuggerOptions.get_StartXSP'. I thought with my environment script it would be pulling all its libraries from /home/sontek/bin/mono but it doesn't seem to be. What am I doing wrong? From billholmes54 at gmail.com Wed Jun 4 16:23:38 2008 From: billholmes54 at gmail.com (Bill Holmes) Date: Wed, 4 Jun 2008 16:23:38 -0400 Subject: [Mono-dev] [PATCH] MSVC implementation of my_g_bit_nth_msf Message-ID: <37c5788d0806041323o6362a6c6p48737dfe2f50c1a3@mail.gmail.com> The attached patch fixes the compilation errors in MSVC with the eglib targets. -bill -------------- next part -------------- A non-text attachment was scrubbed... Name: my_g_bit_nth_msf.diff Type: application/octet-stream Size: 1271 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080604/540e4ded/attachment.obj From billholmes54 at gmail.com Wed Jun 4 18:25:22 2008 From: billholmes54 at gmail.com (Bill Holmes) Date: Wed, 4 Jun 2008 18:25:22 -0400 Subject: [Mono-dev] [PATCH] Marshaling structs on Winx64 Message-ID: <37c5788d0806041525l78b86689ib0d2f64f95df13bd@mail.gmail.com> The attached code is some of the fixes needed for marshaling structs on Winx64. In mini-amd64 two things have been fixed. 1) Structs containing floats are passed in the integer registers, not the float registers. 2) Only structs that are 1,2,4,or 8 bytes will be copied into a register. All others are pushed at the beginning of the stack (depending on your point of reference) and the address of that stack location is stored in the argument register. I still am struggling to figure out how to fix the case where the struct will not fit into the register because of the criteria listed above. What needs to happen is that the struct is copied onto the stack and the address of that location is stored in an argument register. Any suggestion of how to do this or something that I should be reading would be appreciated. I have also attached a new set of unit tests that represents the code I am using to debug some of these issues. I have disabled the Test_In_Args_Value_On_Stack_ADDR_In_RCX portion of the test because of the problem mentioned above. More tests are needed for return values as well as calling managed code from native. I will be adding theses soon. I have encountered another problem that I have decided to ignore for the time being. Originally the C# portion of my tests contained char types instead of byte types. This worked fine when run under .net. However mono assumes 2 bytes for the char. Is this just another Winx64 bug that needs addressed? As always suggestions are not only welcome but encouraged. I am defiantly a fish out of water in this code. OK to commit? thanks -bill -------------- next part -------------- A non-text attachment was scrubbed... Name: winx64_struct_08_06_04.diff Type: application/octet-stream Size: 1730 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080604/dc803ee9/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: winx64_struct_tests_08_06_04.diff Type: application/octet-stream Size: 13112 bytes Desc: not available Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080604/dc803ee9/attachment-0003.obj From slashboot at gmail.com Thu Jun 5 01:43:01 2008 From: slashboot at gmail.com (slashboot) Date: Wed, 4 Jun 2008 22:43:01 -0700 (PDT) Subject: [Mono-dev] Process.ExitCode may return an uninitlialized value In-Reply-To: <17635993.post@talk.nabble.com> References: <17635993.post@talk.nabble.com> Message-ID: <17662570.post@talk.nabble.com> I actually resolved the "GetExitCodeProcess: Can't find process 0x1" part which was due to the fact that if fork() fails when it creates a process no exception is thrown and the caller doesn't know about it. Other calls to Process.Start() will also fail. Fork() was failing for me because my process was allocating alot of memory while the fork was happening and mono code wasn't calling execv right after the fork() leading to a big chunk of memory being re-allocated for the child process (copy on write). This is against 1.1.17-2. -- Mahdi. slashboot wrote: > > Hello, > > Recently, I run into an issue where Process.ExitCode was returning numbers > out of the 0-255 range which turned out to be random numbers. I was trying > to figure out how this can happen and found that in ExitCode_internal (see > below, this is the latest revision), no checks were made on the return > value of the GetExitCodeProcess (process, &code) call which might lead to > returning uninitialized exit code if GetExitCodeProcess returns FALSE. > That doesn't look right to me.. > > For some reason that I still can't explain, GetExitCodeProcess was > returning FALSE and I saw this message : "GetExitCodeProcess: Can't find > process 0x1" on every process that I created (the process didn't seem to > execute correctly). Is anyone aware of such kind of problem ? (I'm using > an old 1.1.17-2 version). I cannot reproduce this consistently, but each > time it happens, no more processes could be created going forward and I > need to restart the app. > > -- > Mahdi. > > //trunk/mono/mono/metadata/process.c > gint32 ves_icall_System_Diagnostics_Process_ExitCode_internal (HANDLE > process) > { > DWORD code; > MONO_ARCH_SAVE_REGS; > GetExitCodeProcess (process, &code); > #ifdef DEBUG > g_message (G_GNUC_PRETTY_FUNCTION ": process exit code is %d", code); > #endif > return(code); > } > -- View this message in context: http://www.nabble.com/Process.ExitCode-may-return-an-uninitlialized-value-tp17635993p17662570.html Sent from the Mono - Dev mailing list archive at Nabble.com. From kornelpal at gmail.com Thu Jun 5 04:33:03 2008 From: kornelpal at gmail.com (=?UTF-8?Q?Korn=C3=A9l_P=C3=A1l?=) Date: Thu, 5 Jun 2008 10:33:03 +0200 Subject: [Mono-dev] How to create trampolines for mono_marshal_get_vtfixup_ftnptr? Message-ID: <9440ace50806050133sd008a5cyf54a10aa66546d37@mail.gmail.com> Hi, Current implementation of mono_image_fixup_vtable calls mono_marshal_get_vtfixup_ftnptr that JITs a wrapper. The problem however is that the wrapper has to know the types uses used as arguments and return value that means that the assembly has to be loaded before mono_marshal_get_vtfixup_ftnptr is called. mono_image_fixup_vtable should be called when loading the image and the assembly should not be loaded by LoadLibray to any AppDomain. I would like to only create a trampline in mono_image_fixup_vtable that will load the assembly and will create a wrapper using mono_marshal_get_vtfixup_ftnptr. This should also enable implementing proper AppDomain handling for VTFIXUP_TYPE_FROM_UNMANAGED and VTFIXUP_TYPE_FROM_UNMANAGED_RETAIN_APPDOMAIN. I have no problem in creating a trampoline function for calling mono_marshal_get_vtfixup_ftnptr but I don't know how to replace the trampline with the actual wrapper with respect to concurency handling. Could you please point me to some existing code in the runtime already doing similar things? Thanks. Korn?l From eric.moret at gmail.com Mon Jun 2 14:08:33 2008 From: eric.moret at gmail.com (Eric Moret) Date: Mon, 2 Jun 2008 11:08:33 -0700 Subject: [Mono-dev] mono-service process name Message-ID: Hello, First time posting on this list. Attaching patch file so it does not get wrapped by my mailer. This is a patch against mono svn trunk 104692. This adds option -a: to mono-service so the process name can be changed. Changing the process name to something different than "mono" allows for a clearner output in ps and top and permits manupilating the processes with killall. Best, __ Eric begin 666 mono-service-procname.patch M9&EF9B M#L at 9&\-"B )8V%S M92 D,2!I;@T**PD)+6$Z*BD@<')O8VYA;64]8&5C:&\@)#$@?"!S960@)W,O M.B\@+R=@(#L[#0H@"0DM6VQD;FU=.BHI(&%R9W,](B1A7-L M;V&5C($!B:6YD:7) M+T!M;VYO7VEN=&5R<$ @)$U/3D]?3U!424].4R! ;6]N;U]I;G-T9&ER0"] M9G)A;65W;W)K7W9E&4@)&%R9W,-"BL@ M("!E>&5C("1P First I want to express how impressed I am with how well mono performs (both speed and stability). I'm trying to get native bindings working for gdal 1.5.1 (or any version of gdal) in Linux. If anyone has knowledge of gdal/mono/linux bindings that would be great. If not, then I suppose a general discussion of native bindings is the next step. I'm outside my comfort zone, and struggling to even phrase the question. But here are my observations. When I compile gdal in linux it creates libraries and executables such as: gdalconst_csharp.dll gdal_csharp.dll ogr_csharp.dll osr_csharp.dll GDALInfo.exe So when I run the command 'mono GDALInfo.exe' it returns a usage statement. no errors. But when I run 'mono GDALinfo.exe foo.tif', I get a type-loader exception. =================== ANALYSIS =================== Each library has a dllmap config mapping. For anyone who is interested in getting gdal to work in mono/linux I believe that the dllmap generated by the GNUMakefile has an error. The build process generates the following... But this is missing the closing "/" for the Xml tag, so it should look like this. ============================ ?WHAT's MISSING? ============================ The build also creates gdal_wrap.lo, ogr_wrap.lo, etc. But it doesn't produce a .so file for these, it doesn't produce a gdal_wrap.dll or a dllmap. I'm pretty sure this is a problem, because those are the libraries which contain the native bindings. At least, they do in Windows. I tried creating gdal_wrap.so gcc -shared -Wl,-soname,libgdal_wrap.so.1 -o libgdal_wrap.so.1.0.1 gdal_wrap.o It didn't help. I ran the command with 'mono -verbose'. See attached file. http://www.nabble.com/file/p17622978/output3.txt output3.txt I ran the command 'mono-shlib-cop gdal_csharp.dll'. It produced the following. error: in OSGeo.GDAL.GdalPINVOKE.UseExceptions: Could not load library `gdal_wrap': ./libgdal_wrap.so: cannot open shared object file: No such file or directory error: in OSGeo.GDAL.GdalPINVOKE.DontUseExceptions: Could not load library `gdal_wrap': ./libgdal_wrap.so: cannot open shared object file: No such file or directory error: in OSGeo.GDAL.GdalPINVOKE.Debug: Could not load library `gdal_wrap': ./libgdal_wrap.so: cannot ============================ CONCLUSIONS ============================ >From what I've read if the library is named properly (libgdal_wrap.so in linux, gdal_wrap.dll in windows), and if the file exists in the path (PATH in Windows, LD_LIBRARY_PATH in Linux) the native bindings should work. If anyone has advice on gdal, on native-bindings, or on tracking down type-loader-exceptions help is appreciated. Thanks... -- View this message in context: http://www.nabble.com/gdal-mono-linux--Native-bindings%2C-PInvoke%2C-and-tracking-TypeLoader-exceptions-tp17622978p17622978.html Sent from the Mono - Dev mailing list archive at Nabble.com. From andrew at castlesoft.com.au Wed Jun 4 09:16:30 2008 From: andrew at castlesoft.com.au (CastleSoft) Date: Wed, 4 Jun 2008 06:16:30 -0700 (PDT) Subject: [Mono-dev] Mono JIT compiler version 104788 (tarball) throwing error with Mojo Portal 2.2.5.8.. Message-ID: <17646531.post@talk.nabble.com> I've install the last 2 nightly snapshots (currently using 104788) for OpenSuSe 10.3. Basic asp.net 2.0 stuff via xsp2 and lighttpd working. Got mysql/latest build etc all configured/changes to Web.config, dll's etc. (Thanks Joe). /Setup/Default.aspx runs perfectly. No errors. (OK) I disable Setup.. And try the site.. Then I get this. (after enabling real messages)... (running Lighttpd+FastCGI) ==================================================================== Server Error in '/' Application Object reference not set to an instance of an object Description: HTTP 500. Error processing request. Stack Trace: System.NullReferenceException: Object reference not set to an instance of an object at System.Web.Handlers.ScriptResourceHandler.EncryptString (System.String s) [0x00000] at System.Web.Handlers.ScriptResourceHandler+RuntimeScriptResourceHandler.System.Web.Handlers.IScriptResourceHandler.GetScriptResourceUrl (System.Reflection.Assembly assembly, System.String resourceName, System.Globalization.CultureInfo culture, Boolean zip, Boolean notifyScriptLoaded) [0x00000] at System.Web.Handlers.ScriptResourceHandler.GetScriptResourceUrl (System.Reflection.Assembly assembly, System.String resourceName, System.Globalization.CultureInfo culture, Boolean zip, Boolean notifyScriptLoaded) [0x00000] at System.Web.UI.ScriptReference.GetUrlFromName (System.Web.UI.ScriptManager scriptManager, IControl scriptManagerControl, Boolean zip) [0x00000] at System.Web.UI.ScriptReference.GetUrl (System.Web.UI.ScriptManager scriptManager, IControl scriptManagerControl, Boolean zip) [0x00000] at System.Web.UI.ScriptManager.RegisterScripts () [0x00000] at System.Web.UI.ScriptManager.OnPagePreRenderComplete (System.Object sender, System.EventArgs e) [0x00000] at System.Web.UI.Page.OnPreRenderComplete (System.EventArgs e) [0x00000] at System.Web.UI.Page.ProcessLoadComplete () [0x00000] at System.Web.UI.Page.InternalProcessRequest () [0x00000] at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x00000] Version information: Mono Version: 2.0.50727.42; ASP.NET Version: 2.0.50727.42 ======================================================================= (Same error if I switch to XSP2 also..) Joe reports it works on an older release.. Regression ?? -- View this message in context: http://www.nabble.com/Mono-JIT-compiler-version-104788-%28tarball%29-throwing-error-with-Mojo-Portal-2.2.5.8..-tp17646531p17646531.html Sent from the Mono - Dev mailing list archive at Nabble.com. From mono at vokabeln.de Wed Jun 4 10:58:48 2008 From: mono at vokabeln.de (iguana) Date: Wed, 4 Jun 2008 07:58:48 -0700 (PDT) Subject: [Mono-dev] "Invalid format" message using DataSet.ReadXML with a xs:dateTime column Message-ID: <17648818.post@talk.nabble.com> Hello, I created a DataSet table with a DateTime column and saved it into a file using DataSet.WriteXML. Using the same code, the files created by .NET and MONO differ because, apparently, MONO saves DateTime values in a different way: .NET: 2008-06-06T07:07:00.009+02:00 MONO: 2008-06-06T07:07:00.0088888 MONO saves the milliseconds more accurately but seems to be unaware of time zones. What's worse, however, is that when I create a file with .NET and then try to read it with MONO I get an "Invalid format" error message: MONO does not seem to be able to deal with the time zone information "+02:00" saved by .NET. This is the VB code I use (having created a simple form with two buttons "cmdWriteXML" and "cmdReadXML"): Imports System.Data Public Class Form1 Private TestFile As String = "C:\Test.xml" Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim MyDate As DateTime = CDate("06.06.2008 07:07").AddMilliseconds(8.8888) Dim TestTable As DataTable = New DataTable("TestTable") TestTable.Columns.Add("TestColumn", Type.GetType("System.DateTime")) Dim TestRow As DataRow = TestTable.NewRow TestRow("TestColumn") = MyDate TestTable.Rows.Add(TestRow) Dim TestDataSet As DataSet = New DataSet("TestDataSet") TestDataSet.Tables.Add(TestTable) TestDataSet.WriteXml(TestFile, XmlWriteMode.WriteSchema) End Sub Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click Try Dim TestDataSet As DataSet = New DataSet() TestDataSet.ReadXml(TestFile, XmlReadMode.ReadSchema) MsgBox("Success") Catch ex As Exception MsgBox(ex.Message) End Try End Sub End Class Clicking both Button1 and Button2 in .NET produces "Success". Clicking both Button1 and Button2 in MONO produces "Success". Clicking Button1 in MONO and Button2 in .NET produces "Success." Clicking Button1 in .NET and Button2 in MONO produces "Invalid format." The file created by this code looks like this: ***DIFFERENT VALUES SEE ABOVE*** Is this a bug in MONO? Can it be fixed? Regards iguana -- View this message in context: http://www.nabble.com/%22Invalid-format%22-message-using-DataSet.ReadXML-with-a-xs%3AdateTime-column-tp17648818p17648818.html Sent from the Mono - Dev mailing list archive at Nabble.com. From joe at unity3d.com Thu Jun 5 07:27:50 2008 From: joe at unity3d.com (Joachim Ante) Date: Thu, 5 Jun 2008 20:27:50 +0900 Subject: [Mono-dev] Paid mono hacking: Make AOT generate all code ahead of time In-Reply-To: References: <6343822E-B914-436A-A7CC-C4395390EE9B@unity3d.com> <295e750a0806040611r6352b6e2kb45fec58b38e4fa4@mail.gmail.com> Message-ID: <7A9B0883-1EBD-44C6-B318-81C6E7ECB886@unity3d.com> >> The current AOT code does generate shared libraries, but all the >> methods are in >> a giant array named 'methods', we resolve its address using dlsym >> (), then >> add offsets to it to get the addresses of the code for the individual >> methods. Is >> there a device were this will not work ? > That sounds good. Thanks for the heads up. > It seems like we misunderstood something in the AOT then. That makes things quite a bit easier. Here is some information from Paolo on how complete AOTing of all functions can be implemented: Anyone who is interested in a contract job for implementing this, drop me a mail. ---- I'll list the steps that are needed to implement this. 1) you need a complete test suite of all the code that you'll need to run, since there are many codepaths involved 2) add asserts in the mono_code_mananger() so you're sure they are not called 3) aot corlib and all the other needed assemblies 4) run the test suite programs and fix the issues as they come up To do 4 the general rule is: each reference to a runtime value needs to be replaced in the generated code to a reference to an array element. When you'll load the code, before executing it you will set the array element to the expected runtime value. To do this you will need to save in the aot file also a description of what goes inside each array element. Let's consider mono_arch_create_trampoline_code() in tramp-arm.c: you'll need to change the function so that the code is emitted into the aot file (or at least have it return the generated size, since in this particular case it is position independent). After that you'll note that currently the runtime addresses of mono_get_lmf_addr and of mono_get_trampoline_func (tramp_type) are embedded in the code: you will need to allocate slots in the mentioned array and change the generated code to load the values from the array instead of from the constant pool in the generated code. A note about the array: this should be quick to access and the access itself may not use runtime values. I don't know if OSX on ARM provides fast access to tls data (and even if it does if it gives any guarantee about future compatibility). Anyway, that would be the best choice. An alternative is to reserve a global register for it (you will need to remove that register from the list of registers available to the register allocator and you will need to set the register at each entrance to managed code). The array can be fixed-size (but then you are limited or you'll use much more memory) or it can be extensible (make sure the deallocation is thread safe or use a design similar to the one I implemented for managed ThreadStatic slots). There are many places in the jit and runtime code where runtime values are embedded as constants in the generated code: most are in mini- $arch.c and in metadata/marshal.c. After all the trampolines and similar snippets of code are converted to run under AOT there are still other methods that are currently created and jitted at runtime. Using the test suite I mentioned above you will need to get a list of them and pregenerate them in the AOT files as well. This includes the methods used to perform the unmanaged->managed transitions (those used to invoke Main() or to invoke the Finalizer method in the finalizer thread and so on). You will likely also need to change the values that are used to implement interface method calls: currently it is a MonoMethod*. You'd need to assign and keep track of the IDs there. From nagappan at gmail.com Thu Jun 5 08:57:35 2008 From: nagappan at gmail.com (Nagappan A) Date: Thu, 5 Jun 2008 05:57:35 -0700 Subject: [Mono-dev] "Invalid format" message using DataSet.ReadXML with a xs:dateTime column In-Reply-To: <17648818.post@talk.nabble.com> References: <17648818.post@talk.nabble.com> Message-ID: <9d0602eb0806050557k42cbdeabia0de09716b55ff58@mail.gmail.com> Hello, It looks like the bug is in Mono. Could you please file a bug with a C# test case to reproduce this issue ? Thanks Nagappan On Wed, Jun 4, 2008 at 7:58 AM, iguana wrote: > > Hello, > > I created a DataSet table with a DateTime column and saved it into a file > using DataSet.WriteXML. Using the same code, the files created by .NET and > MONO differ because, apparently, MONO saves DateTime values in a different > way: > > .NET: > 2008-06-06T07:07:00.009+02:00 > MONO: > 2008-06-06T07:07:00.0088888 > > MONO saves the milliseconds more accurately but seems to be unaware of time > zones. What's worse, however, is that when I create a file with .NET and > then try to read it with MONO I get an "Invalid format" error message: MONO > does not seem to be able to deal with the time zone information "+02:00" > saved by .NET. > > This is the VB code I use (having created a simple form with two buttons > "cmdWriteXML" and "cmdReadXML"): > > > Imports System.Data > Public Class Form1 > Private TestFile As String = "C:\Test.xml" > > Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As > System.EventArgs) Handles Button1.Click > Dim MyDate As DateTime = CDate("06.06.2008 > 07:07").AddMilliseconds(8.8888) > Dim TestTable As DataTable = New DataTable("TestTable") > TestTable.Columns.Add("TestColumn", Type.GetType("System.DateTime")) > Dim TestRow As DataRow = TestTable.NewRow > TestRow("TestColumn") = MyDate > TestTable.Rows.Add(TestRow) > Dim TestDataSet As DataSet = New DataSet("TestDataSet") > TestDataSet.Tables.Add(TestTable) > TestDataSet.WriteXml(TestFile, XmlWriteMode.WriteSchema) > End Sub > > Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As > System.EventArgs) Handles Button2.Click > Try > Dim TestDataSet As DataSet = New DataSet() > TestDataSet.ReadXml(TestFile, XmlReadMode.ReadSchema) > MsgBox("Success") > Catch ex As Exception > MsgBox(ex.Message) > End Try > End Sub > End Class > > Clicking both Button1 and Button2 in .NET produces "Success". > Clicking both Button1 and Button2 in MONO produces "Success". > Clicking Button1 in MONO and Button2 in .NET produces "Success." > Clicking Button1 in .NET and Button2 in MONO produces "Invalid format." > > > The file created by this code looks like this: > > > > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"> > msdata:UseCurrentLocale="true"> > > > > > > minOccurs="0" /> > > > > > > > > > ***DIFFERENT VALUES SEE ABOVE*** > > > > > Is this a bug in MONO? Can it be fixed? > > Regards > iguana > -- > View this message in context: > http://www.nabble.com/%22Invalid-format%22-message-using-DataSet.ReadXML-with-a-xs%3AdateTime-column-tp17648818p17648818.html > Sent from the Mono - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Linux Desktop (GUI Application) Testing Project - http://ldtp.freedesktop.org http://nagappanal.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080605/909ba8c6/attachment.html From kumpera at gmail.com Thu Jun 5 10:56:28 2008 From: kumpera at gmail.com (Rodrigo Kumpera) Date: Thu, 5 Jun 2008 11:56:28 -0300 Subject: [Mono-dev] Mono JIT compiler version 104788 (tarball) throwing error with Mojo Portal 2.2.5.8.. In-Reply-To: <17646531.post@talk.nabble.com> References: <17646531.post@talk.nabble.com> Message-ID: <8cca42d80806050756t4b6b2df3td95239a776dde6f9@mail.gmail.com> Please fill a bug report and we will take a look. On Wed, Jun 4, 2008 at 10:16 AM, CastleSoft wrote: > > I've install the last 2 nightly snapshots (currently using 104788) for > OpenSuSe 10.3. > > Basic asp.net 2.0 stuff via xsp2 and lighttpd working. > > Got mysql/latest build etc all configured/changes to Web.config, dll's etc. > (Thanks Joe). > > /Setup/Default.aspx runs perfectly. No errors. (OK) > > I disable Setup.. And try the site.. > > Then I get this. (after enabling real messages)... (running > Lighttpd+FastCGI) > > ==================================================================== > > Server Error in '/' Application > Object reference not set to an instance of an object > > > > Description: HTTP 500. Error processing request. > > Stack Trace: > > System.NullReferenceException: Object reference not set to an instance of > an > object > at System.Web.Handlers.ScriptResourceHandler.EncryptString (System.String > s) > [0x00000] > at > > System.Web.Handlers.ScriptResourceHandler+RuntimeScriptResourceHandler.System.Web.Handlers.IScriptResourceHandler.GetScriptResourceUrl > (System.Reflection.Assembly assembly, System.String resourceName, > System.Globalization.CultureInfo culture, Boolean zip, Boolean > notifyScriptLoaded) [0x00000] > at System.Web.Handlers.ScriptResourceHandler.GetScriptResourceUrl > (System.Reflection.Assembly assembly, System.String resourceName, > System.Globalization.CultureInfo culture, Boolean zip, Boolean > notifyScriptLoaded) [0x00000] > at System.Web.UI.ScriptReference.GetUrlFromName > (System.Web.UI.ScriptManager > scriptManager, IControl scriptManagerControl, Boolean zip) [0x00000] > at System.Web.UI.ScriptReference.GetUrl (System.Web.UI.ScriptManager > scriptManager, IControl scriptManagerControl, Boolean zip) [0x00000] > at System.Web.UI.ScriptManager.RegisterScripts () [0x00000] > at System.Web.UI.ScriptManager.OnPagePreRenderComplete (System.Object > sender, System.EventArgs e) [0x00000] > at System.Web.UI.Page.OnPreRenderComplete (System.EventArgs e) [0x00000] > at System.Web.UI.Page.ProcessLoadComplete () [0x00000] > at System.Web.UI.Page.InternalProcessRequest () [0x00000] > at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) > [0x00000] > > Version information: Mono Version: 2.0.50727.42; ASP.NET Version: > 2.0.50727.42 > > ======================================================================= > > (Same error if I switch to XSP2 also..) > > Joe reports it works on an older release.. > > Regression ?? > > > -- > View this message in context: > http://www.nabble.com/Mono-JIT-compiler-version-104788-%28tarball%29-throwing-error-with-Mojo-Portal-2.2.5.8..-tp17646531p17646531.html > Sent from the Mono - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080605/f38941de/attachment.html From jonpryor at vt.edu Thu Jun 5 11:00:38 2008 From: jonpryor at vt.edu (Jonathan Pryor) Date: Thu, 05 Jun 2008 15:00:38 +0000 Subject: [Mono-dev] mono-service process name In-Reply-To: References: Message-ID: <1212678038.5169.83.camel@lina.magi.balthasar.com> On Mon, 2008-06-02 at 11:08 -0700, Eric Moret wrote: > This is a patch against mono svn trunk 104692. This adds option > -a: to mono-service so the process name can be changed. Silly question, but why "-a"? I'm trying to think of what mnemonic this is supposed to mimic... Furthermore, wouldn't it make sense to "reuse" the -n value as the process name instead of adding a new -a flag? Thanks, - Jon From pablosantosluac at terra.es Thu Jun 5 11:33:01 2008 From: pablosantosluac at terra.es (pablosantosluac at terra.es) Date: Thu, 05 Jun 2008 17:33:01 +0200 Subject: [Mono-dev] mono-service process name In-Reply-To: <1212678038.5169.83.camel@lina.magi.balthasar.com> References: <1212678038.5169.83.camel@lina.magi.balthasar.com> Message-ID: <4848072D.1000108@terra.es> Does it only work on Linux? Jonathan Pryor escribi?: > On Mon, 2008-06-02 at 11:08 -0700, Eric Moret wrote: > >> This is a patch against mono svn trunk 104692. This adds option >> -a: to mono-service so the process name can be changed. >> > > Silly question, but why "-a"? I'm trying to think of what mnemonic this > is supposed to mimic... > > Furthermore, wouldn't it make sense to "reuse" the -n value as the > process name instead of adding a new -a flag? > > Thanks, > - Jon > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From martin at ximian.com Thu Jun 5 11:23:04 2008 From: martin at ximian.com (Martin Baulig) Date: Thu, 05 Jun 2008 17:23:04 +0200 Subject: [Mono-dev] SVN Debugger issues In-Reply-To: <1212607480.1165.6.camel@linux.site> References: <1212607480.1165.6.camel@linux.site> Message-ID: <1212679384.4702.25.camel@gondor.trier.ximian.com> Ok, finally have a fix for this on my local hard disk. Unfortunately, I'm currently out of internet connection, so I'll commit later today or tomorrow morning. Martin On Wed, 2008-06-04 at 13:24 -0600, John M. Anderson wrote: > Hey, I'm trying to get the SVN of the mono debugger working properly but > at run time it crashes because of version issues, which I assume is > because of the way I have my environment setup... Was wondering if > anyone had any ideas how to fix it. > > I have svn mono and the debugger in: in /home/sontek/bin/mono > > I use this script to setup my environment: > > > #!/bin/bash > MONO_PREFIX=/home/sontek/bin/mono > export LD_LIBRARY_PATH=$MONO_PREFIX/lib:$LD_LIBRARY_PATH > export C_INCLUDE_PATH=$MONO_PREFIX/include > export ACLOCAL_PATH=$MONO_PREFIX/share/aclocal > export PKG_CONFIG_PATH=$MONO_PREFIX/lib/pkgconfig > export MONO_GAC_PREFIX=/usr > PATH=$MONO_PREFIX/bin:$PATH > PS1="[mono] \w @ " > > and these are the errors I get when I run mdb. > > [mono] ~/code/oss/mono/debugger/backend @ mdb > > ** (/home/sontek/bin/mono//lib/mono/2.0/mdb.exe:24384): WARNING **: > Symbol > file /usr/lib/mono/gac/Mono.GetOptions/2.0.0.0__0738eb9f132ed756/Mono.GetOptions.dll.mdb has incorrect version (expected 41, got 39) > > ** (/home/sontek/bin/mono//lib/mono/2.0/mdb.exe:24384): WARNING **: > Symbol > file /usr/lib/mono/gac/Mono.Debugger/1.0.0.0__0738eb9f132ed756/Mono.Debugger.dll.mdb has incorrect version (expected 41, got 39) > > ** (/home/sontek/bin/mono//lib/mono/2.0/mdb.exe:24384): WARNING **: > Symbol > file /usr/lib/mono/gac/Mono.Debugger.Backend/1.0.0.0__0738eb9f132ed756/Mono.Debugger.Backend.dll.mdb has incorrect version (expected 41, got 39) > > ** (/home/sontek/bin/mono//lib/mono/2.0/mdb.exe:24384): WARNING **: > Missing method Mono.Debugger.DebuggerOptions::get_StartXSP() in > assembly /usr/lib/mono/gac/Mono.Debugger.Backend/1.0.0.0__0738eb9f132ed756/Mono.Debugger.Backend.dll, referenced in assembly /home/sontek/bin/mono/lib/mono/2.0/mdb.exe > > Unhandled Exception: System.MissingMethodException: Method not found: > 'Mono.Debugger.DebuggerOptions.get_StartXSP'. > > > > I thought with my environment script it would be pulling all its > libraries from /home/sontek/bin/mono but it doesn't seem to be. > > What am I doing wrong? > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Martin Baulig - martin at novell.com Novell GmbH, D?sseldorf GF: Volker Smid, Djamel Souici; HRB 21108 (AG D?sseldorf) From andreas.faerber at web.de Thu Jun 5 12:51:27 2008 From: andreas.faerber at web.de (=?ISO-8859-1?Q?Andreas_F=E4rber?=) Date: Thu, 5 Jun 2008 18:51:27 +0200 Subject: [Mono-dev] [PATCH] Mono DTrace provider v3 In-Reply-To: <295e750a0806031412n6194a82bu9ab7b0153dc7b7c9@mail.gmail.com> References: <295e750a0805280632g35fa2001t731608df02bf2423@mail.gmail.com> <5C7FDD33-96B5-4C08-A836-2870931AB0A1@web.de> <046E175E-9FFF-4070-AF30-11264FCC9281@unity3d.com> <0610BF94-DE71-4CB9-80A0-EB5372694781@web.de> <295e750a0806030932t46a05608k671e9e59fee8f08c@mail.gmail.com> <5744EE8D-68AA-4DD6-ACD0-92A2002931F7@web.de> <295e750a0806031412n6194a82bu9ab7b0153dc7b7c9@mail.gmail.com> Message-ID: <8E340389-402A-4452-9663-A085E9C1A871@web.de> Thanks, done: r104964. Andreas Am 03.06.2008 um 23:12 schrieb Zoltan Varga: > Hi, > > I think this is ok to check in. If it works out, we can enable it by > default later. > > Zoltan > > On Tue, Jun 3, 2008 at 10:49 PM, Andreas F?rber > wrote: >> Hi Zoltan, >> >> Thanks again for your feedback. >> >> v2 has been tested to work on Solaris 10 5/08 i86, too, in the >> meantime. It >> requires the same workaround for the gc-end probe as OpenSolaris. >> >> >> Am 03.06.2008 um 18:32 schrieb Zoltan Varga: >> >>> Wouldn't be easier to pass the DTRACE and DTRACEFLAGS arguments to >>> the >>> prelink.sh script in Makefile.am as well, instead of creating it >>> from >>> an .in file ? >> >> Done. This eliminates calling config.status after changes to the >> script. >> >> >>> Other than that, I think this is ok to check in. >> >> Has the issue of --enable-dtrace vs. --disable-dtrace been decided? >> There >> appeared to be a disagreement between Miguel and you, and there >> were no >> further comments. >> >> One of Sun's DTrace developers writes that DTrace probes would work >> on >> earlier versions of Solaris as no-ops. >> http://blogs.sun.com/ahl/entry/user_land_tracing_gets_better#comment-1148081088000 >> I don't have access to pre-10 Solaris systems to confirm this. >> I verified it on OSX, by compiling a DTrace-enabled Hello World >> with gcc-3.3 >> and running it on both v10.5 and v10.3.9. So it would seem possible >> to >> enable DTrace support for the official Mono.framework 2.0, in case >> this was >> Miguel's thought. >> >> >>> I still don't like >>> the makefile changes, >>> but at least they are inside an ifdef, so they won't break anything. >> >> We have two options here. Either we commit the changes, allowing to >> improve >> them later. Or we commit only the Mac OS X part for now. As you like. >> >> >> I've added new probes for the JIT, method-compile-begin and >> method-compile-end. The MONO_PROBE_METHOD_COMPILE_* macros I've >> defined to >> accept a MonoMethod* argument and to translate it to the final probe >> arguments there. This avoids code duplication in mini.c. >> Note that my patch shows four returns not handled by Mono's >> profiler, for >> unsuccessful AOT generic sharing and for parts==1,2,3. Should that >> be fixed, >> or is it not necessary for some reason? >> >> >> Signed-off-by: Andreas Faerber >> >> ChangeLog v3: >> >> * dtrace-prelink.sh: Renamed (from dtrace-prelink.sh.in) >> Don't define AR, DTRACE, DTRACEFLAGS. >> Removed debug output. >> >> * configure.in: >> Don't output dtrace-prelink.sh. >> Move DTrace section up, to after the big-arrays section. >> >> * data/mono.d, >> mono/utils/dtrace.h, >> mono/mini/mini.c: >> Add new probes method-compile-{begin,end}. >> >> * mono/metadata/Makefile.am, >> mono/mini/Makefile.am: >> dtrace-prelink.sh is now in $(top_srcdir). >> Pass AR, DTRACE, DTRACEFLAGS as environment variables to dtrace- >> prelink.sh. >> >> Andreas >> >> >> >> >> >> From sontek at gmail.com Thu Jun 5 14:03:56 2008 From: sontek at gmail.com (John M. Anderson) Date: Thu, 05 Jun 2008 12:03:56 -0600 Subject: [Mono-dev] SVN Debugger issues In-Reply-To: <1212679384.4702.25.camel@gondor.trier.ximian.com> References: <1212607480.1165.6.camel@linux.site> <1212679384.4702.25.camel@gondor.trier.ximian.com> Message-ID: <1212689036.1165.18.camel@linux.site> On Thu, 2008-06-05 at 17:23 +0200, Martin Baulig wrote: > Ok, finally have a fix for this on my local hard disk. > > Unfortunately, I'm currently out of internet connection, so I'll commit > later today or tomorrow morning. Hey, I saw you committed a lot of fixes today, including allowing HEAD to build against svn mono again, but I still get the same environment issues. I've installed latest mono and mdb from svn and i'm using the bash script I posted before to setup the environment. Is there anything special I have to do to get the debugger to pull its libs from its own prefix first other than what I've already been doing? Here are the errors again: ** (/home/sontek/bin/lib/mono/2.0/m