[Mono-dev] Compiling mono with Clang/LLVM
I tried to compile Mono 2.6.4 (trunk of 2.6 branch) with Clang/LLVM trunk (1.5/2.8) and it seemed to work without a hitch. All I did was set CC to /usr/bin/clang. Is there any reason that I should not be building Mono with Clang/LLVM? Does it bring any advantage? The build was on a setup that is just for playing around so this kinda falls into the "see if it works" category. That said, it would be very nice if compiling Mono was faster and less resource intensive. This machine is often busy with a few such tasks and I compile Mono trunk fairly often to see how things are coming along. The web is all abuzz about LLVM. Would it make the parts of the Mono runtime that are written in C any more performant? If it does, and if this is a relatively safe operation, I would consider building Mono this way on machines that are less experimental. Anybody have any idea? PS. I tried the same build (Mono 2.6.4 with Clang/LLVM trunk) on a CentOS 5.4 box and it failed. The test system mentioned above is running Ubuntu Lucid Lynx (due out in a week) and it also built on Ubuntu Karmic. -- View this message in context: http://n4.nabble.com/Compiling-mono-with-Clang-LLVM-tp2018329p2018329.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
Re: [Mono-dev] 480152 - string.Normalize() frequently produces incorrect output
Hello, I have never had time enough to read this set of big changes, but my gut feeling is the new rewrite would be okay (on e.g. performance). Feel free to commit the changes, or I'll make changes leter in case you don't have write access. It has been five years since I volunteered to write it and I did only few bugfixes, so I'm not likely to pay attention to this stuff. Atsushi Eno On 2010/04/21 5:47, Damien Diederen wrote: > Hello everybody, > > I just attached a (second) series of patches addressing a mix of Unicode > normalization problems to the following bug: > >https://bugzilla.novell.com/show_bug.cgi?id=480152#c32 > > As noted in the “cover letter”: > > >> This, a couple other fixes, and the addition of the Hangul composition >> algorithm (complementing Gabriel's work on decomposition) causes the >> number of failures in the BMP subset of the Unicode canonicalization >> test suite to drop from 4k+ to 888. >> >> (Another, still experimental, and more controversial series of mine >> brings that number down to zero, but it still needs a bit of work >> before I post it as an RFC.) >> > As I'm not sure anybody following that bug has any “free cycles,” I'm > posting the link here for other committers to see. I would really > appreciate if somebody could have a look at the patches and comment on > what has to be done/changed/improved to get them in Mono. > > Thanks, > Damien > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Make System.IO.Ports work on UNIX systems other than Linux
Hi
The attached diff makes SerialPort.GetPortNames() work on
all Unix systems other than Linux too, because ttyS* and
ttyUSB* is linux specific and on *BSD the serial ports are
tty[0-9]+.
(I've tested this code on Linux and it should also support
ttySG0 (SGI running Linux (ia64)).
The other way would be to add a different platform id for
*BSDs.
Comments? (My C# is not good :))
Index: class/System/System.IO.Ports/SerialPort.cs
===
--- class/System/System.IO.Ports/SerialPort.cs (revision 155801)
+++ class/System/System.IO.Ports/SerialPort.cs (working copy)
@@ -24,6 +24,7 @@
using System.ComponentModel;
using System.Diagnostics;
using System.Text;
+using System.Text.RegularExpressions;
using System.Runtime.InteropServices;
using Microsoft.Win32;
@@ -525,10 +526,18 @@
// Are we on Unix?
if (p == 4 || p == 128 || p == 6) {
string[] ttys = Directory.GetFiles("/dev/",
"tty*");
+ Regex lnx = new
Regex(@"^\/dev\/tty(S(G)?|USB)[0-9]+$");
+ Regex rem = new
Regex(@"^\/dev\/tty(U)?[0-9]+$");
+
foreach (string dev in ttys) {
- if (dev.StartsWith("/dev/ttyS") ||
dev.StartsWith("/dev/ttyUSB"))
- serial_ports.Add(dev);
+ if (lnx.Match(dev).Success)
+ rem = lnx;
+ serial_ports.Add(dev);
}
+ for (int i = serial_ports.Count - 1; i >= 0;
i--) {
+ if (!rem.Match(serial_ports[i]).Success)
+ serial_ports.RemoveAt(i);
+ }
} else {
using (RegistryKey subkey =
Registry.LocalMachine.OpenSubKey("HARDWARE\\DEVICEMAP\\SERIALCOMM"))
{
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] 480152 - string.Normalize() frequently produces incorrect output
Hello everybody, I just attached a (second) series of patches addressing a mix of Unicode normalization problems to the following bug: https://bugzilla.novell.com/show_bug.cgi?id=480152#c32 As noted in the “cover letter”: > This, a couple other fixes, and the addition of the Hangul composition > algorithm (complementing Gabriel's work on decomposition) causes the > number of failures in the BMP subset of the Unicode canonicalization > test suite to drop from 4k+ to 888. > > (Another, still experimental, and more controversial series of mine > brings that number down to zero, but it still needs a bit of work > before I post it as an RFC.) As I'm not sure anybody following that bug has any “free cycles,” I'm posting the link here for other committers to see. I would really appreciate if somebody could have a look at the patches and comment on what has to be done/changed/improved to get them in Mono. Thanks, Damien -- http://crosstwine.com “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] MonoDevelop & MoonLight debugger
On Tue, Apr 20, 2010 at 6:37 PM, Timothy Graupmann wrote: > I found a video on using the MonoDeveloper debugger with Moonlight. > http://www.youtube.com/watch?v=GSUZRZWzTQM > > Apparently this works on Linux. I didn't have the same success on the mac. It requires Moonlight, not Silverlight. We don't have any way to access the SL debugger APIs. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoDevelop & MoonLight debugger
I found a video on using the MonoDeveloper debugger with Moonlight. http://www.youtube.com/watch?v=GSUZRZWzTQM Apparently this works on Linux. I didn't have the same success on the mac. --- On Sun, 4/11/10, Timothy Graupmann wrote: From: Timothy Graupmann Subject: [Mono-dev] MonoDevelop & MoonLight debugger To: "mono-devel-list" Date: Sunday, April 11, 2010, 12:28 AM Did I say MonoLight? I meant MoonLight. --- On Thu, 4/8/10, Timothy Graupmann wrote: From: Timothy Graupmann Subject: [Mono-dev] MonoDevelop & MonoLight debugger To: "mono-devel-list" Date: Thursday, April 8, 2010, 8:09 AM I was able to compile my Silverlight User Control with MonoLight fairly easily. Now I want to run the debugger. However, the page with any info about how to do line by line debugging in MonoDevelop is blank. http://monodevelop.com/Enabling_the_Debugger Who do we have to poke to finish the wiki? Thanks, ~Tim -Inline Attachment Follows- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -Inline Attachment Follows- ___ 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] [PATCH] Android Support [3/4]
On Tue, 2010-04-20 at 11:16 +0200, Paolo Molaro wrote: > We must use feature checks and not platform checks as much as possible. The changes you outlined were commited to trunk (r155826) and the mono-2-6 branch (r155825). Thanks, - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Android Support [3/4]
Am 20.04.2010 um 11:16 schrieb Paolo Molaro: > On 04/19/10 Jonathan Pryor wrote: >> Index: mono/mini/exceptions-arm.c >> === >> --- mono/mini/exceptions-arm.c (revision 155735) >> +++ mono/mini/exceptions-arm.c (working copy) >> @@ -12,7 +12,11 @@ >> #include >> #include >> #include >> +#if defined(PLATFORM_ANDROID) >> +#include >> +#else >> #include >> +#endif > > Please make sure configure has the appropriate header checks and use: > > #ifdef HAVE_ASM_SIGCONTEXT_H > #include > #endif > #ifdef HAVE_UCONTEXT_H > #include > #endif > > We must use feature checks and not platform checks as much as > possible. +1. ucontext.h was dropped in POSIX.1-2008, so this is not just about Android. 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] Android Support [1/4]
Oops, meant to send this to the list. Just a quick question. I'm new to the mono build process - with these changes, how do you target the android platform when building mono/mcs? On Mon, Apr 19, 2010 at 1:44 PM, Jonathan Pryor wrote: > This is a series of patches to add support to Mono for building against > the Android NDK [0]. Android runs the Linux kernel, but moves many > things around compared to a "normal" desktop Linux distro. > > These patches are based against the mono-2-6 branch. > > This first patch patches eglib so that messages produced by g_print(), > g_printerr(), and g_log() are sent to the Android message log: > >* src/glib.h: Rebase g_return_if_fail(), g_return_val_if_fail() in > terms of g_critical() instead of printf, and turn g_printerr() > into > an actual function instead of a macro. >* src/goutput.c: Add Android support, sending g_print(), > g_printerr(), > and g_log() messages to the Android system log. > > Permission to commit? > > - Jon > > [0] http://developer.android.com/sdk/ndk/index.html > > > ___ > 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] [PATCH] Android Support [3/4]
On 04/19/10 Jonathan Pryor wrote:
> Index: mono/io-layer/collection.c
> ===
> --- mono/io-layer/collection.c(revision 155735)
> +++ mono/io-layer/collection.c(working copy)
> @@ -58,7 +58,10 @@
> ret = pthread_attr_init (&attr);
> g_assert (ret == 0);
>
> -#ifdef HAVE_PTHREAD_ATTR_SETSTACKSIZE
> +/* Android implements pthread_attr_setstacksize(), but errors out when using
> + * PTHREAD_STACK_MIN: http://code.google.com/p/android/issues/detail?id=7808
> + */
> +#if defined(HAVE_PTHREAD_ATTR_SETSTACKSIZE) && !defined(PLATFORM_ANDROID)
> if (set_stacksize == 0) {
> #if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
> ret = pthread_attr_setstacksize (&attr, 65536);
Instead of adding more checks there, just change the code to do:
ret = pthread_attr_setstacksize (&attr, MAX (65536, PTHREAD_STACK_MIN));
> Index: mono/io-layer/mono-mutex.c
> ===
> --- mono/io-layer/mono-mutex.c(revision 155735)
> +++ mono/io-layer/mono-mutex.c(working copy)
> @@ -22,11 +22,24 @@
>
>
> #ifndef HAVE_PTHREAD_MUTEX_TIMEDLOCK
> +/* Android does not implement pthread_mutex_timedlock(), but does provide an
> + * unusual declaration:
> http://code.google.com/p/android/issues/detail?id=7807
> + */
> +#if defined(PLATFORM_ANDROID)
> int pthread_mutex_timedlock (pthread_mutex_t *mutex,
> + struct timespec *timeout);
> +#else
> +int pthread_mutex_timedlock (pthread_mutex_t *mutex,
> const struct timespec *timeout);
> +#endif
Just do this at the start:
#ifdef PLATFORM_ANDROID
#define CONST_NEEDED const
#else
#define CONST_NEEDED const
#endif
And then insert CONST_NEEDED where appropriate instead of the ugly
duplication and ifdef mess.
> Index: mono/mini/exceptions-arm.c
> ===
> --- mono/mini/exceptions-arm.c(revision 155735)
> +++ mono/mini/exceptions-arm.c(working copy)
> @@ -12,7 +12,11 @@
> #include
> #include
> #include
> +#if defined(PLATFORM_ANDROID)
> +#include
> +#else
> #include
> +#endif
Please make sure configure has the appropriate header checks and use:
#ifdef HAVE_ASM_SIGCONTEXT_H
#include
#endif
#ifdef HAVE_UCONTEXT_H
#include
#endif
We must use feature checks and not platform checks as much as possible.
lupus
--
-
lu...@debian.org debian/rules
lu...@ximian.com Monkeys do it better
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
