[Mono-dev] Mono.Cairo on OSX
It looks like Mono.Cairo is trying to load libcairo.so.2 on OS X. Creating the following Mono.Cairo.dll.config works for me. configuration dllmap dll=libcairo-2.dll target=libcairo.2.dylib/ /configuration However, I'm not sure how to go around making a proper patch as you folks would like it. The reason I ask is because I don't see any other dll's in mcs/class/ that have dllmaps based on platform (and maybe this will require a configure.in change). So if you provide me a little direction, I'll go ahead and submit a patch. -- Christian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Re: Patch to fix comparison of DateTime objects in Mono.Data.SqlExpressions
Is anything else needed to get this patch in? Thanks, Adam On Thu, Jul 23, 2009 at 12:57 PM, Adam Wendt a...@awendtconsulting.comwrote: Attached is full patch including ChangeLog and Tests On Thu, Jul 23, 2009 at 12:25 PM, Adam Wendt a...@awendtconsulting.comwrote: Here is test case patch: http://pastebin.com/m15952d84 On Thu, Jul 23, 2009 at 11:52 AM, Veerapuram Varadhan vvarad...@novell.com wrote: Hi Adam, Patch looks fine to go - along with a test case. Thanks, V. Varadhan On Thu, 2009-07-23 at 11:32 -0700, Adam Wendt wrote: http://pastebin.com/m45199c62 This makes it possible to compare DateTime to string (parsable to DateTime) when the existing DateTime is on the right rather than just when it is on the left (the previous behavior) Adam Adam Wendt Consulting ___ 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.Cairo on OSX
Hi Christian, Christian Hergert wrote: It looks like Mono.Cairo is trying to load libcairo.so.2 on OS X. Creating the following Mono.Cairo.dll.config works for me. configuration dllmap dll=libcairo-2.dll target=libcairo.2.dylib/ /configuration However, I'm not sure how to go around making a proper patch as you folks would like it. The reason I ask is because I don't see any other dll's in mcs/class/ that have dllmaps based on platform (and maybe this will require a configure.in change). So if you provide me a little direction, I'll go ahead and submit a patch. No configure magic is required if the os attribute is applied: configuration dllmap dll=libcairo-2.dll target=libcairo.2.dylib os=osx/ /configuration Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Cairo on OSX
Oh thats handy. Anyone have objections to committing this? -- Christian On Aug 4, 2009, at 1:19 AM, Robert Jordan wrote: Hi Christian, Christian Hergert wrote: It looks like Mono.Cairo is trying to load libcairo.so.2 on OS X. Creating the following Mono.Cairo.dll.config works for me. configuration dllmap dll=libcairo-2.dll target=libcairo.2.dylib/ /configuration However, I'm not sure how to go around making a proper patch as you folks would like it. The reason I ask is because I don't see any other dll's in mcs/class/ that have dllmaps based on platform (and maybe this will require a configure.in change). So if you provide me a little direction, I'll go ahead and submit a patch. No configure magic is required if the os attribute is applied: configuration dllmap dll=libcairo-2.dll target=libcairo.2.dylib os=osx/ /configuration Robert ___ 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] Occasional native stack trace in mono
Hi! I've written a custom server software that handles several connections and processes data that is sent across them. Application is running on mono 2.4.2.2 on debian unstable (amd64). From time to time mono tends to throw native stack trace: mono [0x47ea60] mono [0x4aec9d] /lib/libpthread.so.0 [0x7f6a02a137b0] mono [0x47c6cb] mono [0x47d6d3] mono [0x47d7c6] mono [0x4aedee] /lib/libpthread.so.0 [0x7f6a02a137b0] [0x417c05e0] And application hangs completely. So far I'm unable to debug the root cause of this (only happens on debian - so far our server on SuSE didn't die this way). Does anyone have any clue on what can be causing this (maybe wrong socket handling as this error happens when client disconnects) ? -- Maciej Paszta ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ConcurrentDictionary.cs breakng the svn trunk
Fixed in r139338 --Jérémie Laval jeremie.la...@gmail.com http://garuma.wordpress.com On Tue, Aug 4, 2009 at 3:33 AM, Tony Alexander Hild lt;tony_h...@yahoo.comgt; wrote: Hi, I can't build from trunk due this exception make[8]: Entering directory `/home/tony/mono/mcs/class/corlib'nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; MCSnbsp;nbsp;nbsp;nbsp; [net_4_0] mscorlib.dllnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; System.Reflection/MonoGenericClass.cs(247,36): warning CS0168: The variable `accessor' is declared but never usednbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; System.Threading.Tasks/Future..cs(118,41): warning CS3005: Identifier `System.Threading.Tasks.Tasklt;TResultgt;.ContinueWithlt;TNewResultgt;(System.Funclt;System.Threading.Tasks.Tasklt;TResultgt;,TNewResultgt;)' differing only in case is not CLS-compliantnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; System.Threading.Tasks/Task.cs(174,38): (Location of the symbol related to previous warning)nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; System.Collections.Concurrent/ConcurrentDictionary.cs(34,22): error CS0737: `System.Collections.Concurrent.ConcurrentDictionarylt;TKey,TValuegt;' does not implement interface member `System.Collections.IDictionary.GetEnumerator()' and the best implementing candidate `System.Collections.Concurrent.ConcurrentDictionarylt;TKey,TValuegt;.System.Collections.IDictionary.Add(object, object)' in not publicnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; System.Collections/IDictionary.cs(63,43): (Location of the symbol related to previous error)nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; System.Collections.Concurrent/ConcurrentDictionary.cs(308,34): (Location of the symbol related to previous error)nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; System.Collections.Concurrent/ConcurrentDictionary.cs(34,22): error CS0535: `System.Collections.Concurrent.ConcurrentDictionarylt;TKey,TValuegt;' does not implement interface member `System.Collections.IDictionary.Keys.get' System.Collections/IDictionary.cs(51,36): (Location of the symbol related to previous error)nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; System.Collections.Concurrent/ConcurrentDictionary.cs(34,22): error CS0737: `System.Collections.Concurrent.ConcurrentDictionarylt;TKey,TValuegt;' does not implement interface member `System.Collections.IDictionary.Values.get' and the best implementing candidate `System.Collections.Concurrent.ConcurrentDictionarylt;TKey,TValuegt;.System.Collections.IDictionary.Contains(object)' in not public System.Collections/IDictionary.cs(53,38): (Location of the symbol related to previous error) System.Collections.Concurrent/ConcurrentDictionary.cs(276,34): (Location of the symbol related to previous error) Compilation failed: 3
Re: [Mono-dev] Occasional native stack trace in mono
Hi, You can try compiling mono from source, so the runtime has debugging symbols, so you get more meaningfull stacktraces. Zoltan On Tue, Aug 4, 2009 at 12:31 PM, Maciej Paszta pasz...@go2.pl wrote: Hi! I've written a custom server software that handles several connections and processes data that is sent across them. Application is running on mono 2.4.2.2 on debian unstable (amd64). From time to time mono tends to throw native stack trace: mono [0x47ea60] mono [0x4aec9d] /lib/libpthread.so.0 [0x7f6a02a137b0] mono [0x47c6cb] mono [0x47d6d3] mono [0x47d7c6] mono [0x4aedee] /lib/libpthread.so.0 [0x7f6a02a137b0] [0x417c05e0] And application hangs completely. So far I'm unable to debug the root cause of this (only happens on debian - so far our server on SuSE didn't die this way). Does anyone have any clue on what can be causing this (maybe wrong socket handling as this error happens when client disconnects) ? -- Maciej Paszta ___ 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] Occasional native stack trace in mono
On Tue, Aug 4, 2009 at 2:07 PM, Zoltan Varga var...@gmail.com wrote: Hi, You can try compiling mono from source, so the runtime has debugging symbols, so you get more meaningfull stacktraces. I'm actually compiling from the source, but no more info is produced. Is there any option I should pass to ./configure to make mono preserve and use runtime debugging symbols? -- Maciej Paszta ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Occasional native stack trace in mono
On Tue, Aug 4, 2009 at 9:49 AM, Maciej Paszta pasz...@go2.pl wrote: On Tue, Aug 4, 2009 at 2:07 PM, Zoltan Varga var...@gmail.com wrote: Hi, You can try compiling mono from source, so the runtime has debugging symbols, so you get more meaningfull stacktraces. I'm actually compiling from the source, but no more info is produced. Is there any option I should pass to ./configure to make mono preserve and use runtime debugging symbols? Maybe you don't have GDB installed, which is used to get a richer crash dump. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiler warnings
Hi Chistian, Your patch is full of very different kind of changes, some are simple, others require some thought about. So let's sort them into smaller and centered patches. For example, the ones changing printf style calls are mostly ok and should be committed on their own. Then we can see the warnings changes, the io retry stuff and finally what looks like real bugs. What do you think about it? Rodrigo On Fri, Jul 24, 2009 at 2:02 AM, Christian Hergert ch...@dronelabs.comwrote: Round 2, * Moved TEMP_FAILURE_RETRY macro to mono/utils/mono-io-portability.h. * Removed #ifndef PLATFORM_MACOSX for now. -- Christian On Jul 23, 2009, at 8:24 PM, Geoff Norton wrote: 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Occasional native stack trace in mono
Maybe you don't have GDB installed, which is used to get a richer crash dump. GDB is installed but when debug info from GDB is about to be generated - everything freezes and stays that way. -- Maciej Paszta ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Occasional native stack trace in mono
On Tue, Aug 4, 2009 at 3:40 PM, Maciej Paszta pasz...@go2.pl wrote: Maybe you don't have GDB installed, which is used to get a richer crash dump. GDB is installed but when debug info from GDB is about to be generated - everything freezes and stays that way. Just for the record - GDB generates debug info for other native stacktraces (like one for the bug 350011) but in this case - nothing works. -- Maciej Paszta ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono Visual Profiler
We're seeking the input of profiler users and other interested parties to help create a visual profiling tool for mono applications. Development is under way in the mono-tools module alongside the current command line decoder. The tool is a UI to interact with the built-in mono logging profiler and graphically display captured profile logs. The visualization capabilities of the tool are still fairly primitive, but it is already capable of creating and displaying log data for instrumented, allocation, and statistical profiles. I have created a Wiki page to track the feature capabilities and plans: http://mono-project.com/MonoVisualProfiler There is also now a Visual Profiler category for bug reporting and enhancement requests in the Mono:Tools bugzilla product. Discussion should occur on mono-devel-list. -- Mike Kestner mkest...@gmail.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Visual Profiler
Mono profiler still not work (runtime crash at app exit) on some mainstream platforms like Mac OS 10.5. May it will be better to enhance profiling support on most OSes before building GUI tool? 2009/8/4 Mike Kestner mkest...@gmail.com We're seeking the input of profiler users and other interested parties to help create a visual profiling tool for mono applications. Development is under way in the mono-tools module alongside the current command line decoder. The tool is a UI to interact with the built-in mono logging profiler and graphically display captured profile logs. The visualization capabilities of the tool are still fairly primitive, but it is already capable of creating and displaying log data for instrumented, allocation, and statistical profiles. I have created a Wiki page to track the feature capabilities and plans: http://mono-project.com/MonoVisualProfiler There is also now a Visual Profiler category for bug reporting and enhancement requests in the Mono:Tools bugzilla product. Discussion should occur on mono-devel-list. -- Mike Kestner mkest...@gmail.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- WBR, Eugeny Grishul ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Visual Profiler
People are already working on porting to non-linux targets. On Tue, Aug 4, 2009 at 3:27 PM, Евгений Гришуль eugeny.gris...@gmail.comwrote: Mono profiler still not work (runtime crash at app exit) on some mainstream platforms like Mac OS 10.5. May it will be better to enhance profiling support on most OSes before building GUI tool? 2009/8/4 Mike Kestner mkest...@gmail.com We're seeking the input of profiler users and other interested parties to help create a visual profiling tool for mono applications. Development is under way in the mono-tools module alongside the current command line decoder. The tool is a UI to interact with the built-in mono logging profiler and graphically display captured profile logs. The visualization capabilities of the tool are still fairly primitive, but it is already capable of creating and displaying log data for instrumented, allocation, and statistical profiles. I have created a Wiki page to track the feature capabilities and plans: http://mono-project.com/MonoVisualProfiler There is also now a Visual Profiler category for bug reporting and enhancement requests in the Mono:Tools bugzilla product. Discussion should occur on mono-devel-list. -- Mike Kestner mkest...@gmail.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- WBR, Eugeny Grishul ___ 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] Compiler warnings
That makes sense, I'll split them up. -- Christian On Aug 4, 2009, at 6:11 AM, Rodrigo Kumpera wrote: Hi Chistian, Your patch is full of very different kind of changes, some are simple, others require some thought about. So let's sort them into smaller and centered patches. For example, the ones changing printf style calls are mostly ok and should be committed on their own. Then we can see the warnings changes, the io retry stuff and finally what looks like real bugs. What do you think about it? Rodrigo On Fri, Jul 24, 2009 at 2:02 AM, Christian Hergert ch...@dronelabs.com wrote: Round 2, * Moved TEMP_FAILURE_RETRY macro to mono/utils/mono-io-portability.h. * Removed #ifndef PLATFORM_MACOSX for now. -- Christian On Jul 23, 2009, at 8:24 PM, Geoff Norton wrote: 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Cairo on OSX
So it turns out that this is really defined in etc/mono/config and the OS X packaging scripts will munge that to create the Framework install. So I suggest we update the config.in with a os=osx addition and update the line in the release scripts to reflect the proper dylib. Patches attached. -- Christian mono-etc-config-cairo.patch Description: Binary data release-macosx-cairo.patch Description: Binary data On Aug 4, 2009, at 1:26 AM, Christian Hergert wrote: Oh thats handy. Anyone have objections to committing this? -- Christian On Aug 4, 2009, at 1:19 AM, Robert Jordan wrote: Hi Christian, Christian Hergert wrote: It looks like Mono.Cairo is trying to load libcairo.so.2 on OS X. Creating the following Mono.Cairo.dll.config works for me. configuration dllmap dll=libcairo-2.dll target=libcairo.2.dylib/ /configuration However, I'm not sure how to go around making a proper patch as you folks would like it. The reason I ask is because I don't see any other dll's in mcs/class/ that have dllmaps based on platform (and maybe this will require a configure.in change). So if you provide me a little direction, I'll go ahead and submit a patch. No configure magic is required if the os attribute is applied: configuration dllmap dll=libcairo-2.dll target=libcairo.2.dylib os=osx/ /configuration Robert ___ 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] Compiler warnings
Hi, I've split the patches up based on their content. Attached. unused-functions.patch - #if 0 unused functions in dlmalloc.c and strtod.c uninitialized-fixes.patch - make sure variables are initialized with NULL/0 where used without initialization mono-printf-fixes.patch - make sure a format string such as %s is used with variable string input printf() style methods explicit-word-size-changes.patch - use GINT_TO_POINTER and such when converting from int32 to word-size declaration-fixes.patch - Fix method declarations that have () instead of (void) and add missing non-static declarations bitwise-branch-checks.patch - be explicit with parenthesis when using bitwise operation as implicit boolean I've omitted the patch for using write() without checking the result for now. Let me know if you want to move forward with those and how we would want to do it properly. Thanks, -- Christian bitwise-branch-checks.patch Description: Binary data declaration-fixes.patch Description: Binary data explicit-word-size-changes.patch Description: Binary data mono-printf-fixes.patch Description: Binary data uninitialized-fixes.patch Description: Binary data unused-functions.patch Description: Binary data On Aug 4, 2009, at 6:11 AM, Rodrigo Kumpera wrote: Hi Chistian, Your patch is full of very different kind of changes, some are simple, others require some thought about. So let's sort them into smaller and centered patches. For example, the ones changing printf style calls are mostly ok and should be committed on their own. Then we can see the warnings changes, the io retry stuff and finally what looks like real bugs. What do you think about it? Rodrigo On Fri, Jul 24, 2009 at 2:02 AM, Christian Hergert ch...@dronelabs.com wrote: Round 2, * Moved TEMP_FAILURE_RETRY macro to mono/utils/mono-io-portability.h. * Removed #ifndef PLATFORM_MACOSX for now. -- Christian On Jul 23, 2009, at 8:24 PM, Geoff Norton wrote: 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
