Re: [Mono-dev] explicit conversion to bool and bool? on XElement

2010-07-15 Thread Atsushi Eno
Hello,

I don't see such a problem.


$ cat x.cs
using System;
using System.Xml.Linq;

public class Test
{
 public static void Main ()
 {
 XName n = XName.Get (x);
 Console.WriteLine ((bool?) new XElement (n, true));
 Console.WriteLine ((bool?) new XElement (n, True));
 Console.WriteLine ((bool?) new XElement (n, false));
 Console.WriteLine ((bool?) new XElement (n, False));
 }
}

$ gmcs x.cs -r:System.Xml.Linq.dll

$ ./x.exe
True
True
False
False

$ mono ./x.exe
True
True
False
False


Atsushi Eno

On 2010/07/15 5:53, David Mitchell wrote:
 Currently (or at least as of revision 147679), the explicit conversion to 
 bool for XElement calls System.Xml.XmlConvert.ToBoolean(), which is case 
 sensitive. However, Microsoft's implementation of the explicit conversion is 
 case insensitive.

 Attached is a patch that corrects this issue by converting the convent of the 
 XElement to lower case before sending it to XmlConvert.ToBoolean().

 I would very much appreciate it if someone would review/apply this patch (or 
 fix the issue in some other way).

 Thanks!
 -- Dave

   


 ___
 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] explicit conversion to bool and bool? on XElement

2010-07-15 Thread David Mitchell
It seems that it's been fixed on a more recent revision. Apologies

-- Dave (on the iPhone)

On Jul 15, 2010, at 3:55 AM, Atsushi Eno 
atsushi...@veritas-vos-liberabit.com wrote:

 Hello,
 
 I don't see such a problem.
 
 
 $ cat x.cs
 using System;
 using System.Xml.Linq;
 
 public class Test
 {
 public static void Main ()
 {
 XName n = XName.Get (x);
 Console.WriteLine ((bool?) new XElement (n, true));
 Console.WriteLine ((bool?) new XElement (n, True));
 Console.WriteLine ((bool?) new XElement (n, false));
 Console.WriteLine ((bool?) new XElement (n, False));
 }
 }
 
 $ gmcs x.cs -r:System.Xml.Linq.dll
 
 $ ./x.exe
 True
 True
 False
 False
 
 $ mono ./x.exe
 True
 True
 False
 False
 
 
 Atsushi Eno
 
 On 2010/07/15 5:53, David Mitchell wrote:
 Currently (or at least as of revision 147679), the explicit conversion to 
 bool for XElement calls System.Xml.XmlConvert.ToBoolean(), which is case 
 sensitive. However, Microsoft's implementation of the explicit conversion is 
 case insensitive.
 
 Attached is a patch that corrects this issue by converting the convent of 
 the XElement to lower case before sending it to XmlConvert.ToBoolean().
 
 I would very much appreciate it if someone would review/apply this patch (or 
 fix the issue in some other way).
 
 Thanks!
 -- Dave
 
 
 
 
 ___
 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] Make mono_dl_register_library into a fallback

2010-07-15 Thread Paolo Molaro
On 07/13/10 Miguel de Icaza wrote:
  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).
 
 This implements the suggested API based on Michael's patch.
 
 I still kept the mono_dl_register as we are now using in 4 different
 ports and we have a bunch of different tools generating that output as
 well as having pointed third parties to this API.

As I said, if the tables are generated by tools, they could be easily
changed to use the new API. As for other uses: I don't think we should
promote the use of an inefficient API especially since the primary use
would be in embedded systems where startup time and memory usage are
important (the array is unsorted, so the search is linear, it is
memory inefficient since the string pointer array uses more space than
needed and on some systems it causes runtime relocations). Sure, if
we're dealing with 10 entry points it's a non issue, but I know that in
the end this will be used for huge APIs like OpenGL etc (the fact you're
talking about tools generating the data hints that there are going to be
lots of entries).

 Index: mono-dl.c
 ===
 --- mono-dl.c (revision 160304)
 +++ mono-dl.c (working copy)
  
 +MonoDlMapping *
 +dl_mapping_open (const char *file);
 +
 +void *
 +dl_mapping_symbol (void *handle, const char *symbol);
 +
 +char *
 +dl_mapping_error (void);
 +

These declarations do not belong here and should be removed, the rest
looks fine.

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


[Mono-dev] Mono API: field type attributes

2010-07-15 Thread David Yuste
Hello,

  This is my first mail here. I'm David Yuste, I'm working in the gcc
branch gcc4cli.  The whole project also includes a GCC front-end for
CLI, which uses the Mono parser. The front end interacts with Mono
through the Mono API.

  The problem that I have is that I need to check whether a field is
declared as 'static' or not, given a MonoClassField pointer. Inside
Mono, it can be done just by checking 'field-type-attrs 
FIELD_ATTRIBUTE_STATIC', but this is not possible using the API.

  I've been looking for some function providing such information, but
I didn't found any way. Do you have any suggestion?

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


Re: [Mono-dev] Mono API: field type attributes

2010-07-15 Thread Robert Jordan
On 15.07.2010 16:55, David Yuste wrote:
 Hello,

This is my first mail here. I'm David Yuste, I'm working in the gcc
 branch gcc4cli.  The whole project also includes a GCC front-end for
 CLI, which uses the Mono parser. The front end interacts with Mono
 through the Mono API.

The problem that I have is that I need to check whether a field is
 declared as 'static' or not, given a MonoClassField pointer. Inside
 Mono, it can be done just by checking 'field-type-attrs
 FIELD_ATTRIBUTE_STATIC', but this is not possible using the API.

I've been looking for some function providing such information, but
 I didn't found any way. Do you have any suggestion?

mono_field_get_flags ().

MonoClassField *field = ...
int flags = mono_field_get_flags (field);
if (flags  MONO_FIELD_ATTR_STATIC)


Robert

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


Re: [Mono-dev] Visual Studio Projects Upgrade

2010-07-15 Thread Daniel Morgan
What if someone wants to create a GTK# App on Windows?  Will this Gtk# app work 
with eglib instead of glib?

--- On Wed, 7/14/10, Jonathan Chambers jonc...@gmail.com wrote:


From: Jonathan Chambers jonc...@gmail.com
Subject: [Mono-dev] Visual Studio Projects Upgrade
To: mono-devel-list mono-devel-list@lists.ximian.com
Date: Wednesday, July 14, 2010, 7:16 PM


Hello All,
      I was planning on upgrading the runtime .sln/.vcproj files in svn to 
Visual Studio 2010. I was also planning on removing the older versions (2005  
2008). I am not sure if 2005 is buildable at this point anyway.  VS2010 
supports native multi-targeting, meaning one can target the 2008 C-runtimes 
even when building in 2010. Mixing C-runtimes is a common cause of concern on 
windows and was a partial reason for trying to maintain multiple VS files.


Unless anyone objects in the next few days, I'll upgrade the files. I'll also 
make the default build use eglib rather than glib.


Thanks,
Jonathan
-Inline Attachment Follows-


___
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] Visual Studio Projects Upgrade

2010-07-15 Thread Robert Jordan
On 15.07.2010 23:02, Daniel Morgan wrote:
 What if someone wants to create a GTK# App on Windows?  Will this Gtk# app 
 work with eglib instead of glib?

It will work because EGLib does not interfere with GLib.

Robert


 --- On Wed, 7/14/10, Jonathan Chambersjonc...@gmail.com  wrote:


 From: Jonathan Chambersjonc...@gmail.com
 Subject: [Mono-dev] Visual Studio Projects Upgrade
 To: mono-devel-listmono-devel-list@lists.ximian.com
 Date: Wednesday, July 14, 2010, 7:16 PM


 Hello All,
I was planning on upgrading the runtime .sln/.vcproj files in svn to 
 Visual Studio 2010. I was also planning on removing the older versions (2005 
  2008). I am not sure if 2005 is buildable at this point anyway.  VS2010 
 supports native multi-targeting, meaning one can target the 2008 C-runtimes 
 even when building in 2010. Mixing C-runtimes is a common cause of concern on 
 windows and was a partial reason for trying to maintain multiple VS files.


 Unless anyone objects in the next few days, I'll upgrade the files. I'll also 
 make the default build use eglib rather than glib.


 Thanks,
 Jonathan
 -Inline Attachment Follows-


 ___
 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-list] moonlight key focus (abort) in browser [flash has same issue]

2010-07-15 Thread ted leslie


Now that I am using moonlight more often (and flash has this problem, but I 
turn off flash alot now),
I hate the issue of it stealing all key presses, so browser key short cuts 
don't work.

I can understand that its important to offer up as many keys to the moonlight 
plugin as possible,
but is there not some kind of combination (or custom pick for it in moonlight 
[right click settings])
that one could have browser get back focus?
How about ctrl-alt-^ ?  or maybe two odd key codes back to back  ctrl-z ctrl-z 
breaks it out?

This of course assumes there isn't already a way? But googling (against this 
annoyance in flash) didn't 
provide any answers, so I wouldn't be suprized if there isn't currently a focus 
breakout for moonlight.
Not sure if there is a way in silverlight for IE in Windows (not that I need 
that, but if it did exist, use same in linux world with moonlight).


-- 
ted leslie tles...@tcn.net
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list