[Mono-dev] ../mini/.libs/libmono-2.0.so: undefined reference to `MONO_DEBUGGER__debugger_info'

[KISHIMOTO, Makoto]

Hello

In my FreeBSD box, svn trunk build failed with
../mini/.libs/libmono-2.0.so: undefined reference to 
`MONO_DEBUGGER__debugger_info' .

Following is build log.

$ gmake
gmake  all-recursive
gmake[1]: Entering directory `/export/home/ksmakoto/Mono/BUILD'
(snip)
gmake[3]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/mono/mini'
Making all in dis
gmake[3]: Entering directory `/export/home/ksmakoto/Mono/BUILD/mono/dis'
../../doltlibtool --tag=CC   --mode=link gcc  -g -O2 -fno-strict-aliasing 
-Wdeclaration-after-statement -g -Wall -Wunused -Wmissing-prototypes 
-Wmissing-declarations -Wstrict-prototypes  -Wmissing-prototypes 
-Wnested-externs -Wpointer-arith -Wno-cast-qual -Wwrite-strings 
-mno-tls-direct-seg-refs  -pthread -o monodis dump.o main.o declsec.o 
libmonodis.a ../mini/libmono-2.0.la  -L../../eglib/src -leglib -lm  -lm   
-pthread
libtool: link: gcc -g -O2 -fno-strict-aliasing -Wdeclaration-after-statement -g 
-Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes 
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual 
-Wwrite-strings -mno-tls-direct-seg-refs -pthread -o .libs/monodis dump.o 
main.o declsec.o -pthread  libmonodis.a ../mini/.libs/libmono-2.0.so 
-L/export/home/ksmakoto/Mono/BUILD/eglib/src 
/export/home/ksmakoto/Mono/BUILD/eglib/src/.libs/libeglib.a -lm -pthread 
-Wl,-rpath -Wl,/usr/local/lib
../mini/.libs/libmono-2.0.so: undefined reference to 
`MONO_DEBUGGER__debugger_info'
gmake[3]: *** [monodis] Error 1
gmake[3]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/mono/dis'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/mono'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/export/home/ksmakoto/Mono/BUILD'
gmake: *** [all] Error 2
___
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

[Rodrigo Kumpera]

  /*
  * g_printerr ("\nUnhandled Exception: %s.%s: %s\n",
exc->vtable->klass->name_space,
  *   exc->vtable->klass->name, message);
  */
+
  g_printerr ("\nUnhandled Exception: %s\n", message);
-
+
  if (free_message)

Please remove the whitespace noise.

mono_string_to_utf8_checked can't be added to the public API without proper
documentation.

Patch looks good besides this.


On Fri, Jul 2, 2010 at 5:34 PM, Michael Hutchinson  wrote:

> On Fri, Jul 2, 2010 at 3:43 PM, Robert Jordan  wrote:
> >
> > You can get rid of the loop and optimize it further by caching
> > System.Object's ToString method:
> >
> > MonoString *
> > mono_object_to_string (MonoObject *obj, MonoObject **exc)
> > {
> >static MonoMethod *to_string = NULL;
> >MonoMethod *method;
> >
> >g_assert (obj);
> >
> >if (!to_string)
> >to_string = mono_class_get_method_from_name_flags
> > (mono_get_object_class (), "ToString", 0, METHOD_ATTRIBUTE_VIRTUAL |
> > METHOD_ATTRIBUTE_PUBLIC);
> >
> >method = mono_object_get_virtual_method (obj, method);
> >
> >return (MonoString *) mono_runtime_invoke (method, obj, NULL,
> exc);
> > }
>
> Makes sense - I'm not familiar with Mono runtime API, and I'd just
> lifted code directly from mono_print_exception.
>
> I've folded this into my patch (with the to_string fix), added
> Changelogs, and updated the utils Makefile.am to install mono-error.h.
>
> OK to commit now?
>
> --
> 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-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

[Michael Hutchinson]

On Fri, Jul 2, 2010 at 3:43 PM, Robert Jordan  wrote:
>
> You can get rid of the loop and optimize it further by caching
> System.Object's ToString method:
>
> MonoString *
> mono_object_to_string (MonoObject *obj, MonoObject **exc)
> {
>        static MonoMethod *to_string = NULL;
>        MonoMethod *method;
>
>        g_assert (obj);
>
>        if (!to_string)
>                to_string = mono_class_get_method_from_name_flags
> (mono_get_object_class (), "ToString", 0, METHOD_ATTRIBUTE_VIRTUAL |
> METHOD_ATTRIBUTE_PUBLIC);
>
>        method = mono_object_get_virtual_method (obj, method);
>
>        return (MonoString *) mono_runtime_invoke (method, obj, NULL, exc);
> }

Makes sense - I'm not familiar with Mono runtime API, and I'd just
lifted code directly from mono_print_exception.

I've folded this into my patch (with the to_string fix), added
Changelogs, and updated the utils Makefile.am to install mono-error.h.

OK to commit now?

-- 
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] Proposed Patch - Google Native Client

[Elijah Taylor]

Hi Zoltan, comments below inline.  I'll update with an new diff early next
week to address the feedback.

On Fri, Jul 2, 2010 at 12:41 PM, Zoltan Varga  wrote:

> Hi,
>
>   I finally managed to read the codegen specific changes, and here are my
> comments:
> - I'd prefer the nacl related changes to be in as few places as possible,
> so later changes by
>   people who don't know nacl won't break nacl support.
>

Agreed.  I'd like the diffs to be small so NaCl support doesn't break and
also so the changes are as easy to understand as possible.


>   There are three places where this is not done:
>   - x86_prefix - this might be unavoidable
>

Yes, I wasn't sure what to do about this, but I don't like it either.
 Luckily it's in very few spots.  Unfortunately it means that anyone writing
new code that uses x86 prefixes will likely not write NaCl-compliant code,
and what's worse, it will be a really obscure bug if it does show up,
because it will only occur when the instruction that follows it along with
the prefix would straddle a 32-byte boundary.  This error would show up as a
NaCl validation error, so at least there shouldn't be any runtime bug
exposed with this.

One possibility is to pad out all x86_prefix instructions to the nearest
32-byte boundary, but that could really bloat things depending on how often
they're used.  Do you have any idea of the prefix to non-prefix instruction
ratio?  It seems like it'd be pretty low based on looking at the code but I
haven't looked at any actual metrics.



>   - the calls to nacl_pad_call_reg/call_membase (). Could this be folded
> into
> x86_call_reg/x86_call_membase () ?
>

Agreed. This is what I've been experimenting with on x86-64 already (mostly
because of the variable length of the call sequences), I would like to do
the same on x86.  Essentially have pre/post calls in those macros that align
the call and pad it out correctly based on the actual length of the call
emitted, it also gets away from having to hard-code the length of various
call sequences which is fragile.


>   - places the where code is later patched. I think it would be better to
> modify
> x86_patch () so it skips the padding added by nacl so these changes are
> not needed.
>

I did modify x86_patch to skip the nops emitted by x86_padding, so I didn't
need to align simple inline branch patterns, but I can't recall the specific
reason off the top of my head why I still needed to align some of these
instructions prior to adding a patch info.  It might have been related to
mono_arch_get_patch_offset, which I did not modify to skip nops.  I'll
experiment with this more to see if we can lose these extra instructions.


>
>   Zoltan
>
> On Tue, Jun 22, 2010 at 7:29 PM, Elijah Taylor wrote:
>
>> Greetings Mono Developers,
>>
>> Attached is a patch to support 32-bit x86 code generation for Google
>> Native Client (http://code.google.com/p/nativeclient/).  I encourage you
>> to browse our project for more information if you're curious.  I apologize
>> for the large diff, let me try to explain the highlights to make it easier
>> to digest.
>>
>> There is a code generation component (define: __native_client_codegen__)
>> which affects the Mono bytecode -> native code generation for x86-32.  There
>> are a set of alignment restrictions, illegal instructions, and replacement
>> instructions we use for Native Client to ensure proper control-flow
>> sandboxing.  Please see
>> http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/nacl_paper.pdffor
>>  more details.
>>
>> There is also a runtime component (define: __native_client__) which
>> modifies or disables some functionality to be compatible with the Native
>> Client runtime.
>>
>> We also had to modify some code that doesn't fall under either of the
>> above defines.  Most of these changes revolved around type safety.  The
>> modified version of gcc we use to compile Native Client modules is more
>> strict about types, and it caught what look like legitimate issues with the
>> Mono codebase.  The largest issue in terms of number of errors was the use
>> of mono_bool and gboolean interchangeably between declaration and definition
>> of many functions.  gboolean is defined as an "int" but mono_bool is defined
>> as int32_t.  Other type issues are listed directly below.  Feedback is
>> appreciated on these changes because of our unfamiliarity with this code,
>> but I modified these in the way that seemed most "right" at the time.
>>
>> mono/metadata/decimal.h:47 mono_decimal2string int -> gint32
>> mono/metadata/filewatcher.h:28 gboolean -> int
>> mono/metadata/filewatcher.c:158 int32 -> gint32
>> mono/metadata/threads-type.h:64 int -> gint32
>>
>> mono/mini/mini.h:1546  gboolean sort_end -> int sort_type
>> mono/mini/mini.h:1733  gboolean fp -> int bank
>>
>> The last bit of modification is to genmdesc and the Makefiles in general.
>

Re: [Mono-dev] [PATCH] Extract mono_exception_get_message_string from mono_print_exception

[Robert Jordan]

On 02.07.2010 21:43, Robert Jordan wrote:
>   method = mono_object_get_virtual_method (obj, method);

This must be

method = mono_object_get_virtual_method (obj, to_string);

Robert

___
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

[Robert Jordan]

Hi Michael,

On 02.07.2010 21:13, Michael Hutchinson wrote:
>
> Implemented - new patch attached.

> +MonoString *
> +mono_object_to_string (MonoObject *obj, MonoObject **exc)
> +{
> + MonoString *str;
> + MonoMethod *method;
> + MonoClass *klass;
> + 
> + klass = obj->vtable->klass;
> + method = NULL;
> + while (klass && method == NULL) {
> + method = mono_class_get_method_from_name_flags (klass, 
> "ToString", 0, METHOD_ATTRIBUTE_VIRTUAL | METHOD_ATTRIBUTE_PUBLIC);
> + if (method == NULL)
> + klass = klass->parent;
> + }
> +
> + g_assert (method);
> +
> + return (MonoString *) mono_runtime_invoke (method, obj, NULL, exc);
> +}

You can get rid of the loop and optimize it further by caching
System.Object's ToString method:

MonoString *
mono_object_to_string (MonoObject *obj, MonoObject **exc)
{
static MonoMethod *to_string = NULL;
MonoMethod *method;

g_assert (obj);

if (!to_string)
to_string = mono_class_get_method_from_name_flags 
(mono_get_object_class (), "ToString", 0, METHOD_ATTRIBUTE_VIRTUAL | 
METHOD_ATTRIBUTE_PUBLIC);

method = mono_object_get_virtual_method (obj, method);

return (MonoString *) mono_runtime_invoke (method, obj, NULL, exc);
}

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Proposed Patch - Google Native Client

[Zoltan Varga]

Hi,

  I finally managed to read the codegen specific changes, and here are my
comments:
- I'd prefer the nacl related changes to be in as few places as possible, so
later changes by
  people who don't know nacl won't break nacl support.
  There are three places where this is not done:
  - x86_prefix - this might be unavoidable
  - the calls to nacl_pad_call_reg/call_membase (). Could this be folded
into
x86_call_reg/x86_call_membase () ?
  - places the where code is later patched. I think it would be better to
modify
x86_patch () so it skips the padding added by nacl so these changes are
not needed.

  Zoltan

On Tue, Jun 22, 2010 at 7:29 PM, Elijah Taylor wrote:

> Greetings Mono Developers,
>
> Attached is a patch to support 32-bit x86 code generation for Google Native
> Client (http://code.google.com/p/nativeclient/).  I encourage you to
> browse our project for more information if you're curious.  I apologize for
> the large diff, let me try to explain the highlights to make it easier to
> digest.
>
> There is a code generation component (define: __native_client_codegen__)
> which affects the Mono bytecode -> native code generation for x86-32.  There
> are a set of alignment restrictions, illegal instructions, and replacement
> instructions we use for Native Client to ensure proper control-flow
> sandboxing.  Please see
> http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/nacl_paper.pdffor
>  more details.
>
> There is also a runtime component (define: __native_client__) which
> modifies or disables some functionality to be compatible with the Native
> Client runtime.
>
> We also had to modify some code that doesn't fall under either of the above
> defines.  Most of these changes revolved around type safety.  The modified
> version of gcc we use to compile Native Client modules is more strict about
> types, and it caught what look like legitimate issues with the Mono
> codebase.  The largest issue in terms of number of errors was the use of
> mono_bool and gboolean interchangeably between declaration and definition of
> many functions.  gboolean is defined as an "int" but mono_bool is defined as
> int32_t.  Other type issues are listed directly below.  Feedback is
> appreciated on these changes because of our unfamiliarity with this code,
> but I modified these in the way that seemed most "right" at the time.
>
> mono/metadata/decimal.h:47 mono_decimal2string int -> gint32
> mono/metadata/filewatcher.h:28 gboolean -> int
> mono/metadata/filewatcher.c:158 int32 -> gint32
> mono/metadata/threads-type.h:64 int -> gint32
>
> mono/mini/mini.h:1546  gboolean sort_end -> int sort_type
> mono/mini/mini.h:1733  gboolean fp -> int bank
>
> The last bit of modification is to genmdesc and the Makefiles in general.
> We added a new flag to genmdesc called "nacl" which overrides the given max
> length of an instruction.  Native Client code tends to be larger because of
> some of the instruction requirements we have, so some of the instructions in
> cpu-x86.md had to be modified.  This is all tied to a new configure flag
> called "--enable-nacl-codegen", which enables the codegen define, and sets
> up calls to genmdesc with a --nacl flag.  It also modifies the mono-wrapper
> script so one aspect of our code generation rules (masking jump targets to
> 32-byte boundaries) is turned off while compiling and testing mono from the
> Makefiles, which is required when testing outside of the Native Client
> environment.  We're also including a standalone check "fsacheck" which tests
> mono code generation as full AOT and a the library linked into a fully
> static executable.
>
>
> I look forward to your comments, questions, and suggestions.
>
>
> -Elijah Taylor
> Google Native Client Team
>
> ___
> 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] Extract mono_exception_get_message_string from mono_print_exception

[Michael Hutchinson]

On Fri, Jul 2, 2010 at 3:13 PM, Michael Hutchinson
 wrote:
> On Fri, Jul 2, 2010 at 6:28 AM, Paolo Molaro  wrote:
<...>
>> Anyway, we can certainly add an helper method, but it should be more
>> general:
>>
>> MonoString *mono_object_to_string (MonoObject *obj, MonoObject **exc);
>>
>> Note that it works for any object and that it allows the user to
>> handle exceptions thrown from the implict method invocation.
>> The result can be used as is or mono_string_to_utf8 () can be called on
>
> Implemented - new patch attached.
>
> I also made mono_string_to_utf8_checked public, as mono_string_to_utf8
> is marked deprecated.

I just noticed that the definition in object.h should be
mono_object_to_string, not mono_object_get_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

[Michael Hutchinson]

On Fri, Jul 2, 2010 at 6:28 AM, Paolo Molaro  wrote:
> On 07/01/10 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.
>
> It is already possible to use the embedding API to get the same result
> without using any private API, of course.

My bad, I hadn't found mono_get_exception_class.

> Anyway, we can certainly add an helper method, but it should be more
> general:
>
> MonoString *mono_object_to_string (MonoObject *obj, MonoObject **exc);
>
> Note that it works for any object and that it allows the user to
> handle exceptions thrown from the implict method invocation.
> The result can be used as is or mono_string_to_utf8 () can be called on

Implemented - new patch attached.

I also made mono_string_to_utf8_checked public, as mono_string_to_utf8
is marked deprecated.

-- 
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] Problem in SvcHttpHandler.cs ?

[Atsushi Eno]

Hi,

Right, thanks for the analysis, that should be fixed, and I have an 
idea. Though I am now rewriting ASP.NET channel support based on our new 
HTTP (non-ASP.NET) channel stack and it does not use the code path you 
mentioned, I'd rather finish the rewrite first and then fix the actual 
issue.

The idea above is to use Uri comparison using UriComponents based on 
HostNameComparisonMode value (which is ignored so far).

Atsushi Eno

On 2010/06/29 21:46, Thiago Padilha wrote:
> Hi,
>
> I'm hosting a WCF service using asp.net/mono from trunk (r159644)
> but encountered a problem when accessing the service from a virtual
> machine :
>
> "
>The argument HTTP context did not match any of the registered
> listener manager (could be mismatch in URL, method etc.)
> http://172.16.122.2:8080/Person.svc
>
> Description: HTTP 500. Error processing request.
>
> Stack Trace:
>
> System.InvalidOperationException: The argument HTTP context did not
> match any of the registered listener manager (could be mismatch in
> URL, method etc.) http://172.16.122.2:8080/Person.svc
>at System.ServiceModel.Channels.SvcHttpHandler.FindBestMatchListener
> (System.Web.HttpContext ctx) [0x00120] in
> /home/thiago/monotrunk/mcs/class/System.ServiceModel/System.ServiceModel.Channels/SvcHttpHandler.cs:141
>at System.ServiceModel.Channels.SvcHttpHandler.ProcessRequest
> (System.Web.HttpContext context) [0xd] in
> /home/thiago/monotrunk/mcs/class/System.ServiceModel/System.ServiceModel.Channels/SvcHttpHandler.cs:156
>at System.Web.HttpApplication+c__Iterator2.MoveNext ()
> [0x00ce5] in 
> /home/thiago/monotrunk/mcs/class/System.Web/System.Web/HttpApplication.cs:1344
>at System.Web.HttpApplication.Tick () [0x0] in
> /home/thiago/monotrunk/mcs/class/System.Web/System.Web/HttpApplication.cs:914
> "
>
>   I think this happened because I tried to access the service trough
> the "172.16.122.0" network which is the virtual network for my VMs.
> The service works well if I access it on the local machine using the
> "http://127.0.0.1:8080/Person.svc"; Url, but fails with the same error
> if I use "http://localhost:8080/Person.svc";. After looking into the
> source code I think the problem may be on the following conditionals
> (method 'FindBestMatchListener') :
>
> "
> if (l.Uri.Equals (ctx.Request.Url)) {
>   best = l;
>   break;
>   }
> //
> if (!ctx.Request.Url.ToString ().StartsWith (l.Uri.ToString (),
> StringComparison.Ordinal))
>   continue;
> "
>
> Maybe it should check the Uris for all the network interfaces?(I have
> no idea on how to do that).
> ___
> 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] Proposed Patch - Google Native Client

[Elijah Taylor]

Great, glad to hear I made the right choices in those type changes.  Thanks
for the update.

I was hoping for a little more feedback on the x86 codegen changes,
particularly from anyone with expertise in the code generation aspects of
mono.  There's no rush on this, but it would be nice to have our changes
incorporated in the mono tree, particularly so external developers could
make use of this, and any future patches can hopefully be a bit smaller.

-Elijah


On Fri, Jul 2, 2010 at 7:42 AM, Zoltan Varga  wrote:

> Hi,
>
>
>> We also had to modify some code that doesn't fall under either of the
>> above defines.  Most of these changes revolved around type safety.  The
>> modified version of gcc we use to compile Native Client modules is more
>> strict about types, and it caught what look like legitimate issues with the
>> Mono codebase.  The largest issue in terms of number of errors was the use
>> of mono_bool and gboolean interchangeably between declaration and definition
>> of many functions.  gboolean is defined as an "int" but mono_bool is defined
>> as int32_t.  Other type issues are listed directly below.  Feedback is
>> appreciated on these changes because of our unfamiliarity with this code,
>> but I modified these in the way that seemed most "right" at the time.
>>
>> mono/metadata/decimal.h:47 mono_decimal2string int -> gint32
>> mono/metadata/filewatcher.h:28 gboolean -> int
>> mono/metadata/filewatcher.c:158 int32 -> gint32
>> mono/metadata/threads-type.h:64 int -> gint32
>>
>> mono/mini/mini.h:1546  gboolean sort_end -> int sort_type
>> mono/mini/mini.h:1733  gboolean fp -> int bank
>>
>>
> These changes look ok, and are now in SVN.
>
>  Zoltan
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Make mono_dl_register_library into a fallback

[Michael Hutchinson]

On Fri, Jul 2, 2010 at 6:18 AM, Paolo Molaro  wrote:
> On 07/01/10 Michael Hutchinson wrote:
>> 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?
>
> This interface is not suitable as a fallback mechanism, it would be too
> cumbersome to use and it's probably not ideal even for its intended
> purpose. What about a callback registration system instead?

The intended purpose, AFAIK, is to expose statically linked libraries
to P/Invoke. That's what I'm using it for, and it's very
straightforward to use this way. I have a trivial C# tool that
reflects over the library with the P/Invokes and dumps the mappings to
source files.

My patch isn't intended to provide a generic dynamic linker fallback.
It's meant to provide an easy way to P/Invoke statically linked
libraries for all embedders, not just those on platforms without
dynamic linkers.

> It is more flexible as a fallback since it doesn't require to register
> upfront all the possible names and load the all functions at startup.
> It's likely better also for the original purpose when, for example,
> even if dynamic linking is not possible it is possible to lookup a
> symbol at runtime.
> It opens up the possibility of also generating the code at runtime
> (for redirecting some win32 p/invokes to winforms for example, or other
> tricks).
>
> Something along these lines:
>
> typedef void* (*MonoDlFallbackLoad) (const char *name, int flags, char **err, 
> void *user_data);
> typedef void* (*MonoDlFallbackSymbol) (void *handle, const char *name, char 
> **err, void *user_data);
> typedef void* (*MonoDlFallbackClose) (void *handle, void *user_data);
>
> void mono_dl_register_fallback (MonoDlFallbackLoad load_func, 
> MonoDlFallbackSymbol symbol_func,
>                MonoDlFallbackClose close_func, void *user_data);
>
> The old interface could be easily implemented on top of this new one (though 
> we
> likely could drop it as well).

That's certainly more flexible, but I'm not convinced it's necessary
at this time without concrete use cases. If we're going to include the
old interface anyway - else we make embedders responsible for
reimplementing its functionality - then why not go this path for now,
and reimplement it on top of the callbacks later?

The tricks you mention could be much more useful if callbacks could
intercept lookups for individual symbols, rather than acting as a
fallback for handling whole libraries. But this would require much
more substantial changes to the dynamic linker code.

-- 
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] Proposed Patch - Google Native Client

[Zoltan Varga]

Hi,


> We also had to modify some code that doesn't fall under either of the above
> defines.  Most of these changes revolved around type safety.  The modified
> version of gcc we use to compile Native Client modules is more strict about
> types, and it caught what look like legitimate issues with the Mono
> codebase.  The largest issue in terms of number of errors was the use of
> mono_bool and gboolean interchangeably between declaration and definition of
> many functions.  gboolean is defined as an "int" but mono_bool is defined as
> int32_t.  Other type issues are listed directly below.  Feedback is
> appreciated on these changes because of our unfamiliarity with this code,
> but I modified these in the way that seemed most "right" at the time.
>
> mono/metadata/decimal.h:47 mono_decimal2string int -> gint32
> mono/metadata/filewatcher.h:28 gboolean -> int
> mono/metadata/filewatcher.c:158 int32 -> gint32
> mono/metadata/threads-type.h:64 int -> gint32
>
> mono/mini/mini.h:1546  gboolean sort_end -> int sort_type
> mono/mini/mini.h:1733  gboolean fp -> int bank
>
>
These changes look ok, and are now in SVN.

 Zoltan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Patch: Docs for System.Diagnostics.Contracts.Internal

[Chris Bacon]

Hi,

Attached is a patch that contains documentation for just the 
System.Diagnostics.Contracts.Internal namespace.
Please can I have some feedback so I know if I'm doing things correctly 
or not.
Then I will complete the documentation for the whole 
System.Diagnostics.Contracts namespace as well.


Thanks
Chris
Index: Documentation/en/System.Diagnostics.Contracts.Internal/ContractHelper.xml
===
--- Documentation/en/System.Diagnostics.Contracts.Internal/ContractHelper.xml   
(revision 159760)
+++ Documentation/en/System.Diagnostics.Contracts.Internal/ContractHelper.xml   
(working copy)
@@ -9,8 +9,8 @@
   
   
   
-To be added.
-To be added.
+Methods required by the contract rewriter to handle contract 
failures.
+These methods are called by code that has been rewritten by the 
Ccrewrite tool.
   
   
 
@@ -37,13 +37,13 @@
 
   
   
-To be added.
-To be added.
-To be added.
-To be added.
-To be added.
-To be added.
-To be added.
+The kind of contract failure.
+The user message describing this contract 
failure.
+The condition that caused this contract 
failure.
+The exception that caused this contract 
filure, if any.
+Implements the default behaviour on code contract 
failure.
+The code contract failure message, if the failure has not 
been handled already. Null if the failure has been handled 
successfully.
+The default behaviour is to call each event handler in turn, 
with exceptions thrown in the handlers treated as calls to . 
This is defined fully in section 7.3 of UserDoc.pdf from Microsoft.
   
 
 
@@ -71,13 +71,13 @@
 
   
   
-To be added.
-To be added.
-To be added.
-To be added.
-To be added.
-To be added.
-To be added.
+The kind of contract failure.
+The message to display describing this 
contract failure.
+The user message describing this contract 
failure.
+The condition that caused this contract 
failure.
+The exception that caused this contract 
filure, if any.
+Implements the default code contract failure 
behaviour.
+The default code contract failure behaviour is to trigger an 
assert if in user interactive mode, otherwise  is called to 
immediately terminate the process.
   
 
   
Index: Documentation/en/ns-System.Diagnostics.Contracts.Internal.xml
===
--- Documentation/en/ns-System.Diagnostics.Contracts.Internal.xml   
(revision 159760)
+++ Documentation/en/ns-System.Diagnostics.Contracts.Internal.xml   
(working copy)
@@ -1,6 +1,6 @@
 
   
-To be added.
-To be added.
+This namespace contains classes for handling code contract 
failures.
+
   
 
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Please help me find a good mono based Bluetooth framework.

[jgossett]

Good morning everyone,

Is there a good recommended Bluetooth framework for mono?

Thank,

Joshua Gossett___
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

[Chris Bacon]

Thanks - it's working fine now.

Jonathan Pryor wrote:
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 documentation.

 - Jon

[0] I can't actually recommend 'monodoc --edit' for editing
documentation [1], but it is handy for viewing documentation without
assembling

Re: [Mono-dev] [PATCH] Extract mono_exception_get_message_string from mono_print_exception

[Paolo Molaro]

On 07/01/10 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.

It is already possible to use the embedding API to get the same result
without using any private API, of course.
Anyway, we can certainly add an helper method, but it should be more
general:

MonoString *mono_object_to_string (MonoObject *obj, MonoObject **exc);

Note that it works for any object and that it allows the user to
handle exceptions thrown from the implict method invocation.
The result can be used as is or mono_string_to_utf8 () can be called on
it.

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] [PATCH] Make mono_dl_register_library into a fallback

[Paolo Molaro]

On 07/01/10 Michael Hutchinson wrote:
> 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?

This interface is not suitable as a fallback mechanism, it would be too
cumbersome to use and it's probably not ideal even for its intended
purpose. What about a callback registration system instead?

It is more flexible as a fallback since it doesn't require to register
upfront all the possible names and load the all functions at startup.
It's likely better also for the original purpose when, for example,
even if dynamic linking is not possible it is possible to lookup a
symbol at runtime.
It opens up the possibility of also generating the code at runtime
(for redirecting some win32 p/invokes to winforms for example, or other
tricks).

Something along these lines:

typedef void* (*MonoDlFallbackLoad) (const char *name, int flags, char **err, 
void *user_data);
typedef void* (*MonoDlFallbackSymbol) (void *handle, const char *name, char 
**err, void *user_data);
typedef void* (*MonoDlFallbackClose) (void *handle, void *user_data);

void mono_dl_register_fallback (MonoDlFallbackLoad load_func, 
MonoDlFallbackSymbol symbol_func,
MonoDlFallbackClose close_func, void *user_data);

The old interface could be easily implemented on top of this new one (though we
likely could drop it as well).

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