Re: [Mono-winforms-list] Removing the IDeviceContext.cs file
Don't know anthing about it really. Just to note that the one in System.Drawing is official (http://msdn.microsoft.com/en-us/library/system.drawing.idevicecontext.a spx) and is an interface. This one is a *class* matching -- but *not* implementing -- that interface... George Giolfan who worked on theming support is the only committer in SVN/GIT. Presumably it's obsolete -- and maybe was never used in production. Perhaps it was used for diagnostics purposes or something. Jonathan might know know more, or ask George -- though presumably not at the wonky email address listed in that file. Andy -Original Message- From: mono-winforms-list-boun...@lists.ximian.com [mailto:mono-winforms-list-boun...@lists.ximian.com] On Behalf Of st...@free.fr Sent: 20 January 2011 22:41 To: mono-winforms-list Cc: Miguel de Icaza Subject: [Mono-winforms-list] Removing the IDeviceContext.cs file Hi guys, As I was cleaning up WinForms from .NET 1.1 code, I stumbled on the IDeviceContext.cs file (in the System.Windows.Forms namespace). I'm not sure what this class was for exactly (some kind of replacement for the class of the same name in the System.Drawing namespace, I take it), but it now seems useless, since it's wrapped inside a #if !NET_2_0 condition. Also, from what I understand, if I remove it, I should also remove it from the System.Windows.Forms.dll.sources file (if I'm not mistaken, that's what the make command uses to find classes it should build), and I think that's it. Nothing else to update. Am I right, and can I go ahead with this? Thanks. ___ 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-winforms-list] Removing the IDeviceContext.cs file
Hi Andy, Thanks for the answer. I think it was just some kind of internal class to replicate the behavior of the Drawing.IDeviceContext one, but since Drawing.IDeviceContext didn't exist in .NET 1.1, it was done internally in System.Windows.Forms, without exposing the class. That way, more code could be shared between 1.1 and 2.0, using 2 different classes as if it was the same one. I think we want to remove it, can't see why we'd want to keep it. Do you know if the only file reference I need to remove is in the System.Windows.Forms.dll.sources file, as I suspect? Just making sure I don't break anything. - Mail Original - De: Andy Hume andyhum...@yahoo.co.uk À: mono-winforms-list mono-winforms-list@lists.ximian.com Cc: st...@free.fr Envoyé: Mardi 25 Janvier 2011 21:46:03 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: RE: [Mono-winforms-list] Removing the IDeviceContext.cs file Don't know anthing about it really. Just to note that the one in System.Drawing is official (http://msdn.microsoft.com/en-us/library/system.drawing.idevicecontext.a spx) and is an interface. This one is a *class* matching -- but *not* implementing -- that interface... George Giolfan who worked on theming support is the only committer in SVN/GIT. Presumably it's obsolete -- and maybe was never used in production. Perhaps it was used for diagnostics purposes or something. Jonathan might know know more, or ask George -- though presumably not at the wonky email address listed in that file. Andy -Original Message- From: mono-winforms-list-boun...@lists.ximian.com [mailto:mono-winforms-list-boun...@lists.ximian.com] On Behalf Of st...@free.fr Sent: 20 January 2011 22:41 To: mono-winforms-list Cc: Miguel de Icaza Subject: [Mono-winforms-list] Removing the IDeviceContext.cs file Hi guys, As I was cleaning up WinForms from .NET 1.1 code, I stumbled on the IDeviceContext.cs file (in the System.Windows.Forms namespace). I'm not sure what this class was for exactly (some kind of replacement for the class of the same name in the System.Drawing namespace, I take it), but it now seems useless, since it's wrapped inside a #if !NET_2_0 condition. Also, from what I understand, if I remove it, I should also remove it from the System.Windows.Forms.dll.sources file (if I'm not mistaken, that's what the make command uses to find classes it should build), and I think that's it. Nothing else to update. Am I right, and can I go ahead with this? Thanks. ___ 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
[Mono-winforms-list] How to execute my win app built in mono( Windows ) on Mono (Mac OSX)
Hi Team, I have built a cross platform windows application (exe) on Mono (Windows), I have test the same(exe) on Linux, that was working good with the help of wine software, now I need to deploy the same on Mac OSX. Could anyone help with the steps or guidelines, so that I can run my win app on Mac OSX? Thank you!! Regards, Sudarshan Hegde ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] How to execute my win app built in mono( Windows ) on Mono (Mac OSX)
Though it is a manage app, exe extension belongs to windows hence to run these exes we need to have some software(other than windows OS) that would execute these exes. Regards, Sudarshan Hegde -Original Message- From: andresen.n...@googlemail.com [mailto:andresen.n...@googlemail.com] On Behalf Of Nils Andresen Sent: Wednesday, January 26, 2011 1:05 PM To: Sudarshan Hegde Cc: mono-winforms-list@lists.ximian.com Subject: Re: [Mono-winforms-list] How to execute my win app built in mono( Windows ) on Mono (Mac OSX) Hi, I'm no OSX-user so I can not help you there but: I have test the same(exe) on Linux, that was working good with the help of wine software If it is a managed app, what was wine used for? Why not run mono yourapp.exe ? Nils ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-dev] Soft Debugger issues (can't suspend threads in wait_for_suspend)
I am having trouble with mono soft debugger. - I embed Mono runtime in my program, and I got MonoDevelop to act as SoftDebugger client - Mono soft debugger is loading properly (first breakpoint usually works -- if already set beforehand -- I can see callstacks, etc...) - As soon as I press F5 -- to execute until this breakpoint is reached again next iteration -- or if I disable/reenable this breakpoint, program hang (see log) - Main loop is in C and Mono functions are called regularly. I traced down the problem to thread(s) not suspending (cf log). Usually, it seems it is the Finalizer thread (in this case 2054) that doesn't get suspended. In mono sources, I tried to call mono_gc_collect/mono_gc_invoke_finalizers in the suspend_thread loop. In that case, I can manage to have F5 working (breakpoint trigger every step inside the loop). However it doesn't work as soon as I do anything else (such as removing adding again the breakpoint). I remember seeing this problem on more than 1 thread when I had other threads active (i.e. Waiting for 3(4) threads to suspend...) Does anyone have an idea? Maybe there is something special to do if Mono doesn't keep hand (often back to full unmanaged world since main loop is in C) Debugger log: [0410] Thread started, obj=04702F20, tls=004CDA60. [0410] Suspended. [0410] Resumed. [0410] Suspending vm... [0410] Sent event VM_START, suspend=2. [0410] Suspended. [dbg] Agent thread started, pid=1260 [2054] Thread started, obj=04702E70, tls=004EC1D8. Finalizer thread [2054] Suspended. [dbg] Received command VM(VERSION), id=1. [dbg] Received command VM(SET_PROTOCOL_VERSION), id=2. [dbg] Protocol version 2.2, client protocol version 2.2. [dbg] Received command APPDOMAIN(1), id=3. ... [0410] Suspended. [dbg] Received command TYPE(1), id=1785. [dbg] Received command TYPE(6), id=1786. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1787. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1788. [dbg] Received command TYPE(6), id=1789. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1790. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1791. [dbg] Received command TYPE(6), id=1792. [dbg] Received command VM(RESUME), id=1793. [2054] Received single step event for suspending. [2054] Suspended. [1260] Resuming vm... [0410] Resumed. [2054] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1794. [dbg] Received command TYPE(6), id=1795. [dbg] Received command VM(RESUME), id=1796. [1260] Resuming vm... [0410] Resumed. [0410] Breakpoint hit, method=Step, offset=0x1e. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event BREAKPOINT, suspend=2. [0410] Suspended. [dbg] Received command VM(ALL_THREADS), id=1797. [dbg] Received command THREAD(1), id=1798. Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... ___ 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 issues (can't suspend threads in wait_for_suspend)
Just as a small addition, to confirm what I said earlier concerning situation with additional threads. After adding 2 threads that don't actually call mono (simply register them with mono_thread_attach(mono_get_root_domain())), I end up having: Waiting for 2(4) threads to suspend... which mean 1 of the fully native threads is also blocking it. Maybe it can't detect well when threads are running in native mode? I will continue to investigate as well. On Wed, Jan 26, 2011 at 12:58 AM, Virgile Bello virgile.be...@gmail.comwrote: I am having trouble with mono soft debugger. - I embed Mono runtime in my program, and I got MonoDevelop to act as SoftDebugger client - Mono soft debugger is loading properly (first breakpoint usually works -- if already set beforehand -- I can see callstacks, etc...) - As soon as I press F5 -- to execute until this breakpoint is reached again next iteration -- or if I disable/reenable this breakpoint, program hang (see log) - Main loop is in C and Mono functions are called regularly. I traced down the problem to thread(s) not suspending (cf log). Usually, it seems it is the Finalizer thread (in this case 2054) that doesn't get suspended. In mono sources, I tried to call mono_gc_collect/mono_gc_invoke_finalizers in the suspend_thread loop. In that case, I can manage to have F5 working (breakpoint trigger every step inside the loop). However it doesn't work as soon as I do anything else (such as removing adding again the breakpoint). I remember seeing this problem on more than 1 thread when I had other threads active (i.e. Waiting for 3(4) threads to suspend...) Does anyone have an idea? Maybe there is something special to do if Mono doesn't keep hand (often back to full unmanaged world since main loop is in C) Debugger log: [0410] Thread started, obj=04702F20, tls=004CDA60. [0410] Suspended. [0410] Resumed. [0410] Suspending vm... [0410] Sent event VM_START, suspend=2. [0410] Suspended. [dbg] Agent thread started, pid=1260 [2054] Thread started, obj=04702E70, tls=004EC1D8. Finalizer thread [2054] Suspended. [dbg] Received command VM(VERSION), id=1. [dbg] Received command VM(SET_PROTOCOL_VERSION), id=2. [dbg] Protocol version 2.2, client protocol version 2.2. [dbg] Received command APPDOMAIN(1), id=3. ... [0410] Suspended. [dbg] Received command TYPE(1), id=1785. [dbg] Received command TYPE(6), id=1786. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1787. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1788. [dbg] Received command TYPE(6), id=1789. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1790. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1791. [dbg] Received command TYPE(6), id=1792. [dbg] Received command VM(RESUME), id=1793. [2054] Received single step event for suspending. [2054] Suspended. [1260] Resuming vm... [0410] Resumed. [2054] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1794. [dbg] Received command TYPE(6), id=1795. [dbg] Received command VM(RESUME), id=1796. [1260] Resuming vm... [0410] Resumed. [0410] Breakpoint hit, method=Step, offset=0x1e. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event BREAKPOINT, suspend=2. [0410] Suspended. [dbg] Received command VM(ALL_THREADS), id=1797. [dbg] Received command THREAD(1), id=1798. Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... ___ 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 issues (can't suspend threads in wait_for_suspend)
Sorry, last small update, if I simply disable the waiting loop in wait_for_suspend() and make is_suspended() always return TRUE, breakpoints/tracing work as expected (except maybe playing with other threads of course). This seems to confirm there might be some false positive when trying to detect threads that run in native mode (mono think they are managed). On Wed, Jan 26, 2011 at 1:06 AM, Virgile Bello virgile.be...@gmail.comwrote: Just as a small addition, to confirm what I said earlier concerning situation with additional threads. After adding 2 threads that don't actually call mono (simply register them with mono_thread_attach(mono_get_root_domain())), I end up having: Waiting for 2(4) threads to suspend... which mean 1 of the fully native threads is also blocking it. Maybe it can't detect well when threads are running in native mode? I will continue to investigate as well. On Wed, Jan 26, 2011 at 12:58 AM, Virgile Bello virgile.be...@gmail.comwrote: I am having trouble with mono soft debugger. - I embed Mono runtime in my program, and I got MonoDevelop to act as SoftDebugger client - Mono soft debugger is loading properly (first breakpoint usually works -- if already set beforehand -- I can see callstacks, etc...) - As soon as I press F5 -- to execute until this breakpoint is reached again next iteration -- or if I disable/reenable this breakpoint, program hang (see log) - Main loop is in C and Mono functions are called regularly. I traced down the problem to thread(s) not suspending (cf log). Usually, it seems it is the Finalizer thread (in this case 2054) that doesn't get suspended. In mono sources, I tried to call mono_gc_collect/mono_gc_invoke_finalizers in the suspend_thread loop. In that case, I can manage to have F5 working (breakpoint trigger every step inside the loop). However it doesn't work as soon as I do anything else (such as removing adding again the breakpoint). I remember seeing this problem on more than 1 thread when I had other threads active (i.e. Waiting for 3(4) threads to suspend...) Does anyone have an idea? Maybe there is something special to do if Mono doesn't keep hand (often back to full unmanaged world since main loop is in C) Debugger log: [0410] Thread started, obj=04702F20, tls=004CDA60. [0410] Suspended. [0410] Resumed. [0410] Suspending vm... [0410] Sent event VM_START, suspend=2. [0410] Suspended. [dbg] Agent thread started, pid=1260 [2054] Thread started, obj=04702E70, tls=004EC1D8. Finalizer thread [2054] Suspended. [dbg] Received command VM(VERSION), id=1. [dbg] Received command VM(SET_PROTOCOL_VERSION), id=2. [dbg] Protocol version 2.2, client protocol version 2.2. [dbg] Received command APPDOMAIN(1), id=3. ... [0410] Suspended. [dbg] Received command TYPE(1), id=1785. [dbg] Received command TYPE(6), id=1786. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1787. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1788. [dbg] Received command TYPE(6), id=1789. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1790. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1791. [dbg] Received command TYPE(6), id=1792. [dbg] Received command VM(RESUME), id=1793. [2054] Received single step event for suspending. [2054] Suspended. [1260] Resuming vm... [0410] Resumed. [2054] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1794. [dbg] Received command TYPE(6), id=1795. [dbg] Received command VM(RESUME), id=1796. [1260] Resuming vm... [0410] Resumed. [0410] Breakpoint hit, method=Step, offset=0x1e. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event BREAKPOINT, suspend=2. [0410] Suspended. [dbg] Received command VM(ALL_THREADS), id=1797. [dbg] Received command THREAD(1), id=1798. Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... Waiting for 1(2) threads to suspend... ___
Re: [Mono-dev] Soft Debugger issues (can't suspend threads in wait_for_suspend)
Turns out it might be due to Win32 limitations (QueueUserAPC works only if SleepEx/WaitForMultipleObjectsEx etc... are used), as notify_thread_apc is never called back. I can fix that on my own threads. However, finalizer thread should use such functions as well otherwise it will always hang internally. Sorry for the trouble. On Wed, Jan 26, 2011 at 1:26 AM, Virgile Bello virgile.be...@gmail.comwrote: Sorry, last small update, if I simply disable the waiting loop in wait_for_suspend() and make is_suspended() always return TRUE, breakpoints/tracing work as expected (except maybe playing with other threads of course). This seems to confirm there might be some false positive when trying to detect threads that run in native mode (mono think they are managed). On Wed, Jan 26, 2011 at 1:06 AM, Virgile Bello virgile.be...@gmail.comwrote: Just as a small addition, to confirm what I said earlier concerning situation with additional threads. After adding 2 threads that don't actually call mono (simply register them with mono_thread_attach(mono_get_root_domain())), I end up having: Waiting for 2(4) threads to suspend... which mean 1 of the fully native threads is also blocking it. Maybe it can't detect well when threads are running in native mode? I will continue to investigate as well. On Wed, Jan 26, 2011 at 12:58 AM, Virgile Bello virgile.be...@gmail.comwrote: I am having trouble with mono soft debugger. - I embed Mono runtime in my program, and I got MonoDevelop to act as SoftDebugger client - Mono soft debugger is loading properly (first breakpoint usually works -- if already set beforehand -- I can see callstacks, etc...) - As soon as I press F5 -- to execute until this breakpoint is reached again next iteration -- or if I disable/reenable this breakpoint, program hang (see log) - Main loop is in C and Mono functions are called regularly. I traced down the problem to thread(s) not suspending (cf log). Usually, it seems it is the Finalizer thread (in this case 2054) that doesn't get suspended. In mono sources, I tried to call mono_gc_collect/mono_gc_invoke_finalizers in the suspend_thread loop. In that case, I can manage to have F5 working (breakpoint trigger every step inside the loop). However it doesn't work as soon as I do anything else (such as removing adding again the breakpoint). I remember seeing this problem on more than 1 thread when I had other threads active (i.e. Waiting for 3(4) threads to suspend...) Does anyone have an idea? Maybe there is something special to do if Mono doesn't keep hand (often back to full unmanaged world since main loop is in C) Debugger log: [0410] Thread started, obj=04702F20, tls=004CDA60. [0410] Suspended. [0410] Resumed. [0410] Suspending vm... [0410] Sent event VM_START, suspend=2. [0410] Suspended. [dbg] Agent thread started, pid=1260 [2054] Thread started, obj=04702E70, tls=004EC1D8. Finalizer thread [2054] Suspended. [dbg] Received command VM(VERSION), id=1. [dbg] Received command VM(SET_PROTOCOL_VERSION), id=2. [dbg] Protocol version 2.2, client protocol version 2.2. [dbg] Received command APPDOMAIN(1), id=3. ... [0410] Suspended. [dbg] Received command TYPE(1), id=1785. [dbg] Received command TYPE(6), id=1786. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1787. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1788. [dbg] Received command TYPE(6), id=1789. [2054] Received single step event for suspending. [2054] Suspended. [dbg] Received command VM(RESUME), id=1790. [1260] Resuming vm... [2054] Resumed. [0410] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1791. [dbg] Received command TYPE(6), id=1792. [dbg] Received command VM(RESUME), id=1793. [2054] Received single step event for suspending. [2054] Suspended. [1260] Resuming vm... [0410] Resumed. [2054] Resumed. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event TYPE_LOAD, suspend=2. [0410] Suspended. [dbg] Received command TYPE(1), id=1794. [dbg] Received command TYPE(6), id=1795. [dbg] Received command VM(RESUME), id=1796. [1260] Resuming vm... [0410] Resumed. [0410] Breakpoint hit, method=Step, offset=0x1e. [0410] Suspending vm... [0410] Interrupting 2054... [0410] Sent event BREAKPOINT, suspend=2. [0410] Suspended. [dbg] Received command VM(ALL_THREADS), id=1797. [dbg] Received command THREAD(1), id=1798. Waiting for 1(2) threads to suspend... Waiting
[Mono-dev] AOT + the osx installer.
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! I'm unsure who owns the OSX build/packaging, but it seems like this should be a simple change to make since we already do it on linux, and it would be great to get this kind of performance out of the box. ___ 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, I'm unsure who owns the OSX build/packaging, but it seems like this should be a simple change to make since we already do it on linux, and it would be great to get this kind of performance out of the box. It would consume more disk space. Perhaps we could provide the option for the user to toggle those on and off at install time. Miguel ___ 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
[Mono-dev] C++ Interop
It was with great interest I read about the upcoming FOSDEM presentation on Mono C++ Interop. I was unaware such an project had been started. I looked at http://www.mono-project.com/Interop_with_Native_Libraries and http://www.mono-project.com/CPlusPlus and didn't see any mention of it. Is the result of the summer-of-code project documented somewhere? Many thanks, Sebastian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C++ Interop
On Tue, Jan 25, 2011 at 5:54 PM, Sebastian Good sebast...@palladiumconsulting.com wrote: It was with great interest I read about the upcoming FOSDEM presentation on Mono C++ Interop. I was unaware such an project had been started. I looked at http://www.mono-project.com/Interop_with_Native_Libraries and http://www.mono-project.com/CPlusPlus and didn't see any mention of it. Is the result of the summer-of-code project documented somewhere? I am also excited to hear about this talk. There isn't much written documentation on the project yet, though perhaps the pages you mention should be updated to mention it. For now, there's the code at https://github.com/nirvanai/cppinterop, which holds the work I've done over the summer and since. I'd also be happy to answer any questions about it. Best, Alex Corrado ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] WCF NetPeerTcpBinding
I've tried various different ways to initialise the mesh networking but all have the same result. I've not tried to set it up via a config file yet as I was under the impression that the config stuff was not totally complete under mono. It seems from this blog entry http://veritas-vos-liberabit.com/monogatari/2009/12/mono-wcf-advent-day-12-netpeertcpbinding.html that netpeertcpbinding does work (sort of) but there is no examlpe code. -- View this message in context: http://mono.1490590.n4.nabble.com/WCF-NetPeerTcpBinding-tp3231619p3235732.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] OutOfMemory Segmentation fault for Hashtable
Hi !
I would like to allocate a hashtable for more than 200 mln entries.
My test program is:
using System;
using System.Collections;
public class HashTest {
public static void Main ( String[] args ) {
int N = Convert.ToInt32 ( args [ 0 ] ) * 100;
Console.WriteLine ( N = + N );
Hashtable hash = new Hashtable ( N );
long m = GC.GetTotalMemory(false);
Console.WriteLine ( Total memory = + m );
}
}
A hashtable for 200 mln elements is allocated successfully and occupied
nearly 5,5 Gb
(on machine with 32Gb memory):
mono HashTest.exe 200
N = 2
Total memory = 5333598208
But for N = 202 mln I have got
mono HashTest.exe 202
N = 20200
Unhandled Exception: System.OutOfMemoryException: Out of memory
at (wrapper managed-to-native)
object:__icall_wrapper_mono_array_new_specific (intptr,int)
at System.Collections.Hashtable..ctor (Int32 capacity, Single
loadFactor, IHashCodeProvider hcp, IComparer comparer) [0x0] in
filename unknown:0
at System.Collections.Hashtable..ctor (Int32 capacity, Single
loadFactor) [0x0] in filename unknown:0
at System.Collections.Hashtable..ctor (Int32 capacity) [0x0] in
filename unknown:0
at HashTest.Main (System.String[] args) [0x0] in filename
unknown:0
I have used for the above tests Mono 2.8.2.
For Mono 2.10, I have
a )
mono HashTest.exe 202
N = 20200
Unhandled Exception: OutOfMemoryException
b) with --enable-big-arrays
$ mono HashTest.exe 202
N = 20200
Stacktrace:
Segmentation fault
Can I post a corresponding entry on the bugzilla?
Yury.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] OutOfMemory Segmentation fault for Hashtable
On 25.01.2011 13:16, Yury Serdyuk wrote: Can I post a corresponding entry on the bugzilla? You can, but consider that even on 64 bit systems *a single object* cannot exceed 2GB (except Mono's big arrays), so the error you've encountered is probably not a bug (in doesn't work under MS.NET 64-bit either). Neither S.C.Hashtable nor S.C.G.Dictionary were written with big arrays in mind. Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] OutOfMemory Segmentation fault for Hashtable
On Tue, Jan 25, 2011 at 2:23 PM, Robert Jordan robe...@gmx.net wrote: On 25.01.2011 13:16, Yury Serdyuk wrote: Can I post a corresponding entry on the bugzilla? You can, but consider that even on 64 bit systems *a single object* cannot exceed 2GB (except Mono's big arrays), so the error you've encountered is probably not a bug (in doesn't work under MS.NET 64-bit either). Neither S.C.Hashtable nor S.C.G.Dictionary were written with big arrays in mind. And big arrays is an experimental, non supported feature. As of now it's not complete and only works on selected toy examples. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Gtksourceview-sharp for Windows?
FYI, I gave up on GtkSourceView under Windows and switched to Mono.TextEditor from MonoDevelop. It is working great on Windows, Mac, and Linux. In case anyone is interested, this is now part of the Pyjama Project. Pyjama is an IDE and shell designed for multiple languages (Python, Ruby, Scheme, etc). It runs under Mono, with GUI provided by Gtk#. For more information, please see: http://pyjamaproject.org/ -Doug On Fri, Jan 14, 2011 at 11:20 AM, Doug Blank doug.bl...@gmail.com wrote: Still looking for any info on gtksourceview-sharp on Windows. I notice: http://www.mono-project.com/GtkSharpDetails#GtkSourceView_Sharp says *Not not available on the Windows GTK# package (which I presume the double negative means really not, rather than logical positive). Anyone know why? Is it possible to make work with gtk-sharp? What's the issue? I see that gedit has a version for windows; can that be intermixed with gtk-sharp? If anyone knows any details about this package, or knows someone I can write to, please let me know. Thanks! -Doug On Mon, Jan 10, 2011 at 10:47 AM, Doug Blank doug.bl...@gmail.com wrote: Hello mono-list, It would be great if gtksourceview-sharp could come with the Mono for Windows install. Otherwise, it would be great if I could build it. I am running Mono 2.8.1 on Windows 7, and looking to use with IronPython. This works fine on Linux: % mono ipy.exe import clr clr.AddReference(gtksourceview2-sharp) import GtkSourceView How can I get this to work on Windows? I guess I need gtksourceview, gtksourceview-sharp. Anything else? Do I need to build this using cygwin? I've asked on gedit-list and gtk-sharp-list, but haven't gotten any responses yet. Thanks for *any* pointers! -Doug ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] HTTPS: 'Invalid certificate received from server.' and mozroots
I couldn't get this working with Mono 2.6.7 no matter what I tried on Ubuntu
or CentOS.
With 2.8.2 I did a mozroots --machine --import --sync and it just worked.
This unfortunate hack seems to be littering many open source projects. It's
bad:
ServicePointManager.ServerCertificateValidationCallback += delegate { return
true; };
--
View this message in context:
http://mono.1490590.n4.nabble.com/HTTPS-Invalid-certificate-received-from-server-and-mozroots-tp3226929p3237391.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
