gmane.comp.gnome.mono.devel

Incoming changes to Mono.Simd

Rodrigo Kumpera — 2008-12-03T16:18:58

_______________________________________________ Mono-devel-list mailing list Mono-devel-list< at >lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Proposed change to TestDriver.dll

Mark Mason — 2008-12-02T10:01:58

Hello all, I'd like to propose the following change to TestDriver.dll. The purpose of this patch is to avoid using the DateTime class unless timings are explicitly called for. DateTime pulls in a lot of additional infrastructure code which may cause the test harness itself to fail. With this change, it's a lot easier to run the regression tests such as basic.cs & others with a JIT port in progress. [Which is where the MIPS port is right now. There's something failing waaaay down in the guts of DateTime, daylight savings time computations, and such. It'd be a lot better to be able to uncover these problems with the simple test cases in basic*.cs] Thanks in advance, Mark Index: TestDriver.cs =================================================================== --- TestDriver.cs (revision 120080) +++ TestDriver.cs (working copy) < at >< at > -13,7 +13,6 < at >< at > bool do_timings = false; bool verbose = false; int tms = 0; - DateTime start, end = DateTime.Now; if (args != null && args.Length > 0) { for (j = 0; j < args.Length; j++) { < at >< at > -61,15 +60,18 < at >< at > if (verbose) Console.WriteLine ("Running '{0}' ...", name); expected = Int32.Parse (name.Substring (5, j - 5)); - start = DateTime.Now; - result = (int)methods [i].Invoke (null, null); if (do_timings) { - end = DateTime.Now; + DateTime start = DateTime.Now; + result = (int)methods [i].Invoke (null, null); + DateTime end = DateTime.Now; long tdiff = end.Ticks - start.Ticks; int mdiff = (int)tdiff/10000; tms += mdiff; Console.WriteLine ("{0} took {1} ms", name, mdiff); } + else { + result = (int)methods [i].Invoke (null, null); + } ran++; if (result != expected) { failed++;

MIPS port update

Mark Mason — 2008-12-02T01:39:09

Hello all, The MIPS port is coming along nicely. Hello, World! now works, the tests in basic.exe all pass if run manually and not by using the reflection technique that the test harness normally uses. There's still a lot to do - a lot of the logic that was in the old style brg files for MIPS still needs to be ported to the new JIT, and there's a number of additional tweaks that are needed, but it should at least be fairly straightforward from here on out. All of this is checked into svn. I'll be out of town for a few days w/o access to this email account (but still reachable at mason< at >broadcom.com). Cheers, Mark

String.GetHashCode on Mac

David Suarez — 2008-12-01T14:25:46

Hi, I've run into a problem with the String.GetHashCode method in macosx (10.5.3, intel). The point is I get the same hashcode for very different strings, apparently only taking into account the last 7 chars of the string. This happens with mono 2.0 installer. Consider this test case: using System; namespace hashtest { class Class2 { private static string[] testStrings2 = new string[] { "something to worry about", "ing to worry about", "to worry about", "orry about", "y about", " about" }; [STAThread] static void Main(string[] args) { foreach (string s in testStrings2) PrintHash(s, s.GetHashCode()); } private static void PrintHash(string str, int hash) { Console.WriteLine(" hash [{1}] line: [{0}]", str, hash.ToString("X8")); } } } Running on mac, I get this result: hash [9DA57994] line: [something to worry about] hash [9DA57994] line: [ing to worry about] hash [9DA57994] line: [to worry about] hash [9DA57994] line: [orry about] hash [9DA57994] line: [y about] hash [1DA57994] line: [ about] It seems to me that the String.GetHashCode in String.cs is not getting called, because this method works fine (I tested separately). Is this happening to anybody else? Any clue on what code is being called on the mac for getting the hash code of strings? Thanks, David Is this happening to anybody else??

MD not packaging binaries correctly though it could be mono at fault

Paul — 2008-11-30T19:05:12

_______________________________________________ Mono-devel-list mailing list Mono-devel-list< at >lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

build fails if AOT is disabled

Miha Vrhovnik — 2008-11-29T15:40:05

Hi, Both trunk and mono 2.2 tagged fail if you disable AOT. Tried on both Ubuntu 8.10 and Windows.... Regards, Miha

Patch for monotools Gendarme makefiles

Paul — 2008-11-29T13:04:40

_______________________________________________ Mono-devel-list mailing list Mono-devel-list< at >lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Would someone care to patch coree.c...

Miha Vrhovnik — 2008-11-29T09:48:57

Hi *, As I said in one of previous messages mono on windows doesn't compile using VS 2005 if you have Vista SDK installed. Would be nice to have this in mono 2.2 code... Would someone please care to add code below to coree.c, coree.h or other proper place #ifndef IMAGE_SIZEOF_BASE_RELOCATION // Vista SDKs no longer define IMAGE_SIZEOF_BASE_RELOCATION!? #define IMAGE_SIZEOF_BASE_RELOCATION (sizeof(IMAGE_BASE_RELOCATION)) #endif Best regards, Miha

System.Data.OracleClient broken in mono 2.2 Preview1?

kray — 2008-11-27T05:20:36

I need to run some further tests, but retrieving a datatable from a cursor in Oracle, using the System.Data.OracleClient appears to be broken in the Mono 2.2 Preview. I was testing using code that worked in Mono 1.9. Is anyone else seeing this? thanks, Kris

problem compiling on cygwin.

Lucas Meijer — 2008-11-28T17:18:43

_______________________________________________ Mono-devel-list mailing list Mono-devel-list< at >lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Tuning of assemblies in the mcs module

Jb Evain — 2008-11-28T15:46:30

Hey there, Atsushi earlier this week stumbled upon an interesting bug in our build, which made me think. The issue right now, is that the build of the `tuner` and the actual tuning of our assemblies for the net_2_1 (SL2) profile are tied together. So the tuner is not built when mono is not configured to build the moonlight bits, but the tuner is required to build our Mono.CSharp library which contains our (most amazing) C# evaluator. A trivial fix would be to separate the actual tuning and the tuner build, introducing something like csharplib does. We could have a moonlib, which would trigger the tuning process during the net_2_1 build. The issue I have with this (and it's entirely my fault), is that we started building libraries in the mcs/tools module. While we have a mcs/class module which heh, is for libraries. The main issue comes from the tuner is a library which references the assembly `linker.exe`, produces by mcs/tools/linker. This was done to simplify the life of the .net developers who are simply pulling the linker or the tuner extensions from SVN. Or maybe only to simplify my life :) So my proposal for a correct fix would be to extract a Mono.Linker library, move it to mcs/class, move the library mcs/tools/tuner to a mcs/class/Mono.Tuner library, referencing Mono.Linker. We would also build Mono.CSharp into mcs/class instead of mcs/tools/csharplib. Then I would add a `tuning` folder in mcs, which could contains entries for each tuning step, which would be so far, one for the evaluator, and another one for SL2 libraries. This sounds the cleaner way to me, but it requires more work than the trivial fix. How does that sound?

ANN: NUnit 2.5 Beta 1

Charlie Poole — 2008-11-28T06:28:44

Hi All, Well, NUnit 2,5 Beta 1 was just announced. That's good news except for the "minor" problem that the Gui isn't working on Mono right now. In addition, although you can run the gui on .NET 2.0 and successfully load tests under Mono in another process, the execution either fails unexpectedly or sometimes just loses contact with the controlling process. However, I felt the release had already been delayed too long, and it works well on Windows so I made the drop. I decided to post here to invite folks who would like to build from source and debug it to send me any fixes they come up with. I plan to work on the Mono side more heavily as soon as my new Linux machine arrives, so Beta 2 should be more directly useful. Here's the announcement: Today we are announcing the first Beta release of NUnit 2.5. This release has lots of new features, ready to use. Important hilights include: * Parameterized tests, with a set of attributes that allow you to supply data to your tests in different ways. * Test methods may be static and generic methods are supported. * Generic test fixtures may be instantiated multiple times with different type parameters. * Tests may be run using a separate thread and the Apartment State may be specified individually for a test, fixture or assembly. * Tests may be run in a separate process using the CLR version of your choice. * A timeout value may be specified so that tests are cancelled if they get into an infinite loop. For the full story of this release the release notes at http://nunit.org/?p=releaseNotes&r=2.5. You may download the release at http://nunit.org/?p=downloads. Charlie

Trunk broken,g_slist_append_mempool declaration inconsistency

KISHIMOTO, Makoto — 2008-11-28T03:35:38

Hello Trunk cannot build, like follows gmake[4]: Entering directory `/local/home/ksmakoto/Mono/mono/mono/mini' if ../../doltcompile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DGC_FREEBSD_THREADS -DPLATFORM_BSD -I../.. -I../../libgc/include -D_REENTRANT -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -g -O2 -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -mno-tls-direct-seg-refs -MT regalloc2.lo -MD -MP -MF ".deps/regalloc2.Tpo" -c -o regalloc2.lo regalloc2.c; \ then mv -f ".deps/regalloc2.Tpo" ".deps/regalloc2.Plo"; else rm -f ".deps/regalloc2.Tpo"; exit 1; fi regalloc2.c:192: error: static declaration of 'g_slist_append_mempool' follows non-static declaration ../../mono/metadata/mempool-internals.h:11: error: previous declaration of 'g_slist_append_mempool' was here gmake[4]: *** [regalloc2.lo] Error 1 gmake[4]: Leaving directory `/local/home/ksmakoto/Mono/mono/mono/mini' ======== Sources are like this. mono/mini/regalloc2.c 189 static inline GSList* 190 g_slist_append_mempool (MonoMemPool *mp, GSList *list, 191 gpointer data) mono/metadata/mempool-internals.h 10 GSList* 11 g_slist_append_mempool (MonoMemPool *mp, GSList *list, gpointer data) MONO_INTERNAL;

NUnit migration and test failure status

Atsushi Eno — 2008-11-28T01:40:21

Hello, As some of you may have noticed, I have upgraded our local use of nunit from 2.2.0 to 2.4.8. It involved some changes in our test run, but should be invisble to most of you. The build has been broken for a while (am sorry for that; it was a set of make dist / packaging mess), and now we have a couple of test failures. So before Marc dives into the hell list of unknown bugs to him, I wanted to give some survey on them: - some JIT stuff: test-verifier, test-System_Web-2.0 - mere build failure: test-System_Data-2.0 - some floating point failures: test-corlib-*, test-System_Drawing-*, test-System_Data-1.0, test-System_Runtime_SFS-* - possible NUnit run changes: test-corlib-2.0 (MonoTests.System.Threading.ExecutionContextTest.Copy_FromThread), test-System_Runtime_Remoting-* - possibly gdiplus: test-System_Drawing-*, test-Windows_Forms-2.0 (MonoTests.System.Drawing.PenTest.DashCap_Valid) - some sys.data changes: test-Mono_Data_Sqlite-*, test-Mono_Data_SqliteClient* The only pattern I am concerned is the one with (possible) NUnit run changes. NUnit 2.4.8 now requires -noshadow to get our tests run fine. This also happens under .NET (i.e. make run-test-ondotnet) even without -noshadow, so I am rather afraid that NUnit 2.4.8 unlike 2.2.0 cannot handle it. I'd like to hear inputs on what could be done to fix this issue. Atsushi Eno

System.Drawing.Graphics.MeasureCharacterRanges broken with empty layout rectangle

Stefanos A. — 2008-11-27T14:27:48

When MeasureCharacterRanges is passed an empty layout rectangle (RectangleF.Empty), it should not perform any word wrapping. Attached is a test case that demonstrates the issue (runs fine under .Net). Compile with "gmcs Program.cs -r:System.Drawing.dll". Expected output: $ mono Program.exe Using rectangle {X=0,Y=0,Width=100,Height=100}: {X=0,Y=0,Width=9,Height=18} {X=9,Y=0,Width=9,Height=18} {X=18,Y=0,Width=8,Height=18} Using rectangle {X=0,Y=0,Width=0,Height=0}: {X=0,Y=0,Width=9,Height=18} {X=9,Y=0,Width=9,Height=18} {X=18,Y=0,Width=8,Height=18} Observed output: $ mono Program.exe Using rectangle {X=0,Y=0,Width=100,Height=100}: {X=0,Y=0,Width=9,Height=18} {X=9,Y=0,Width=9,Height=18} {X=18,Y=0,Width=8,Height=18} Using rectangle {X=0,Y=0,Width=0,Height=0}: {X=-4194304,Y=-4194304,Width=8388608,Height=8388608} {X=-4194304,Y=-4194304,Width=8388608,Height=8388608} {X=-4194304,Y=-4194304,Width=8388608,Height=8388608} _______________________________________________ Mono-devel-list mailing list Mono-devel-list< at >lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Question(s) about the JIT implementation

Mark Mason — 2008-11-26T18:14:13

Hello all, I'm working on getting the MIPS JIT ported back up to the top-of-tree, and have run into a few issues - primarily with areas that have changed a lot since I looked at it last. I am hoping that someone can spare a couple of sentences to point me in the right direction here. As it stands now, hello.exe on MIPS gets as far as the following: mason< at >10:~/Mono-MIPS/mono/mono/mini$ ./mono hello.exe Stacktrace: at System.Globalization.TextInfo..ctor (System.Globalization.CultureInfo,int,void*,bool) <0xffffffff> at System.Globalization.TextInfo..ctor (System.Globalization.CultureInfo,int,void*,bool) <0x00148> at System.Globalization.CultureInfo.ConstructInvariant (bool) <0x001c0> at System.Globalization.CultureInfo..ctor (int,bool,bool) <0x00088> at System.Threading.Thread.get_CurrentCulture () <0xffffffff> at System.Threading.Thread.get_CurrentCulture () <0x0011c> at System.NumberFormatter..ctor (System.Threading.Thread) <0x00078> at System.Threading.Thread.AcquireNumberFormatter () <0x0006c> at System.NumberFormatter.GetInstance () <0x00030> at System.NumberFormatter.NumberToString (string,int,System.IFormatProvider) <0x00024> at System.NumberFormatter.NumberToString (int,System.IFormatProvider) <0x0007c> at int.ToString () <0x0002c> at System.Text.Encoding.GetEncoding (int) <0x003cc> at System.Text.Encoding.get_Default () <0x00210> at System.Console..cctor () <0x00210> at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> at TestBed1.MainClass.Main (string[]) <0xffffffff> at TestBed1.MainClass.Main (string[]) <0x0002c> at (wrapper runtime-invoke) TestBed1.MainClass.runtime_invoke_void_object (object,intptr,intptr,intptr) <0xffffffff> Aborted Rewriting: As MIPS uses compare-and-branch opcodes rather than separate compare/branch opcodes (there's no condition register for one thing), what we used to do was rewrites to MIPS specific opcodes in the burg rules. Burg isn't with us any more, but the rewriting still needs to happen. I'm currently doing it in peephole pass 1, but this really needs to move into a separate pass which isn't an "optimization" that can be disabled from the command line. Maybe add mono_arch_rewrite_pass_1() and the appropriate enabling macro, and call it right after the lowering pass? Thoughts? IMT: I'm not quite clear on what this is, which makes adding support for it a bit difficult. I have it enabled at the moment, and hello world is crashing on the first "use" of it (see below). I know that I'm locating the LMF correctly [because MIPS LMFs have magic numbers ;)] but I'm no where near so confident about MONO_ARCH_IMT_REG, mono_arch_build_imt_thunk (which hasn't been called yet below), and other friends. (gdb) r hello.exe Starting program: /home/mason/Mono-MIPS/mono/mono/mini/mono hello.exe [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 14569)] [New Thread 32769 (LWP 14572)] [New Thread 16386 (LWP 14573)] [New Thread 32771 (LWP 14574)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 14569)] 0x00548ce4 in mono_convert_imt_slot_to_vtable_slot (slot=0x8395c0, regs=0x7f88b440, code=0x2b3ffeb0 "\024< at >", method=0x84b3f8, impl_method=0x0) at mini-trampolines.c:63 63 interface_offset = mono_class_interface_offset (vt->klass, imt_method->klass); (gdb) where #0 0x00548ce4 in mono_convert_imt_slot_to_vtable_slot (slot=0x8395c0, regs=0x7f88b440, code=0x2b3ffeb0 "\024< at >", method=0x84b3f8, impl_method=0x0) at mini-trampolines.c:63 #1 0x0054a0f0 in mono_magic_trampoline (regs=0x7f88b440, code=0x2b3ffeb0 "\024< at >", m=0x84b3f8, tramp=0x0) at mini-trampolines.c:335 #2 0x2aac8164 in ?? () Thanks all, Mark _______________________________________________ Mono-devel-list mailing list Mono-devel-list< at >lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list

Simple web service test with windows authentication

marcos b — 2008-11-26T17:39:41

I'm trying to do a web service invocation using mono. The web service is hosted on my machine using iis. Windows authentication is used in the web.config and in iis. The test runs ok using .net environment but throws an Unauthorized exception when using mono. I don't know if this is a bug or I'm missing something... Thanks in advance [Test] public void WebServiceTest() { WS.Service1 s=new app.WS.Service1(); //s.UseDefaultCredentials = true; //Also throws an exception //s.Credentials = CredentialCache.DefaultCredentials; //Also throws an exception s.Credentials = new NetworkCredential("myLogin", "12345678", "myDomain"); Assert.AreEqual(s.Add(3,5),8); } Exception detail----------------------------------------------------------------------------- TestCase 'app.MonoWebTests.WebServiceTest' failed: System.Net.WebException : The request failed with HTTP status 401: Unauthorized at System.Web.Services.Protocols.SoapHttpClientProtocol.ReceiveResponse (System.Net.WebResponse response, System.Web.Services.Protocols.SoapClientMessage message, System.Web.Services.Protocols.SoapExtension[] extensions) [0x00000] at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke (System.String method_name, System.Object[] parameters) [0x00000] at app.WS.Service1.Sumar (Int32 a, Int32 b) [0x00000] at (wrapper remoting-invoke-with-check) app.WS.Service1:Sumar (int,int) at app.MonoWebTests.WebServiceTest () [0x00000] at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000]

Typed dataset serialization still failing in mono 2.0.1

marcos b — 2008-11-26T11:37:08

I have an extremelly simple typed dataset generated using vs 2005 with one datatable with a simple column When I try to run this test I get the following exception (I get the same error using vs 2008 typed dataset) System.ArgumentException : The given name 'MyDataTable' matches atleast two namesin the collection object with different namespaces [Test] public void SimpleTypedDataSetSerialization() { MyDataSet ds = new MyDataSet(); BinaryFormatter f = new BinaryFormatter(); MemoryStream ms = new MemoryStream(); f.Serialize(ms, ds); ms.Position = 0; ds = (MyDataSet)f.Deserialize(ms); } It's extremelly important for me to have the possibility of serializing and deserializing typed datasets for the migration of my application to the mono platform. So I would be very happy to know if this issue is going to be addressed soon. I have posted the same issue a couple of months, even a file the bug in mono bugzilla but, but nothing happened. The idea of the mono platform is great, but no supporting simple code like the posted above can make someone to give up porting his .net application to the linux world. Thanks in advance

tuner, csharplib and --with-moonlight=no

Atsushi Eno — 2008-11-26T01:54:29

Hello, Right now I am building mono configured as "--with-moonlight=no" to workaround some weird build failure on windows. Now, I'm getting build error at csharplib because of lack of tuner. tuner is built only as part of NET_2_1 profile, while csharplib uses tuner regardless of --with-moonlight option. Actually I think that tuner should be built regardless of this option. Is it impossible to build tuner under 2.0 profile? Atsushi Eno

System.Net.Sockets upgrade to comply with .NET 3.5 - when?

FractalizeR — 2008-11-24T14:54:02

Hello. Could you please tell, when System.Net.Sockets namespace will be upgraded with changes came in MS .NET Framework 3.5? High-production socket classes were introduced and that's quite important. But I can't find any information on the subject on the roadmap... Thanks in advance.

Embedding (iterating over assembly/image types)

MWheeler — 2008-11-23T23:20:49

Hey all, I've been doing a bit of work with embedding mono into a game engine, and I'm yet to find a way (without using reflection 'inside' of C#/whatever) to iterate over all types in an assembly/image... There's no reference to doing this in the documentation, and searching through the mini/metadata headers didn't unearth anything interesting. Is this supported by the mono API at present? Any help would be greatly appreciated. Cheers, Mitch