Re: [Mono-dev] Mono on DD-WRT or OpenWrt

2008-09-05 Thread Kornél Pál
Hi,

Rodrigo Kumpera wrote:
  Well, OpenWrt runs mostly or arm based devises, so mono should work.
 
  The issue will be building a small enough runtime to fit the flash card.

Sorry not mentioning the architecture. The devices I'm interested in use 
the MIPS32 architecture. I've found few documentation on the status of 
MIPS support on the home page.

The disk space problem can be solved by using an external hard drive 
connected via USB. (Other solutions involve hardware modification.)

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


Re: [Mono-dev] error CS0006: cannot find metadata file `System.Data.dll`

2008-09-05 Thread Leandro Tracchia
ok i found the package
(http://packages.ubuntu.com/search?suite=defaultsection=allarch=anysearchon=contentskeywords=System.Data.dll).
i installed both 1.0 and 2.0, but which one am i supposed to
use/install???

i also found i have to install this package to get the .exe file to
run because i was getting the following error:
Unhandled Exception: System.NotSupportedException: CodePage 1252 not supported
http://packages.ubuntu.com/search?suite=hardysection=allarch=anysearchon=contentskeywords=libmono-i18n2.0-cil
http://ubuntuforums.org/showthread.php?t=831409


On Thu, Sep 4, 2008 at 5:59 PM, Michael Hutchinson
[EMAIL PROTECTED] wrote:

 Unlike most other distros, Debian/Ubuntu breaks Mono up into many
 smaller packages. One of them contains the 1.0 System.Data.dll, and
 another contains the 2.0 System.Data.dll, though I can't remember the
 package names right 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-dev] Compilation error for ARM

2008-09-05 Thread FirstName LastName
Hi,
 
I'm trying to compile the latest code from SVN (rev 112374) because I have some 
issues with mono 1.9.1 regarding soft float with ARM.
 
I get the following error:
 
CC  pedump.oLD  pedump../utils/.libs/libmonoutils.a(mono-mmap.o): In 
function 
`shared_cleanup':/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:387:
 undefined reference to `shm_unlink'../utils/.libs/libmonoutils.a(mono-mmap.o): 
In function 
`mono_shared_area':/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:409:
 undefined reference to 
`shm_open'/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:412:
 undefined reference to 
`shm_unlink'/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:413:
 undefined reference to 
`shm_open'/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:421:
 undefined reference to 
`shm_unlink'/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:426:
 undefined reference to `shm_unlink'../utils/.libs/libmonoutils.a(mono-mmap.o): 
In function 
`mono_shared_area_remove':/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:447:
 undefined reference to `shm_unlink'../utils/.libs/libmonoutils.a(mono-mmap.o): 
In function 
`mono_shared_area_for_pid':/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:464:
 undefined reference to `shm_open'collect2: ld returned 1 exit statusmake[3]: 
*** [pedump] Error 1make[3]: Leaving directory 
`/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/metadata'make[2]: *** 
[all-recursive] Error 1make[2]: Leaving directory 
`/home/ubuntu/Install/cross-arm-mono-tip/mono/mono'make[1]: *** [all-recursive] 
Error 1make[1]: Leaving directory 
`/home/ubuntu/Install/cross-arm-mono-tip/mono'make: *** [all] Error [EMAIL 
PROTECTED]:/home/ubuntu/Install/cross-arm-mono-tip/mono# 
 
Basically, it doesn't find shm_open and shm_unlink.  I'm working with uClibc. I 
noticed that my librt.a doesn't have these methods.  That's why I get this 
error.
 
However, I didn't have this issue when compiling 1.9.1.  Is there a way to 
configure MONO to not use shared memory?
 
I tried  --disable-shared-handles but it doesn't work.
 
_

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


Re: [Mono-dev] System.Drawing.Graphics ignores InterpolationMode

2008-09-05 Thread Sebastien Pouliot
Hello,

Cairo, on which libgdiplus depends for graphics, has much
less interpolation options than MS GDI+ defines in its API. So
libgdiplus maps many to few options in this case.

Cairo is also known not to downscale images very well (but some Cairo
people are looking at this). Google cairo's mailing-list if you want to
know more about the issues.

Sebastien

On Thu, 2008-09-04 at 06:06 -0700, Onelook wrote:
 I have similar problem. All resized (downsampled) images by this code:
 https://bugzilla.novell.com/attachment.cgi?id=169051
 have very low quality in compare with MS .NET Framework. How can I generate
 good quality thumbnails in Mono?
 
 Thanks,
 Onelook
 
 
 
 Jonathan Resnick wrote:
  
  When using the System.Drawing.Graphics class, I set the the property
  InterpolationMode to InterpolationMode.NearestNeighbor.  However, the
  image
  rendered to the screen still looks as though it has undergone bilinear
  interpolation.  Running the exact same code on .NET runtime in Windows,
  the
  image is clearly not interpolated.
   
  Does anyone know if this is a bug (in which case I can submit a bug
  report),
  or is the InterpolationMode property simply not yet supported on Linux?
   
  Thanks,
  Jonathan
  
  ___
  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] Compilation error for ARM

2008-09-05 Thread Rodrigo Kumpera
Hi,

The functions that uses shm_* exists for making performance counters
readable from the outside.
But the patch to export performance counters has not yet hit trunk so, for
now, you can just comment the offending
code.

It would be nice, thou, to have a configure option to turn this off once it
hits trunk as embedded targets (as yours) might not
have proper support.




2008/9/5 FirstName LastName [EMAIL PROTECTED]

 Hi,

 I'm trying to compile the latest code from SVN (rev 112374) because I have
 some issues with mono 1.9.1 regarding soft float with ARM.

 I get the following error:

 CC  pedump.o
 LD  pedump
 ../utils/.libs/libmonoutils.a(mono-mmap.o): In function `shared_cleanup':
 /home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:387:
 undefined reference to `shm_unlink'
 ../utils/.libs/libmonoutils.a(mono-mmap.o): In function `mono_shared_area':
 /home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:409:
 undefined reference to `shm_open'
 /home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:412:
 undefined reference to `shm_unlink'
 /home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:413:
 undefined reference to `shm_open'
 /home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:421:
 undefined reference to `shm_unlink'
 /home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:426:
 undefined reference to `shm_unlink'
 ../utils/.libs/libmonoutils.a(mono-mmap.o): In function
 `mono_shared_area_remove':
 /home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:447:
 undefined reference to `shm_unlink'
 ../utils/.libs/libmonoutils.a(mono-mmap.o): In function
 `mono_shared_area_for_pid':
 /home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:464:
 undefined reference to `shm_open'
 collect2: ld returned 1 exit status
 make[3]: *** [pedump] Error 1
 make[3]: Leaving directory
 `/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/metadata'
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory
 `/home/ubuntu/Install/cross-arm-mono-tip/mono/mono'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/home/ubuntu/Install/cross-arm-mono-tip/mono'
 make: *** [all] Error 2
 [EMAIL PROTECTED]:/home/ubuntu/Install/cross-arm-mono-tip/mono#


 Basically, it doesn't find shm_open and shm_unlink.  I'm working with
 uClibc. I noticed that my librt.a doesn't have these methods.  That's why I
 get this error.

 However, I didn't have this issue when compiling 1.9.1.  Is there a way to
 configure MONO to not use shared memory?

 I tried --disable-shared-handles but it doesn't work.


 --

 ___
 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] Compilation error for ARM

2008-09-05 Thread FirstName LastName
What do you mean removed offending code?  Could you give me an example of how 
to remove it? ( I want to be sure that I'm doing the right stuff)
 
Thanks!



Date: Fri, 5 Sep 2008 17:30:10 -0300From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: 
Re: [Mono-dev] Compilation error for ARMCC: mono-devel-list@lists.ximian.com; 
[EMAIL PROTECTED]
Hi,The functions that uses shm_* exists for making performance counters 
readable from the outside.But the patch to export performance counters has not 
yet hit trunk so, for now, you can just comment the offendingcode.It would be 
nice, thou, to have a configure option to turn this off once it hits trunk as 
embedded targets (as yours) might nothave proper support.
2008/9/5 FirstName LastName [EMAIL PROTECTED]

Hi, I'm trying to compile the latest code from SVN (rev 112374) because I have 
some issues with mono 1.9.1 regarding soft float with ARM. I get the following 
error: CC  pedump.oLD  
pedump../utils/.libs/libmonoutils.a(mono-mmap.o): In function 
`shared_cleanup':/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:387:
 undefined reference to `shm_unlink'../utils/.libs/libmonoutils.a(mono-mmap.o): 
In function 
`mono_shared_area':/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:409:
 undefined reference to 
`shm_open'/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:412:
 undefined reference to 
`shm_unlink'/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:413:
 undefined reference to 
`shm_open'/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:421:
 undefined reference to 
`shm_unlink'/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:426:
 undefined reference to `shm_unlink'../utils/.libs/libmonoutils.a(mono-mmap.o): 
In function 
`mono_shared_area_remove':/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:447:
 undefined reference to `shm_unlink'../utils/.libs/libmonoutils.a(mono-mmap.o): 
In function 
`mono_shared_area_for_pid':/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/utils/mono-mmap.c:464:
 undefined reference to `shm_open'collect2: ld returned 1 exit statusmake[3]: 
*** [pedump] Error 1make[3]: Leaving directory 
`/home/ubuntu/Install/cross-arm-mono-tip/mono/mono/metadata'make[2]: *** 
[all-recursive] Error 1make[2]: Leaving directory 
`/home/ubuntu/Install/cross-arm-mono-tip/mono/mono'make[1]: *** [all-recursive] 
Error 1make[1]: Leaving directory 
`/home/ubuntu/Install/cross-arm-mono-tip/mono'make: *** [all] Error [EMAIL 
PROTECTED]:/home/ubuntu/Install/cross-arm-mono-tip/mono#  Basically, it doesn't 
find shm_open and shm_unlink.  I'm working with uClibc. I noticed that my 
librt.a doesn't have these methods.  That's why I get this error. However, I 
didn't have this issue when compiling 1.9.1.  Is there a way to configure MONO 
to not use shared memory? I tried --disable-shared-handles but it doesn't work. 

___Mono-devel-list mailing [EMAIL 
PROTECTED]://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] Compilation error for ARM

2008-09-05 Thread Andreas Färber

Am 05.09.2008 um 22:30 schrieb Rodrigo Kumpera:

 The functions that uses shm_* exists for making performance counters  
 readable from the outside.
 [...]

 It would be nice, thou, to have a configure option to turn this off  
 once it hits trunk as embedded targets (as yours) might not
 have proper support.

shm_* is part of the optional POSIX XSI feature, so they should only  
be used when they are detected in configure.

Andreas

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


[Mono-dev] SEGV in mono_class_is_assignable_from in gmcs

2008-09-05 Thread Casey Marshall
I'm getting a SEGV in the function `mono_class_is_assignable_from' when 
trying to compile some internal code. I can't get the location in my 
source code where the error occurs, but I'll add some info from GDB to 
this email. Has anyone seen something like this before?

This is with a mono/gmcs from the mono-2-0 branch, revision 110293. I 
*think* the class being compiled is of the form class FooT : 
IComparableFooT, but I've been unsuccessful in getting a simple 
test case so far.

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x2b9ff82c96e0 (LWP 17401)]
 0x004a6314 in mono_class_is_assignable_from (klass=0x8d0330, 
 oklass=0x1102200) at class.c:5775
 5775if (MONO_CLASS_IMPLEMENTS_INTERFACE (oklass, 
 klass-interface_id))
 (gdb) print *klass
 $1 = {element_class = 0x8d0330, cast_class = 0x8d0330, supertypes = 0x90e470, 
 idepth = 1, rank = 0 '\0', instance_size = 16, inited = 1, init_pending = 0, 
 size_inited = 1, valuetype = 0,
   enumtype = 0, blittable = 1, unicode = 0, wastypebuilder = 0, min_align = 
 1, packing_size = 0, ghcimpl = 0, has_finalize = 0, marshalbyref = 0, 
 contextbound = 0, delegate = 0,
   gc_descr_inited = 0, has_cctor = 0, has_references = 0, has_static_refs = 
 0, no_special_static_fields = 0, is_com_object = 0, exception_type = 0 '\0', 
 parent = 0x0, nested_in = 0x0,
   nested_classes = 0x0, image = 0x8b1d50, name = 0x2ace0fdc 
 IComparable, name_space = 0x2ace09a0 System, enum_basetype = 0x0, 
 declsec_flags = 0, type_token = 33554441,
   vtable_size = 0, interface_count = 0, interface_id = 0, max_interface_id = 
 0, interface_offsets_count = 1, interfaces_packed = 0x90e4a0, 
 interface_offsets_packed = 0x90e4a8,
   interface_bitmap = 0x90e4b0 \001, interfaces = 0x0, sizes = {class_size = 
 0, element_size = 0, generic_param_token = 0}, flags = 161, field = {first = 
 3, count = 0}, method = {
 first = 128, count = 1}, property = {first = 0, count = 0}, event = 
 {first = 0, count = 0}, marshal_info = 0x0, fields = 0x0, properties = 0x0, 
 events = 0x0, methods = 0x9037c8,
   this_arg = {data = {klass = 0x8d0330, type = 0x8d0330, array = 0x8d0330, 
 method = 0x8d0330, generic_param = 0x8d0330, generic_class = 0x8d0330}, attrs 
 = 0, type = MONO_TYPE_CLASS,
 num_mods = 0, byref = 1, pinned = 0, modifiers = 0x8d0424}, byval_arg = 
 {data = {klass = 0x8d0330, type = 0x8d0330, array = 0x8d0330, method = 
 0x8d0330, generic_param = 0x8d0330,
   generic_class = 0x8d0330}, attrs = 0, type = MONO_TYPE_CLASS, num_mods 
 = 0, byref = 0, pinned = 0, modifiers = 0x8d0434}, generic_class = 0x0, 
 generic_container = 0x0,
   reflection_info = 0x0, gc_descr = 0x0, runtime_info = 0x0, next_class_cache 
 = 0x0, vtable = 0x0}
 (gdb) print *oklass
 $2 = {element_class = 0x1102200, cast_class = 0x1102200, supertypes = 
 0xf5abf8, idepth = 2, rank = 0 '\0', instance_size = 0, inited = 1, 
 init_pending = 0, size_inited = 0, valuetype = 0,
   enumtype = 0, blittable = 0, unicode = 0, wastypebuilder = 0, min_align = 
 0, packing_size = 0, ghcimpl = 0, has_finalize = 0, marshalbyref = 0, 
 contextbound = 0, delegate = 0,
   gc_descr_inited = 0, has_cctor = 0, has_references = 0, has_static_refs = 
 0, no_special_static_fields = 0, is_com_object = 0, exception_type = 0 '\0', 
 parent = 0x8b1b40, nested_in = 0x0,
   nested_classes = 0x0, image = 0x2c2bd000, name = 0xf54ad0 XXX`1, 
 name_space = 0xf54ae0 XXX.XXX.XXX.XXX, enum_basetype = 0x0, declsec_flags = 
 0,
   type_token = 33554437, vtable_size = 0, interface_count = 0, interface_id = 
 0, max_interface_id = 0, interface_offsets_count = 0, interfaces_packed = 
 0x0, interface_offsets_packed = 0x0,
   interface_bitmap = 0x0, interfaces = 0x0, sizes = {class_size = 0, 
 element_size = 0, generic_param_token = 0}, flags = 1048577, field = {first = 
 0, count = 0}, method = {first = 0,
 count = 0}, property = {first = 0, count = 0}, event = {first = 0, count 
 = 0}, marshal_info = 0x0, fields = 0x0, properties = 0x0, events = 0x0, 
 methods = 0x0, this_arg = {data = {
   klass = 0xfe5f60, type = 0xfe5f60, array = 0xfe5f60, method = 0xfe5f60, 
 generic_param = 0xfe5f60, generic_class = 0xfe5f60}, attrs = 0, type = 
 MONO_TYPE_GENERICINST, num_mods = 0,
 byref = 1, pinned = 0, modifiers = 0x11022f4}, byval_arg = {data = {klass 
 = 0xfe5f60, type = 0xfe5f60, array = 0xfe5f60, method = 0xfe5f60, 
 generic_param = 0xfe5f60,
   generic_class = 0xfe5f60}, attrs = 0, type = MONO_TYPE_GENERICINST, 
 num_mods = 0, byref = 0, pinned = 0, modifiers = 0x1102304}, generic_class = 
 0xfe5f60, generic_container = 0x0,
   reflection_info = 0x0, gc_descr = 0x0, runtime_info = 0x0, next_class_cache 
 = 0x0, vtable = 0x0}

The null pointer seems to be oklass-interface_bitmap, which is accessed 
by the MONO_CLASS_IMPLEMENTS_INTERFACE macro:

 (gdb) print oklass-interface_bitmap
 $3 = (guint8 *) 0x0

Managed stacktrace:

 Stacktrace:
 
   at (wrapper managed-to-native) 

Re: [Mono-dev] SEGV in mono_class_is_assignable_from in gmcs

2008-09-05 Thread Casey Marshall
Running gmcs under the mono debugger got me further: I was able to find 
the code causing the issue.

There were two methods in a class that had the form:

   private static XXXT FindRelevantT(XXXT[] candidates);
   private static object FindRelevantT(IComparable[] candidates);

And the type XXX is 'public class XXXT : IComparableXXXT'. These 
FindRelevant methods are called in various places in the containing 
class, always with an argument of type XXXT[]. Renaming the latter 
method fixed this issue, but I'll still try to make a concise test case.

Casey Marshall wrote:
 I'm getting a SEGV in the function `mono_class_is_assignable_from' when 
 trying to compile some internal code. I can't get the location in my 
 source code where the error occurs, but I'll add some info from GDB to 
 this email. Has anyone seen something like this before?
 
   [...]
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] SEGV in mono_class_is_assignable_from in gmcs

2008-09-05 Thread Casey Marshall
Bug filed with test case: https://bugzilla.novell.com/show_bug.cgi?id=423975

This is easy to work around in my case, so it's low priority.


Casey Marshall wrote:
 Running gmcs under the mono debugger got me further: I was able to find 
 the code causing the issue.
 
 There were two methods in a class that had the form:
 
   private static XXXT FindRelevantT(XXXT[] candidates);
   private static object FindRelevantT(IComparable[] candidates);
 
 And the type XXX is 'public class XXXT : IComparableXXXT'. These 
 FindRelevant methods are called in various places in the containing 
 class, always with an argument of type XXXT[]. Renaming the latter 
 method fixed this issue, but I'll still try to make a concise test case.
 
 Casey Marshall wrote:
 I'm getting a SEGV in the function `mono_class_is_assignable_from' 
 when trying to compile some internal code. I can't get the location in 
 my source code where the error occurs, but I'll add some info from GDB 
 to this email. Has anyone seen something like this before?

   [...]

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