Re: [Mono-dev] [PATCH] Extract mono_exception_get_message_string from mono_print_exception
On Thu, Jul 1, 2010 at 8:06 PM, Michael Hutchinson wrote: > Also, mono_free, as defined in mono-publib.h, does not seem to exist, > so as an embedder it's currently not possible to free the returned > string. Oh, false alarm, it seems the problem is that mono-publib.c isn't included in the MSVC project. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Extract mono_exception_get_message_string from mono_print_exception
On Thu, Jul 1, 2010 at 3:44 PM, Michael Hutchinson wrote: > The attached patch adds a new mono_exception_get_message_string > function to the Mono public API, extracted from mono_print_exception. > This makes it possible for embedders easily to convert exceptions to > strings without printing them and without using private API. > > OK to commit to trunk? On second thoughts, mono_exception_to_string is a better name. Also, mono_free, as defined in mono-publib.h, does not seem to exist, so as an embedder it's currently not possible to free the returned string. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Make mono_dl_register_library into a fallback
The mono_dl_register_library function can currently be used to register P/Invoke mappings for platforms that do not have a dynamic linker. The attached patch makes it also function as a fallback when the system's dynamic linker cannot resolve the library, so that it is always available to embedders. I'll also need to restore mono/utils/mono-embed.h to the public headers in the autotools build (but this patch was created using MSVC on Windows). OK to commit to trunk? -- Michael Hutchinson http://mjhutchinson.com mono-dl-map.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Extract mono_exception_get_message_string from mono_print_exception
The attached patch adds a new mono_exception_get_message_string function to the Mono public API, extracted from mono_print_exception. This makes it possible for embedders easily to convert exceptions to strings without printing them and without using private API. OK to commit to trunk? -- Michael Hutchinson http://mjhutchinson.com mono-print-exception.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Why GIT?
We are moving to github as our primary repo, which means people can continue to use svn via their svn bridge, or all the associated web tools. -g On 2010-07-01, at 3:09 PM, Teravus Ovares wrote: > Going the Git route, I'd suggest you set up a github account and have > a github mirror. Git is... complicated.And, while, advanced > developers can appreciate the things that make it nice. Beginner > developers see it as a huge hurdle to get over to contribute. One of > the things that helps with Git transitions is advanced tools such as > GitHub. The other thing that helps is 'how to do x' for people used > to subversion.Even with all of this in place, you're still > probably going to see a decrease in contributions from the individual > in the community. You may see more organizations contributing though > if most of your contributions comes from organizations since it's > easier to merge. > > Regards > > Teravus > > On Thu, Jul 1, 2010 at 1:26 AM, Miguel de Icaza wrote: >> Hello Amir, >> >>> I was wondering if you can elaborate on why/how you chose GIT for future >>> source control of Mono? With a lot of options out there, I'm just wanting a >>> peek at some of your or the Mono team's thoughts when evaluating other VCS. >>> Maybe a post on your blog is due :) >> >> I am afraid I do not have a great answer to that question. >> It was mostly inertia from the rest of the team. I do not mind subversion >> myself and find it very simple to use. But some members in the team have >> started using svn2git and keeping their own repositories around, so we kind >> of gravitated there. >> Miguel. >> ___ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Why GIT?
Going the Git route, I'd suggest you set up a github account and have a github mirror. Git is... complicated.And, while, advanced developers can appreciate the things that make it nice. Beginner developers see it as a huge hurdle to get over to contribute. One of the things that helps with Git transitions is advanced tools such as GitHub. The other thing that helps is 'how to do x' for people used to subversion.Even with all of this in place, you're still probably going to see a decrease in contributions from the individual in the community. You may see more organizations contributing though if most of your contributions comes from organizations since it's easier to merge. Regards Teravus On Thu, Jul 1, 2010 at 1:26 AM, Miguel de Icaza wrote: > Hello Amir, > >> I was wondering if you can elaborate on why/how you chose GIT for future >> source control of Mono? With a lot of options out there, I'm just wanting a >> peek at some of your or the Mono team's thoughts when evaluating other VCS. >> Maybe a post on your blog is due :) > > I am afraid I do not have a great answer to that question. > It was mostly inertia from the rest of the team. I do not mind subversion > myself and find it very simple to use. But some members in the team have > started using svn2git and keeping their own repositories around, so we kind > of gravitated there. > Miguel. > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] altstack for osx
On 06/23/10 Geoff Norton wrote:
> Attached is a patch which enables sigaltstack for OSX (x86 and amd64).
>
> The configure.in check passes on amd64 and fails on x86 for some reason (the
> signal isn't delivered to the child ?)
> but the support appears to work correctly on both.
> --- a/mono/mini/exceptions-amd64.c
> +++ b/mono/mini/exceptions-amd64.c
> @@ -723,7 +723,6 @@ handle_signal_exception (gpointer obj, gboolean test_only)
> gboolean
> mono_arch_handle_exception (void *sigctx, gpointer obj, gboolean test_only)
> {
> -#if defined(MONO_ARCH_USE_SIGACTION) && defined(UCONTEXT_GREGS)
> /*
>* Handling the exception in the signal handler is problematic, since
> the original
>* signal is disabled, and we could run arbitrary code though the
> debugger. So
> @@ -748,29 +747,8 @@ mono_arch_handle_exception (void *sigctx, gpointer obj,
> gboolean test_only)
> UCONTEXT_REG_RIP (sigctx) = (guint64)handle_signal_exception;
>
> return TRUE;
> -#else
> - MonoContext mctx;
> -
> - mono_arch_sigctx_to_monoctx (sigctx, &mctx);
> -
> - if (mono_debugger_handle_exception (&mctx, (MonoObject *)obj))
> - return TRUE;
> -
> - mono_handle_exception (&mctx, obj, MONO_CONTEXT_GET_IP (&mctx),
> test_only);
> -
> - mono_arch_monoctx_to_sigctx (&mctx, sigctx);
> -
> - return TRUE;
> -#endif
I would leave the alternate code in, it may be needed for other ports.
> diff --git a/mono/mini/mini-exceptions.c b/mono/mini/mini-exceptions.c
> index 5a73ac9..3881b7e 100644
> --- a/mono/mini/mini-exceptions.c
> +++ b/mono/mini/mini-exceptions.c
> @@ -1594,13 +1594,23 @@ mono_handle_exception (MonoContext *ctx, gpointer
> obj, gpointer original_ip, gbo
> #error "Can't use sigaltstack without sigaction"
> #endif
>
> +/*
> + * Handling a ovf on osx requires a lot more stack space than on linux
> because
> + * we might end up in CoreFoundation getting the locale
You might want to adjust also the minimum thread stack size to account
for this (adding a check in metadata/threads.c). Bonus points for also
fixing the race with the mono_threads_set_default_stacksize() calls in
threadpool.c (maybe adding a stack size argument to
mono_thread_create_internal() in a separate patch).
> @@ -1682,13 +1699,19 @@ static gboolean
> try_restore_stack_protection (MonoJitTlsData *jit_tls, int extra_bytes)
> {
> gint32 unprotect_size = jit_tls->stack_ovf_guard_size;
> + /* OSX requires a ton of stack space when we're handling an overflow
> exception, because
> + * we might call into corefoundation to get the locale and other such
> things
> + * as such we'll just give the entire page back to the system
> + */
In this case some of the more complex stack overflow scenarios won't be
handled. We unprotect a page at a time to have a chance of handling
an additional overflow during finally or catch handlers.
Anyway, the patch is ok to commit.
Thanks!
lupus
--
-
lu...@debian.org debian/rules
lu...@ximian.com Monkeys do it better
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Adding documentation for new namespace
Make sure you're running monodoc trunk (maybe 2.6; not sure). 2.4 has lots of
known+filed+fixed-in-trunk bugs.
- Jon
On Jul 1, 2010, at 7:11 AM, Chris Bacon wrote:
> Hi Jon,
>
> Thanks for thes instructions.
>
> When I run monodoc and select one of the new namespaces in corlib (e.g.
> System.Diagnostics.Contracts) monodoc throws an exception:
> ch...@ubuntupc:~/Mono/mcs/class/corlib$ monodoc --edit Documentation/en
> using WebKit
> using WebKit
> Marshaling changed signal
> Exception in Gtk# callback delegate
> Note: Applications can use GLib.ExceptionManager.UnhandledException to
> handle the exception.
> System.Reflection.TargetInvocationException: Exception has been thrown by the
> target of an invocation. ---> System.ArgumentNullException: Argument cannot
> be null.
> Parameter name: path
> at System.IO.FileStream..ctor (System.String path, FileMode mode,
> FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous,
> FileOptions options) [0x0]
> at System.IO.FileStream..ctor (System.String path, FileMode mode,
> FileAccess access, FileShare share) [0x0]
> at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor
> (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
> at System.IO.File.OpenRead (System.String path) [0x0]
> at ICSharpCode.SharpZipLib.Zip.ZipFile..ctor (System.String name) [0x0]
> at Monodoc.HelpSource.GetHelpXmlWithChanges (System.String id) [0x0]
> at Monodoc.EcmaHelpSource.RenderNamespaceLookup (System.String nsurl,
> Monodoc.Node& match_node) [0x0]
> at Monodoc.RootTree.RenderUrl (System.String url, Monodoc.Node& match_node)
> [0x0]
> at Monodoc.TreeBrowser.RowActivated (System.Object sender, System.EventArgs
> a) [0x0]
> at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke
> (object,object[],System.Exception&)
> at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags
> invokeAttr, System.Reflection.Binder binder, System.Object[] parameters,
> System.Globalization.CultureInfo culture) [0x0]
> --- End of inner exception stack trace ---
> at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags
> invokeAttr, System.Reflection.Binder binder, System.Object[] parameters,
> System.Globalization.CultureInfo culture) [0x0]
> at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[]
> parameters) [0x0]
> at System.Delegate.DynamicInvokeImpl (System.Object[] args) [0x0]
> at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args)
> [0x0]
> at System.Delegate.DynamicInvoke (System.Object[] args) [0x0]
> at GLib.Signal.ClosureInvokedCB (System.Object o, GLib.ClosureInvokedArgs
> args) [0x0]
> at GLib.SignalClosure.Invoke (GLib.ClosureInvokedArgs args) [0x0]
> at GLib.SignalClosure.MarshalCallback (IntPtr raw_closure, IntPtr
> return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint,
> IntPtr marshal_data) [0x0]
>at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e,
> Boolean is_terminal)
>at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr
> return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint,
> IntPtr marshal_data)
>at Gtk.Application.gtk_main()
>at Gtk.Application.Run()
>at Monodoc.Driver.Main(System.String[] args)
> ch...@ubuntupc:~/Mono/mcs/class/corlib$
>
> It doesn't crash when selecting a namespace that isn't new.
>
> Thanks
> Chris
>
> Jonathan Pryor wrote:
>>
>> On Wed, 2010-06-30 at 14:58 +0100, Chris Bacon wrote:
>>
>>> I would like to add some documentation for the
>>> System.Diagnostics.Contracts namespace, for which there is currently no
>>> documentation.
>>>
>>> I cannot see a way to add a new namespace using the Mono Documentation
>>> Library. Please could someone let me know how best to do this.
>>>
>>
>> cd mcs/class/corlib
>> # or some other assembly directory.
>> make PROFILE=net_4_0 doc-update
>> # generates doc stubs in Documentation/en
>> monodoc --edit Documentation/en
>> # view the 'Mono Documentation/mscorlib' node in the
>> # left-hand pane. [0]
>>
>> You can then edit e.g.
>> mcs/class/corlib/Documentation/en/System.Diagnostics.Contracts/*.xml,
>> `svn add` your XML files and `svn commit` them.
>>
>> I've just committed the doc stubs for mscorlib.dll v4.0, so your first
>> commit won't intermix stubs with content (and be gigantic); r159740.
>>
>> To install the docs:
>>
>> cd mcs/docs
>> rm netdocs{.tree,.zip}
>> make PROFILE=net_4_0
>> make PROFILE=net_4_0 install
>>
>> The intermediate `rm` is needed to ensure that nedocs.zip is rebuilt, as
>> the make(1) dependencies for rebuilding are inadequate.
>>
>> Once you've `make install`ed, monodoc will show the new d
Re: [Mono-dev] Adding documentation for new namespace
Hi Jon,
Thanks for thes instructions.
When I run monodoc and select one of the new namespaces in corlib (e.g.
System.Diagnostics.Contracts) monodoc throws an exception:
ch...@ubuntupc:~/Mono/mcs/class/corlib$ monodoc --edit Documentation/en
using WebKit
using WebKit
Marshaling changed signal
Exception in Gtk# callback delegate
Note: Applications can use GLib.ExceptionManager.UnhandledException to
handle the exception.
System.Reflection.TargetInvocationException: Exception has been thrown
by the target of an invocation. ---> System.ArgumentNullException:
Argument cannot be null.
Parameter name: path
at System.IO.FileStream..ctor (System.String path, FileMode mode,
FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous,
FileOptions options) [0x0]
at System.IO.FileStream..ctor (System.String path, FileMode mode,
FileAccess access, FileShare share) [0x0]
at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor
(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
at System.IO.File.OpenRead (System.String path) [0x0]
at ICSharpCode.SharpZipLib.Zip.ZipFile..ctor (System.String name)
[0x0]
at Monodoc.HelpSource.GetHelpXmlWithChanges (System.String id) [0x0]
at Monodoc.EcmaHelpSource.RenderNamespaceLookup (System.String nsurl,
Monodoc.Node& match_node) [0x0]
at Monodoc.RootTree.RenderUrl (System.String url, Monodoc.Node&
match_node) [0x0]
at Monodoc.TreeBrowser.RowActivated (System.Object sender,
System.EventArgs a) [0x0]
at (wrapper managed-to-native)
System.Reflection.MonoMethod:InternalInvoke
(object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj,
BindingFlags invokeAttr, System.Reflection.Binder binder,
System.Object[] parameters, System.Globalization.CultureInfo culture)
[0x0]
--- End of inner exception stack trace ---
at System.Reflection.MonoMethod.Invoke (System.Object obj,
BindingFlags invokeAttr, System.Reflection.Binder binder,
System.Object[] parameters, System.Globalization.CultureInfo culture)
[0x0]
at System.Reflection.MethodBase.Invoke (System.Object obj,
System.Object[] parameters) [0x0]
at System.Delegate.DynamicInvokeImpl (System.Object[] args) [0x0]
at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args)
[0x0]
at System.Delegate.DynamicInvoke (System.Object[] args) [0x0]
at GLib.Signal.ClosureInvokedCB (System.Object o,
GLib.ClosureInvokedArgs args) [0x0]
at GLib.SignalClosure.Invoke (GLib.ClosureInvokedArgs args) [0x0]
at GLib.SignalClosure.MarshalCallback (IntPtr raw_closure, IntPtr
return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr
invocation_hint, IntPtr marshal_data) [0x0]
at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e,
Boolean is_terminal)
at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr
return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr
invocation_hint, IntPtr marshal_data)
at Gtk.Application.gtk_main()
at Gtk.Application.Run()
at Monodoc.Driver.Main(System.String[] args)
ch...@ubuntupc:~/Mono/mcs/class/corlib$
It doesn't crash when selecting a namespace that isn't new.
Thanks
Chris
Jonathan Pryor wrote:
On Wed, 2010-06-30 at 14:58 +0100, Chris Bacon wrote:
I would like to add some documentation for the
System.Diagnostics.Contracts namespace, for which there is currently no
documentation.
I cannot see a way to add a new namespace using the Mono Documentation
Library. Please could someone let me know how best to do this.
cd mcs/class/corlib
# or some other assembly directory.
make PROFILE=net_4_0 doc-update
# generates doc stubs in Documentation/en
monodoc --edit Documentation/en
# view the 'Mono Documentation/mscorlib' node in the
# left-hand pane. [0]
You can then edit e.g.
mcs/class/corlib/Documentation/en/System.Diagnostics.Contracts/*.xml,
`svn add` your XML files and `svn commit` them.
I've just committed the doc stubs for mscorlib.dll v4.0, so your first
commit won't intermix stubs with content (and be gigantic); r159740.
To install the docs:
cd mcs/docs
rm netdocs{.tree,.zip}
make PROFILE=net_4_0
make PROFILE=net_4_0 install
The intermediate `rm` is needed to ensure that nedocs.zip is rebuilt, as
the make(1) dependencies for rebuilding are inadequate.
Once you've `make install`ed, monodoc will show the new documentation.
- Jon
[0] I can't actually recommend 'monodoc --edit' for editing
documentation [1], but it is handy for viewing documentation without
assembling and installing it.
[1]
http://www.jprl.com/Blog/archive/development/mono/mdoc/2010/Jan-10.html
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
