[us...@lists.monobjc.net] Monobjc is breaking AppDomain.CreateDomain?
Hi,
I have a problem.
I've noticed that when you use
AppDomain.CreateDomain("name");
and somewhere in your app, there is a reference to the MonobjC assembly,
it throws an exception.
In other words, it's not possible to create a second AppDomain.
Is there any way to get around this?
In the second AppDomain, I don't even need Monobjc...
The exception can be found below.
Thanks,
- Kenny
Exception:
TypeInitializationException
An exception was thrown by the type initializer for
System.Runtime.Serialization.Formatters.Binary.CodeGenerator
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.CreateMemberTypeMetadata
(System.Type type) [0x0]
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.GetObjectData (System.Object
obj, System.Runtime.Serialization.Formatters.Binary.TypeMetadata&
metadata, System.Object& data) [0x0]
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject
(System.IO.BinaryWriter writer, Int64 id, System.Object obj) [0x0]
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectInstance
(System.IO.BinaryWriter writer, System.Object obj, Boolean
isValueObject) [0x0]
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQueuedObjects
(System.IO.BinaryWriter writer) [0x0]
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectGraph
(System.IO.BinaryWriter writer, System.Object obj,
System.Runtime.Remoting.Messaging.Header[] headers) [0x0]
at
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize
(System.IO.Stream serializationStream, System.Object graph,
System.Runtime.Remoting.Messaging.Header[] headers) [0x0]
at
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize
(System.IO.Stream serializationStream, System.Object graph) [0x0]
at System.Runtime.Remoting.Channels.CADSerializer.SerializeObject
(System.Object obj) [0x0]
at System.Runtime.Remoting.Messaging.CADMethodCallMessage..ctor
(IMethodCallMessage callMsg) [0x0]
at System.Runtime.Remoting.Messaging.CADMethodCallMessage.Create
(IMessage callMsg) [0x0]
at
System.Runtime.Remoting.Channels.CrossAppDomainSink.SyncProcessMessage
(IMessage msgRequest) [0x0]
InnerException: NotSupportedException
The invoked member is not supported in a dynamic module.
at System.Reflection.Emit.AssemblyBuilder.GetExportedTypes () [0x0]
at Monobjc.ObjectiveCRuntime.ScanAssembly (System.Reflection.Assembly
assembly) [0x0]
at Monobjc.ObjectiveCRuntime.CurrentDomain_AssemblyLoad
(System.Object sender, System.AssemblyLoadEventArgs args) [0x0]
at System.AppDomain.DoAssemblyLoad (System.Reflection.Assembly
assembly) [0x0]
at (wrapper managed-to-native)
System.Reflection.Emit.AssemblyBuilder:basic_init
(System.Reflection.Emit.AssemblyBuilder)
at System.Reflection.Emit.AssemblyBuilder..ctor
(System.Reflection.AssemblyName n, System.String directory,
AssemblyBuilderAccess access, Boolean corlib_internal) [0x0]
at System.AppDomain.DefineInternalDynamicAssembly
(System.Reflection.AssemblyName name, AssemblyBuilderAccess access)
[0x0]
at (wrapper remoting-invoke-with-check)
System.AppDomain:DefineInternalDynamicAssembly
(System.Reflection.AssemblyName,System.Reflection.Emit.AssemblyBuilderAccess)
at
System.Runtime.Serialization.Formatters.Binary.CodeGenerator..cctor ()
[0x0]
[us...@lists.monobjc.net] Re: Monobjc is breaking AppDomain.CreateDomain?
Hi,
Monobjc version: 1.0.324.0. I'm using the 1.0 assemblies, because I need
Tiger support.
Haven't tried in the new version of Monobjc yet.
mono -V:
Mono JIT compiler version 2.4 (tarball Fri Mar 13 09:25:35 MDT 2009)
It's reproducable in any Monobjc app with 1 single line:
AppDomain.CreateDomain("name");
I've put this line in the SimpleCocoaApp Sample
SimpleCocoaApp/HelloController.cs
Just put this line in the awakeFromNib function and the app will crash
at startup.
Regards,
Kenny Clement
Laurent Etiemble wrote:
Hello,
Can you indicate the version of Mono and Monobjc ? Also, can you post
a small sample code to demonstrate the problem ?
Regards, Laurent Etiemble.
2009/8/13 Kenny Clement:
Hi,
I have a problem.
I've noticed that when you use
AppDomain.CreateDomain("name");
and somewhere in your app, there is a reference to the MonobjC assembly, it
throws an exception.
In other words, it's not possible to create a second AppDomain.
Is there any way to get around this?
In the second AppDomain, I don't even need Monobjc...
The exception can be found below.
Thanks,
- Kenny
Exception:
TypeInitializationException
An exception was thrown by the type initializer for
System.Runtime.Serialization.Formatters.Binary.CodeGenerator
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.CreateMemberTypeMetadata
(System.Type type) [0x0]
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.GetObjectData
(System.Object obj,
System.Runtime.Serialization.Formatters.Binary.TypeMetadata& metadata,
System.Object& data) [0x0]
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject
(System.IO.BinaryWriter writer, Int64 id, System.Object obj) [0x0]
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectInstance
(System.IO.BinaryWriter writer, System.Object obj, Boolean isValueObject)
[0x0]
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQueuedObjects
(System.IO.BinaryWriter writer) [0x0]
at
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectGraph
(System.IO.BinaryWriter writer, System.Object obj,
System.Runtime.Remoting.Messaging.Header[] headers) [0x0]
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize
(System.IO.Stream serializationStream, System.Object graph,
System.Runtime.Remoting.Messaging.Header[] headers) [0x0]
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize
(System.IO.Stream serializationStream, System.Object graph) [0x0]
at System.Runtime.Remoting.Channels.CADSerializer.SerializeObject
(System.Object obj) [0x0]
at System.Runtime.Remoting.Messaging.CADMethodCallMessage..ctor
(IMethodCallMessage callMsg) [0x0]
at System.Runtime.Remoting.Messaging.CADMethodCallMessage.Create (IMessage
callMsg) [0x0]
at System.Runtime.Remoting.Channels.CrossAppDomainSink.SyncProcessMessage
(IMessage msgRequest) [0x0]
InnerException: NotSupportedException
The invoked member is not supported in a dynamic module.
at System.Reflection.Emit.AssemblyBuilder.GetExportedTypes () [0x0]
at Monobjc.ObjectiveCRuntime.ScanAssembly (System.Reflection.Assembly
assembly) [0x0]
at Monobjc.ObjectiveCRuntime.CurrentDomain_AssemblyLoad (System.Object
sender, System.AssemblyLoadEventArgs args) [0x0]
at System.AppDomain.DoAssemblyLoad (System.Reflection.Assembly assembly)
[0x0]
at (wrapper managed-to-native)
System.Reflection.Emit.AssemblyBuilder:basic_init
(System.Reflection.Emit.AssemblyBuilder)
at System.Reflection.Emit.AssemblyBuilder..ctor
(System.Reflection.AssemblyName n, System.String directory,
AssemblyBuilderAccess access, Boolean corlib_internal) [0x0]
at System.AppDomain.DefineInternalDynamicAssembly
(System.Reflection.AssemblyName name, AssemblyBuilderAccess access)
[0x0]
at (wrapper remoting-invoke-with-check)
System.AppDomain:DefineInternalDynamicAssembly
(System.Reflection.AssemblyName,System.Reflection.Emit.AssemblyBuilderAccess)
at System.Runtime.Serialization.Formatters.Binary.CodeGenerator..cctor ()
[0x0]
Re: [us...@lists.monobjc.net] Feeback Wanted on Snow Leopard
Hi, Just so you know, The bugreport you see below is the one I posted on mono's bugzilla. I think it is caused by Mono's boehm GC, and not specifically MonobjC, even though I cannot be sure, so far. I have a few smaller sample apps using Mono and MonObjC, and none of those crash. However, my main, way more complex app, has this issue. Other people on the mono-osx mailing list have reported this as well. I've been working on this for a bit now, but I still haven't found a way to reproduce outside of my main app (of which I cannot share the code here). I didn't see a link between the GC and the threading yet, I'll try to write another sample with some threading and see if that causes the issue. If you find any solution or have any clue on how to reproduce it, it would be very much appreciated!! - Kenny Clement Franky De Meyer wrote: Here's some further info on my problems with Snow Leopard. Our app appears to crash at random points, very soon after startup, when threading is busy. The error log always seems to refer to GC in combination with threads. I noticed a bug report at the Mono site, also referring to monobjc, so this may not be a coincidence: https://bugzilla.novell.com/show_bug.cgi?id=537764 I have exactly the same problem. Laurent, did you get to do some testing on Snow Leopard yourself? If so, do you have the feeling that all functionality should simply work, including threading? If so, can you give any suggestions on what we can do to isolate this problem? It may be mono-related or monobjc related, what is your guess? Thanks! Franky Here is an example error log I got (Mac OSX 10.6, Mono 2.4.2.3_3, Monobjc 1.0.413): Thread 11 Crashed: 0 libSystem.B.dylib 0x95a62c8e __semwait_signal_nocancel + 10 1 libSystem.B.dylib 0x95a62b72 nanosleep$NOCANCEL$UNIX2003 + 166 2 libSystem.B.dylib 0x95ade5b2 usleep$NOCANCEL$UNIX2003 + 61 3 libSystem.B.dylib 0x95affbfd __abort + 136 4 libSystem.B.dylib 0x95affc6d abort_report_np + 0 5 DM 0x0012c5b8 GC_enable + 0 (misc.c:1080) 6 DM 0x00123c12 GC_push_all_stacks + 196 (darwin_stop_world.c:119) 7 DM 0x0012d8ff GC_default_push_other_roots + 11 (os_dep.c:2079) 8 DM 0x0012b6ce GC_push_roots + 279 (mark_rts.c:651) 9 DM 0x00128a85 GC_mark_some + 593 (mark.c:327) 10 DM 0x00122290 GC_stopped_mark + 525 (alloc.c:543) 11 DM 0x00121de9 GC_try_to_collect_inner + 449 (alloc.c:382) 12 DM 0x00123019 GC_collect_or_expand + 151 (alloc.c:1046) 13 DM 0x00123304 GC_allocobj + 313 (alloc.c:1125) 14 DM 0x00126f2f GC_generic_malloc_inner + 270 (malloc.c:136) 15 DM 0x00127086 GC_generic_malloc + 84 (malloc.c:192) 16 DM 0x0012728d GC_malloc_atomic + 142 (malloc.c:262) 17 DM 0x000ae5ec mono_array_new_specific + 206 (object.c:3536) 18 ??? 0x00e56a6b 0 + 15034987 19 ??? 0x147d1dd2 0 + 343743954 20 ??? 0x147d25a8 0 + 343745960 21 ??? 0x147d22ba 0 + 343745210 22 ??? 0x147d1966 0 + 343742822 23 ??? 0x147da4ac 0 + 343778476 24 ??? 0x147da1fa 0 + 34386 25 ??? 0x147d9326 0 + 343773990 26 ??? 0x147d92a4 0 + 343773860 27 ??? 0x147f92dd 0 + 343904989 28 ??? 0x147f9262 0 + 343904866 29 ??? 0x147f920f 0 + 343904783 30 ??? 0x147f9a6a 0 + 343906922 31 ??? 0x147f99b7 0 + 343906743 32 ??? 0x0327fa19 0 + 52951577 33 ??? 0x0327f9ba 0 + 52951482 34 ??? 0x0327f83a 0 + 52951098 35 ??? 0x0327f78d 0 + 52950925 36 ??? 0x0327f6d9 0 + 52950745 37 ??? 0x0327f651 0 + 52950609 38 ??? 0x189db63c 0 + 412988988 39 ??? 0x032872bc 0 + 52982460 40 ??? 0x03287223 0 + 52982307 41 ??? 0x03287208 0 + 52982280 42 ??? 0x03286d95 0 + 52981141 43 ??? 0x03286c13 0 + 52980755 44 ??? 0x032869a8 0 + 52980136 45 ??? 0x00e56086 0 + 15032454 46 DM 0x000adc67 mono_runtime_invoke_array + 592 (object.c:3495) 47 DM 0x000ae74a mono_message_invoke + 225 (object.c:5010) 48 D
Re: [us...@lists.monobjc.net] Re: [us...@lists.monobjc.net] Feeback Wanted on Snow Leopard
0x02f1268e 0 + 49358478 41 ??? 0x02f12622 0 + 49358370 42 ??? 0x02f123c7 0 + 49357767 43 ??? 0x02f121f1 0 + 49357297 44 ??? 0x02f12162 0 + 49357154 45 ??? 0x02f1185e 0 + 49354846 46 ??? 0x00e562bd 0 + 15033021 MONOBJC TRACE: thread_get_state failed Stacktrace: at (wrapper managed-to-native) object.__icall_wrapper_mono_object_new_fast (intptr) <0x4> at (wrapper managed-to-native) object.__icall_wrapper_mono_object_new_fast (intptr) <0x> at System.Reflection.Emit.TypeBuilder.DefinePInvokeMethod (string,string,string,System.Reflection.MethodAttributes,System.Reflection.C allingConventions, System.Type,System.Type[],System.Type[],System.Type[],System.Type[][], System.Type[][],System.Runtime.InteropServices.CallingConvention,System.Runt ime.InteropServices.CharSet) <0x00085> at System.Reflection.Emit.TypeBuilder.DefinePInvokeMethod (string,string,string,System.Reflection.MethodAttributes, System.Reflection.CallingConventions,System.Type, System.Type[],System.Runtime.InteropServices.CallingConvention,System.Runtim e.InteropServices.CharSet) <0x00033> at Monobjc.Bridge.Generators.DynamicMessagingGenerator.DefineNativeCallMethod (System.Reflection.Emit.TypeBuilder,string,string,System.Type,System.Type[]) <0x000f3> at Monobjc.Bridge.Generators.DynamicMessagingGenerator.EmitCodeForBlittableType (System.Reflection.Emit.TypeBuilder,string,string,System.Type,System.Type[]) <0x0001e> at Monobjc.Bridge.Generators.DynamicMessagingGenerator.DefineMessagingDelegate (string,string,System.Type[]) <0x0003b> at Monobjc.Bridge.Generators.DynamicMessagingGenerator.SendMessage (string,intptr,intptr,object[]) <0x0010a> at Monobjc.ObjectiveCRuntime.SendMessage (Monobjc.IManagedWrapper,string,object[]) <0x00078> at Monobjc.Cocoa.NSButton.set_Image (Monobjc.Cocoa.NSImage) <0x00046> at DM.StockController.SetUploadStatusStates () <0x00052> at DM.StockController.AwakeFromNib () <0x004ad> at Monobjc.Dynamic.Proxies.DM.StockController.AwakeFromNib (intptr,intptr) <0x00036> at (wrapper native-to-managed) Monobjc.Dynamic.Proxies.DM.StockController.AwakeFromNib (intptr,intptr) <0x> at (wrapper managed-to-native) 364DB0EB.pinvoke (intptr,intptr,intptr,intptr) <0x4> at (wrapper managed-to-native) 364DB0EB.pinvoke (intptr,intptr,intptr,intptr) <0x> at 364DB0EB.objc_msgSend (intptr,intptr,object[]) <0x000c9> at Monobjc.Bridge.Generators.DynamicMessagingGenerator.SendMessage (string,intptr,intptr,object[]) <0x00166> at Monobjc.ObjectiveCRuntime.SendMessage (Monobjc.IManagedWrapper,string,object[]) <0x00078> at Monobjc.Cocoa.NSBundle.LoadNibNamedOwner (Monobjc.Cocoa.NSString,Monobjc.Id) <0x00061> at Monobjc.Cocoa.NSApplication.LoadNib (string) <0x00055> at DM.Program.Main (string[]) <0x0003c> Abort trap -Original Message- From: laurent.etiem...@gmail.com [mailto:laurent.etiem...@gmail.com] On Behalf Of Laurent Etiemble Sent: maandag 14 september 2009 22:42 To: users@lists.monobjc.net Subject: Re: [users@lists.monobjc.net] Re: [us...@lists.monobjc.net] Feeback Wanted on Snow Leopard Hello, @Franky: Until now, I have tested the 27 samples applications on Core Duo and Core 2 Duo processors. On both platforms, the application runs as a 32 bits process, with no problems or crashes. @Everyone: Does the application that crashes uses System.Drawing or System.Windows.Forms ? Regards, Laurent Etiemble. 2009/9/14 Russell Joyce : I'm getting the same "thread_get_state failed" error. It usually occurs if I'm doing something which pauses the application (such as resizing the windows or using menus) at the same time as an event fires (such as a Windows.Forms.Timer tick) but sometimes just occurs (seemingly) randomly. Monobjc events don't seem to cause this problem though when using objective-c selectors (such as NSTimer fire events), but I may be wrong. I'm glad this isn't just a problem with my application and is something more common, as I was not using Monobjc before Snow Leopard so I've always had this problem. I've got Leopard installed on a different partition still though so I can always develop there for now... -- Kenny Clement Software Developer Tel. +32 9 233 68 86 Fax +32 9 240 10 39 kenny.clem...@nomadesk.com twitter.com/nomadesk Confidentiality Notice: This message, together with any attachments, is intended only for the use of the individual or entity to which it is addressed. It may contain information that is confidential and prohibited from disclosure. If you are not the intende
Re: [us...@lists.monobjc.net] Re: [us...@lists.monobjc.net] Feeback Wanted on Snow Leopard
any movement. Any idea on how we can trigger the nice mono people to look into the issue ? Best regards, Miguel Franky De Meyer wrote: @Laurent: Did you get a chance to try out the modified sample app that Kenny created? If so, what is your feeling? Does it indeed look like a Mono problem related to garbage collection? There doesn't seem to be any action in the bugzilla report https://bugzilla.novell.com/show_bug.cgi?id=537764 I have taken the liberty to change the severity to "Major" (actually it should even be "Critical", IMHO), but I get a feeling we may be weeks or months away from a reply or fix. No other developers seem to be confirming the problem, which is weird. I'm getting more and more questions from users who have upgraded to Snow Leopard and can no longer use our software. @Kenny: Did you find out anything more on this? Any clues on a work-around. Thanks all! Franky From: Kenny Clement [mailto:psyki...@gmail.com] Sent: dinsdag 15 september 2009 19:49 To: users@lists.monobjc.net Cc: psyki.be+nomad...@gmail.com Subject: Re: [users@lists.monobjc.net] Re: [us...@lists.monobjc.net] Feeback Wanted on Snow Leopard Hi, Me again. I narrowed it down a bit more. I adjusted the SimpleCocoaApp MonoObjc sample. I removed all unrequired stuff, and just kept 1 button connected to an action in HelloController. Clicking the button will open the default about panel, sleep for 1 millisec, and then force Garbage Collection. This ALWAYS causes the crash on Snow Leopard, and works without any issues on Leopard. Note that I didn't do anything with threading (excluding default Mono/MonobjC threads) in this sample. You can find the sample app + sourcecode attached to the original bug report: https://bugzilla.novell.com/show_bug.cgi?id=537764 I hope someone here can help me. Feel free to contact me if there are any questions. Thanks in advance, - Kenny Laurent Etiemble wrote: Hello, @Franz: - Can you append the stack trace and all the information to the this bug entry (https://bugzilla.novell.com/show_bug.cgi?id=537764) ? - Are you able to get a small sample application (only with the awakeFromNib call) method that exhibits the crash, so I can investigate ? Regards, Laurent Etiemble. ith any attachments. -- Miguel DE BUF CTO Error! Filename not specified. Tel. +32 9 233 68 86 Fax +32 9 240 10 39 miguel.de...@nomadesk.com Confidentiality Notice: This message, together with any attachments, is intended only for the use of the individual or entity to which it is addressed. It may contain information that is confidential and prohibited from disclosure. If you are not the intended recipient, you are hereby notified that any dissemination or copying of this message or any attachment is strictly prohibited. If you have received this item in error, please notify the original sender and destroy this item, along with any attachments. -- Kenny Clement Software Developer Tel. +32 9 233 68 86 Fax +32 9 240 10 39 kenny.clem...@nomadesk.com twitter.com/nomadesk Confidentiality Notice: This message, together with any attachments, is intended only for the use of the individual or entity to which it is addressed. It may contain information that is confidential and prohibited from disclosure. If you are not the intended recipient, you are hereby notified that any dissemination or copying of this message or any attachment is strictly prohibited. If you have received this item in error, please notify the original sender and destroy this item, along with any attachments.
Re: [us...@lists.monobjc.net] Backgroundworker thread
Hi, The way I do it, I make sure the MonobjC objects are only used on 1 thread. Make sure all stuff on the backgroundworker threads is pure mono only, if you need to use MonobjC objects, throw events and invoke those on your 'cocoa' thread. However, a better way, is probably described on the Monobjc site: http://www.monobjc.net/index.php?page=multithreading Is your application in Multithreaded mode? If it already is, can you use NSThreadRunner instead of .NET backgroundworkers? - Kenny Mario De Clippeleir wrote: Hi, I am using a backgroudworker to show progress of a task. This compiles and runs fine (it shows the progress), however i always get a lot of notifications : "object of class autoreleased with no pool in place". So i defined a NSAutoreleasepool in the DoWork event and release it after it has done all the work, but still i have the same problem. I'm pretty much stuck hereAny help ? Thanks, Mario -- Kenny Clement Software Developer Tel. +32 9 233 68 86 Fax +32 9 240 10 39 kenny.clem...@nomadesk.com twitter.com/nomadesk Confidentiality Notice: This message, together with any attachments, is intended only for the use of the individual or entity to which it is addressed. It may contain information that is confidential and prohibited from disclosure. If you are not the intended recipient, you are hereby notified that any dissemination or copying of this message or any attachment is strictly prohibited. If you have received this item in error, please notify the original sender and destroy this item, along with any attachments.
Re: [us...@lists.monobjc.net] Re: [us...@lists.monobjc.net] Feeback Wanted on Snow Leopard
Franky, For glib, I'm using the following: CC="cc -L/Users/fdm/Mono/lib" CFLAGS="-I/Users/fdm/Mono/include -m32" PATH=/Users/fdm/Mono/bin:$PATH ./configure --prefix=/Users/fdm/Mono sorry, I forgot that CC and extra CFLAGS in my previous mail. When I got your gettext error, it was because my mono prefix was not in the path, however, you say it is. I also did an upgrade from leopard to Snow. My application is now working without crashes, however, on a certain window in my app, CPU spikes to 100% whenever something on the form is changed. This CPU spike only occurs after a few hours (or lots of activity), it seems to 'build up' and after a while, the app is no longer usable. Still investigating, trying to turn off some bindings, ... seeing if that helps or not. I didn't get this behaviour on Leopard / old mono, so it must be something in either Snow Leopard, or the new Mono (after all, it is an svn build, not an official release). I also see some issues when building my app with integrated mono, it fails a lot more than on regular leopard. I don't think either of those issues is related to the patch from Laurent/Sledge Ham, but we're still testing... mvg, - Kenny Franky De Meyer wrote: Thanks for the extra info for the Snow Leopard build. It helped me get a little further now: "GNU Gettext" and "pkg-config" now both build OK on Snow Leopard. The "glib" configure however stops with following error: (After installing Gettext and pkg-config in /Users/fdm/Mono) When I execute: cd glib-2.22.0 CFLAGS="-m32" CXXFLAGS="-m32" CC="cc -L/Users/fdm/Mono/lib" ./configure --prefix=/Users/fdm/Mono I get the following output: (only the last few lines shown) ... checking for libintl.h... yes checking for ngettext in libc... no checking for bindtextdomain in -lintl... no checking if -liconv is needed to use gettext... checking for ngettext in -lintl... no configure: error: *** You must have either have gettext support in your C library, or use the *** GNU gettext library. (http://www.gnu.org/software/gettext/gettext.html -- So, there must still be something I'm doing wrong. The install of gettext-0.17 was OK, and was built with the same settings as glib. I can just type gettext at the command prompt however, and it is found.I have the latest XCode version. I did do an upgrade from Leopard to Snow Leopard and not a fresh install. Maybe that has something to do with it. In any case, thanks for your help. BTW, does your app work OK on Snow Leopard, with the latest patch from Laurent? Regards, Franky From: Kenny Clement [mailto:psyki...@gmail.com] Sent: donderdag 1 oktober 2009 9:56 To: users@lists.monobjc.net Subject: Re: [us...@lists.monobjc.net] Re: [us...@lists.monobjc.net] Feeback Wanted on Snow Leopard Franky, I've struggled with the same issues. In order to build Mono on Snow Leopard, you need the CFLAGS and CXXFlags set to -m32 for Mono and all the components required for it (gettext, pkg-config, libiconv, glib): example: CFLAGS="-m32" CXXFLAGS="-m32" ./configure --prefix=/mono make make install (note that the prefix should be changed to where-ever you want to install it.) Add the prefix path to your envvar PATH if it is not yet in there. (otherwise it will complain about not finding gettext, ...) In case you get 'deprecated' errors in ucontext, add the following line at the top in /usr/include/ucontext.h: #define _XOPEN_SOURCE 500 (I'm sure there is a better way, but this works for me.) nant is a separate install (build) if you compile Mono: http://www.mono-project.com/NAnt_Installation Hope this helps! - Kenny
[us...@lists.monobjc.net] Localizing app: Nib not found errors
Hi,
I'm running into a problem localizing our application.
The way it should work:
Copy the en.lproj folder to nl.lproj, adjust the texts, and you should
have a dutch version.
This works in sample applications (so I guess it's not really a
problem caused by monobjc)
However, in my application, it does not.
I have the folowing folders with nibs: en.lproj, nl.lproj, fr.lproj
All of these have working nib files.
If I change my preferred OS language to Dutch, I expect to see the
nibs from nl.lproj. I see the English ones.
When removing en.lproj, I get no more UI, no menu, ...
All MonobjC shows me is the following error: (upping the
MONOBJC_DEBUG level doesn't show more)
633946702097321770 [ERROR] NSApplication - Error while loading the NIB
file
It seems as if it simply can't find the nl.lproj folder, even though
it is there.
In Finder: app ==> get Info ==> Languages, I can see the 3 languages.
In order to find more info, I tried to loop through the
NSBundle.MainBundle.Localizations property.
According to the documentation (both MonobjC and Cocoa), this should
return an NSArray, with NSStrings of the languages available in the
bundle.
However, this property does return an NSArray, which contains 3
elements (I'm assuming this is nl, fr and en), but the elements are
not NSStrings (I'm getting Id's, casting to NSStrings throws
exceptions).
Why aren't these NSStrings?
I'm loading my nib with the line:
NSApplication.LoadNib("MainMenu");
According to the MonObjC code, this is just a shortcut to
NSBundle.LoadNibNamedOwner("Mainmenu", NSApplication.SharedApplication).
According to the MonObjC Documentation of NSBundle.LoadNibNamedOwner,
the path where Cocoa looks for the Nibs is determined by the owner. In
this case, taht would be NSApplication.SharedApplication.
Is there any way I can see more information, like the exact paths it
is looking for?
I'm hoping someone here can point me in the right direction, or show
me a way to get more logging.
Thanks in advance,
- Kenny
Re: [us...@lists.monobjc.net] Localizing app: Nib not found errors
Hi,
I've tried to get the localizations property in the HelloCocoa sample
as well. It also returns an NSArray of non-NSStrings.
(however, localization works there as expected).
I'm still using nibs in the NIB 2.X format, but I've tried that in the
sample app, and I can localize those without problems too.
Is there something I might've done that disables localization?
In plist files or something?)
I've checked them, and don't see anything out of order, but you never
know.
Is there a way to disable localization completely?
regards,
- Kenny
On 26 Nov 2009, at 08:53, Laurent Etiemble wrote:
Hello,
I never had such problem during localization. As long as you follow
the bundle naming and structure, you can add localization on the fly
if the NIB are not compiled.
Have you tried to get the localizations list in a sample application ?
Does it also returns non-NSString objects ?
Regards, Laurent Etiemble.
2009/11/24 Kenny Clement :
Hi,
I'm running into a problem localizing our application.
The way it should work:
Copy the en.lproj folder to nl.lproj, adjust the texts, and you
should have
a dutch version.
This works in sample applications (so I guess it's not really a
problem
caused by monobjc)
However, in my application, it does not.
I have the folowing folders with nibs: en.lproj, nl.lproj, fr.lproj
All of these have working nib files.
If I change my preferred OS language to Dutch, I expect to see the
nibs from
nl.lproj. I see the English ones.
When removing en.lproj, I get no more UI, no menu, ...
All MonobjC shows me is the following error: (upping the
MONOBJC_DEBUG
level doesn't show more)
633946702097321770 [ERROR] NSApplication - Error while loading the
NIB file
It seems as if it simply can't find the nl.lproj folder, even
though it is
there.
In Finder: app ==> get Info ==> Languages, I can see the 3 languages.
In order to find more info, I tried to loop through the
NSBundle.MainBundle.Localizations property.
According to the documentation (both MonobjC and Cocoa), this
should return
an NSArray, with NSStrings of the languages available in the bundle.
However, this property does return an NSArray, which contains 3
elements
(I'm assuming this is nl, fr and en), but the elements are not
NSStrings
(I'm getting Id's, casting to NSStrings throws exceptions).
Why aren't these NSStrings?
I'm loading my nib with the line:
NSApplication.LoadNib("MainMenu");
According to the MonObjC code, this is just a shortcut to
NSBundle.LoadNibNamedOwner("Mainmenu",
NSApplication.SharedApplication).
According to the MonObjC Documentation of
NSBundle.LoadNibNamedOwner, the
path where Cocoa looks for the Nibs is determined by the owner. In
this
case, taht would be NSApplication.SharedApplication.
Is there any way I can see more information, like the exact paths
it is
looking for?
I'm hoping someone here can point me in the right direction, or
show me a
way to get more logging.
Thanks in advance,
- Kenny
Re: [us...@lists.monobjc.net] Snow Leopard support: call for testing (Take 2)
The way I see it, even asking users to install the regular Mono on OS X is too much. Especially because things tend to break with newer/ multiple versions of Mono on Mac. This solution is perfect for deployment, because we deploy after using mkbundle (= package this mono version in the app). That way, the application is larger, but new/different versions of mono can never break my app, and my application can never break existing mono apps the user might have. + I assume that eventually, these patches will be integrated in the official Mono trunk. Regards, - Kenny On 06 Dec 2009, at 15:43, marc hoffman wrote: Am i the only one who thinks this custom runtime thing is not really acceptable for anyone who wants to - oh, say - *deploy* applications to regular users who can't/won't just patch their Mono install? what's the short-term plan for enabling people to actually ship apps based on Monobjc, and why can't we stick to the unmanaged dylib that can easily be deployed alongside the app, at least until an official Mono is out that contains these patches (if that will ever happen)? just thinking out loud, here. On Dec 2, 2009, at 12:15 AM, Laurent Etiemble wrote: Hello, Sorry for the late update, but I had some busy nights trying to find another work-around for the Snow Leopard crash. The 4.0.436 release of the Monobjc bridge has brought mixed results regarding the Snow Leopard crash: some users have reported success while others have reported nasty crashes. So, I have resumed my work on the Mono runtime patching to find an acceptable way to do it (not too hacky so Novell would accept it). During my tests, I have discover that the conditions of the bug are already present under Leopard. Why it does not crash seems linked to the way TSD (Thread Specfic Data) are destroyed. So I have changed my approach and I have come to a workaround that seems to prevent the crash. The archive of the patched Mono runtime is available at: http://build.monobjc.net/releases/2.4.2.3_M/MonoFramework-2.4.2.3_M-universal.tar.bz2 In order to use the archive: - you need to have a working installation of Mono. - uncompress the archive in /Library/Frameworks/Mono.framework/ Versions - relink the Current symlink to the archive (sudo rm Current && sudo ln -s 2.4.2.3_M Current) Some points about this runtime: - The runtime is universal. I have made some tests under some OS/Processor combinations, but I cannot cover all hardware. - The runtime contains Mono, Visual Basic and NAnt. It does not contains libgdiplus or any of the third-party packages. - The runtime contains all what is needed to run mkbundle or the packaging tasks. - The runtime also contains other patches: embedded "machine.config" and "app.config" are now usable. If you decide to test this runtime, please provide the following: - hardware/system full version - kind of application/complexity - anything that can help in case of crash Regards, Laurent Etiemble.
[us...@lists.monobjc.net] mkbundle and localized resx files
Hi, As you said it might've been caused by MonobjC, I just tested some more, to see if I could rule out MonobjC/determine for sure it was MonobjC. So, I compiled my application using Visual Studio. And did mkbundle manually on the commandline (instead of using the MonobjC NAnt task). So I didn't use MonobjC at all, and I'm still getting the same problem. It seems this is a limitation of mkbundle. And I can see why, it can't possibly know which assembly to use, because the namespaces, classname, ... is exactly the same However, I kind of need this to work. Is there another way to do what I'm doing? Some sort of workaround? Other people must've encountered this before. Now that I know it's not MonobjC related, I'll look around to see if there's a mailing list that is better suited for this kind of question. Thanks for the reply, and for looking into it! Btw, we've switched to the latest version of MonobjC, and are testing with your patched Mono version (which indeed fixes the SL crashes and the bundled machine.config) The application is pretty complex (compared to the other MonobjC projects I've seen so far) and is currently being tested. So far, it looks pretty good, we'll let you know if we encounter any problems. Keep up the good work. - Kenny Op 19 Dec 2009, om 11:03 heeft Laurent Etiemble het volgende geschreven: Hello, I think this is a Monobjc issue, because the name of the satellite assemblies is mis-generated during the assembly phase. I have already make some corrections to handle assembly name with space, but I have missed the satellite case. I will try to give it a try this week-end. Regards, Laurent Etiemble. 2009/12/18 Kenny Clement Hi, I'm not too sure this belongs on the MonobjC mailing list, as this seems more of a problem/shortcoming in mkbundle, but I am using the NAnt.Monobjc tasks, so, and I am looking for a solution for my MonobjC app, so here goes: One of the more standard ways of localizing Applications, is by using resource files (.resx) for getting strings out of it. Let's say we have an application that uses strings from Resource.resx If you then copy Resource.resx to Resource.nl-BE.resx and set the thread's CurrentCUlture/CurrentUICulture to nl-BE the string you requested will be from the Resource.nl-BE.resx file. If Visual studio, or even Mono compiles this, it creates 'Satellite assemblies': 1 for each language you have the resx file in. I assume .NET then automagically loads these through Reflection. This works with Mono. However, when I deploy to my customers, I don't want them to install the (patched) Mono Framework, I use mkbundle. However, with mkBundle, it seems to be impossible to include more than 1 of these satellite assemblies. As I need (currently) 3 languages, this is a bit of a problem. I've created a sample application to show the problem a little clearer. It's a console application, that requests you what culture you want to load, and then displays a localized string from the resource file. There's a nant.build file in the sample, with 3 targets: clean (cleans up the ./bin and ./dist folder) build (builds the app in ./bin) bundle (builds the app in ./bin + uses mkbundle to create a bundle in ./dist) nant clean build - works as expected. execute the app with mono bin/ConsoleApp.exe nant clean bundle - Does not work in the current version, gives the output you can see below. To make it work, you can comment 2 lines, as described in the file, but then you will only support 1 language Is this a bug? Is this simply impossible? Is there some sort of workaround available? Thanks in advance, - Kenny mkbundle output: ... [mkbundle] Reference added 'file:///Library/Frameworks/Mono.framework/Versions/2.4/lib/mono/gac/System.Security/2.0.0.0__b03f5f7f11d50a3a/System.Security.dll' [mkbundle] Reference added 'file:///Library/Frameworks/Mono.framework/Versions/2.4/lib/mono/gac/Mono.Security/2.0.0.0__0738eb9f132ed756/Mono.Security.dll' [mkbundle] Getting references for additional libraries [mkbundle] Reference added 'file:///Users/kclement/Projects/homes/kclement/code/dotnet/Localization/bin/nl-BE/ConsoleApp.resources.dll' [mkbundle] Reference added 'file:///Users/kclement/Projects/homes/kclement/code/dotnet/Localization/bin/fr-FR/ConsoleApp.resources.dll' [mkbundle] Reference added 'file:///Users/kclement/Projects/homes/kclement/code/dotnet/Localization/bin/en-US/ConsoleApp.resources.dll' [mkbundle] Generating native sources... [mkbundle] Embedding Assembly '/Users/kclement/Projects/homes/ kclement/code/dotnet/Localization/bin/ConsoleApp.exe' [mkbundle] Embedding Assembly '/Library/Frameworks/Mono.framework/ Versions/2.4/lib/mono/2.0/mscorlib.dll' [mkbundle] Embedd
Re: [us...@lists.monobjc.net] mkbundle and localized resx files
Laurent, I don't think that is the case. Mono can deal with multiple cultures of an assembly. My test app works without any issues, as long as I don't mkbundle it. The problem is that mkbundle refuses to bundle 2 resource dlls (it doesn't see the difference between the 2 ==> embedding 2 identical assemblies is impossible). My guess is that the resourceManager internally uses reflection to load assemblies that are exactly the same. It differentiates between them based on the subdirectory they're in (the compiler places them in nl-BE, fr-FR, en-US, ... subfolders). I think that, in Mono, or even the original .NET Framework, there are never 2 resources dlls with different cultures loaded simultaneously either. The problem seems to be that mkbundle hard-links these assemblies, and simply does not know how to differentiate between the satellite assemblies, because the only difference is the subfolder they're in. Therefor, I don't know whether this is in fact, a bug, or just a 'limitation' of mkbundle. regards, - Kenny Op 21 Dec 2009, om 12:01 heeft Laurent Etiemble het volgende geschreven: Hello, I came to the same conclusion after some testing. I thought that there was something missing in Monobjc, but it appears that there is huge limitation in the embedding API of the Mono runtime. In the "mono/metadata/assembly.c", the "mono_assembly_open_from_bundle" is responsible for loading requested assembly. But the lookup does not handle the culture of the assembly. This is why, only one resources dll can be loaded at a time. I guess I need to produce another patch for Mono, in order to handle the satellite assemblies loading. Regards, Laurent Etiemble. 2009/12/21 Kenny Clement Hi, As you said it might've been caused by MonobjC, I just tested some more, to see if I could rule out MonobjC/determine for sure it was MonobjC. So, I compiled my application using Visual Studio. And did mkbundle manually on the commandline (instead of using the MonobjC NAnt task). So I didn't use MonobjC at all, and I'm still getting the same problem. It seems this is a limitation of mkbundle. And I can see why, it can't possibly know which assembly to use, because the namespaces, classname, ... is exactly the same However, I kind of need this to work. Is there another way to do what I'm doing? Some sort of workaround? Other people must've encountered this before. Now that I know it's not MonobjC related, I'll look around to see if there's a mailing list that is better suited for this kind of question. Thanks for the reply, and for looking into it! Btw, we've switched to the latest version of MonobjC, and are testing with your patched Mono version (which indeed fixes the SL crashes and the bundled machine.config) The application is pretty complex (compared to the other MonobjC projects I've seen so far) and is currently being tested. So far, it looks pretty good, we'll let you know if we encounter any problems. Keep up the good work. - Kenny Op 19 Dec 2009, om 11:03 heeft Laurent Etiemble het volgende geschreven: Hello, I think this is a Monobjc issue, because the name of the satellite assemblies is mis-generated during the assembly phase. I have already make some corrections to handle assembly name with space, but I have missed the satellite case. I will try to give it a try this week-end. Regards, Laurent Etiemble. 2009/12/18 Kenny Clement Hi, I'm not too sure this belongs on the MonobjC mailing list, as this seems more of a problem/shortcoming in mkbundle, but I am using the NAnt.Monobjc tasks, so, and I am looking for a solution for my MonobjC app, so here goes: One of the more standard ways of localizing Applications, is by using resource files (.resx) for getting strings out of it. Let's say we have an application that uses strings from Resource.resx If you then copy Resource.resx to Resource.nl-BE.resx and set the thread's CurrentCUlture/CurrentUICulture to nl-BE the string you requested will be from the Resource.nl-BE.resx file. If Visual studio, or even Mono compiles this, it creates 'Satellite assemblies': 1 for each language you have the resx file in. I assume .NET then automagically loads these through Reflection. This works with Mono. However, when I deploy to my customers, I don't want them to install the (patched) Mono Framework, I use mkbundle. However, with mkBundle, it seems to be impossible to include more than 1 of these satellite assemblies. As I need (currently) 3 languages, this is a bit of a problem. I've created a sample application to show the problem a little clearer. It's a console application, that requests you what culture you want to load, and then displays a localized string from the resource file. The
Re: [us...@lists.monobjc.net] Re: Snow Leopard support: call for testing (Take 2)
Hello, the patch can be found in the Mono bug report. here: https://bugzilla.novell.com/show_bug.cgi?id=537764 I believe the build Laurent made also contained a patch for the machine.config problem. More info, and the patch can be found here: https://bugzilla.novell.com/show_bug.cgi?id=495957 regards, - Kenny On 22 Dec 2009, at 10:50, yoni shalom wrote: Lauren, I compile my own mono so if you could post the patch file somewhere that would be great. Thanks. On Tue, Dec 15, 2009 at 1:04 PM, Laurent Etiemble > wrote: Hello, I am still working on a patch for the Mono runtime: the goal is to have it integrated by Novell but it must meet certain criteria to do so. Meanwhile, I have prepared a patched version of the recently released 2.4.3. If you need an interim solution, you can find the disk images at http://build.monobjc.net/releases/2.4.3_M/MonoFramework-2.4.3_M-universal.dmg Regards, Laurent Etiemble. 2009/12/2 Laurent Etiemble : > Hello, > > Sorry for the late update, but I had some busy nights trying to find > another work-around for the Snow Leopard crash. The 4.0.436 release of > the Monobjc bridge has brought mixed results regarding the Snow > Leopard crash: some users have reported success while others have > reported nasty crashes. > > So, I have resumed my work on the Mono runtime patching to find an > acceptable way to do it (not too hacky so Novell would accept it). > During my tests, I have discover that the conditions of the bug are > already present under Leopard. Why it does not crash seems linked to > the way TSD (Thread Specfic Data) are destroyed. So I have changed my > approach and I have come to a workaround that seems to prevent the > crash. > > The archive of the patched Mono runtime is available at: > http://build.monobjc.net/releases/2.4.2.3_M/MonoFramework-2.4.2.3_M-universal.tar.bz2 > > In order to use the archive: > - you need to have a working installation of Mono. > - uncompress the archive in /Library/Frameworks/Mono.framework/ Versions > - relink the Current symlink to the archive (sudo rm Current && sudo > ln -s 2.4.2.3_M Current) > > Some points about this runtime: > - The runtime is universal. I have made some tests under some > OS/Processor combinations, but I cannot cover all hardware. > - The runtime contains Mono, Visual Basic and NAnt. It does not > contains libgdiplus or any of the third-party packages. > - The runtime contains all what is needed to run mkbundle or the > packaging tasks. > - The runtime also contains other patches: embedded "machine.config" > and "app.config" are now usable. > > If you decide to test this runtime, please provide the following: > - hardware/system full version > - kind of application/complexity > - anything that can help in case of crash > > Regards, Laurent Etiemble. >
