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
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 ch...@dunelm.org.uk 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 documentation.
- Jon
[0] I can't actually recommend 'monodoc --edit' for editing
documentation [1], but it is handy for viewing
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] 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 mig...@novell.com wrote: Hello Amir, I was wondering if you can elaborate on why/how you chose GIT for future source control of Mono? With a lot of options out there, I'm just wanting a peek at some of your or the Mono team's thoughts when evaluating other VCS. Maybe a post on your blog is due :) I am afraid I do not have a great answer to that question. It was mostly inertia from the rest of the team. I do not mind subversion myself and find it very simple to use. But some members in the team have started using svn2git and keeping their own repositories around, so we kind of gravitated there. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Why GIT?
We are moving to github as our primary repo, which means people can continue to use svn via their svn bridge, or all the associated web tools. -g On 2010-07-01, at 3:09 PM, Teravus Ovares wrote: Going the Git route, I'd suggest you set up a github account and have a github mirror. Git is... complicated.And, while, advanced developers can appreciate the things that make it nice. Beginner developers see it as a huge hurdle to get over to contribute. One of the things that helps with Git transitions is advanced tools such as GitHub. The other thing that helps is 'how to do x' for people used to subversion.Even with all of this in place, you're still probably going to see a decrease in contributions from the individual in the community. You may see more organizations contributing though if most of your contributions comes from organizations since it's easier to merge. Regards Teravus On Thu, Jul 1, 2010 at 1:26 AM, Miguel de Icaza mig...@novell.com wrote: Hello Amir, I was wondering if you can elaborate on why/how you chose GIT for future source control of Mono? With a lot of options out there, I'm just wanting a peek at some of your or the Mono team's thoughts when evaluating other VCS. Maybe a post on your blog is due :) I am afraid I do not have a great answer to that question. It was mostly inertia from the rest of the team. I do not mind subversion myself and find it very simple to use. But some members in the team have started using svn2git and keeping their own repositories around, so we kind of gravitated there. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[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
[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
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 m.j.hutchin...@gmail.com 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
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 m.j.hutchin...@gmail.com 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
