Re: [Mono-dev] crash on exit with Mono 2.10.2 on Lioen
This is fixed in git by rodrigo iirc. -g On Fri, Jun 24, 2011 at 3:02 PM, Duane Wandless du...@wandless.net wrote: I am getting this exception on exit when using Lion and running the latest 2.10.2. I've tried calling Environment.Exit(0) and mono_jit_cleanup during app shutdown. But doing either of those leads to other exceptions. Hopefully there is a solution for this situation. Thanks, Duane 0 libmono-2.0.1.dylib 0x001da7ab mono_handle_native_sigsegv + 376 1 libmono-2.0.1.dylib 0x0023d11d sigabrt_signal_handler + 116 2 libsystem_c.dylib 0x9745059b _sigtramp + 43 3 ??? 0x 0x0 + 4294967295 4 libsystem_c.dylib 0x973ebbdd abort + 167 5 libmono-2.0.1.dylib 0x0038ad29 monoeg_g_logv + 197 6 libmono-2.0.1.dylib 0x0038ad5b monoeg_g_log + 44 7 libmono-2.0.1.dylib 0x00357486 _wapi_handle_unref_full + 1114 8 libmono-2.0.1.dylib 0x00355404 handle_cleanup + 199 9 libsystem_c.dylib 0x973eb944 __cxa_finalize + 243 10 libsystem_c.dylib 0x973eb7f2 exit + 25 11 AppKit 0x97d2e38a +[NSMenuItem initialize] + 0 12 AppKit 0x97ff832d -[NSApplication _terminateFromSender:askIfShouldTerminate:saveWindows:] + 435 13 AppKit 0x9847ef90 -[NSApplication(NSWindowCache) _checkForTerminateAfterLastWindowClosed:saveWindows:] + 167 14 AppKit 0x9847f5c1 __-[NSApplication(NSWindowCache) _scheduleCheckForTerminateAfterLastWindowClosed]_block_invoke_1 + 126 15 CoreFoundation 0x98ba6e96 _runLoopTimerWithBlockContext + 22 16 CoreFoundation 0x98b6b586 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22 17 CoreFoundation 0x98b6af17 __CFRunLoopDoTimer + 743 18 CoreFoundation 0x98b49f70 __CFRunLoopRun + 1888 19 CoreFoundation 0x98b4947c CFRunLoopRunSpecific + 332 20 CoreFoundation 0x98b49328 CFRunLoopRunInMode + 120 21 HIToolbox 0x96ebe4ab RunCurrentEventLoopInMode + 318 22 HIToolbox 0x96ec5d12 ReceiveNextEventCommon + 168 23 HIToolbox 0x96ec5c56 BlockUntilNextEventMatchingListInMode + 88 24 AppKit 0x97d27530 _DPSNextEvent + 678 25 AppKit 0x97d26d9c -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 113 26 AppKit 0x97d231a4 -[NSApplication run] + 897 27 AppKit 0x97fb5f55 NSApplicationMain + 1047 28 PIX 0xbbf5 main + 257 29 PIX 0x28fa start + 54 ___ 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] crash on exit with Mono 2.10.2 on Lioen
Is there a g_error printed prior to the crash? -g On Fri, Jun 24, 2011 at 3:12 PM, Duane Wandless du...@wandless.net wrote: I thought it was fixed with this commit: https://github.com/mono/mono/commit/2b487789c8e3dcc3fbbcb16bb0268f88718cf8d0 However, I'm using this code and still seeing the exception. Just now in _wapi_handle_unref_full. Duane On Fri, Jun 24, 2011 at 3:04 PM, Geoff Norton gro...@gmail.com wrote: This is fixed in git by rodrigo iirc. -g On Fri, Jun 24, 2011 at 3:02 PM, Duane Wandless du...@wandless.net wrote: I am getting this exception on exit when using Lion and running the latest 2.10.2. I've tried calling Environment.Exit(0) and mono_jit_cleanup during app shutdown. But doing either of those leads to other exceptions. Hopefully there is a solution for this situation. Thanks, Duane 0 libmono-2.0.1.dylib 0x001da7ab mono_handle_native_sigsegv + 376 1 libmono-2.0.1.dylib 0x0023d11d sigabrt_signal_handler + 116 2 libsystem_c.dylib 0x9745059b _sigtramp + 43 3 ??? 0x 0x0 + 4294967295 4 libsystem_c.dylib 0x973ebbdd abort + 167 5 libmono-2.0.1.dylib 0x0038ad29 monoeg_g_logv + 197 6 libmono-2.0.1.dylib 0x0038ad5b monoeg_g_log + 44 7 libmono-2.0.1.dylib 0x00357486 _wapi_handle_unref_full + 1114 8 libmono-2.0.1.dylib 0x00355404 handle_cleanup + 199 9 libsystem_c.dylib 0x973eb944 __cxa_finalize + 243 10 libsystem_c.dylib 0x973eb7f2 exit + 25 11 AppKit 0x97d2e38a +[NSMenuItem initialize] + 0 12 AppKit 0x97ff832d -[NSApplication _terminateFromSender:askIfShouldTerminate:saveWindows:] + 435 13 AppKit 0x9847ef90 -[NSApplication(NSWindowCache) _checkForTerminateAfterLastWindowClosed:saveWindows:] + 167 14 AppKit 0x9847f5c1 __-[NSApplication(NSWindowCache) _scheduleCheckForTerminateAfterLastWindowClosed]_block_invoke_1 + 126 15 CoreFoundation 0x98ba6e96 _runLoopTimerWithBlockContext + 22 16 CoreFoundation 0x98b6b586 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22 17 CoreFoundation 0x98b6af17 __CFRunLoopDoTimer + 743 18 CoreFoundation 0x98b49f70 __CFRunLoopRun + 1888 19 CoreFoundation 0x98b4947c CFRunLoopRunSpecific + 332 20 CoreFoundation 0x98b49328 CFRunLoopRunInMode + 120 21 HIToolbox 0x96ebe4ab RunCurrentEventLoopInMode + 318 22 HIToolbox 0x96ec5d12 ReceiveNextEventCommon + 168 23 HIToolbox 0x96ec5c56 BlockUntilNextEventMatchingListInMode + 88 24 AppKit 0x97d27530 _DPSNextEvent + 678 25 AppKit 0x97d26d9c -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 113 26 AppKit 0x97d231a4 -[NSApplication run] + 897 27 AppKit 0x97fb5f55 NSApplicationMain + 1047 28 PIX 0xbbf5 main + 257 29 PIX 0x28fa start + 54 ___ 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] Mono 2.8 (trunk) compiling on Mac OS X 10.6 (SL)
As per your output this isn't a mono issue, but a toolchain issue: checking for C compiler default output file name... configure: error: in `/Users/nmccready/Desktop/mono-20110416': configure: error: C compiler cannot create executables See `config.log' for more details. Have you checked the config.log for more details like it says? Geoff On 2011-04-16, at 10:30 PM, nmccready wrote: I am having the same problems on compiling too. nems-MacBook-Pro:mono-20110416 nmccready$ ./configure checking build system type... i386-apple-darwin10.7.0 checking host system type... i386-apple-darwin10.7.0 checking target system type... i386-apple-darwin10.7.0 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking how to create a ustar tar archive... gnutar checking whether to enable maintainer-specific portions of Makefiles... no checking whether ln -s works... yes checking host platform characteristics... ok checking for gcc... gcc checking for gcc... (cached) gcc checking for C compiler default output file name... configure: error: in `/Users/nmccready/Desktop/mono-20110416': configure: error: C compiler cannot create executables See `config.log' for more details. -- View this message in context: http://mono.1490590.n4.nabble.com/Mono-2-8-trunk-compiling-on-Mac-OS-X-10-6-SL-tp2133834p3454908.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-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.8 (trunk) compiling on Mac OS X 10.6 (SL)
Zoltan, This comes by default with Xcode, something is very broken with his setup. -g On 2011-04-17, at 12:51 PM, Zoltan Varga wrote: Hi, You probably need to install g++ too in addition to gcc. Zoltan On Sun, Apr 17, 2011 at 6:39 PM, Geoff Norton gnor...@novell.com wrote: As per your output this isn't a mono issue, but a toolchain issue: checking for C compiler default output file name... configure: error: in `/Users/nmccready/Desktop/mono-20110416': configure: error: C compiler cannot create executables See `config.log' for more details. Have you checked the config.log for more details like it says? Geoff On 2011-04-16, at 10:30 PM, nmccready wrote: I am having the same problems on compiling too. nems-MacBook-Pro:mono-20110416 nmccready$ ./configure checking build system type... i386-apple-darwin10.7.0 checking host system type... i386-apple-darwin10.7.0 checking target system type... i386-apple-darwin10.7.0 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking how to create a ustar tar archive... gnutar checking whether to enable maintainer-specific portions of Makefiles... no checking whether ln -s works... yes checking host platform characteristics... ok checking for gcc... gcc checking for gcc... (cached) gcc checking for C compiler default output file name... configure: error: in `/Users/nmccready/Desktop/mono-20110416': configure: error: C compiler cannot create executables See `config.log' for more details. -- View this message in context: http://mono.1490590.n4.nabble.com/Mono-2-8-trunk-compiling-on-Mac-OS-X-10-6-SL-tp2133834p3454908.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-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] AOT + the osx installer.
Hello, On 2011-01-25, at 4:39 PM, Brian Luczkiewicz wrote: When I build mono from source and install on linux, I've noticed that I end up with .so's next to some of the installed dll's and exe's. This provides a nice speedup when running compilers/tools from the mono distribution. Now that we have AOT working on osx, the same optimization makes sense there, too. I decided to try this out with mono 2.8.2 on an intel mac. I manually AOT'd: /Library/Frameworks/Mono.Framework/Versions/Current/lib/mono/*/*.exe /Library/Frameworks/Mono.Framework/Versions/Current/lib/mono/gac/*/*/*.dll I have a project that is about 500kloc of C# and builds with gmcs. AOT'ing the mono distribution as I've described dropped the build time for this project from 84s to 46s on my c2d macbook pro. This is a 44% speedup! This is great news, as we just recently enabled this. Was this with LLVM or with the regular AOT? -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Can't compile mono 2.8 for ARM Linux 2.6.24
This is already fixed. -g On 2011-01-14, at 12:15 AM, J.P. wrote: I cannot compile current mono in git. See below. AOT [basic] mscorlib.dll.so /bin/sh: line 1: 3231 Aborted MONO_PATH='./../../class/lib/basic/' /skcomms/src/mono/git/mono/runtime/mono-wrapper --aot=bind-to-runtime-version --debug ./../../class/lib/basic//mscorlib.dll basic_aot.log 21 /skcomms/src/mono/git/mono/libtool: line 6823: LC_CTYPE: command not found /skcomms/src/mono/git/mono/libtool: line 6823: LC_COLLATE: command not found /skcomms/src/mono/git/mono/libtool: line 6823: LC_MESSAGES: command not found Mono Ahead of Time compiler - compiling assembly /skcomms/src/mono/git/mono/mcs/class/lib/basic/mscorlib.dll * Assertion: should not be reached at boehm-gc.c:1150 Stacktrace: Native stacktrace: /skcomms/src/mono/git/mono/mono/mini/mono [0x4a831d] /lib64/libpthread.so.0 [0x38b300e7c0] /lib64/libc.so.6(gsignal+0x35) [0x38b2430265] /lib64/libc.so.6(abort+0x110) [0x38b2431d10] /skcomms/src/mono/git/mono/mono/mini/mono [0x5ee032] /skcomms/src/mono/git/mono/mono/mini/mono [0x5ee20a] /skcomms/src/mono/git/mono/mono/mini/mono [0x5bd3ea] /skcomms/src/mono/git/mono/mono/mini/mono [0x4c5ac1] /skcomms/src/mono/git/mono/mono/mini/mono [0x4c6d91] /skcomms/src/mono/git/mono/mono/mini/mono [0x42cdcd] /skcomms/src/mono/git/mono/mono/mini/mono [0x489cbc] /skcomms/src/mono/git/mono/mono/mini/mono [0x493be8] /skcomms/src/mono/git/mono/mono/mini/mono(mono_main+0x1449) [0x4845a9] /lib64/libc.so.6(__libc_start_main+0xf4) [0x38b241d994] /skcomms/src/mono/git/mono/mono/mini/mono(realloc+0x389) [0x423c09] Debug info from gdb: [Thread debugging using libthread_db enabled] [New Thread 0x2ad55d083910 (LWP 3231)] [New Thread 0x44c1b940 (LWP 3310)] [New Thread 0x44a07940 (LWP 3309)] [New Thread 0x44006940 (LWP 3307)] [New Thread 0x43605940 (LWP 3306)] [New Thread 0x42c04940 (LWP 3305)] [New Thread 0x42203940 (LWP 3304)] [New Thread 0x41802940 (LWP 3303)] [New Thread 0x40cb1940 (LWP 3302)] 0x0038b300d5cb in read () from /lib64/libpthread.so.0 9 Thread 0x40cb1940 (LWP 3302) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 8 Thread 0x41802940 (LWP 3303) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7 Thread 0x42203940 (LWP 3304) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 Thread 0x42c04940 (LWP 3305) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5 Thread 0x43605940 (LWP 3306) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x44006940 (LWP 3307) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 Thread 0x44a07940 (LWP 3309) 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2 Thread 0x44c1b940 (LWP 3310) 0x0038b300c9b1 in sem_wait () from /lib64/libpthread.so.0 * 1 Thread 0x2ad55d083910 (LWP 3231) 0x0038b300d5cb in read () from /lib64/libpthread.so.0 Thread 9 (Thread 0x40cb1940 (LWP 3302)): #0 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00604c0a in GC_wait_marker () at pthread_support.c:1863 #2 0x005f8b71 in GC_help_marker (my_mark_no=1) at mark.c:1116 #3 0x00603a02 in GC_mark_thread (id=0x0) at pthread_support.c:552 #4 0x0038b30064a7 in start_thread () from /lib64/libpthread.so.0 #5 0x0038b24d3c2d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x41802940 (LWP 3303)): #0 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00604c0a in GC_wait_marker () at pthread_support.c:1863 #2 0x005f8b71 in GC_help_marker (my_mark_no=1) at mark.c:1116 #3 0x00603a02 in GC_mark_thread (id=0x1) at pthread_support.c:552 #4 0x0038b30064a7 in start_thread () from /lib64/libpthread.so.0 #5 0x0038b24d3c2d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x42203940 (LWP 3304)): #0 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00604c0a in GC_wait_marker () at pthread_support.c:1863 #2 0x005f8b71 in GC_help_marker (my_mark_no=1) at mark.c:1116 #3 0x00603a02 in GC_mark_thread (id=0x2) at pthread_support.c:552 #4 0x0038b30064a7 in start_thread () from /lib64/libpthread.so.0 #5 0x0038b24d3c2d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x42c04940 (LWP 3305)): #0 0x0038b300ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00604c0a in GC_wait_marker () at pthread_support.c:1863 #2 0x005f8b71 in GC_help_marker (my_mark_no=1) at mark.c:1116 #3 0x00603a02 in
Re: [Mono-dev] Problem when running winforms app on arm processor
Matt, We cannot replicate this problem, so you'll need to help narrow down the field. Can you get the gdb output of x/6i code-16 when gdb is at tramp-arm.c line 48? Thanks -g On 2011-01-14, at 11:28 AM, Matt Johnson wrote: PLEA FOR URGENT HELP Almost 7 weeks and not a single response on this except to confirm that another is also having the problem. Is there no one that can shed light on what is going on here? I cannot run any winforms apps on an arm processor without hitting the assertion in tramp-arm.c. I am willing to help in any way I can, but I’m not an assembly language programmer, nor am I familiar with reasons behind the patching that is going on in the arm trampoline, so I really need some assistance. Thank You. Matt From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Matt Johnson Sent: Monday, January 03, 2011 10:24 AM To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Problem when running winforms app on arm processor No, I have no resolution yet. I have simplified my winforms test application such that it is a single form with a single text “hello world” label and no code logic whatsoever. It crashes in the exact same manner. One point I am unclear on is that I read in some old posts that the thumb instruction set is not supported. I am not compiling with thumb enabled, but I am using a toolchain that targets armv4t instead of straight armv4. I actually found it very difficult to even find an “non-t” toolchain out there – I’d have to compile one from scratch if this is the problem. I don’t see how it could be though. Especially since it is only winforms apps that are failing. Can someone with some expertise with the arm trampoline please chime in here? It is fairly urgent. Thanks, Matt From: Jae Kim [mailto:jkim0...@gmail.com] Sent: Friday, December 17, 2010 10:52 AM To: mj1856 Subject: Re: [Mono-dev] Problem when running winforms app on arm processor Hi Matt, Did you ever resolve this? I'm experiencing the same problem. Thanks, Jae On Mon, Nov 29, 2010 at 7:44 PM, mj1856 mj1...@hotmail.com wrote: I have cross compiled mono 2.8 with libgdiplus for the s3c2410 processor I am running. It is an arm920t (armv4t architecture). I use scratchbox with a recent codesourcery toolchain. I have two test applications that I wrote in visual studio targeting .net 2.0. The first is a console app with a basic Hello world. It works perfectly. The second is a winforms app with a single form that has a simple label that gets updated with a timer control to show the current date and time. (basically a digital clock). Running it, I get the following error: * Assertion: should not be reached at tramp-arm.c:48 Checking /mono/mini/tramp-arm.c, the function in question is mono_arch_patch_callsite, which has two blocks of code, where one of them is supposed to run. I'm not sure exactly what it's checking here, but neither block gets executed, so it hits the assertion. Can anyone shed some light on what might be the problem? One note that may or may not be of interest, but because the codesourcery toolchain is multilib, I have to specify -march=armv4t on the CFLAGS passed to configure mono. This appears to be working, as my console app works fine. I do have a running X server, which I've tested with other native apps, so I know at least that part is functional. Thanks, Matt -- View this message in context: http://mono.1490590.n4.nabble.com/Problem-when-running-winforms-app-on-arm-processor-tp3064820p3064820.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-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] Too many open files when adding many embedded resources
Tom,
If you .Close and .Dispose the stream, does the issue resolve itself?
-g
On 2010-12-14, at 7:24 PM, Tom Philpot wrote:
Building Mono 2.9 from git master, we're encountering an issue where an
assembly with lots of embedded resources (approx 4000), where gmcs is
throwing Too many open files exception.
The culprit seems to be that a new file handle is opened for every embedded
resource when it's added. Mono 2.6 doesn't have this problem, so it appears
to be a regression
Assembly.cs line 730:
if (res.IsEmbeded) {
var stream =
File.OpenRead (res.FileName);
module.Builder.DefineManifestResource (res.Name, stream, res.Attributes);
} else {
Builder.AddResourceFile
(res.Name, Path.GetFileName (res.FileName), res.Attributes);
}
___
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] windows.form regression with mono 2.8.1
It seems I introduced a regression, my apologies. I've commited a fix in 14f0ab6 and uploaded a hotfix to: http://sublimeintervention.com/mwf-hotfix.zip Download that file and unzip its contents to: /Library/Frameworks/Mono.framework/Versions/Current/lib/mono and it should resolve the issue. Please let me know if there are any further problems. -g On 2010-11-19, at 9:21 PM, Miguel de Icaza wrote: [Adding Geoff] Still, that doesn't explain the regression from 2.8 to 2.8.1... There were apparently no WinForms fixes, and the only Mac-specific change seems to be GetProcessById now works on Mac. There were a bunch of changes on commit 44dc98ddd17629a11fded1488e13cf5e30f2ae49 from Geoff precisely on the Graphics.cs file which is causing the nullref, precisely in the Dispose method. You can view the changes with: git show 44dc98ddd17629a11fded1488e13cf5e30f2ae49 Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] windows.form regression with mono 2.8.1
Fixed, sorry. -g On 2010-11-20, at 3:53 PM, st...@free.fr wrote: Geoff, The mwf-hotfix link seems to be dead. Could you please fix it? - Mail Original - De: Geoff Norton gnor...@novell.com À: Miguel de Icaza mig...@novell.com Cc: Stifu st...@free.fr, gnorton novell gnorton.nov...@gmail.com, mono-devel-list@lists.ximian.com Envoyé: Samedi 20 Novembre 2010 05:35:28 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [Mono-dev] windows.form regression with mono 2.8.1 It seems I introduced a regression, my apologies. I've commited a fix in 14f0ab6 and uploaded a hotfix to: http://sublimeintervention.com/mwf-hotfix.zip Download that file and unzip its contents to: /Library/Frameworks/Mono.framework/Versions/Current/lib/mono and it should resolve the issue. Please let me know if there are any further problems. -g On 2010-11-19, at 9:21 PM, Miguel de Icaza wrote: [Adding Geoff] Still, that doesn't explain the regression from 2.8 to 2.8.1... There were apparently no WinForms fixes, and the only Mac-specific change seems to be GetProcessById now works on Mac. There were a bunch of changes on commit 44dc98ddd17629a11fded1488e13cf5e30f2ae49 from Geoff precisely on the Graphics.cs file which is causing the nullref, precisely in the Dispose method. You can view the changes with: git show 44dc98ddd17629a11fded1488e13cf5e30f2ae49 Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-winforms-list] download mono winform from svs
Mono has moved to github: http://github.com/mono/mono -g On 2010-11-10, at 11:32 PM, slowhand wrote: New kid on the block, I tried to check out the mono winform from svs. How do I get past this barrier? Command: Checkout from svn://anonsvn.mono-project.com/source/trunk/mcs/class/Managed.Windows.Forms., revision HEAD, Fully recursive, Externals included Error: Can't connect to host 'anonsvn.mono-project.com': No connection could be made Error: because the target machine actively refused it. Finished!: -- View this message in context: http://mono.1490590.n4.nabble.com/download-mono-winform-from-svs-tp3037236p3037236.html Sent from the Mono - WinForms mailing list archive at Nabble.com. ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-dev] Mono Winforms on Mac (Carbon) fixes - all my source code changes attached
On 2010-10-07, at 9:33 PM, Bojan Rajkovic wrote: Hi Ralph, This sounds really cool, but my bet is that the WinForms maintainer is going to want to see it as smaller patch chunks, and preferably without whitespace/formatting changes (which it sounds like you have if you used Visual Studio's Format Document feature). Yes, this would be ideal, I've done a diff -w -u -r and there is a lot of noise in the patch, making it very difficult to seperate the signal. You may want to also fork Mono on Github and apply these patches to your fork (make the patch applications atomic, commit often, and document the commits appropriately), then send a pull request. In my experience, pull requests make it easier for the team to review what's changed and decide whether it's good to apply. This would be ideal. -g Of course, my opinions are not those of the WinForms maintainer, who may be happy to take your code as is—definitely wait for them before doing anything drastic. Regards, Bojan On Oct 7, 2010, at 12:56 PM, Ralph Leckett wrote: Hi All, Attached is a zip file of 54 classes that I modified to get Mono Winforms on Mac Carbon working with my .net application from hell. My apologies for using MS Visual Studio's Format Document on all of them. Ralph Leckett MonoLibs-Diff.zip___ 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-list] Patch for GC_stop_world bug in Android apps
Koush, Nice, can you please confirm on the list that you're willing to contribute this patch under the terms of the MIT/X11 license? Thanks -g On 2010-09-30, at 12:26 AM, Koushik Dutta wrote: Here is the fix for the following bug: https://bugzilla.novell.com/show_bug.cgi?id=633454 The underlying problem is there is a bug in Android's libc, where after a process forks, the kernel id of the forked thread is not changed to reflect the new child thread. The pthread kernel id still points to the kernel id of the parent process: zygote. This bug breaks all multithread monodroid apps (as well as my mono on Android port), as Garbage Collection fails and the process hangs. The fix/workaround for the bug in Android is as follows: The GC_Thread structure on Android has a new kernel_id member. When GC_new_thread is called, the kernel id is also retrieved and stored with gettid. When the world needs to be stopped/started, a new function android_thread_kill is called, which is a reimplementation of Android's pthread_kill. Instead, which takes the correct kernel id, rather than the potentially hosed pthread. I have attached a patch file, as well as committed to my fork of mono on Github: http://github.com/koush/mono/commit/414aff5598a2dea618741bea714fa8dd1baf0d52 pthread_android.patch___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Patch for GC_stop_world bug in Android apps
Great thanks, commited to master. -g On 2010-10-01, at 12:31 PM, Koushik Dutta wrote: I submit this patch under the terms of the MIT/X11 license On Fri, Oct 1, 2010 at 7:12 AM, Geoff Norton gnor...@novell.com wrote: Koush, Nice, can you please confirm on the list that you're willing to contribute this patch under the terms of the MIT/X11 license? Thanks -g On 2010-09-30, at 12:26 AM, Koushik Dutta wrote: Here is the fix for the following bug: https://bugzilla.novell.com/show_bug.cgi?id=633454 The underlying problem is there is a bug in Android's libc, where after a process forks, the kernel id of the forked thread is not changed to reflect the new child thread. The pthread kernel id still points to the kernel id of the parent process: zygote. This bug breaks all multithread monodroid apps (as well as my mono on Android port), as Garbage Collection fails and the process hangs. The fix/workaround for the bug in Android is as follows: The GC_Thread structure on Android has a new kernel_id member. When GC_new_thread is called, the kernel id is also retrieved and stored with gettid. When the world needs to be stopped/started, a new function android_thread_kill is called, which is a reimplementation of Android's pthread_kill. Instead, which takes the correct kernel id, rather than the potentially hosed pthread. I have attached a patch file, as well as committed to my fork of mono on Github: http://github.com/koush/mono/commit/414aff5598a2dea618741bea714fa8dd1baf0d52 pthread_android.patch___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] [Mono-osx] [Mono-list] Mono 2.8 Second Public Preview
I would start by building the port and running the test suite, there is at least one transient crash when compiling. Additionally, the mach support for sgen will need to be completed for amd64 Im sure there is more but thats probably going to uncover lots of work, off the top of my head On 2010-09-21, at 10:01 AM, Natalia Portillo wrote: Hi, If you guide me to the bugs I'll do my best, however I don't know what they are, where they are, or the mono codebase. Regards, Natalia Portillo El 21/09/2010, a las 03:31, Geoff Norton escribió: The x86-64 support for OSX is still unstable at this time, as it does have some transient bugs with it. Are you interested in contributing to stabalizing this port? I'm happy to review patches. -g On 2010-09-20, at 8:37 PM, Natalia Portillo wrote: Hi and congratulations, Will this version include x86-64 support on Mac OS X or that will stay in the unstable git? Regards, Natalia Portillo Claunia.com El 21/09/2010, a las 01:06, Andrew Jorgensen escribió: Tonight we publish the second (or third if you were watching closely) public preview of Mono 2.8[0]. To see what's been fixed since the first preview head over to github[6] and read the commits on mono-2-8 from d88e223dd4bd0469594e to 58f029f2d1a2ed2c3f16 (older to newer). We are still fixing a problem hitting breakpoints when remotely debugging using Mono Tools for Visual Studio but as far as we know that's the only bug holding back the final release of 2.8. If you find a bug please report it: http://www.mono-project.com/Bugs Also, the QA team asks that we put the string mono-2.8 (without quotes) in the whiteboard field on the bug report. Internally this is Preview 6, so mention that in your bugs. If you use mono on windows we strongly encourage you to do some testing now as we have not done a lot of testing on windows ourselves. Community power activate! There have been some further changes to the RPM spec file so packagers are again encouraged to peruse the spec on github[4]. [6] http://github.com/mono/mono/commits/mono-2-8 On Sat, 2010-09-11 at 16:30 +, Andrew Jorgensen wrote: Yesterday we published the first public preview[0] of Mono 2.8. This release contains many improvements and new features. Please refer to the draft release notes[1] for details. Linux builds include SGen[2] and LLVM[3] either or both of which can be enabled at runtime. [0] http://mono.ximian.com/monobuild/preview/download-preview/ [1] http://www.mono-project.com/Release_Notes_Mono_2.8 [2] http://www.mono-project.com/Compacting_GC [3] http://www.mono-project.com/Mono_LLVM If you find a bug please report it: http://www.mono-project.com/Bugs Packagers for distributions like Fedora are strongly encouraged to have a look at the mono-core.spec file[4] as there are a large number of new assemblies and we have rearranged a few packages to break cyclical dependencies etc.. [4] http://github.com/mono/mono/blob/mono-2-8/mono-core.spec.in The Mono Project is very much alive and a lot of work has gone into this release. We are positioning 2.8 as a sort of early version of what will eventually become Mono 3.0. The next release after 2.8 will be 2.8.2 which will be branched from Git master. This means that we will not be maintaining the mono-2-8 branch (except possibly for security fixes). We will continue in this fashion until 3.0 to allow developers to stay focused on their work and not maintain multiple branches. ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-osx mailing list mono-...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-osx ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-osx] [Mono-list] Mono 2.8 Second Public Preview
The x86-64 support for OSX is still unstable at this time, as it does have some transient bugs with it. Are you interested in contributing to stabalizing this port? I'm happy to review patches. -g On 2010-09-20, at 8:37 PM, Natalia Portillo wrote: Hi and congratulations, Will this version include x86-64 support on Mac OS X or that will stay in the unstable git? Regards, Natalia Portillo Claunia.com El 21/09/2010, a las 01:06, Andrew Jorgensen escribió: Tonight we publish the second (or third if you were watching closely) public preview of Mono 2.8[0]. To see what's been fixed since the first preview head over to github[6] and read the commits on mono-2-8 from d88e223dd4bd0469594e to 58f029f2d1a2ed2c3f16 (older to newer). We are still fixing a problem hitting breakpoints when remotely debugging using Mono Tools for Visual Studio but as far as we know that's the only bug holding back the final release of 2.8. If you find a bug please report it: http://www.mono-project.com/Bugs Also, the QA team asks that we put the string mono-2.8 (without quotes) in the whiteboard field on the bug report. Internally this is Preview 6, so mention that in your bugs. If you use mono on windows we strongly encourage you to do some testing now as we have not done a lot of testing on windows ourselves. Community power activate! There have been some further changes to the RPM spec file so packagers are again encouraged to peruse the spec on github[4]. [6] http://github.com/mono/mono/commits/mono-2-8 On Sat, 2010-09-11 at 16:30 +, Andrew Jorgensen wrote: Yesterday we published the first public preview[0] of Mono 2.8. This release contains many improvements and new features. Please refer to the draft release notes[1] for details. Linux builds include SGen[2] and LLVM[3] either or both of which can be enabled at runtime. [0] http://mono.ximian.com/monobuild/preview/download-preview/ [1] http://www.mono-project.com/Release_Notes_Mono_2.8 [2] http://www.mono-project.com/Compacting_GC [3] http://www.mono-project.com/Mono_LLVM If you find a bug please report it: http://www.mono-project.com/Bugs Packagers for distributions like Fedora are strongly encouraged to have a look at the mono-core.spec file[4] as there are a large number of new assemblies and we have rearranged a few packages to break cyclical dependencies etc.. [4] http://github.com/mono/mono/blob/mono-2-8/mono-core.spec.in The Mono Project is very much alive and a lot of work has gone into this release. We are positioning 2.8 as a sort of early version of what will eventually become Mono 3.0. The next release after 2.8 will be 2.8.2 which will be branched from Git master. This means that we will not be maintaining the mono-2-8 branch (except possibly for security fixes). We will continue in this fashion until 3.0 to allow developers to stay focused on their work and not maintain multiple branches. ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-osx mailing list mono-...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-osx ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling with NaCl support
NACL is only being developed on 32-bit x86 currently. -g On 2010-08-16, at 8:34 PM, Kannan Goundan wrote: I wanted to experiment a bit with Mono's NaCl support, but I can't get it to compile. Any hints? (The README says to use --enable-nacl and configure.in mentions --enabled-nacl-codegen, so I used both.) 1. I'm on Ubuntu 10.04, amd64. 2. I got Mono trunk from GitHub. 3. ./autogen.sh --prefix=/usr/local/stow/Mono-NaCl --enable-nacl-codegen --enable-nacl 4. make [... snip ...] LDlibmonosgen-static.la CCmono-main.o LDmono ./.libs/libmono-static.a(libmono_static_la-mini.o): In function `mono_nacl_fix_patches': /home/kannan/Develop/Mono/trunk/mono/mini/mini.c:230: undefined reference to `mono_arch_nacl_skip_nops' ./.libs/libmono-static.a(libmono_static_la-mini.o): In function `mono_nacl_pad_call': /home/kannan/Develop/Mono/trunk/mono/mini/mini.c:208: undefined reference to `mono_arch_nacl_pad' ./.libs/libmono-static.a(libmono_static_la-mini.o): In function `mono_nacl_align_inst': /home/kannan/Develop/Mono/trunk/mono/mini/mini.c:174: undefined reference to `mono_arch_nacl_pad' ./.libs/libmono-static.a(libmono_static_la-mini.o): In function `mono_nacl_align': /home/kannan/Develop/Mono/trunk/mono/mini/mini.c:221: undefined reference to `mono_arch_nacl_pad' ./.libs/libmono-static.a(libmono_static_la-mini.o): In function `mono_nacl_pad_call': /home/kannan/Develop/Mono/trunk/mono/mini/mini.c:216: undefined reference to `mono_arch_nacl_pad' collect2: ld returned 1 exit status make[4]: *** [mono] Error 1 make[4]: Leaving directory `/home/kannan/Develop/Mono/trunk/mono/mini' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/kannan/Develop/Mono/trunk/mono/mini' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/kannan/Develop/Mono/trunk/mono' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/kannan/Develop/Mono/trunk' make: *** [all] Error 2 ___ 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] Compiling with NaCl support
Cross compile mono for 32-bits? -g On 2010-08-16, at 9:02 PM, Kannan Goundan wrote: Is there any way to use my 64-bit host machine to generate 32-bit NaCl modules? On Mon, Aug 16, 2010 at 17:39, Geoff Norton gnor...@novell.com wrote: NACL is only being developed on 32-bit x86 currently. -g On 2010-08-16, at 8:34 PM, Kannan Goundan wrote: I wanted to experiment a bit with Mono's NaCl support, but I can't get it to compile. Any hints? (The README says to use --enable-nacl and configure.in mentions --enabled-nacl-codegen, so I used both.) 1. I'm on Ubuntu 10.04, amd64. 2. I got Mono trunk from GitHub. 3. ./autogen.sh --prefix=/usr/local/stow/Mono-NaCl --enable-nacl-codegen --enable-nacl 4. make [... snip ...] LD libmonosgen-static.la CC mono-main.o LD mono ./.libs/libmono-static.a(libmono_static_la-mini.o): In function `mono_nacl_fix_patches': /home/kannan/Develop/Mono/trunk/mono/mini/mini.c:230: undefined reference to `mono_arch_nacl_skip_nops' ./.libs/libmono-static.a(libmono_static_la-mini.o): In function `mono_nacl_pad_call': /home/kannan/Develop/Mono/trunk/mono/mini/mini.c:208: undefined reference to `mono_arch_nacl_pad' ./.libs/libmono-static.a(libmono_static_la-mini.o): In function `mono_nacl_align_inst': /home/kannan/Develop/Mono/trunk/mono/mini/mini.c:174: undefined reference to `mono_arch_nacl_pad' ./.libs/libmono-static.a(libmono_static_la-mini.o): In function `mono_nacl_align': /home/kannan/Develop/Mono/trunk/mono/mini/mini.c:221: undefined reference to `mono_arch_nacl_pad' ./.libs/libmono-static.a(libmono_static_la-mini.o): In function `mono_nacl_pad_call': /home/kannan/Develop/Mono/trunk/mono/mini/mini.c:216: undefined reference to `mono_arch_nacl_pad' collect2: ld returned 1 exit status make[4]: *** [mono] Error 1 make[4]: Leaving directory `/home/kannan/Develop/Mono/trunk/mono/mini' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/kannan/Develop/Mono/trunk/mono/mini' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/kannan/Develop/Mono/trunk/mono' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/kannan/Develop/Mono/trunk' make: *** [all] Error 2 ___ 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] github workflow proposals
On 2010-07-29, at 11:29 AM, Mark Probst wrote: On Wed, Jul 28, 2010 at 5:12 PM, Mark Probst mark.pro...@gmail.com wrote: If nobody else does it I'm volunteering - I really, really want to get rid of ChangeLogs :-) snip These will be put into the corresponding ChangeLog files. If a comment specifies files in directories with separate ChangeLogs, the comments will be put in each of them, but only with the relevant files in the comment. If there are no comments mentioning files for a particular ChangeLog in whose directory some file has been touched, then whatever comes before the first per-file comment will be put into that ChangeLog. In the extreme case (no per-file comments) that means the whole comment. Please see the test cases for details. Comments, suggestions? Is this enough to get rid of ChangeLog entries in commits? I think this looks great, but before we can get rid of them we probably need to integrate this into make dist so that its automatic, so we need some way of determining the start commit programatically if at all possible. Thoughts? -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Ximian-mono-list] github workflow proposals
On 2010-07-28, at 11:27 AM, Andreia Vidigal Gaita wrote: Dropping the per-file changes as a rule is not good, I think. Things won't be as well documented as they should be, and we'll end up having to dig through the commit itself to parse the code and try to understand which change does what. I'm all for detailed commit messages that give us as much information as possible. I'm not so sure I agree here, our commits by and large tend to be pretty atomic. Thats not to say that it cannot have unintended consequences, but you're going to need to understand the motivation behind the entire commit to fix an unintended consequence regardless to ensure that you dont go and break whatever the fix was for. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] The new world of Git -- what else can we change :-)
On 2010-07-28, at 10:52 AM, Miguel de Icaza wrote: In general I like the idea of cleaning this up a little bit, perhaps the idea of tags that was brought up on the list would allow us to keep the history in some form, while keeping branches useful. * Real release branches, these have value in that we can determine what we shipped when. The older the release, the lesser the value. * Work branches for code that was eventually merged: I could not find a single branch of these that was worth keeping around (C5, SAVANNAH_CVS, NUNIT, XIMIAN, anonymous-methods*, atsushi*, dick*, jb*, martin*, messaging*, mwf*, post*, sports-model, vargaz*) * Customer or specific port branches (mainsoft*, wii) If we go thru this cleanup process; what would happen with product based branches like monotouch? We could move it to a fork and keep the branch there, or keep it in mainline. I dont have an opinion either way. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] github workflow proposals
Github takes the first line from the commit message to build this page: http://github.com/mono/mono/commits/master I think we should modify our current commit messages to not just be the change log entries, but have a 1 line summary of the patch first like this: http://github.com/mono/mono/commit/5ab946450584e127878d7abbedeeca2688ef032f Additionally, I think we should implement a policy that all work branches are made in user forks; and the only people who should be making branches in the mainline github are QA for release managment practices. thoughts? -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On 2010-07-27, at 5:42 PM, Rodrigo Kumpera wrote: It doesn't make any sense to have work/feature branches on the central repository given we're using git. It's much easier and cleaner to simply have them on personal forks. One might not like dealing with extra remotes, but that would be a burnen only to mantainers merging code from contributors. Miguel has agreed with my suggestion, so I'll document this in more detail on the workflow changes page after dinner. I have another proposition to make. Can we stop using Changelog files? Those can be generated from the commit logs for tarballs and releases without losing anything at all. Commit messages would still have to be at least as informative as they currently are. Not having Changelog files resolve 90%+ of our sources of conflicts and make the forkqueue much more useful. If we are to move to a DVCS style of development, this will be a big barrier otherwise. I strongly support this as well, but in fact I'd like to suggest that we all strive to do a better job of commit messages. I'm guilty of this as much as anyone, but we have a lot of things that say Fix bla; without describing why its broken, or what the fix is. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On 2010-07-27, at 6:27 PM, Mark Probst wrote: On Tue, Jul 27, 2010 at 11:37 PM, Dale Ragan dale.ra...@sinesignal.com wrote: +1 on the commit message change I'd also like to vote, along with work branches be in user's forks, to use this model: http://nvie.com/git-model One detail I really like about this is the non-fast-forwarding merge for feature branches. This makes a whole lot of sense and I think we should adopt it - of course only for multi-commit features. Right, that is very nice. I dont think the development/master segmentation fits our workflow tho. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] github workflow proposals
On 2010-07-27, at 6:21 PM, Alan wrote: For commit messages, how about gnome style ones? http://live.gnome.org/Git/CommitMessages This is actually very nice. My only concern is maintaining the list of [Tag]'s. -g We'll end up with messages like this: http://github.com/mono/moon/commit/feadf070d237c1227ff2709cf1d0131d267118e2 :) Alan. On Tue, Jul 27, 2010 at 11:16 PM, Mark Probst mark.pro...@gmail.com wrote: On Tue, Jul 27, 2010 at 11:42 PM, Rodrigo Kumpera kump...@gmail.com wrote: I have another proposition to make. Can we stop using Changelog files? Those can be generated from the commit logs for tarballs and releases without losing anything at all. Commit messages would still have to be at least as informative as they currently are. Not having Changelog files resolve 90%+ of our sources of conflicts and make the forkqueue much more useful. If we are to move to a DVCS style of development, this will be a big barrier otherwise. I totally agree with this. A few days ago I wanted to merge a simple commit Sanjoy made, and the fork queue would have been perfect for this. Unfortunately it didn't grok the ChangeLog conflict, so I had to pull the change myself, rebase it on master and then push it by hand. I also agree with the one-line summaries and work branches in private repositories. Mark ___ 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-list] macosx --host=x86_64-apple-darwin10
64-bit support on OSX is only experimentally supported on SVN and Intel -g On 2010-07-21, at 11:45 AM, Sylvain Pointeau wrote: Hi, I am running in 64bits mode on my mac and I compiled everything in 64 bits. therefore now, I am obliged to compile Mono in 64b as well. I thought it will work to take the SVN version and to compile it with the configure below: ./configure --prefix=/user/local/mono270/ --host=x86_64-apple-darwin10 but I have this error then: /bin/sh ./libtool --mode=compile gcc -DPACKAGE_NAME=\libgc-mono\ -DPACKAGE_TARNAME=\libgc-mono\ -DPACKAGE_VERSION=\6.6\ -DPACKAGE_STRING=\libgc-mono\ 6.6\ -DPACKAGE_BUGREPORT=\hans_bo...@hp.com\ -DGC_DARWIN_THREADS=1 -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I./.. -I./include -no-cpp-precomp -D_THREAD_SAFE -DGC_MACOSX_THREADS -DPLATFORM_MACOSX -DUSE_MMAP -DUSE_MUNMAP -DGetCurrentProcess=MonoGetCurrentProcess -DGetCurrentThread=MonoGetCurrentThread -DCreateEvent=MonoCreateEvent -g -MT allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c -o allchblk.lo allchblk.c mkdir .libs gcc -DPACKAGE_NAME=\libgc-mono\ -DPACKAGE_TARNAME=\libgc-mono\ -DPACKAGE_VERSION=\6.6\ -DPACKAGE_STRING=\libgc-mono 6.6\ -DPACKAGE_BUGREPORT=\hans_bo...@hp.com\ -DGC_DARWIN_THREADS=1 -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I./.. -I./include -no-cpp-precomp -D_THREAD_SAFE -DGC_MACOSX_THREADS -DPLATFORM_MACOSX -DUSE_MMAP -DUSE_MUNMAP -DGetCurrentProcess=MonoGetCurrentProcess -DGetCurrentThread=MonoGetCurrentThread -DCreateEvent=MonoCreateEvent -g -MT allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c allchblk.c -fno-common -DPIC -o .libs/allchblk.o In file included from ./include/private/gc_priv.h:66, from allchblk.c:19: ./include/private/gcconfig.h:500: error: expected identifier or ‘(’ before ‘--’ token make[3]: *** [allchblk.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 the configure command gave me this summary: mcs source:$(top_srcdir)/mcs olive source: GC: included GLIB: system TLS: pthread SIGALTSTACK: no Engine:Building and using the JIT 2.0 Profile: yes Moon Profile: yes 4.0 Alpha: no MonoTouch: no JNI support: IKVM Native libgdiplus:assumed to be installed zlib: bundled zlib oprofile: no BigArrays: no DTrace:no Parallel Mark: Disabled_Currently_Hangs_On_MacOSX LLVM Back End: no and I took the tar.gz from http://mono.ximian.com/monobuild/snapshot/snapshot_sources/mono/mono-142439.tar.bz2 I saw this message from the how to build from source MACOSX If you wish to try the experimental 64-bit x86 support available in 2.7+ you should check out mono from svn and do: $ cd mono-trunk $ ./configure --prefix=DIR --with-glib=embedded --host=x86_64-apple-darwin10 $ make $ make install What should I do? is it possible to have it 64 bits? best regards, Sylvain ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] macosx --host=x86_64-apple-darwin10
You seem to have installed a bunch of weird dependencies into your environment. I suggest following the wiki with a clean environment. iconv is included with osx, eglib is the only support glib method on x86_64 darwin, etc. -g On 2010-07-21, at 2:06 PM, Sylvain Pointeau wrote: I re-installed libiconv on /usr/local/ and I run the command: CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./autogen.sh --prefix=/user/local/mono270/ --host=x86_64-apple-darwin10 I had a message saying I should not use host but build? do you have an idea? what are the value I can put? same as host? but I made make, seems to run now. is it correct? Best regards, Sylvain On Wed, Jul 21, 2010 at 6:45 PM, Geoff Norton gnor...@novell.com wrote: You dont; only eglib is supported on x86-64; libiconv is shipped with apples compiler tho; so you'll need to figure out whats wrong with your environment. -g On 2010-07-21, at 12:41 PM, Sylvain Pointeau wrote: I just made svn co http://anonsvn.mono-project.com/source/trunk/mono ./autogen.sh --prefix=/user/local/mono270/ --host=x86_64-apple-darwin10 make I have: Undefined symbols: _libiconv_open, referenced from: _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o) _libiconv_close, referenced from: _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o) _libiconv, referenced from: _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o) ld: symbol(s) not found How to force it by taking the glib2 in my /usr/local/ ? Many thanks for your help, Sylvain ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] macosx --host=x86_64-apple-darwin10
On 2010-07-21, at 2:23 PM, Sylvain Pointeau wrote: that's strange ... how can I introduce dependencies in my system? make ended with an error: sgen-os-mach.c: In function ‘mono_sgen_thread_handshake’: sgen-os-mach.c:101: warning: implicit declaration of function ‘UCONTEXT_GREGS’ sgen-os-mach.c:101: warning: nested extern declaration of ‘UCONTEXT_GREGS’ sgen-os-mach.c:101: error: ‘REG_RAX’ undeclared (first use in this function) sgen-os-mach.c:101: error: (Each undeclared identifier is reported only once sgen-os-mach.c:101: error: for each function it appears in.) sgen-os-mach.c:101: error: ‘REG_RBX’ undeclared (first use in this function) sgen-os-mach.c:101: error: ‘REG_RCX’ undeclared (first use in this function) sgen-os-mach.c:101: error: ‘REG_RDX’ undeclared (first use in this function) sgen-os-mach.c:101: error: ‘REG_RSI’ undeclared (first use in this function) sgen-os-mach.c:101: error: ‘REG_RDI’ undeclared (first use in this function) sgen-os-mach.c:101: error: ‘REG_RBP’ undeclared (first use in this function) sgen-os-mach.c:101: error: ‘REG_R8’ undeclared (first use in this function) sgen-os-mach.c:101: error: ‘REG_R9’ undeclared (first use in this function) sgen-os-mach.c:101: error: ‘REG_R10’ undeclared (first use in this function) sgen-os-mach.c:101: error: ‘REG_R11’ undeclared (first use in this function) sgen-os-mach.c:101: error: ‘REG_R12’ undeclared (first use in this function) sgen-os-mach.c:101: error: ‘REG_R13’ undeclared (first use in this function) sgen-os-mach.c:101: error: ‘REG_R14’ undeclared (first use in this function) sgen-os-mach.c:101: error: ‘REG_R15’ undeclared (first use in this function) make[3]: *** [libmonoruntimesgen_la-sgen-os-mach.lo] Error 1 This will be fixed in svn shortly. I installed: boost cmake git Qt readline sqlite icu for compiling mono, I installed gettext 0.18.1.1 libiconv 1.13.1 glib-2.24.1 You shouldn't have installed any of these as they aren't needed, and not supported on x86-64 darwin. -g ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] macosx --host=x86_64-apple-darwin10
Please follow the directions on the wiki: http://www.mono-project.com/Compiling_Mono_on_OSX pkg-config is required, pass ---enable-nls=no if you want to not have gettext which is an optional dep. glib2 and libiconv are not. -g On 2010-07-21, at 3:28 PM, Sylvain Pointeau wrote: On Wed, Jul 21, 2010 at 9:21 PM, Sylvain Pointeau sylvain.point...@gmail.com wrote: On Wed, Jul 21, 2010 at 9:03 PM, Sylvain Pointeau sylvain.point...@gmail.com wrote: for compiling mono, I installed gettext 0.18.1.1 libiconv 1.13.1 glib-2.24.1 You shouldn't have installed any of these as they aren't needed, and not supported on x86-64 darwin. I listened to you, then I uninstall all of them... I rerun the command: ./autogen.sh --prefix=/user/local/mono64/ --build=x86_64-apple-darwin10 then I have the error: configure: error: msgfmt not found. You need to install the 'gettext' package, or pass --enable-nls=no to configure. Should I put the option --enable-nls=no then? I just removed also pkg-config... and I have now: configure: error: You need to install pkg-config configure: error: ./configure failed for eglib Are you sure I should not install those tools? Best regards, Sylvain ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] macosx --host=x86_64-apple-darwin10
You didn't checkout mcs; -g On 2010-07-21, at 4:41 PM, Sylvain Pointeau wrote: On Wed, Jul 21, 2010 at 9:31 PM, Geoff Norton gnor...@novell.com wrote: Please follow the directions on the wiki: http://www.mono-project.com/Compiling_Mono_on_OSX pkg-config is required, pass ---enable-nls=no if you want to not have gettext which is an optional dep. glib2 and libiconv are not. -g it does not describe how to build the SVN... furthermore I don't understand the error I have : if test -w ; then :; else chmod -R +w ; fi cd make NO_DIR_CHECK=1 PROFILES='net_2_0 net_3_5 net_4_0 ' CC='gcc' all-profiles make[3]: *** No rule to make target `all-profiles'. Stop. make[2]: *** [all-local] Error 2 ... Best regards, Sylvain ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] macosx --host=x86_64-apple-darwin10
http://mono-project.com/Compiling_Mono_From_SVN On 2010-07-21, at 5:32 PM, Sylvain Pointeau wrote: On Wed, Jul 21, 2010 at 11:27 PM, Geoff Norton gnor...@novell.com wrote: You didn't checkout mcs; -g right! I was just seeing now the next error... mkdir -p -- build/deps touch build/deps/.stamp make[6]: gmcs: No such file or directory make[6]: *** [build/deps/basic-profile-check.exe] Error 1 *** The compiler 'gmcs' doesn't appear to be usable. *** You need Mono version 2.4 or better installed to build MCS *** Read INSTALL.txt for information on how to bootstrap a Mono installation. make[5]: *** [do-profile-check] Error 1 make[4]: *** [profile-do--basic--all] Error 2 make[3]: *** [profiles-do--all] Error 2 Cheers, Sylvain ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] PATCH: Don't suspend Mach exception thread when stopping the world
Looks fine to me. Thanks Mark -g On 2010-07-09, at 6:51 PM, Mark Probst wrote: The mono_sgen_is_worker_thread() will be needed soon when SGen actually uses worker threads, for parallel mark and concurrent sweep. Please review, Geoff. Mark sgen-darwin-exception-thread ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Why GIT?
We are moving to github as our primary repo, which means people can continue to use svn via their svn bridge, or all the associated web tools. -g On 2010-07-01, at 3:09 PM, Teravus Ovares wrote: Going the Git route, I'd suggest you set up a github account and have a github mirror. Git is... complicated.And, while, advanced developers can appreciate the things that make it nice. Beginner developers see it as a huge hurdle to get over to contribute. One of the things that helps with Git transitions is advanced tools such as GitHub. The other thing that helps is 'how to do x' for people used to subversion.Even with all of this in place, you're still probably going to see a decrease in contributions from the individual in the community. You may see more organizations contributing though if most of your contributions comes from organizations since it's easier to merge. Regards Teravus On Thu, Jul 1, 2010 at 1:26 AM, Miguel de Icaza mig...@novell.com wrote: Hello Amir, I was wondering if you can elaborate on why/how you chose GIT for future source control of Mono? With a lot of options out there, I'm just wanting a peek at some of your or the Mono team's thoughts when evaluating other VCS. Maybe a post on your blog is due :) I am afraid I do not have a great answer to that question. It was mostly inertia from the rest of the team. I do not mind subversion myself and find it very simple to use. But some members in the team have started using svn2git and keeping their own repositories around, so we kind of gravitated there. Miguel. ___ 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] Mono Contributors, Action required: Preparing the Subversion to GIT Migration
On 2010-06-30, at 10:33 AM, Miguel de Icaza wrote: Yes, it will. They also have a Subversion bridge that lets you checkout with svn. And commit now. -g --- On Tue, 6/29/10, Miguel de Icaza mig...@novell.com wrote: From: Miguel de Icaza mig...@novell.com Subject: [Mono-dev] Mono Contributors, Action required: Preparing the Subversion to GIT Migration To: mono-devel-list mono-devel-list@lists.ximian.com, Mono Announce mono-announce-l...@lists.ximian.com, mono-l...@lists.ximian.com Date: Tuesday, June 29, 2010, 4:27 PM Hello guys, As part of our migration from Subversion to GIT, we need all Mono contributors to get a GitHub account and provide your Mono SVN account and your new GitHub account name here: http://spreadsheets.google.com/viewform?hl=enformkey=dEdpdTFoNHBwUUI0clVLRFJtTC02N0E6MQ#gid=0 ___ 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-dev] armv6+ atomics / thumb support
I've just commited support for armv6+ processors to the mono runtime in r159690 and r159691. While mono has worked on these processors for quite some time, we relied on the deprecated swp instruction. When compiling for armv6+ now we will use ldrex/strex which allows us to work on processors which do not have (or emulate) swp, and additionally the runtime can be compiled in thumb mode. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] altstack for osx
Attached is a patch which enables sigaltstack for OSX (x86 and amd64). The configure.in check passes on amd64 and fails on x86 for some reason (the signal isn't delivered to the child ?) but the support appears to work correctly on both. Comments? -g altstack-osx.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] altstack for osx
On 2010-06-23, at 7:02 PM, Miguel de Icaza wrote: Hello, Attached is a patch which enables sigaltstack for OSX (x86 and amd64). It seems to alter other operating systems with some of the changes (the patch in threads.c) Correct, this function was incorrect for systems which have: #if defined(HAVE_PTHREAD_GET_STACKSIZE_NP) defined(HAVE_PTHREAD_GET_STACKADDR_NP) which is where the block is localized. mono_thread_get_stack_bounds is asking for the stack bottom, and we were returning the stack top, which is what pthread_get_stackaddr_np does. -g The configure.in check passes on amd64 and fails on x86 for some reason (the signal isn't delivered to the child ?) but the support appears to work correctly on both. Comments? -g ___ 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] Arm9 NS9215 floating point troubles
The change you posted is certainly not correct as soft float works on
all our dev boards. Could you send us the contents of /process/cpuinfo
please?
On Friday, June 18, 2010, Trevor Ackerman t_acker...@yahoo.com wrote:
I believe it is armel, here's what 'file' reports for a natively compiled C
program.
hello_world_c: ELF 32-bit LSB executable, ARM, version 1, dynamically linked
(uses shared libs), not stripped.
Let me know if you still believe it is a bug and how I may contribute a
solution, whether the example change I posted is appropriate or not.
Thanks
--- On Thu, 6/17/10, Geoff Norton gnor...@novell.com wrote:
From: Geoff Norton gnor...@novell.com
Subject: Re: [Mono-dev] Arm9 NS9215 floating point troubles
To: Trevor Ackerman t_acker...@yahoo.com
Cc: mono-devel-list@lists.ximian.com
Date: Thursday, June 17, 2010, 9:54 PM
Is your system armeb or
armel?
It could be a endian bug in our softfloat impl somewhere.
-g
On 2010-06-17, at 7:54 PM, Trevor Ackerman wrote:
I have more to report.
I wrote a quick native C program to print out the bytes of a float and double
variable that were assigned the literal value 1.0f.
Then in the mono 2.6.4 routine mono_method_to_ir in source code file
mono/mini/method_to_ir.c I dumped out the bytes of ip (instruction pointer)
used for the double value in the case for CEE_LDC_R8.
I discovered that the bytes in the double value used on mono had the high and
low 32 bits swapped compared to those produced by the native C program. I
hacked the routine decompose_soft_float to swap the high and low
words and now I have no troubles and the basic-float regression test passes
100%.
Although this happens to work, I have a hard time believing that this is the
correct solution to my problem. I feel that others are probably using ARM9
without
floating point issues and that I am probably missing something in how I
built mono for my platform. If anyone can shed some light on what I did wrong
with building mono that'd be great. Of course if this is the correct action
to take please let me know that too and how I may contribute the change back
to the trunk (assuming that the trunk doesn't work which I haven't had time
to test yet).
In the meantime here's my hack to decompose_soft_float in method-to-ir.c
5073 case OP_R8CONST: {
5074 unsigned char *ucp = (unsigned char *) ins-inst_p0;
5075 unsigned char
rawval[8];
5076 printf(decompose_soft_float OP_R8CONST\n);
5077 rawval[0] =
ucp[4];
5078 rawval[1] = ucp[5];
5079 rawval[2] = ucp[6];
5080 rawval[3] = ucp[7];
5081 rawval[4] = ucp[0];
5082 rawval[5] = ucp[1];
5083 rawval[6] = ucp[2];
5084 rawval[7] = ucp[3];
5085 DVal d;
5086
// d.vald = *(double*)ins-inst_p0;
5087 d.vald = *(double*)rawval;
5088 MONO_EMIT_NEW_I8CONST (cfg, ins-dreg, d.vall);
5089 break;
5090 }
--- On Thu, 6/17/10, Trevor Ackerman
t_acker...@yahoo.com http://mc/compose?to=t_acker...@yahoo.com wrote:
From: Trevor Ackerman
t_acker...@yahoo.com http://mc/compose?to=t_acker...@yahoo.com
Subject: Re: [Mono-dev] Arm9 NS9215 floating point troubles
To: mono-devel-list@lists.ximian.com
Date: Thursday, June 17, 2010, 11:31 AM
Good suggestion but that did not change the results.
--- On Thu, 6/17/10, Robert Jordan
robe...@gmx.net http://mc/compose?to=robe...@gmx.net wrote:
From: Robert Jordan robe...@gmx.net http://mc/compose?to=robe...@gmx.net
Subject: Re: [Mono-dev] Arm9 NS9215 floating point troubles
To: mono-devel-list@lists.ximian.com
Date: Thursday, June 17, 2010, 10:53 AM
On 17.06.2010 18:07, Trevor Ackerman wrote:
I have been able to cross-compile Mono 2.6.4 for the NS9215 (no fpu
afaik) and I'm having trouble with floats when executing
code.
...
My CFLAGS and CPPFLAGS environment variables are
both
-DARM_FPU_NONE=1 -DMONO_ARCH_SOFT_FLOAT=1
-DNO_UNALIGNED_ACCESS is probably needed as
well.
Robert
___
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] mach kernel support for sgen
This time with the actual patch.-g sgen-mach.diff Description: Binary data On 2010-06-17, at 11:56 PM, Geoff Norton wrote:On 2010-06-17, at 7:01 PM, Zoltan Varga wrote:Hi, It would be nice to have at least the larger Mach-centric parts in a separate file sgen-mach.c, or sgen-os-mach.c. The whole thread_handshake() function should go there. I'm taking every opportunity to split the huge sgen-gc.c file into more managable chunks. I think that should start with putting the definitions into a header file, instead of include-ing.c files into each other, which is kinda gross.Here's an updated patch reflecting Mark's changes and _starting_ the move into header files rather than #include-ing the .c's in. Things are still a ugly in that regard, but this should put us on the right path.Comments?-g___Mono-devel-list mailing listMono-devel-list@lists.ximian.comhttp://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-dev] mach kernel support for sgen
I learned recently that one of our long standing issues one mach kernels (darwin specifically) that we chalked up to a bug in their implementation (specifically signal coalescing) is in fact a unfounded assumption by us. Guaranteeing 1 deliver per signal, (and infact the sem_init issue that plagued us historically) is only guaranteed for RT signals in POSIX Realtime Extension. As such I've started undertaking to move our runtime away from signals for thread managment on darwin and to use mach ports instead. With some help from Rodrigo, I got sgen playing nicely with mach ports last night for STW. This cuts about 50% off our sys time doing GC intensive benchmarks. I've introduced a new set of helpers into utils for mach support and arch specific backends for x86 and amd64. It currently is only tested on apple, and certainly wont work anywhere else due to mono_mach_arch_get_tls_value_from_thread being 100% apple specific. Once we figure out what changes the runtime team would like to see I'll look at porting it to arm. After getting these changes incubated, I'd like to start looking at moving our Thread.Abort/Interrupt/Suspend semantics to mach ports, as well as sdb's STW semantics. Comments? sgen-mach.diff Description: Binary data -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arm9 NS9215 floating point troubles
Trevor,
I tested your testcase on a:
Processor : ARMv7 Processor rev 0 (v7l)
Features: swp half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16
I tested:
Mono JIT compiler version 2.4.2.3 (Debian 2.4.2.3+dfsg-2)
Architecture: armel,soft-float
Mono JIT compiler version 2.7 (/trunk/mono r158961 Tue Jun 15 17:26:35 EDT 2010)
Architecture: armel,vfp
Mono JIT compiler version 2.7 (/trunk/mono r158961 Thu Jun 17 13:58:00 EDT 2010)
Architecture: armel,soft-float
and all 3 produce the correct results. I dont have a 2.6.4 build handy, but
nothing really significant in this regard has changed. Could you try trunk?
It might be something else with your board as well.
-g
On 2010-06-17, at 12:07 PM, Trevor Ackerman wrote:
I have been able to cross-compile Mono 2.6.4 for the NS9215 (no fpu afaik)
and I'm having trouble with floats when executing code.
I thought I had correctly specified soft-float and indeed mono tells me so
~ # /usr/local/bin/mono -V
Mono JIT compiler version 2.6.4 (tarball Wed Jun 16 14:55:33 MDT 2010)
Copyright (C) 2002-2010 Novell, Inc and Contributors. www.mono-project.com
TLS: normal
GC:Included Boehm (with typed GC and Parallel Mark)
SIGSEGV: normal
Notifications: epoll
Architecture: arm,soft-float
Disabled: none
~ #
However the following code produces grossly wrong results
using System;
public class FloatTest
{
static public void Main()
{
Console.WriteLine(0.0f literal is + 0.0f);
Console.WriteLine(1.0f literal is + 1.0f);
Console.WriteLine(12.3f literal is + 12.3f);
Console.WriteLine(32f literal is + 32f);
Console.WriteLine(1024f literal is + 1024f);
Console.WriteLine(32768f literal is + 32768f);
}
}
Here are the results
~ # /usr/local/bin/mono FloatTest.exe
0.0f literal is 0
1.0f literal is 5.299809E-315
12.3f literal is -1.491669E-154
32f literal is 5.325712E-315
1024f literal is 5.351615E-315
32768f literal is 5.377519E-315
my configure command is
./configure --host=arm-linux --with-tls=pthread --with-moonlight=no
--with-mcs-docs=no
summary from running config is
mcs source:$(top_srcdir)/mcs
olive source:
GC:included
GLIB: system
TLS: pthread
SIGALTSTACK: yes
Engine:Building and using the JIT
2.0 Profile: yes
Moon Profile: no
4.0 Alpha: no
MonoTouch: no
JNI support: IKVM Native
libgdiplus:assumed to be installed
zlib: system zlib
oprofile: no
BigArrays: no
DTrace:no
Parallel Mark: yes
LLVM Back End: no
My CFLAGS and CPPFLAGS environment variables are both
-DARM_FPU_NONE=1 -DMONO_ARCH_SOFT_FLOAT=1
Any insight would be greatly appreciated, I've looked at some of the code in
the mono/mini directory but cannot make sense of how float values are getting
generated.
TIA
___
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] mach kernel support for sgen
The boehm GC already uses mach ports for suspend/resume. -g On 2010-06-17, at 4:26 PM, Tom Philpot wrote: Would any of these changes make a difference on the currently shipping garbage collector? Is this something that could be back-ported? Thanks, Tom On Jun 17, 2010, at 7:54 AM, Geoff Norton wrote: I learned recently that one of our long standing issues one mach kernels (darwin specifically) that we chalked up to a bug in their implementation (specifically signal coalescing) is in fact a unfounded assumption by us. Guaranteeing 1 deliver per signal, (and infact the sem_init issue that plagued us historically) is only guaranteed for RT signals in POSIX Realtime Extension. As such I've started undertaking to move our runtime away from signals for thread managment on darwin and to use mach ports instead. With some help from Rodrigo, I got sgen playing nicely with mach ports last night for STW. This cuts about 50% off our sys time doing GC intensive benchmarks. I've introduced a new set of helpers into utils for mach support and arch specific backends for x86 and amd64. It currently is only tested on apple, and certainly wont work anywhere else due to mono_mach_arch_get_tls_value_from_thread being 100% apple specific. Once we figure out what changes the runtime team would like to see I'll look at porting it to arm. After getting these changes incubated, I'd like to start looking at moving our Thread.Abort/Interrupt/Suspend semantics to mach ports, as well as sdb's STW semantics. Comments? sgen-mach.diffATT1..txtATT2..txt ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] arm support for sgen
On 2010-06-17, at 4:25 PM, Mark Probst wrote: On Thu, Jun 17, 2010 at 10:02 PM, Geoff Norton gnor...@novell.com wrote: I finished up arm support for sgen this morning. Attached is a patch which implements support for linux/arm and darwin/arm, but I've only tested linux/arm so far. Awesome! Looks good to me. Commited, thanks mark. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arm9 NS9215 floating point troubles
Is your system armeb or armel?
It could be a endian bug in our softfloat impl somewhere.
-g
On 2010-06-17, at 7:54 PM, Trevor Ackerman wrote:
I have more to report.
I wrote a quick native C program to print out the bytes of a float and double
variable that were assigned the literal value 1.0f.
Then in the mono 2.6.4 routine mono_method_to_ir in source code file
mono/mini/method_to_ir.c I dumped out the bytes of ip (instruction pointer)
used for the double value in the case for CEE_LDC_R8.
I discovered that the bytes in the double value used on mono had the high and
low 32 bits swapped compared to those produced by the native C program. I
hacked the routine decompose_soft_float to swap the high and low words and
now I have no troubles and the basic-float regression test passes 100%.
Although this happens to work, I have a hard time believing that this is the
correct solution to my problem. I feel that others are probably using ARM9
without floating point issues and that I am probably missing something in how
I built mono for my platform. If anyone can shed some light on what I did
wrong with building mono that'd be great. Of course if this is the correct
action to take please let me know that too and how I may contribute the
change back to the trunk (assuming that the trunk doesn't work which I
haven't had time to test yet).
In the meantime here's my hack to decompose_soft_float in method-to-ir.c
5073 case OP_R8CONST: {
5074 unsigned char *ucp = (unsigned char *) ins-inst_p0;
5075 unsigned char rawval[8];
5076 printf(decompose_soft_float OP_R8CONST\n);
5077 rawval[0] = ucp[4];
5078 rawval[1] = ucp[5];
5079 rawval[2] = ucp[6];
5080 rawval[3] = ucp[7];
5081 rawval[4] = ucp[0];
5082 rawval[5] = ucp[1];
5083 rawval[6] = ucp[2];
5084 rawval[7] = ucp[3];
5085 DVal d;
5086 // d.vald = *(double*)ins-inst_p0;
5087 d.vald = *(double*)rawval;
5088 MONO_EMIT_NEW_I8CONST (cfg, ins-dreg, d.vall);
5089 break;
5090 }
--- On Thu, 6/17/10, Trevor Ackerman t_acker...@yahoo.com wrote:
From: Trevor Ackerman t_acker...@yahoo.com
Subject: Re: [Mono-dev] Arm9 NS9215 floating point troubles
To: mono-devel-list@lists.ximian.com
Date: Thursday, June 17, 2010, 11:31 AM
Good suggestion but that did not change the results.
--- On Thu, 6/17/10, Robert Jordan robe...@gmx.net wrote:
From: Robert Jordan robe...@gmx.net
Subject: Re: [Mono-dev] Arm9 NS9215 floating point troubles
To: mono-devel-list@lists.ximian.com
Date: Thursday, June 17, 2010, 10:53 AM
On 17.06.2010 18:07, Trevor Ackerman wrote:
I have been able to cross-compile Mono 2.6.4 for the NS9215 (no fpu
afaik) and I'm having trouble with floats when executing code.
...
My CFLAGS and CPPFLAGS environment variables are
both
-DARM_FPU_NONE=1 -DMONO_ARCH_SOFT_FLOAT=1
-DNO_UNALIGNED_ACCESS is probably needed as well.
Robert
___
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
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mach kernel support for sgen
On 2010-06-17, at 7:01 PM, Zoltan Varga wrote: Hi, It would be nice to have at least the larger Mach-centric parts in a separate file sgen-mach.c, or sgen-os-mach.c. The whole thread_handshake() function should go there. I'm taking every opportunity to split the huge sgen-gc.c file into more managable chunks. I think that should start with putting the definitions into a header file, instead of include-ing .c files into each other, which is kinda gross. Here's an updated patch reflecting Mark's changes and _starting_ the move into header files rather than #include-ing the .c's in. Things are still a ugly in that regard, but this should put us on the right path. Comments? -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] _wapi_connect stuck in poll()
Can you try this patch?
-g
poll-fix.diff
Description: Binary data
On 2010-05-25, at 3:05 PM, yoni shalom wrote:
Tested on Mono 2.4.2.3, 2.6.x
Both leopard and snow leopard.
It seems as though _sometime_ (ranges from 0 to 5 out of 50) threads
that are in the middle of performing Socket.Connect() on which
Thread.Abort() is called, never exit and cause the thread to leak
and be stuck indefinitely.
The offending thread is stuck in
Socket.Connect()-Connect_internal-_wapi_connect-poll().
I'm attaching a test program - just let it run, wait for 30 seconds
and then in gdb display all stacks ( t apply all bt ) and you will see
the threads stuck in ves_blabla_Connect_Internal()
The code I'm talking about is this (mono/io-layer/sockets.c) :
while (poll (fds, 1, -1) == -1
!_wapi_thread_cur_apc_pending ()) {
if (errno != EINTR) {
errnum = errno_to_WSA (errno, __func__);
#ifdef DEBUG
g_message (%s: connect poll error: %s,
__func__, strerror (errno));
#endif
WSASetLastError (errnum);
return(SOCKET_ERROR);
}
}
I've been trying to debug this code without much luck understanding
what is special to the misbehaving scenario...
A change in the first line of code, allowing for a timeout of 3
seconds in the poll syscall (not sure how correct this is), seems to
solve the problem for me.
int prslt;
while(((prslt = poll(fds, 1, 3000)) == 0) || (prslt == -1
!_wapi_thread_cur_apc_pending()) {
...
Obviously this is not optimal, and as such - is not a solution
proposal but just additional info.
BeginConnect.zip___
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-list] [Mono-dev] _wapi_connect stuck in poll()
Can you try this patch?
-g
poll-fix.diff
Description: Binary data
On 2010-05-25, at 3:05 PM, yoni shalom wrote:
Tested on Mono 2.4.2.3, 2.6.x
Both leopard and snow leopard.
It seems as though _sometime_ (ranges from 0 to 5 out of 50) threads
that are in the middle of performing Socket.Connect() on which
Thread.Abort() is called, never exit and cause the thread to leak
and be stuck indefinitely.
The offending thread is stuck in
Socket.Connect()-Connect_internal-_wapi_connect-poll().
I'm attaching a test program - just let it run, wait for 30 seconds
and then in gdb display all stacks ( t apply all bt ) and you will see
the threads stuck in ves_blabla_Connect_Internal()
The code I'm talking about is this (mono/io-layer/sockets.c) :
while (poll (fds, 1, -1) == -1
!_wapi_thread_cur_apc_pending ()) {
if (errno != EINTR) {
errnum = errno_to_WSA (errno, __func__);
#ifdef DEBUG
g_message (%s: connect poll error: %s,
__func__, strerror (errno));
#endif
WSASetLastError (errnum);
return(SOCKET_ERROR);
}
}
I've been trying to debug this code without much luck understanding
what is special to the misbehaving scenario...
A change in the first line of code, allowing for a timeout of 3
seconds in the poll syscall (not sure how correct this is), seems to
solve the problem for me.
int prslt;
while(((prslt = poll(fds, 1, 3000)) == 0) || (prslt == -1
!_wapi_thread_cur_apc_pending()) {
...
Obviously this is not optimal, and as such - is not a solution
proposal but just additional info.
BeginConnect.zip___
Mono-devel-list mailing list
mono-devel-l...@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] bug or wrong mono compilation?
It appears to be a bug in the dmcs compiler, could you file it in bugzilla
please?
On 2010-05-23, at 12:17 PM, xplicit wrote:
svn info
URL: svn://anonsvn.mono-project.com/source/trunk/mono
Repository Root: svn://anonsvn.mono-project.com/source
Repository UUID: e3ebcda4-bce8-0310-ba0a-eca2169e7518
Revision: 157507
Why dmcs could be not working in this case? When I change source code to
dynamic a=new object();
string s=a.ToString();
Console.WriteLine(s);
It works as expected.
Alan McGovern wrote:
It works fine with r156922 from SVN. When building from trunk, always
give the svn revision that you built with.
Alan.
On Sat, May 22, 2010 at 5:36 PM, xplicit s...@ngs.ru wrote:
I have compiled mono 2.7 from trunk and try to use C# 4.0 features. I
wrote
simple program:
using System;
namespace test2
{
class MainClass
{
public static void Main (string[] args)
{
dynamic a=new object();
Console.WriteLine(a.ToString());
}
}
}
and run it. I expect System.Object instead of it the exception occurs:
Unhandled Exception:
Microsoft.CSharp.RuntimeBinder.RuntimeBinderException:
`string' does not contain a definition for `WriteLine'
at (wrapper dynamic-method) object.CallSite.Target
(System.Runtime.CompilerServices.Closure,System.Runtime.CompilerServices.CallSite,object)
IL 0x0004e, 0x000a6
at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid1
(System.Runtime.CompilerServices.CallSite,object) 0x00365
at test2.MainClass.Main (string[]) [0x0005d] in
/home/sergey/Projects/test2/test2/Main.cs:11
What is this: bug in the mono, or I have wrongly compiled mono?
--
View this message in context:
http://mono.1490590.n4.nabble.com/bug-or-wrong-mono-compilation-tp2227282p2227282.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-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
View this message in context:
http://mono.1490590.n4.nabble.com/bug-or-wrong-mono-compilation-tp2227282p2227918.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-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Deprecating OSX 10.4 in our binary packages
Hello all, Going forward we will be setting our minimum build version of OSX to 10.5. This will make providing updated gtk+/gtk# stacks significantly easier. Please let me know if there are any concerns or questions. Thanks Geoff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Deprecating OSX 10.4 in our binary packages
Francisco, On 2010-04-29, at 12:11 AM, Francisco Figueiredo Jr. wrote: snip The problem seems that glib-2.0.pc file and gthread-2.0.pc files aren't in the osx install. Install the CSDK -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] 64-bit OSX support
Hey Laurent, I fixed the process problem in r156118, I'll take a look at the failing tests later tonight. -g On 2010-04-26, at 12:28 PM, Laurent Etiemble wrote: Hello Geoff, I have successfully build Mono 64 bits for Mac OS X on my machine (10.6.3/Intel C2Duo 2.4GHz), by using the SVN r156105 trunk. Here some experiments I made: - make check reports 2 failing tests: thread6.exe and appdomain-thread-abort.exe. - mono -V works and report the architecture amd64 - the command line utilities (gmcs, monodis, ...) seem to work. I ran into a crash when calling System.Diagnostics.Process.MainModule. I have attached the crash log and a small test-case to reproduce. Let me know if you need more information. Regards, Laurent Etiemble. 2010/4/23 Geoff Norton gnor...@novell.com Hey all, I've landed experimental support for mono in 64-bit osx on trunk, you can test it by running configure with: /configure --with-glib=embedded --host=x86_64-apple-darwin10 For anyone who is interested I would appreciate some testing and reports, it does successfully bootstrap on my machine. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Program.csoutput.log ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] 64-bit OSX support
Hey all, I've landed experimental support for mono in 64-bit osx on trunk, you can test it by running configure with: /configure --with-glib=embedded --host=x86_64-apple-darwin10 For anyone who is interested I would appreciate some testing and reports, it does successfully bootstrap on my machine. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono-semaphore.c broken on MacOSX in SVN
This is fixed in trunk, sorry I forgot to commit it before. -g On 2010-02-23, at 7:46 PM, Tom Philpot wrote: Mono-semaphore.c won't compile on Mac. I *think* the patch below will fix it in both cases, but my macros are pretty rusty. Basically, semaphore_timedwait doesn't take a mach_timespec_t* where as sem_timedwait does take a struct timespec * ws1048-snow:mono tom.philpot$ svn diff mono/utils/mono-semaphore.c Index: mono/utils/mono-semaphore.c === --- mono/utils/mono-semaphore.c (revision 152312) +++ mono/utils/mono-semaphore.c (working copy) @@ -17,7 +17,7 @@ #define WAIT_BLOCK(a,b) semaphore_timedwait (a, b) # else #define TIMESPEC struct timespec -#define WAIT_BLOCK(a,b) sem_timedwait (a, b) +#define WAIT_BLOCK(a,b) sem_timedwait (a, ##b) # endif gboolean @@ -32,7 +32,7 @@ tv.tv_sec = timeout_ms / 1000; tv.tv_nsec = (timeout_ms % 1000) * 100; - return (!WAIT_BLOCK (sem, tv)); + return (!WAIT_BLOCK (sem, tv)); } #else ___ 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] moonlight
libunwind is only used for debugging and 100% optional. -g On 2010-02-16, at 3:19 PM, Απόστολος Συρόπουλος wrote: At FOSDEM Andreia told me that Linux x86/amd64 were the only supported platforms but patches would be welcome for other platforms. For starters, moonlight needs to find a way to stop using libunwind since this library is almost a Linux-only thing. It has been partially ported only to hpux. Then it is necessary to allow the use of OSS since both OpenSolaris and FreeBSD can use this infrastructure. ALSA is again a Linux-only thing. A.S. -- Apostolos Syropoulos Xanthi, Greece Hotmail: Αξιόπιστο email με την ισχυρή προστασία ενάντια στην ανεπιθύμητη αλληλογραφία που παρέχει η Microsoft. Εγγραφείτε τώρα.___ 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] Mono 2.6.x
Matteo, On 2010-02-08, at 4:57 AM, matteo tesser wrote: Hi Geoff, Is the well tested stable component you refer, public? can we help in testing? Yes, its the GC. We've made the change in trunk which means that it will be in 2.8 barring any problems. I only wan to say that Its a pity that this will not back-ported. Given this any change of running multi-thread apps is loss. I noticed that (at least in my case, a 3x performances boost can be obtained on Mac OS X also in cases where there only one background working thread and an UI thread). Anyway I agree that is more important to have apps running slow that not running at all. 2.6 is a stable supported release, I've discussed with the runtime team, and the consensus is that backporting a fundamental change to the GC into the 2.6 branch is not worth the risks, it needs more time to incubate in trunk so that it can be included in 2.8. Finally a question: I noticed when running autogen.sh I saw the following line: Parallel Mark: Disabled_Currently_Hangs_On_MacOSX I assume that meaining of the word Hangs is: it goes too slow, and maybe this can solved by the synchronization speedup. No, hangs means it hangs and deadlocks the process. I tried to force the use of parallel mark by compiling the trunk with the following option --enable-parallel-mark, and I obtain the following error on make, is this normal? Making all in mini make all-am ../../doltlibtool --quiet --tag=CC --mode=link gcc -I../.. -I../../libgc/include -D_REENTRANT -I/Users/teo/mono2.5/include/glib-2.0 -I/Users/teo/mono2.5/lib/glib-2.0/include -g -O2 -fno-strict-aliasing -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wwrite-strings -export-dynamic -sectcreate __TEXT __info_plist ../../mono/mini/Info.plist -pthread -o mono main.o libmono-static.la -L/Users/teo/mono2.5/lib -lgthread-2.0 -lglib-2.0 -lintl-lm -lpthread -lm Undefined symbols: _mono_gc_get_write_barrier, referenced from: _decode_method_ref in libmono-static.a(aot-runtime.o) ld: symbol(s) not found Are you still seeing this? -g Thanks, Matteo On Wed, Feb 3, 2010 at 8:29 PM, Geoff Norton gnor...@novell.com wrote: On 2010-02-03, at 2:27 AM, matteo tesser wrote: HI The following bug has been fixed on the trunk, I would like it to be backported: https://bugzilla.novell.com/show_bug.cgi?id=402833 This patch will not be backported, it changes the behaviour of well tested stable component in a major way with a serious chance of regressions. Geoff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.6.x
On 2010-02-03, at 2:27 AM, matteo tesser wrote: HI The following bug has been fixed on the trunk, I would like it to be backported: https://bugzilla.novell.com/show_bug.cgi?id=402833 This patch will not be backported, it changes the behaviour of well tested stable component in a major way with a serious chance of regressions. Geoff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mac Boehm CG question
This patch is now in trunk, thanks! -g On 2010-01-22, at 5:05 PM, Tom Philpot wrote: While investigating some performance problems in our application which uses the embedded Mono runtime on Mac OS X targeting 10.5 and 10.6, I noticed that several operations spent an extreme amount of time in GC_lock. That code lead me back to gcconfig.h where NO_PTHREAD_TRYLOCK is defined. I've commented out that #define it on my local Mono build and things seem MUCH faster. In fact I'm now able to do real work on more than 2 threads without a ton of overhead. The question is now, does this check still need to be there for later versions of Mac OS X? The original commit was back in August 2003, which was probably around the timeframe of 10.2 and 10.3 and definitely before the Intel Macs. Also, since I don't have a PPC to test on, I didn't comment that #define. ws1048-snow:mono tom.philpot$ svn diff libgc/include/private/gcconfig.h Index: libgc/include/private/gcconfig.h === --- libgc/include/private/gcconfig.h (revision 150077) +++ libgc/include/private/gcconfig.h (working copy) @@ -329,7 +329,7 @@ #define GETPAGESIZE() getpagesize() /* There seems to be some issues with trylock hanging on darwin. This should be looked into some more */ -# define NO_PTHREAD_TRYLOCK +//# define NO_PTHREAD_TRYLOCK # elif defined(__arm__) #define ARM #define mach_type_known ___ 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-list] Java / Mono performance diff (convolution benchmark)
Jonathan, If you check mono out from SVN you can use eglib on osx instead of eglib; rough directions: cd src/mono/eglib autoreconf -i cd .. autoreconf -i /configure --prefix=/whatever --with-glib=embedded make make install On 2010-01-29, at 5:46 PM, Jonathan Shore wrote: Hi, In my haste to do the prior benchmark, as Jon Harrop pointed out, there was some dead code (or rather dead work that was not going to be used).I wrote a new benchmark based on real code that I use. In this case a multivariate 1D FIR convolution.So as not to include the kitchen sink of dependencies with my libraries wrote some simple substitutes. Be aware that because of this the code is non-idiomatic C# and the same is true for the Java version.Not trying to win design points with this test. Again, this algorithm is array bound. But the test has no code that can be optimised away (that I am aware of) unlike the prior test. The performance results are: Mono: 2 min, 2 secs Java: 0 min, 58 secs The mailer will not allow posts with more than a few K, so will send in a followup message (awaiting moderation). As I've not been able to build glib on OSX, have not yet been able to try this with the LLVM option. regards Jonathan ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Mac Boehm CG question
Tom, Looking back, apple had some issues with trylock in the 10.2/10.3 days, and this came over for safety when we did the initial osx86 port. Its probably safe to make this change on x86 on trunk, but I'd like some metrics if you could. #1, run it for a bit make sure you dont get any random hangs. #2, do you have any perf increase numbers? Thanks Geoff On 2010-01-25, at 4:59 PM, Tom Philpot wrote: Rodrigo, Thanks for the input. Any of the other Mono/MacOS X folks have an opinion on this change? I've been running our heavily multi-threaded app which embeds Mono and haven't seen any issues. We're going to start removing this #define on our build machine and our dev's Mono installs and see if we can detect any issues since the speed up is so significant in certain cases in our app. Tom On Jan 22, 2010, at 2:08 PM, Rodrigo Kumpera wrote: pthread mutexes on OSX are ridiculously slow. So no matter what you do, GC performance will be significantly worse than on linux. But we should check if this change is ok if it does give a nice boost. On Fri, Jan 22, 2010 at 8:05 PM, Tom Philpot tom.phil...@logos.com wrote: While investigating some performance problems in our application which uses the embedded Mono runtime on Mac OS X targeting 10.5 and 10.6, I noticed that several operations spent an extreme amount of time in GC_lock. That code lead me back to gcconfig.h where NO_PTHREAD_TRYLOCK is defined. I've commented out that #define it on my local Mono build and things seem MUCH faster. In fact I'm now able to do real work on more than 2 threads without a ton of overhead. The question is now, does this check still need to be there for later versions of Mac OS X? The original commit was back in August 2003, which was probably around the timeframe of 10.2 and 10.3 and definitely before the Intel Macs. Also, since I don't have a PPC to test on, I didn't comment that #define. ws1048-snow:mono tom.philpot$ svn diff libgc/include/private/gcconfig.h Index: libgc/include/private/gcconfig.h === --- libgc/include/private/gcconfig.h(revision 150077) +++ libgc/include/private/gcconfig.h(working copy) @@ -329,7 +329,7 @@ #define GETPAGESIZE() getpagesize() /* There seems to be some issues with trylock hanging on darwin. This should be looked into some more */ -# define NO_PTHREAD_TRYLOCK +//# define NO_PTHREAD_TRYLOCK # elif defined(__arm__) #define ARM #define mach_type_known ___ 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-list] Announcing the release of Mono 2.6 and MonoDevelop 2.2
Install g++ -g On 2009-12-15, at 8:25 PM, Maxim wrote: That is Great!!! I've tested debugger for asp.net. Fantastic!! I'm completely happy with Mono now! I've just got difficulties compiling Mono from sources on CentOS 5.2 x64, after make: make[3]: Leaving directory `/root/mono/2.6/mono-2.6/mono/mini' Making all in dis make[3]: Entering directory `/root/mono/2.6/mono-2.6/mono/dis' LDmonodis gcc: ../mini/.libs/libmono.so: No such file or directory make[3]: *** [monodis] Error 1 make[3]: Leaving directory `/root/mono/2.6/mono-2.6/mono/dis' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/mono/2.6/mono-2.6/mono' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/mono/2.6/mono-2.6' make: *** [all] Error 2 Thanks to all of you for this great work! All the best, Max Karavaev Andrew Jorgensen wrote: Today we released Mono 2.6 and MonoDevelop 2.2. These releases contain a huge number of improvements. Please go see the release notes for more details or go read Miguel's post: http://tirania.org/blog/archive/2009/Dec-15.html Really a lot of exciting stuff in there! The release notes for mono are here: http://go-mono.com/archive/2.6 .. and for MonoDevelop here: http://monodevelop.com/Download/MonoDevelop_2.2_Released and downloads are available here: http://go-mono.com/mono-downloads/ .. and here: http://monodevelop.com/Download Release of the LiveCD / Appliance images is somewhat delayed. More news in the near future. Thanks to all those who contributed to this release! ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Request for a wiki page for mono
On 2009-12-11, at 1:48 PM, ptr wrote: http://www.mono-project.com/Compiling_Mono_on_OSX 1) This information is not valid for 10.6 snow leopard, Certain CLFAGS need to be set to force a i386 build. No they dont on trunk or 2.6 -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Request for a wiki page for mono
On 2009-12-11, at 2:02 PM, ptr wrote: Looking with otool on all the libraries installed under Mono.Framework in a 2.6 install , they seem to be all 32bit. Unless you force gcc to build 32bit a default compile/link under 10.6 builds 64bit binaries unlike OSX10.5 which produces 32bit binaries by default. I'm perfectly aware of the issue with gcc on 10.6. We fixed configure to do everything needed for you on 2.6 and trunk like I said in my last email. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing the release of Mono 2.4.3
Kris, Apologies, this was an error in the release notes. The first release on OSX with support for the debugger will be 2.6 Geoff On 2009-12-09, at 10:40 PM, Kris Ray wrote: The release notes say that debugging works on OSX now when logged in as root. I just installed mono 2.4.3 and the latest monodevelop 2.2 rc on OSX 10.6.2. I enabled the root account, then logged in as root. I then created a console app in monodevelop and put in breakpoints. The menu under run has the debug option grayed out. What else do I need to do to enable this? thanks, Kris ___ 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] Need help building Mono under Snow Leopard
On 2009-12-07, at 3:55 PM, ptr2009 wrote: snip when using the --with-glib=embedded option I get an error in eglib... Is there a workaround for it ? ---Making all in eglib /bin/sh: line 0: cd: eglib: No such file or directory make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 MonoDevelop on snow leopard is only supported (from source) on 2.6+ Our binaries work fine on 10.6 from our website for 2.4 -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] 'libmono.so: no such file or directory' during build
Install g++ -g On 2009-12-07, at 9:24 PM, nzsaint wrote: Hi, I am trying to update my mono version from the anonymous svn which has been working fine for me for some time. Currently when I attempt to run 'make' on version 147822 I receive the following error: ... make[3]: Entering directory `/root/mono-svn-newest/mono/mono/dis' CCget.o CCdis-cil.o CCutil.o rm -f libmonodis.a ar cru libmonodis.a get.o dis-cil.o util.o ranlib libmonodis.a CCdump.o CCmain.o CCdeclsec.o LDmonodis gcc: ../mini/.libs/libmono.so: No such file or directory make[3]: *** [monodis] Error 1 make[3]: Leaving directory `/root/mono-svn-newest/mono/mono/dis' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/mono-svn-newest/mono/mono' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/mono-svn-newest/mono' make: *** [all] Error 2 Is this an error on my part or a problem with the compilation process? Thanks -- View this message in context: http://old.nabble.com/%27libmono.so%3A-no-such-file-or-directory%27-during-build-tp26687738p26687738.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] [PATCH] mono_debugger_agent_thread_interrupt signature mismatch
Please commit -g On 14-Nov-09, at 8:33 PM, Andreas Färber wrote: Hello, The attached patch changes the signature of mono_agent_thread_interrupt in the DISABLE_DEBUGGER_AGENT case to match the header file. This fixes compilation on Mac OS X ppc. Okay to commit? Regards, Andreas 0001-Fix-signature-of-mono_debugger_agent_thread_interrup.patch ___ 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] Soft debugger HOWTO
On 9-Nov-09, at 6:11 PM, pablosantosl...@terra.es wrote: Hi, After the announcement last week of the new soft debugger, I have several questions: - I understand MD is the primary interface *right now* for the soft debugger, is it possible to debug a Linux app too? You mean a native app? No. You mean a mono app on linux? Yes, on x86 and amd64 and arm currently. - Is there any other available interface to use the soft debugger besides MD? You can create any interface you like on top of the Mono.Debugger.Soft.dll, MonoDevelop is the interface we support. - As Miguel pointed to me last week, the new softdeb will allow debuggin gon any platform, I don't know if anyone experienced it yet (I'll definitely give it a try asap), if so, any feedback? We currently have it ported to: - linux (x86, amd64, arm, arm-full-aot) - darwin (x86, arm, arm-full-aot) The point miguel was making is that porting to new architectures is a minor (1 day) task in most cases. For example, Jonathan Chambers has it mostly ported to win32 already -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Soft debugger HOWTO
On 9-Nov-09, at 6:33 PM, pablosantosl...@terra.es wrote: - Is there any other available interface to use the soft debugger besides MD? You can create any interface you like on top of the Mono.Debugger.Soft.dll, MonoDevelop is the interface we support. Will it make sense to have some sort of command line interface? Maybe not, MD will always be better... We have no plans to make a command line interface, someone from the community is free to do so. Our suggested and supported interface is going to be MonoDevelop -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Does MonoTouch use GC?
Yes On 14-Sep-09, at 6:40 PM, pablosantosl...@terra.es wrote: Hi there, Does MonoTouch use GC when running on the iPhone? Thanks, pablo ___ 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] Mono SVN doesn't build on Mac OSX Snow Leopard
I have some experimental patches for amd64-darwin-mono, but not ready yet. For now you should set the CFLAGS=-m32 -g On 8-Sep-09, at 8:14 PM, Tom Philpot wrote: The primary reason seems to be that the default version of gcc on Snow Leopard, 4.2.1, no longer defines __i386__. gcc 4.2.1 defines __x86_64__. I started down the path of modifying some of the #defines to correctly target DARWIN and use __x86_64__, but I ran into trouble building aot-runtime.c because mini.h wanted to use the -x86 sources not the amd64 sources. Has anyone else tried to build Mono from SVN on Snow Leopard? Thanks, Tom ___ 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] Exceptions-x86.c r140989 causes exceptions.exe test to crash on Mac x86
Fixed in r141069 Thanks -g On 1-Sep-09, at 2:44 PM, Tom Philpot wrote: While trying to rebuild the latest Mono SVN, I noticed that the exceptions.exe was crashing during make check. Digging a little deeper I reverted the latest change to exceptions-x86.c (svn update -r PREV mono/mono/mini/exceptions-x86.c) and everything passed. The crash from the test case using r of exceptions-x86.c is as follows: Test run: image=/Users/tom.philpot/External/mono-project/mono/mono/mini/ exceptions.exe , opts= Stacktrace: at (wrapper managed-to-native) object.__icall_wrapper___emul_fconv_to_ovf_u8 (double) 0x4 at (wrapper managed-to-native) object.__icall_wrapper___emul_fconv_to_ovf_u8 (double) 0x at Tests.test_0_byte_cast () 0x00318 Native stacktrace: 0 mono0x0008e0da mono_handle_native_sigsegv + 266 1 mono0x6eca mono_sigsegv_signal_handler + 298 2 libSystem.B.dylib 0x949402bb _sigtramp + 43 3 ??? 0x 0x0 + 4294967295 Debug info from gdb: warning: Trying to remove a section from the ordered section list that did not exist at 0x29c000. Attaching to process 53961. Reading symbols for shared libraries . done Reading symbols for shared libraries done 0x948f7f95 in read$UNIX2003 () 4 process 53961 thread 0x2703 0x948d42c2 in semaphore_wait_trap () 3 process 53961 thread 0x2303 0x948db46e in __semwait_signal () 2 process 53961 thread 0x1103 0x948d4286 in mach_msg_trap () * 1 process 53961 thread 0x717 0x948f7f95 in read$UNIX2003 () Thread 4 (process 53961 thread 0x2703): #0 0x948d42c2 in semaphore_wait_trap () #1 0x000f8013 in finalizer_thread (unused=0x0) at gc.c:1014 #2 0x001851ba in start_wrapper (data=0x60f4a0) at threads.c:657 #3 0x001b6225 in thread_start_routine (args=0x5dc434) at wthreads.c: 286 #4 0x001d5483 in GC_start_routine (arg=0x593f60) at pthread_support.c:1390 #5 0x94905155 in _pthread_start () #6 0x94905012 in thread_start () Thread 3 (process 53961 thread 0x2303): #0 0x948db46e in __semwait_signal () #1 0x948db2ef in nanosleep$UNIX2003 () #2 0x00199b10 in collection_thread (unused=0x0) at collection.c:34 #3 0x94905155 in _pthread_start () #4 0x94905012 in thread_start () Thread 2 (process 53961 thread 0x1103): #0 0x948d4286 in mach_msg_trap () #1 0x948dba7c in mach_msg () #2 0x000c0dc4 in mach_exception_thread (arg=0x0) at mini-darwin.c:131 #3 0x001d5483 in GC_start_routine (arg=0x593f60) at pthread_support.c:1390 #4 0x94905155 in _pthread_start () #5 0x94905012 in thread_start () Thread 1 (process 53961 thread 0x717): #0 0x948f7f95 in read$UNIX2003 () #1 0x0008e1cb in mono_handle_native_sigsegv (signal=11, ctx=0xbfffec38) at mini-exceptions.c:1560 #2 0x6eca in mono_sigsegv_signal_handler (_dummy=11, info=0xbfffebf8, context=0xbfffec38) at mini.c:4583 #3 signal handler called #4 0x0005a05e in mono_fconv_ovf_u8 (v=0) at jit-icalls.c:860 #5 0x016a23e7 in ?? () #6 0x016a1c49 in ?? () #7 0x00067d7d in mini_regression [inlined] () at driver.c:427 #8 0x00067d7d in mono_main (argc=16, argv=0xb0ec) at driver.c:484 #9 0x1ff6 in start () = Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = ___ Mono-devel-list mailing list Mono-devel-list@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-list] Mono on SnowLeopard
Mono 2.4 binaries work fine on Snow Leopard. The svn version of mono will not compile out of the box on snow leopard because of some changes apple made, but it can be wrangled with some cflags (-arch i386 should do it) -g On 27-Aug-09, at 6:03 AM, Mario De Clippeleir wrote: Hi, Is Mono being supported or tested on SnowLeopard ? Thx, Mario ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Getting Started With MonoTouch
Tim, MonoTouch is not currently available to the public. If you are interested in our private beta please fill out the survey @ http://bit.ly/3MxPlS -g On 3-Aug-09, at 11:19 AM, Tim Scott wrote: I am a total noob to Mono. I was hoping to give a try to MonoTouch. This tutorial shows how to get started with MonoTouch development: http://www.mono-project.com/MonoTouch_Tutorial_MonoDevelop_HelloWorld It instructs to use MonoDevelop MonoTouch Edition, and it provides a link to the MonoDevelop site -- where it can presumably be obtained. I cannot find any such thing on that site. Nor can Google find it for me. I downloaded the latest version of MonoDevelop (for Mac OS X 10.4/10.5), but there is no sign of IPhone MonoTouch project types as shown in the tutorial. I tried version 2009/07/06 and also 2009/05/05. Can someone point me in the right direction? Tim Scott ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Compiler warnings
On 23-Jul-09, at 11:02 PM, Christian Hergert wrote: Hello, In an effort to get more familiar with some of the code-base, I went through and fixed some of the pesky compiler warnings for the runtime. Attached is a patch for said warnings. If anyone has suggestions on how to better fix the warnings, please send them my way and I'll adjust the patch as needed. #1: Having tons of +#ifndef TEMP_FAILURE_RETRY is sucky, localize it into mono/utils/somewhere-logical.h and include it around #2: lots of: +#ifndef PLATFORM_MACOSX FILE *fp; +#endif impedes readability (for me) just for 1 platform, not sure its worth it. As for the rest, it looks sane, but I'll let the runtime guys weigh in. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Cross compiling mono 2.4 to PowerPC
On 25-Jun-09, at 12:38 AM, Dushara Jayasinghe wrote: You should update to the tip of the 2.4 branch or head which fixes this (among other) problem. I'm using the official source distribution @ http://ftp.novell.com/pub/mono/sources-stable/ Anyway, I've got the build itself working or do you believe that the original problem I highlighted (The file /usr/lib/mscorlib.dll is an invalid CIL image) is related to the build system itself? Yes, this is 99% the case, you have a brkoen build. -g ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Cross compiling mono 2.4 to PowerPC
On 24-Jun-09, at 1:05 AM, Dushara Jayasinghe wrote: That would likely save you a lot of pain rather than configure hacking. I remember I got compile time errors when I tried it last (it was trying to build some libraries still). That's why I had to resort to the configure hack. I'll check again to verify though. These are the errors I was getting: ./configure --prefix=/usr --with-sigaltstack=no --with-tls=__thread --disable-mcs-build --host=ppc-linux Resulted in the following error: ... checking for working __thread... configure: error: cannot run test program while cross compiling After configure.in was hacked, 'make' gave the following error: ... make[2]: Entering directory `/home/cis2/mono-2.4/docs' cd . make -f docs.make topdir=../mcs convert.exe make[3]: Entering directory `/home/cis2/mono-2.4/docs' MCS [net_2_0] convert.exe make[3]: *** [convert.exe] Error 1 You should update to the tip of the 2.4 branch or head which fixes this (among other) problem. -g ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-winforms-list] [Mono-osx] multi byte text input support
Go ahead and commit this. Thanks eno On 23-Jun-09, at 8:42 AM, Atsushi Eno wrote: Hello, In case you need multi byte text input, here is my patch: https://bugzilla.novell.com/show_bug.cgi?id=501276 (I'm posting here just to notify that a patch exists.) Atsushi Eno ___ Mono-osx mailing list mono-...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-osx ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-list] Cross compiling mono 2.4 to PowerPC
On 23-Jun-09, at 11:38 PM, Dushara Jayasinghe wrote: Hi I'm trying to cross compile mono 2.4 embedded PowerPC based system. For a couple of reasons, I'm trying to avoid building mono in the target itself. These are the steps I took: 1. Modified Configure.in Makefile.am to avoid compiling the libraries when in cross compile mode. - I needed this step because, the build system attempts to build libraries using mono itself. 2. Compiled the binaries for the target system. 3. Compiled mono for for the host system. 4. Copied the mono binary (built in step 2) and mscorlib.dll (built in step 3) to the target system. Have you looked at the configure options for step 12, specifically -- disable-mcs-build for cross compiling? That would likely save you a lot of pain rather than configure hacking. However, when I try to execute a mono app, I get the following error: The file /usr/lib/mscorlib.dll is an invalid CIL image Does the DLL in question contain native code? If not, is there any way I can overcome this problem? Thanks Dushara ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] NET_4_0 Configure Flags
Can we please add a --enable-profile1 as well? -g On 15-Jun-09, at 3:24 PM, Miguel de Icaza wrote: I have updated the documentation here: http://www.mono-project.com/Unsupported_Advanced_Mono_Compile_Options I would still argue we should default 4.0 to off, but at least I can turn it off and save myself some time. :) It should be off by default; It is not ready for mass use anyways. Miguel. ___ 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] NET_4_0 Configure Flags
On 15-Jun-09, at 3:43 PM, Miguel de Icaza wrote: Can we please add a --enable-profile1 as well? Not worth it; We need this to bootstrap, and without the bootstrap phase we have to do a whole load of work. Profile 1.0 is going to go away anyways at some point in the future (Mono 2.6 might be the last release with 1.0). Well my thought was disabling it would still build what it needed for bootstrapping, but wouldn't go build Winforms, System.Data, etc etc etc for the 1.1 profile. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Mono Develop on OS X
export ACLOCAL_FLAGS=-I /path/to/your/pkg.m4 -g On 15-May-09, at 2:34 PM, jonas echterhoff wrote: When I just try ./configure --profile=mac after installing the framework, I get: ./configure: line 2697: syntax error near unexpected token `UNMANAGED_DEPENDENCIES_MONO,mono' ./configure: line 2697: `PKG_CHECK_MODULES(UNMANAGED_DEPENDENCIES_MONO,mono = $MONO_REQUIRED_VERSION, has_mono=true, has_mono=false)' When I use --prefix to specifiy my mono installation I build from svn (which I ultimately want, since that's the only place where I have my debugger code), I get further then that, but then I'm missing all the requirements (need to build mono-addins, which requires GTK#, which requires pango, etc...) jonas On May 15, 2009, at 8:17 PM, Miguel de Icaza wrote: Hello Jonas, I want to try to get the mono debugger integration work with Mono- Develop on Mac OS X. Now I'm stuck trying to build mono-develop from svn, because of all the involved dependencies. What is the easiest way to get bootstrapped with this? Is there a package manager which can install the requirements for me? Or something which gives me the whole package? When I install the mono framework, that has most or all of what is needed, any way to compile against that? That should have everything you need. I know that this is all I had myself. Could you paste the error messages that you are getting? Miguel. ___ 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] Building Mono Develop on OS X
nod for the sake of google-ability new OSX (10.5+) with X11 has it in /usr/ X11/share/aclocal as well (might need xcode for this, can't remember) -g On 15-May-09, at 3:59 PM, Miguel de Icaza wrote: Hello, export ACLOCAL_FLAGS=-I /path/to/your/pkg.m4 Good lord, let us kill that retarded macro once and for all. We do not ship that with our newer installers. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What mono branch/tag to use from svn
Joe, On 05/06/2009 08:15 AM, Joachim Ante wrote: Hi, We are in the process of upgrading Unity to mono 2.4. I ran into one showstopper bug, that we want to get through asap. https://bugzilla.novell.com/show_bug.cgi?id=500385 To build our mono we used tags mono-2-4 _http://anonsvn.mono-project.com/source/tags/mono-2-4/mono_ 1. Is this the right place to pull the most stable version of mono that has gone through a full test pass? The tag is a snapshot in time when 2.4 was relelased. You probably want to track _http://anonsvn.mono-project.com/source/branches/mono-2-4/mono http://anonsvn.mono-project.com/source/tags/mono-2-4/mono_ and periodically pull the fixes that land there as pertinent to you. 2. At least for us the bug is still present on that tag. Sebastian says it's fixed in 2.4 branch. Does anyone know which specific checkin has fixed this issue? 3. Do you guys usually replace the tags when releasing an update to mono 2.4 or do you create a new tag? It seems like the binary installer has revision 6 in it, but there is no corresponding tag folder on svn. A new tag will be created for every single release, which will be copied from the corresponding revision on the branch. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What mono branch/tag to use from svn
I tested the testcase from my mono 2.4 on mac (tip of branch not release) and it works fine there. -g On 05/06/2009 09:43 AM, Zoltan Varga wrote: Hi, I can't reproduce that bug with the stock mono 2.4 release on linux, maybe it is a mac-only bug ? Zoltan On Wed, May 6, 2009 at 2:15 PM, Joachim Ante j...@unity3d.com mailto:j...@unity3d.com wrote: Hi, We are in the process of upgrading Unity to mono 2.4. I ran into one showstopper bug, that we want to get through asap. https://bugzilla.novell.com/show_bug.cgi?id=500385 To build our mono we used tags mono-2-4 _http://anonsvn.mono-project.com/source/tags/mono-2-4/mono_ 1. Is this the right place to pull the most stable version of mono that has gone through a full test pass? 2. At least for us the bug is still present on that tag. Sebastian says it's fixed in 2.4 branch. Does anyone know which specific checkin has fixed this issue? 3. Do you guys usually replace the tags when releasing an update to mono 2.4 or do you create a new tag? It seems like the binary installer has revision 6 in it, but there is no corresponding tag folder on svn. Best regards, Joachim Ante ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto: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-list] GSoC Proposal: PL/Mono
Please get the proposal on the gsoc site asap (google is pressuring us)
even if its in draft form as the deadline is looming.
This goes for all proposals.
-g
On 03/31/2009 06:23 PM, Olexandr Melnyk wrote:
Hello,
my name is Olexandr Melnyk and I am a third-year Ukrainian student. I
would like to present my proposal for Summer of Code PL/Mono: a
procedural language for PostgreSQL. The objective of my project is to
add support for writing PostgreSQL functions in managed languages.
PostgreSQL functions are often referred to as stored procedures, but
apart from that usage they serve a broad range of purposes (eg. they
are also used for implementing triggers).
So far I've found a couple of places, which I'm uncertain about and
would like to make clear before I submit an application.
1) I see three ways of specifying functions in CREATE FUNCTION statement:
- embedding C# code into the statement (PL/Python and PL/Perl do that):
CREATE FUNCTION SUM(INT) RETURNS INT
AS $$
public static int Add(int x, int y)
{
return x + y;
}
$$ LANGUAGE PLMONO;
This approach is the easiest to use, but is C#-specific. And extra
(little) work is needed to add support for a new managed language.
- by specifying an assembly filename and a fully qualified function name:
CREATE FUNCTION SUM(INT) RETURNS INT
AS 'Library1.dll:Namespace2.Class3.Function4'
LANGUAGE PLMONO;
Assemblies are searched in directories specified by a config variable,
or a full path should be provided.
- by a fully qualified function name (this approach is taken by
PL/Java and is my personal favorite):
CREATE FUNCTION SUM(INT) RETURNS INT
AS 'Namespace1.Class2.Function3'
LANGUAGE PLMONO;
Functions are searched in assemblies from directories specified by a
config variable.
2) If we go with the approach 2 or 3, should all managed functions
exposed to PostgreSQL world be marked with some special attribute? For
example:
public static class FunctionLibrary
{
[PostgresFunc]
public static int Add(int x, int y)
{
return x + y;
}
}
Requiring an attribute would mean that functions can be used from SQL,
only if they were really intended for that. However, this would also
mean that to use a harmless function from standard namespaces (like
System.Math.Abs), one would need to make a wrapper.
I have already briefly discussed my proposal on IRC, but would be glad
to get some more feedback.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] GSoC questions on SIlverlight video editor
CCing moonlight-list I've answered your questions below, and cc'd the moonlight-list for any follow-up you might have. Also feel free to pop by the #moonlight channel, usually one of us is always around -g On 03/29/2009 01:46 PM, cDima wrote: I want to make sure that I understand this proposed GSoC task correctly: “Using Silverlight 2.0 build the UI for video editing software”. Below I wrote my understanding of the deliverable, my questions, bio, and risks. Please tell me if I got the idea right, thanks! The deliverable will be a user-friendly Silverlight application for in-browser video editing. The app will be somewhat like * the GSoC 2005 Diva Video Editor http://mono-project.com/Summer2005#Diva, * the Top Banana MIX2007 http://silverlight.net/learn/learnvideo.aspx?video=125 applications. The well polished GUI should resemble specialized software like Apple’s iMovie and Adobe’s After Effects. The GUI will consist of: * preview area for the video, * timeline editor with drag-and-drop editing, skimming, trimming, cut paste, slicing. * resource list (media library). * Tools to apply effects and transitions to the clips. The sample application should work within web browsers supporting Silverlight 2.0, be written in clean, maintainable code. Questions: 1. The Diva Video Editor was an incredible GUI program. We want a similar Silverlight/Moonlight alternative? Yes, the goal is to provide the solution in-browser in Silverlight and Moonlight. 1. I am most comfortable working in C# in Visual Studio 2008, may I implement this application in Visual Studio 2008 and Expression Blend Suite? This is fine. About me: My name is Dmitri Sadakov. I have a master’s degree in computer science, going on to PhD in CS, both from Saint Petersburg Polytechnic University, Russia. I’ve been a computer engineer for around 8 years, 6 of it devoted to C#, ASP.Net, and winforms. The most complicated coding project I have been involved in is NYSE backend website (http://www.nyse.com/) and the Eluma (http://blog.go2web20.net/2008/05/eluma-as-desktop-client-for-friendfeed.html). My open source experience includes coding my masters degree application as open source samba crawler search interface, Lan-Crawler (http://sourceforge.net/projects/lan-crawler/). The last 2 years I have been working in ASP.Net, Dreamweaver, Photoshop, and objective-c, I am most comfortable working with C#. Creating an in-browser video editing application in Silverlight should be worth spending time on this summer. I am eager to increase Silverlight skills, and help the open source community. Also, lately I have been working a lot with Adobe After Effects for video editing and creating motion graphics. Risks: * I will need to research to understand the mechanics of grabbing images from video streams. * Same for the mechanics of applying transitions and effects * Moonlight 2.0 Beta will be released mid May 2009 http://www.mono-project.com/MoonlightRoadmap , there is a big chance of this video editor to not work on that beta. * The project might prove to be too hard for my experience with silverlight, then again it might not. Thanks, Dmitri Sadakov ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Media Pack for Monolight 1.0
No, it doesn't: [0.23][01:59] pla...@limestone:~/Desktop$ objdump -p silverlight-media-pack-linux-x86-5-1.so | grep NEEDED NEEDED libmoon.so.0 NEEDED libstdc++.so.6 NEEDED libm.so.6 NEEDED libc.so.6 NEEDED libgcc_s.so.1 -g On Sat, 2009-01-17 at 01:14 +0100, Chris Hills wrote: Hi The media pack for Monolight 1 on Firefox for Linux (silverlight-media-pack-linux-x86-5-1.so) links to libmono.so.0. This requires the full Mono framework to be installed as it is not provided by Monolight. This was not clear at install time. Regards, Chris Hills ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Mono Develop native menus on Mac OS X
On Wed, 2009-02-18 at 06:35 -0800, Sandy Armstrong wrote: On 02/18/2009 06:28 AM, Joachim Ante wrote: Hi, Are you guys planning to switch to Mac OS X native menus and hotkeys that fit existing Mac applications for Mono Develop 2.0? (bug 367030) I can't speak for the MonoDevelop guys, but I can say that this would not be hard for a new contributor to do, given the examples available in Banshee, Tomboy, Tasque, etc. Well, I don't think anybody has done hotkeys yet, but I don't think it would be *that* hard. I have a patch somewhere or other for the menu (its 2 lines of code). The hotkeys I havn't looked into yet tho. We should probably move this discussion to the monodevelop-list tho. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Process.GetCurrentProcess().MainModule
This is a bug that has been fixed in SVN and will be in 2.4
-g
On Wed, 2009-01-21 at 16:18 +, Michael Foord wrote:
Hello all,
I'm using Mono 2.2 on Mac OS X. I get an exception when trying to use
Process.GetCurrentProcess().MainModule
Unhandled Exception: System.ArgumentOutOfRangeException: Index is less
than 0 or more than or equal to the list count.
Parameter name: index
0
at System.Collections.ArrayList.ThrowNewArgumentOutOfRangeException
(System.String name, System.Object actual, System.String message)
[0x0]
in
/private/tmp/monobuild/build/BUILD/mono-2.2/mcs/class/corlib/System.Collections/ArrayList.cs:3258
at System.Collections.ArrayList.get_Item (Int32 index) [0x00013]
in
/private/tmp/monobuild/build/BUILD/mono-2.2/mcs/class/corlib/System.Collections/ArrayList.cs:2649
at System.Diagnostics.ProcessModuleCollection.get_Item (Int32 index)
[0x0]
in
/private/tmp/monobuild/build/BUILD/mono-2.2/mcs/class/System/System.Diagnostics/ProcessModuleCollection.cs:63
at System.Diagnostics.Process.get_MainModule () [0x0]
in
/private/tmp/monobuild/build/BUILD/mono-2.2/mcs/class/System/System.Diagnostics/Process.cs:232
at (wrapper remoting-invoke-with-check)
System.Diagnostics.Process:get_MainModule ()
at process.MainClass.Main (System.String[] args) [0x0]
in /Users/michael/Dev/Projects/process/process/Main.cs:15
I get this with the following code compiled with MonoDevelop (and also
IronPython where I was actually trying to use it):
using System;
using System.Diagnostics;
namespace process
{
class MainClass
{
public static void Main(string[] args)
{
Console.WriteLine(Process.GetCurrentProcess().MainModule);
}
}
}
All the best,
Michael Foord
--
http://www.ironpythoninaction.com/
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Moonlight 1.0 released!!!
Kornel, Moonlight works on many many more architectures and platforms than that, we just only provide binaries for Linux x86 and x86_64, and the same is true of the Microsoft Media Pack. -g On Tue, 2009-01-20 at 14:09 +0100, Kornél Pál wrote: Hi, Is there a reason that only Linux on x86 and x86_64 is supported? I know little about Moonlight but since it's based on Mono I belive that a lot broader range of platforms could possibly be supported with small efforts. Kornél 2009/1/20 Rusty Howell rhow...@novell.com: Hey folks, We're very pleased to announce the release of Moonlight 1.0! The Firefox plugin is available at http://go-mono.com/moonlight for Linux 32 and 64 bit platforms. A tarball of Moonlight is available at http://ftp.novell.com/pub/mono/sources/moon/moon-1.0.tar.bz2 As always, any bugs found can be submitted to us at http://mono-project.com/Bugs . We're now looking forward to Moonlight 2.0 and the managed Silverlight goodness. Thanks again. Rusty Howell Moonlight QA ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] State of 64-bit support on OS X
On Thu, 2009-01-15 at 05:12 -0800, shjk wrote: Ok, thanks for the info. For clarification, I forgot to mention that I'm interested primarily in Intel machines. I tried building Mono 2.0.1 from source using x86_64-apple-darwin9.0.0 and amd64-apple-darwin9.0.0 architectures. x86_64 build fine but produces 32-bit executables and an mcs which generated 32-bit binaries. amd64 added a prefix to all executables and mcs failed to run because mono.exe could not be found. I haven't tried with the 2.2 release, yet. I'm not sure where you got all this information. Basically all you need to do is add -m64 to your CFLAGS, and ensure all the dependencies are built with 64-bit support as well. Additionally, mcs doesn't generate 32 or 64-bit binaries, it generates portable IL which can be run anywhere. Lastly, mono.exe only exists on windows, not Darwin, so I'm not entirely sure what you're doing. -g ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] State of 64-bit support on OS X
I've done some really high-level investigative work on it, its probably a 1-2 day job at most. If you need this support, feel free to build it up and send us patches which I will happily review. -g On Wed, 2009-01-14 at 10:21 -0200, Rodrigo Kumpera wrote: Exactly, AFAIK nobody is working on it. Mono has all the bits in place thou. Both amd64 and ppc64 ports works well, it's just that nobody did the darwin 64 bits of the work. You can do it yourself and contribute back to the project, if you really fancy it. On Wed, Jan 14, 2009 at 10:00 AM, shjk cmdk...@gmx.de wrote: Hi, can I infer from the lack of answers that interest in 64-bit support on OS X is currently very low and no one is actively working on this? Jan -- View this message in context: http://www.nabble.com/State-of-64-bit-support-on-OS-X-tp21419366p21454677.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Detecting if platform is Mac
On Mon, 2009-01-05 at 20:57 +0100, Petit Eric wrote: argg, sorry chris , i would like to send this to the list : declare a string Platform = win; use : if(environment.platformid == unix) to use a process with redirect output and start process.start(uname -a); then parse the response with .indexof i remember, for the process + return function, yu can use my class : http://monoosc.svn.sourceforge.net/viewvc/monoosc/MonoOSC/MonoOSC/Class/UnixShell.cs?revision=34view=markup :-) Like I've already said in this thread, using a process to run uname is senseless overhead. Use p/invoke like in XplatUI.cs -g 2009/1/5 Erik Ylvisaker eylvisa...@physics.ucdavis.edu: So, the reason I want to detect if we are running MacOS is I am writing Mac OpenGL bindings for the OpenTK project. On MacOS we need to make appropriate AGL calls instead of GLX or WGL calls in order to construct an OpenGL context. Perhaps a better solution would be to check the type of the XPlatUI driver to see what it is, although I'd like to avoid writing code which depends on private mono internals. Miguel de Icaza wrote: Apparently in .NET 3.5 Microsoft added two members to the System.PlatformID type, called Xbox and MacOSX. Is there any support in Mono for these? Of course, I don't care about the Xbox value I am just interested in being able to detect whether my code is running on MacOS or Linux. We added support for reporting this value back, but it turned out to break too much code in both Mono and our own modules, so we took this patch out. A lot of code assumed that it was Unix if the value was Unix, and when we returned the new value assumed it was running on Windows. We will continue to monitor progress on third party code and eventually make this change. But in general, the PlatformID is a poor way of detecting the platform, and instead you should base your code on other parameters like path separators for example. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Detecting if platform is Mac
On Wed, 2008-12-31 at 11:53 -0800, Erik Ylvisaker wrote: Apparently in .NET 3.5 Microsoft added two members to the System.PlatformID type, called Xbox and MacOSX. Is there any support in Mono for these? Of course, I don't care about the Xbox value I am just interested in being able to detect whether my code is running on MacOS or Linux. We might support this in 2.4. Otherwise, is there another recommended way to detect if running on MacOS? Currently we are spawning uname and checking to see if the output is Darwin. This works, but I don't know if there's a better way. Dont spawn uname, p/invoke it. Look in mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUI.cs for an example. -g ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Mono 2.0 and FreeBSD
Please file a bug for this issue in bugzilla and assign it to me.
-g
On Tue, 2008-12-09 at 12:57 +0100, Romain Tartière wrote:
On Mon, Dec 08, 2008 at 04:14:45PM +0100, Romain Tartière wrote:
As for the exception failures, running configure with
./configure --with-sigaltstack=no
might help.
Just tried it. Instead of hanging-on, mono aborts. The backtrace in gdb
is almost the same, plus ~10 frames that look consistent and are related
to signal handling
Wow! I have just discovered that a patch in the FreeBSD port remove the
explicit activation of sigaltstack [1]. I removed all patches we provide
and only kept path fixes (e.g. /usr/bin/env {bash,perl} instead of
/bin/{bash,perl}).
The result is exactly the same (with a backtrace for all threads). You
can consider this vanilla mono 2.0.1:
| $ gdb ../mini/mono
| GNU gdb 6.1.1 [FreeBSD]
| Copyright 2004 Free Software Foundation, Inc.
| GDB is free software, covered by the GNU General Public License, and you are
| welcome to change it and/or distribute copies of it under certain
conditions.
| Type show copying to see the conditions.
| There is absolutely no warranty for GDB. Type show warranty for details.
| This GDB was configured as i386-marcel-freebsd...
| (gdb) r exception.exe
| Starting program:
/usr/home/romain/Projects/BSD-sharp-latest/lang/mono/work/mono-2.0.1/mono/mini/mono
exception.exe
| [New LWP 100408]
| [New Thread 0x29501100 (LWP 100408)]
| [New Thread 0x29564100 (LWP 100388)]
| [New Thread 0x29564c00 (LWP 100443)]
|
| Program received signal SIGFPE, Arithmetic exception.
| [Switching to Thread 0x29501100 (LWP 100408)]
| 0x294dc2d3 in ?? ()
| (gdb) thread apply all bt
|
| Thread 4 (Thread 0x29564c00 (LWP 100443)):
| #0 0x286ad3a3 in _umtx_op_err () at
/usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36
| #1 0x286ad141 in _thr_ucond_wait (cv=0x2956eae0, m=0x2956eac0,
timeout=0x0, check_unparking=1)
| at /usr/src/lib/libthr/thread/thr_umtx.c:129
| #2 0x286abb6d in cond_wait_common (cond=Variable cond is not available.
| ) at /usr/src/lib/libthr/thread/thr_cond.c:204
| #3 0x08191281 in timedwait_signal_poll_cond (cond=0x295740f0,
mutex=0x295740ec, timeout=0x0, alertable=0)
| at handles.c:1490
| #4 0x081915c6 in _wapi_handle_timedwait_signal_handle (handle=0x5804,
timeout=0x0, alertable=0)
| at handles.c:1570
| #5 0x081913cc in _wapi_handle_wait_signal_handle (handle=0x5804,
alertable=0) at handles.c:1530
| #6 0x081afbf8 in WaitForSingleObjectEx (handle=0x5804, timeout=4294967295,
alertable=0) at wait.c:205
| #7 0x0810182f in finalizer_thread (unused=0x0) at gc.c:908
| #8 0x08122d52 in start_wrapper (data=0x2956f960) at threads.c:621
| #9 0x081a9d8a in thread_start_routine (args=0x295741d4) at threads.c:279
| #10 0x081cd98e in GC_start_routine (arg=0x832bec0) at pthread_support.c:1382
| #11 0x286a5865 in thread_start (curthread=0x29564c00) at
/usr/src/lib/libthr/thread/thr_create.c:256
| #12 0x in ?? ()
| Current language: auto; currently asm
|
| Thread 3 (Thread 0x29564100 (LWP 100388)):
| #0 0x28769f53 in nanosleep () at nanosleep.S:2
| #1 0x286a47e2 in __nanosleep (time_to_sleep=0xbf9fef8c, time_remaining=0x0)
| at /usr/src/lib/libthr/thread/thr_syscalls.c:306
| #2 0x0818bcf5 in collection_thread (unused=0x0) at collection.c:34
| #3 0x286a5865 in thread_start (curthread=0x29564100) at
/usr/src/lib/libthr/thread/thr_create.c:256
| #4 0x in ?? ()
|
| Thread 2 (Thread 0x29501100 (LWP 100408)):
| #0 0x294dc2d3 in ?? ()
| #1 0xbfbfe774 in ?? ()
| #2 0xbfbfe474 in ?? ()
| #3 0x in ?? ()
| #4 0x in ?? ()
| #5 0x in ?? ()
| #6 0x0001 in ?? ()
| #7 0x in ?? ()
| #8 0x2951903c in ?? ()
| #9 0xbfbfe458 in ?? ()
| #10 0xbfbfe474 in ?? ()
| #11 0xbfbfe774 in ?? ()
| ---Type return to continue, or q return to quit---
| #12 0x000a in ?? ()
| #13 0xbfbfe474 in ?? ()
| #14 0x294dc259 in ?? ()
| #15 0x in ?? ()
| #16 0x in ?? ()
| #17 0xbfbfe498 in ?? ()
| #18 0x294dc1b7 in ?? ()
| #19 0x080d935e in mono_custom_attrs_from_index (image=0x0, idx=0) at
reflection.c:7730
| Previous frame inner to this frame (corrupt stack?)
| (gdb)
With regards,
Romain
References:
1.
http://code.google.com/p/bsd-sharp/source/browse/trunk/lang/mono/files/patch-configure
___
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] Mono 2.0 and FreeBSD
Actually scratch that, the SIGFPE is expected there, it gets translated
into an exception by our runtime. Have you tried compiling with
sigaltstack off as asked by zoltan? I updated my 7.0 VM to mono trunk,
and fail in exceptions.cs with the altstack code on. (I havn't tested
with it off yet)
-g
On Tue, 2008-12-09 at 11:30 -0500, Geoff Norton wrote:
Please file a bug for this issue in bugzilla and assign it to me.
-g
On Tue, 2008-12-09 at 12:57 +0100, Romain Tartière wrote:
On Mon, Dec 08, 2008 at 04:14:45PM +0100, Romain Tartière wrote:
As for the exception failures, running configure with
./configure --with-sigaltstack=no
might help.
Just tried it. Instead of hanging-on, mono aborts. The backtrace in gdb
is almost the same, plus ~10 frames that look consistent and are related
to signal handling
Wow! I have just discovered that a patch in the FreeBSD port remove the
explicit activation of sigaltstack [1]. I removed all patches we provide
and only kept path fixes (e.g. /usr/bin/env {bash,perl} instead of
/bin/{bash,perl}).
The result is exactly the same (with a backtrace for all threads). You
can consider this vanilla mono 2.0.1:
| $ gdb ../mini/mono
| GNU gdb 6.1.1 [FreeBSD]
| Copyright 2004 Free Software Foundation, Inc.
| GDB is free software, covered by the GNU General Public License, and you
are
| welcome to change it and/or distribute copies of it under certain
conditions.
| Type show copying to see the conditions.
| There is absolutely no warranty for GDB. Type show warranty for
details.
| This GDB was configured as i386-marcel-freebsd...
| (gdb) r exception.exe
| Starting program:
/usr/home/romain/Projects/BSD-sharp-latest/lang/mono/work/mono-2.0.1/mono/mini/mono
exception.exe
| [New LWP 100408]
| [New Thread 0x29501100 (LWP 100408)]
| [New Thread 0x29564100 (LWP 100388)]
| [New Thread 0x29564c00 (LWP 100443)]
|
| Program received signal SIGFPE, Arithmetic exception.
| [Switching to Thread 0x29501100 (LWP 100408)]
| 0x294dc2d3 in ?? ()
| (gdb) thread apply all bt
|
| Thread 4 (Thread 0x29564c00 (LWP 100443)):
| #0 0x286ad3a3 in _umtx_op_err () at
/usr/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36
| #1 0x286ad141 in _thr_ucond_wait (cv=0x2956eae0, m=0x2956eac0,
timeout=0x0, check_unparking=1)
| at /usr/src/lib/libthr/thread/thr_umtx.c:129
| #2 0x286abb6d in cond_wait_common (cond=Variable cond is not available.
| ) at /usr/src/lib/libthr/thread/thr_cond.c:204
| #3 0x08191281 in timedwait_signal_poll_cond (cond=0x295740f0,
mutex=0x295740ec, timeout=0x0, alertable=0)
| at handles.c:1490
| #4 0x081915c6 in _wapi_handle_timedwait_signal_handle (handle=0x5804,
timeout=0x0, alertable=0)
| at handles.c:1570
| #5 0x081913cc in _wapi_handle_wait_signal_handle (handle=0x5804,
alertable=0) at handles.c:1530
| #6 0x081afbf8 in WaitForSingleObjectEx (handle=0x5804,
timeout=4294967295, alertable=0) at wait.c:205
| #7 0x0810182f in finalizer_thread (unused=0x0) at gc.c:908
| #8 0x08122d52 in start_wrapper (data=0x2956f960) at threads.c:621
| #9 0x081a9d8a in thread_start_routine (args=0x295741d4) at threads.c:279
| #10 0x081cd98e in GC_start_routine (arg=0x832bec0) at
pthread_support.c:1382
| #11 0x286a5865 in thread_start (curthread=0x29564c00) at
/usr/src/lib/libthr/thread/thr_create.c:256
| #12 0x in ?? ()
| Current language: auto; currently asm
|
| Thread 3 (Thread 0x29564100 (LWP 100388)):
| #0 0x28769f53 in nanosleep () at nanosleep.S:2
| #1 0x286a47e2 in __nanosleep (time_to_sleep=0xbf9fef8c,
time_remaining=0x0)
| at /usr/src/lib/libthr/thread/thr_syscalls.c:306
| #2 0x0818bcf5 in collection_thread (unused=0x0) at collection.c:34
| #3 0x286a5865 in thread_start (curthread=0x29564100) at
/usr/src/lib/libthr/thread/thr_create.c:256
| #4 0x in ?? ()
|
| Thread 2 (Thread 0x29501100 (LWP 100408)):
| #0 0x294dc2d3 in ?? ()
| #1 0xbfbfe774 in ?? ()
| #2 0xbfbfe474 in ?? ()
| #3 0x in ?? ()
| #4 0x in ?? ()
| #5 0x in ?? ()
| #6 0x0001 in ?? ()
| #7 0x in ?? ()
| #8 0x2951903c in ?? ()
| #9 0xbfbfe458 in ?? ()
| #10 0xbfbfe474 in ?? ()
| #11 0xbfbfe774 in ?? ()
| ---Type return to continue, or q return to quit---
| #12 0x000a in ?? ()
| #13 0xbfbfe474 in ?? ()
| #14 0x294dc259 in ?? ()
| #15 0x in ?? ()
| #16 0x in ?? ()
| #17 0xbfbfe498 in ?? ()
| #18 0x294dc1b7 in ?? ()
| #19 0x080d935e in mono_custom_attrs_from_index (image=0x0, idx=0) at
reflection.c:7730
| Previous frame inner to this frame (corrupt stack?)
| (gdb)
With regards,
Romain
References:
1.
http://code.google.com/p/bsd-sharp/source/browse/trunk/lang/mono/files/patch-configure
___
Mono-devel-list mailing list
Mono
Re: [Mono-dev] Mono 2.0 and FreeBSD
Its also worth noting that mono building itself is no small feat. If there are specific programs/tests failing with mono (without some set of unknown freebsd patches applied), please file bugs for each of the issues. -g On Mon, 2008-12-08 at 15:07 +0100, Zoltan Varga wrote: Hi, It is possible that freebsd changes broke mono, not mono changes. As for the exception failures, running configure with ./configure --with-sigaltstack=no might help. Zoltan 2008/12/8 Romain Tartière [EMAIL PROTECTED]: Hello, [Note to Geoff Norton in CC] I saw a message [0] from you about Mono working on FreeBSD so I put you in CC since you may have some relevant information to provide ;-) [End of note] The BSD# project [1] aims to bring Mono 2.0 on the FreeBSD operating system. While Mono is already available on this platform [2], it is quite outdated: the latests available version is 1.2.5.1. Updating to the latest version is unfortunately not as easy as expected: basically, mono builds without incident, but not all programs are working correctly. Regression tests are causing trouble, so I guess they have to pass before we can try to see what is okay and what is not. In the past few weeks, I tried to track down the mono subversion tree to get to the commit that broke NullReferenceException down: the test mono/tests/exception.exe pass with =mono-1.2.5.1 but either ABRT or hangs-on with more recent version of mono. I stopped my tests with the version of 2006-10-31 (rev. 67196) from the trunk where the problem is still present. As far I as understand, the development did not took place in trunk or patches where applied for the release since mono-1.2.5 was tagged many month after this date. I am therefore still not able to understand what is happening and I am so trying to get more info at the source. I have put the result of running exception.exe here [3]. The program [3.1] hangs consuming CPU time until it gets killed. I am not sure about the gdb backtrace [3.2]: I followed the instructions about debugging [4] but I have weird results such as: #3 0x in ?? () #4 0x in ?? () #5 0x in ?? () #6 0x0001 in ?? () #7 0x in ?? () ... which I don't think is good (too much 0x)... This is on FreeBSD 7.1-PRERELEASE i386 with mono-2.0.1 [3.3]. Any idea for a better backtrace is welcomed. Any hint is welcomed. Any branch of mono to checkout and test too. If required, I can even provide an SSH connection to a FreeBSD box and assistance to a Mono-guru to hack and fix this bug (Okay, I think you understood that I _really_ want this to work on FreeBSD!). I hope that mixing the BSD# team's knowledge of FreeBSD and your knowledge of Mono internals will result in having a working Mono 2.0 on FreeBSD! With kind regards, Romain Tartière, on behalf of the BSD# Project. References: 0. http://lists.ximian.com/pipermail/mono-devel-list/2008-November/029685.html 1. http://code.google.com/p/bsd-sharp/ 2. http://www.freshports.org/lang/mono/ 3. http://mono.sigabrt.org/ 3.1 http://mono.sigabrt.org/exception.cs 3.2 http://mono.sigabrt.org/gdb 3.3 http://mono.sigabrt.org/VERSION 4. http://www.mono-project.com/Debugging -- Romain Tartière [EMAIL PROTECTED]http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) ___ 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] Mono 2.0 and FreeBSD
On Mon, 2008-12-08 at 16:14 +0100, Romain Tartière wrote: The line « warning: Source file is more recent than executable. » makes me feel uncomfortable however. This is more than uncomfortable, it means we cannot trust any of your stack traces. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GetHashCode() implementation for class string
The java version cannot be used either, as it is GPL'd.
Please do not advise people to look at other sources without
understanding all the implications.
-g
On Mon, 2008-12-08 at 07:25 +0300, Евгений Гришуль wrote:
I know about that violations and have never read their code. Mono
contributors can use Java version of hash code function. I just
suggest possible ways to solve problem =)
2008/12/8 Atsushi Eno [EMAIL PROTECTED]
Do NOT read MS BCL source code. Jack, now we will never accept
your contributions to protect copyright violation possibly
brought by you.
It is EXPLICITLY written in our TOP page for contribution.
http://mono-project.com/Contributing
Atsushi Eno
Jack wrote:
You can use Java version of hash code that loos like:
public static int JavaStringHashCode( string
value )
{
int result = 0;
foreach( char character in value )
result = 31 * result + character;
return result;
}
Also you can look into Microsoft's BCL sources to find
appropriate implementation.
WBR,
Eugeny Grishul
On Mon, 08 Dec 2008 01:47:43 +0300, Alan McGovern
[EMAIL PROTECTED] wrote:
On Mon, Dec 1, 2008 at 9:44 PM, CarGa
[EMAIL PROTECTED] wrote:
Hello, all!
I was directed here by Atsushi Eno
from mono-olive list with this
question/request about GetHashCode()
method.
DependencyProperty class (that lays at
the very base of entire WWF and WPF
libraries) heavily depends on quality
of GetHashCode() method since we use
it to find any particular
DependencyProperty in some huge
Dictionaryint,
DependencyProperty of others.
If i understand correctly, you're using the
hashcode fo a DP as a unique
identifier. This is wrong. Hashcodes are by
definition *not* a unique
identifer and should not be used as such.
You're completly misusing the
hashcode in this case. Your code will never
run correctly if you are using
.GetHashCode() to supply the 'int' in
Dictionaryint, DependencyProperty
Alan.
--
WBR,
Grishul Eugeny
___
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] Can anyone review this fix for FreeBSD build?
Eno,
Whats the testcase/rationale for this patch?
On Sun, 2008-11-09 at 23:34 +0900, Atsushi Eno wrote:
Atsushi Eno
Index: configure.in
===
--- configure.in (revision 118305)
+++ configure.in (working copy)
@@ -2054,6 +2054,37 @@
unset fpu
fi
+case $host_os in
+darwin* | *bsd* )
+ AC_MSG_CHECKING(if sysctl.h defines kinfo_proc completely)
+ AC_TRY_COMPILE([
+ #include sys/types.h
+ #include sys/sysctl.h
+ ], [
+ struct kinfo_proc kp;
+ ],
+ AC_MSG_RESULT(yes)
+ AC_DEFINE(SYSCTL_H_DEFINES_KINFO_PROC, 1, [sysctl.h has complete
definition of struct kinfo_proc])
+ ,
+ AC_MSG_RESULT(no)
+
+ AC_MSG_CHECKING(if struct kinfo_proc has member kp_proc)
+ AC_TRY_COMPILE([
+ #include sys/types.h
+ #include sys/user.h
+ ], [
+ struct kinfo_proc kp;
+ kp.kp_proc;
+ ],
+ AC_MSG_RESULT(yes)
+ ,
+ AC_MSG_RESULT(no)
+ AC_DEFINE(KINFO_PROC_HAS_NO_KP_PROC, 1, [struct
kinfo_proc has no
member kp_proc])
+ )
+ )
+ ;;
+esac
+
if test ${TARGET} = unknown; then
CPPFLAGS=$CPPFLAGS -DNO_PORT
AC_MSG_WARN(mono has not been ported to $host: some things may not
work.)
Index: mono/utils/mono-proclib.c
===
--- mono/utils/mono-proclib.c (revision 118305)
+++ mono/utils/mono-proclib.c (working copy)
@@ -17,6 +17,9 @@
#include sys/types.h
#include sys/sysctl.h
#include sys/proc.h
+# if !defined SYSCTL_H_DEFINES_KINFO_PROC
+#include sys/user.h
+# endif
#define USE_SYSCTL 1
#endif
@@ -54,8 +57,13 @@
}
res = data_len/sizeof (struct kinfo_proc);
buf = g_realloc (buf, res * sizeof (void*));
+# if !defined KINFO_PROC_HAS_NO_KP_PROC
for (i = 0; i res; ++i)
buf [i] = GINT_TO_POINTER (processes [i].kp_proc.p_pid);
+# else
+ for (i = 0; i res; ++i)
+ buf [i] = GINT_TO_POINTER (processes [i].ki_pid);
+# endif
free (processes);
if (size)
*size = res;
@@ -162,7 +170,11 @@
if (res 0 || data_len != sizeof (struct kinfo_proc)) {
return buf;
}
+# if !defined KINFO_PROC_HAS_NO_KP_PROC
strncpy (buf, processi.kp_proc.p_comm, len - 1);
+# else
+ strncpy (buf, processi.ki_comm, len - 1);
+# endif
return buf;
#else
char fname [128];
___
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
