Re: [Mono-dev] Mono on MIPS32
We compiled successfully Mono (2.4.2.3) as well as an early 2.6(taken from SVN) on openembedded. See with Cliff Brake from Bec Systems - he is the expert on this topic. On x86, the result is very nice: a dedicated linux box of 50 Mo with network support and the full Mono on it! Lionel -Message d'origine- De : mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] De la part de Rayson Ho Envoyé : samedi 15 mai 2010 18:14 À : Andrea Cc : Mono Development mailing list Objet : Re: [Mono-dev] Mono on MIPS32 On Sat, May 15, 2010 at 3:28 AM, Andrea serr...@gmail.com wrote: Yes, we tested your patch unsuccessfully. We use openembedded to crosscompile mono, we tested your patch with the last svn, but when we run mono to the target the only output is Segmentation fault. You are introducing too many variables by using the latest svn, openembedded to cross compile, a non-Loongson processor as your target. It would help if you can downgrade the Mono version to the latest 2.4, and introduce any possible source of failure one at a time. I am still waiting for the new MIPS port, so I am not going to touch the latest svn or even Mono 2.6 for a little while. Rayson We tested your patch also in svn r136576, but the compile process fails: | Compilation failed: 1 error(s), 19 warnings | make[7]: *** [../class/lib/basic/mcs.exe] Error 1 | make[7]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mcs/mcs' | make[6]: *** [do-all] Error 2 | make[6]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mcs/mcs' | make[5]: *** [all-recursive] Error 1 | make[5]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mcs' | make[4]: *** [profile-do--basic--all] Error 2 | make[4]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mcs' | make[3]: *** [profiles-do--all] Error 2 | make[3]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mcs' | make[2]: *** [all-local] Error 2 | make[2]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mono/runtime' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-native -2.6.4+svnrr136576-r0/mono' | make: *** [all] Error 2 | FATAL: oe_runmake failed NOTE: Task failed: /home/oe/oedev/box/openembedded/build/tmp-wrt54/work/i686-linux/mono-n ative-2.6.4+svnrr136576-r0/temp/log.do_compile.10933 any help is welcome! Thank you Andrea On Fri, May 14, 2010 at 5:37 PM, Lorenz Cuno Klopfenstein l...@klopfenstein.net wrote: Hello all, I am currently trying to get Mono to run on a little endian MIPS32 based board, but without much success. In fact, compiling Mono - using the same toolchain that worked for other apps - produces a whopping 8.5 megabytes mono executable. Attempting to run it (even launching mono --version or anything) returns a segmentation fault. It appears that the compilation produces a flawed executable, even if it succeeds. Does anybody have some suggestions on building Mono on a MIPS board? Thank you in advance for any help. -- Lorenz Cuno Klopfenstein l...@klopfenstein.net http://lorenz.klopfenstein.net ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ilasm as a library
Andreas Nahr classdevelopm...@a-softtech.com wrote in message news:002b01caf54b$a49d3940$edd7ab...@com... Which use case do you see for a temporary solution using .il files? The compiler backend in question currently generates .il but no .dll or .exe files. That's why I was thinking about calling Mono ilasm as a library (requiring no restart across invocations, which would require Mono ilasm to avoid static state) . Now that you mention System.Reflection, https://blogs.msdn.com/jmstall/archive/2008/03/15/things-in-metadata-that-are-missing-in-reflection.aspx http://weblog.ikvm.net/PermaLink.aspx?guid=9b7ada92-88d7-45c7-be83-8e6f4f3ccb1b Not everyone uses System.Reflection. The list goes on. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ilasm as a library
Now that you mention System.Reflection, I'm not sure how you get to that statement. But I NEVER mentioned System.Reflection. I've been talking about System.Reflection.Emit which is an (entirely) different thing. https://blogs.msdn.com/jmstall/archive/2008/03/15/things-in-metadata- that-are-missing-in-reflection.aspx And what does this have to do with System.Reflection.Emit? http://weblog.ikvm.net/PermaLink.aspx?guid=9b7ada92-88d7-45c7-be83- 8e6f4f3ccb1b That's a cool source-compatible replacement for System.Reflection.Emit. So you can develop against System.Reflection.Emit and simply drop IKVM.Reflection.Emit in to replace it (or vice versa). Not everyone uses System.Reflection. The list goes on. No, not *everyone* does. But nearly everyone does it. Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Read timezones from the registry on Windows.
Hello,
Great patch!
The code doesn't check whether it's running on (or compiled for)
Windows, just whether the appropriate registry key exists. I don't
know if that's the preferred way of doing things.
Would you mind changing the code to not probe the registry unless it is
not running on Unix? This can be done with the following code:
int p = (int) Environment.OSVersion.Platform;
if ((p == 4) || (p == 6) || (p == 128)) {
Console.WriteLine (Running on Unix);
} else {
Console.WriteLine (NOT running on Unix);
}
miguel.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCHES] Bug 480178 - System.Globalization.CharUnicodeInfo.GetUnicodeCategory() does not handle surrogate characters appropriately.
Hello, This approach grows the category data table from 64 to ~70kB, and requires an additional 8kB index for the astral planes. The resulting runtime produces the same results as Microsoft's v2.0.50727 and v3.5.21022 for the whole Unicode range, but has no support for v4. Would that be an acceptable overhead? I think this is acceptable overhead; I would like to have an option to turn off the astral planes if possible. Would supporting v4.0.30319 be worth it at an additional cost of ~78kB of data (which shouldn't be faulted in) in the Mono binary? If you are up for it, I would love to support the 4.0 code as well, as our next release will be a big push for 4.0 support (this will be our new default). Is your Linear + bi-level patch available in Bugzilla? Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCHES] Bug 480178 - System.Globalization.CharUnicodeInfo.GetUnicodeCategory() does not handle surrogate characters appropriately.
Hi Miguel, Miguel de Icaza mig...@novell.com writes: Hello, This approach grows the category data table from 64 to ~70kB, and requires an additional 8kB index for the astral planes. The resulting runtime produces the same results as Microsoft's v2.0.50727 and v3.5.21022 for the whole Unicode range, but has no support for v4. Would that be an acceptable overhead? I think this is acceptable overhead; I would like to have an option to turn off the astral planes if possible. That can certainly be done. I suppose you envision a compile-time switch? Is there already such an option/flag/preprocessor symbol I should use as a model? Would supporting v4.0.30319 be worth it at an additional cost of ~78kB of data (which shouldn't be faulted in) in the Mono binary? If you are up for it, I would love to support the 4.0 code as well, as our next release will be a big push for 4.0 support (this will be our new default). Sure. I guess this means some more compile-time conditionalization of the runtime; corlib can just pass a version parameter at class init time as in v3 of my patches: #if NET_4_0 private const int CategoryDataVersion = 4; #else private const int CategoryDataVersion = 2; #endif (Alternative suggestions are of course welcome.) Is your Linear + bi-level patch available in Bugzilla? I just uploaded v4: https://bugzilla.novell.com/show_bug.cgi?id=480178#c35 Miguel. Cheers, -D -- http://crosstwine.com tel: +49 21 89 29 39 cell: +49 174 34 89 428 “Strong Opinions, Weakly Held” — Bob Johansen ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCHES] Bug 480178 - System.Globalization.CharUnicodeInfo.GetUnicodeCategory() does not handle surrogate characters appropriately.
Hello, MS have (or used to on 2.0) a lot of broken stuff when it comes to unicode/locales. So sometimes fixing for MS compatibility means breaking correctness. It might be time to revisit this policy. Currently the situation is that we kept compatibility with Microsoft as Microsoft's work on this predated the Unicode standard. But today we have various problems: * Our implementation has bugs * We emulated the Microsoft behavior * We do not quite maintain the code to match the MS behavior * The overhead of maintaining it is pretty high * We do not dedicate enough cycles or have enough cycles for keeping up documents that reflect what is required. Additionally, with Silverlight Microsoft broke with the past, and uses whatever the native operating system provides, so we know that Mac vs Windows has differences in this area. To me this seems like it is time for a change in policy: our string collation should reflect what the rules are in Unicode as it will be easier for us to maintain. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCHES] Bug 480178 - System.Globalization.CharUnicodeInfo.GetUnicodeCategory() does not handle surrogate characters appropriately.
Hi To me this seems like it is time for a change in policy: our string collation should reflect what the rules are in Unicode as it will be easier for us to maintain. Miguel. In that case, we might as well use ICU. Zoltan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCHES] Bug 480178 - System.Globalization.CharUnicodeInfo.GetUnicodeCategory() does not handle surrogate characters appropriately.
That can certainly be done. I suppose you envision a compile-time switch? Is there already such an option/flag/preprocessor symbol I should use as a model? For C code, just use the symbol DISABLE_ASTRAL, then we can add that to configure.in Sure. I guess this means some more compile-time conditionalization of the runtime; corlib can just pass a version parameter at class init time as in v3 of my patches: #if NET_4_0 private const int CategoryDataVersion = 4; #else private const int CategoryDataVersion = 2; #endif Exactly right; Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCHES] Bug 480178 - System.Globalization.CharUnicodeInfo.GetUnicodeCategory() does not handle surrogate characters appropriately.
To me this seems like it is time for a change in policy: our string collation should reflect what the rules are in Unicode as it will be easier for us to maintain. In that case, we might as well use ICU. I do not want to go back to the business of maintaining dependencies and carrying a new dependency in Mono for this. It was painful enough the first time, and I do not want go back to it. I want to keep Mono with as few dependencies as possible, specially now that we are being used more often in embedded setups. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling mono from trunk on Ubuntu
I resolved this issue by making fresh install of ubuntu (it was something wrong with mono installation) -- View this message in context: http://mono.1490590.n4.nabble.com/Compiling-mono-from-trunk-on-Ubuntu-tp2220004p2220402.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] namespace name could not be found in FakeMembershipProvider.cs
Hello, In mono svn trunk head, gmake check failed with compile error. $ gmake check (snip) gmake[7]: Leaving directory `/export/home/ksmakoto/Mono/mcs/class/System.ComponentModel.DataAnnotations' gmake[7]: Entering directory `/export/home/ksmakoto/Mono/mcs/class/System.Web.DynamicData' gmake test-local gmake[8]: Entering directory `/export/home/ksmakoto/Mono/mcs/class/System.Web.DynamicData' MCS [net_4_0] System.Web.DynamicData_test_net_4_0.dll Test/../../System.Web/Test/mainsoft/NunitWeb/NunitWeb/FakeMembershipProvider.cs(10,54): error CS0246: The type or namespace name `MembershipProvider' could not be found. Are you missing a using directive or an assembly reference? Compilation failed: 1 error(s), 0 warnings gmake[8]: *** [System.Web.DynamicData_test_net_4_0.dll] Error 1 gmake[8]: Leaving directory `/export/home/ksmakoto/Mono/mcs/class/System.Web.DynamicData' gmake[7]: *** [do-test] Error 2 (snip) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
