date:20090630

Re: [Mono-dev] [PATCH] Handle more gracefully invalid generic instantiations

2009-06-30 Thread Rodrigo Kumpera

Hi,

On Sat, Jun 27, 2009 at 2:49 AM, Raja R Harinath harin...@hurrynot.orgwrote:

 Hi,

 Rodrigo Kumpera kump...@gmail.com writes:

  The attached patch changes class.c/inflate_generic_type to not abort the
 runtime when facing a bad instantiation.
 
  My only issue is that I'm not sure if mono_class_inflate_generic_type*
 and mono_class_inflate_generic_class should
  set a loader error when returning null. I don't think this is necessary
 as this is something their callers should do. But maybe
  mono_class_inflate_generic_method_full should.
 
  This patch doesn't fix the whole thing as an audit of all callers of
 mono_class_inflate_generic_type(_with_mempool | _no_copy)
  and mono_class_inflate_generic_class are required to property handle them
 returning NULL.
 
  I got some local tests for these errors, but they are not in good shape
 for been part of this patch.

 [snip]

  +static gboolean
  +inflate_generic_type (MonoImage *image, MonoType *type,
 MonoGenericContext *context, MonoType **res)
   {
  +#define SUCCESS(VAL) do { *res = VAL; return TRUE; } while (0)
  +#define ERROR() do { *res = NULL; return FALSE; } while (0)
switch (type-type) {
case MONO_TYPE_MVAR: {
MonoType *nt;
int num = mono_type_get_generic_param_num (type);
MonoGenericInst *inst = context-method_inst;
if (!inst || !inst-type_argv)
  - return NULL;
  + SUCCESS (NULL);
if (num = inst-type_argc)
  - g_error (MVAR %d (%s) cannot be expanded in this
 context with %d instantiations,
  - num, mono_generic_param_info
 (type-data.generic_param)-name, inst-type_argc);
  -
  + ERROR ();

 Hmm, so much machinery for the one use of ERROR!

 I think the issue is that we're forced to intertwine this particular
 error check in the middle of code dealing with the mechanics of
 inflating.  It'd be much nicer for inflate_generic_type to have the
 precondition that no VAR or MVAR in 'type' will be out-of-bounds WRT
 'context'.

 The problem is that this precondition check is currently expensive, as
 it would duplicate the same recursive traversal.  However, we _can_ and
 _should_ make it non-recursive -- we can replace the field and
 computation of MonoGenericInst::is_open with something like
 MonoGenericInst::min_context_size (yeah that name is horribly bad.  I've
 been putting of writing that code since I couldn't get a better name).

 The reason I think this is better is that we already have code in JIT
 and the verifier that need only that information (i.e. are equivalent to
 that precondition check), but are forced to walk the MonoType tree
 because 'is_open' is too limited.

 - Hari



Hari, I fail to see how changing MonoGenericInst::is_open would help here.
The type received by inflate_generic_type can be anything such as !T[],
which requires a recursive transversal to check for errors as there is no
MonoGenericInst involved.

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

Re: [Mono-dev] [PATCH] Handle more gracefully invalid generic instantiations

2009-06-30 Thread Raja R Harinath

Hi,

On Tue, Jun 30, 2009 at 19:16, Rodrigo Kumperakump...@gmail.com wrote:
 Hi,

 On Sat, Jun 27, 2009 at 2:49 AM, Raja R Harinath harin...@hurrynot.org
 wrote:

 Hi,

 Rodrigo Kumpera kump...@gmail.com writes:

  The attached patch changes class.c/inflate_generic_type to not abort the
  runtime when facing a bad instantiation.
[snip]
 I think the issue is that we're forced to intertwine this particular
 error check in the middle of code dealing with the mechanics of
 inflating.  It'd be much nicer for inflate_generic_type to have the
 precondition that no VAR or MVAR in 'type' will be out-of-bounds WRT
 'context'.

 The problem is that this precondition check is currently expensive, as
 it would duplicate the same recursive traversal.  However, we _can_ and
 _should_ make it non-recursive -- we can replace the field and
 computation of MonoGenericInst::is_open with something like
 MonoGenericInst::min_context_size (yeah that name is horribly bad.  I've
 been putting of writing that code since I couldn't get a better name).
[snip]
 Hari, I fail to see how changing MonoGenericInst::is_open would help here.
 The type received by inflate_generic_type can be anything such as !T[],
 which requires a recursive transversal to check for errors as there is no
 MonoGenericInst involved.

I guess it's easiest to explain with code.  The basic idea is to
pre-compute more information when a MonoGenericInst is created.  It's
very easy to compute the context size constraints for any context that
MonoGenericInst would be expanded in: it turns out that it can be
computed pretty much the same non-recursive way that 'is_open' is.
Now, given such a context size constraint, it's easy to check the
pre-condition upfront, in a non-recursive manner.

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

Re: [Mono-dev] [PATCH] CultureInfo_construct datetime_format and number_format fix for Windows.

2009-06-30 Thread Bill Holmes

Hi,

I have updated this patch to correct a bug we found since it was
originally posted.

-bill

On Tue, Jun 23, 2009 at 5:41 PM, Bill Holmesbillholme...@gmail.com wrote:
 Hi,

 On Windows users can customize the regional options for their
 language.  To get this information you can call GetLocaleInfo to
 obtain each individual setting.  The attached patch is a new
 implementation of
 ves_icall_System_Globalization_CultureInfo_construct_datetime_format
 and ves_icall_System_Globalization_CultureInfo_construct_number_format
 for Windows to obtain the correct settings.

 Also this patch contains a fix the missing implementation of
 g_win32_getlocale in eglib.

 -bill

 2009-06-23  Bill Holmes  billholme...@gmail.com

        * locales.c  
 (ves_icall_System_Globalization_CultureInfo_construct_datetime_format)
          (ves_icall_System_Globalization_CultureInfo_construct_number_format) 
 :
          For Windows call GetLocaleInfoA when possible to populate the 
 culture info.
          This is needed when users customize a language for the regional 
 options.

        * locales.c (get_current_locale_name) : Replace the eglib call to
 g_win32_getlocale.

        Contributed under MIT/X11 license.



CultureInfo_construct.patch
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] Simple implementation of network interface properties for Mac OS X

2009-06-30 Thread Alex Shulgin


Alex Shulgin wrote:

Alex Shulgin wrote:

Hi,

In the current version System.Net.NetworkInformation.NetworkInterface 
provides limited information about network interfaces on the system 
(their names only).


The attached patch adds support for NetworkInterfaceType and 
GetPhysicalAddress() on Mac OS.


Oops, I've almost forgot about IPv6... and missed the added file 
MacOsNetworkInterfaceMarshal.


Please see the fixed patch instead.


This worked fine, until one user reported a crash on Array.Copy in 
NetworkInformation.MacOsNetworkInterface.ImplGetAllNetworkInterfaces(). 
 I traced this down to that I believe is a problem with non-standard 
length interface name: thus the 12-byte buffer sockaddr_dl.sdl_data is 
not enough.


I've noticed that sockaddr_dl contains sdl_len member which holds the 
length of the whole sockaddr structure.  With that we can use 
Marshal.Copy instead of Array.Copy to access data past default 12-byte 
data array.  A patch against trunk is attached.


I didn't have a chance to try it with the problematic user, but still 
would like someone to review the patch and comment on it.


--
Alex
PS: is there more appropriate way to increment IntPtr value w/o using 
ToInt64()?
Index: System.Net.NetworkInformation/NetworkInterface.cs
===
--- System.Net.NetworkInformation/NetworkInterface.cs	(revision 137150)
+++ System.Net.NetworkInformation/NetworkInterface.cs	(working copy)
@@ -480,7 +480,8 @@
 			MacOsStructs.sockaddr_dl sockaddrdl = (MacOsStructs.sockaddr_dl) Marshal.PtrToStructure (addr.ifa_addr, typeof (MacOsStructs.sockaddr_dl));
 
 			macAddress = new byte [(int) sockaddrdl.sdl_alen];
-			Array.Copy (sockaddrdl.sdl_data, sockaddrdl.sdl_nlen, macAddress, 0, macAddress.Length);
+			// copy `sdl_alen' bytes from `sdl_data + sdl_nlen'
+			Marshal.Copy ((IntPtr)(addr.ifa_addr.ToInt64 () + 8 + sockaddrdl.sdl_nlen), macAddress, 0, macAddress.Length);
 			index = sockaddrdl.sdl_index;
 
 			int hwtype = (int) sockaddrdl.sdl_type;
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [PATCH] Simple implementation of network interface properties for Mac OS X

2009-06-30 Thread Alan McGovern

Hey,

On Tue, Jun 30, 2009 at 4:09 PM, Alex Shulgin 
alexander.shul...@yessoftware.com wrote:

 Alex Shulgin wrote:

 Alex Shulgin wrote:

 Hi,

 In the current version System.Net.NetworkInformation.NetworkInterface
 provides limited information about network interfaces on the system (their
 names only).

 The attached patch adds support for NetworkInterfaceType and
 GetPhysicalAddress() on Mac OS.


 Oops, I've almost forgot about IPv6... and missed the added file
 MacOsNetworkInterfaceMarshal.

 Please see the fixed patch instead.


 This worked fine, until one user reported a crash on Array.Copy in
 NetworkInformation.MacOsNetworkInterface.ImplGetAllNetworkInterfaces().  I
 traced this down to that I believe is a problem with non-standard length
 interface name: thus the 12-byte buffer sockaddr_dl.sdl_data is not enough.

 I've noticed that sockaddr_dl contains sdl_len member which holds the
 length of the whole sockaddr structure.  With that we can use Marshal.Copy
 instead of Array.Copy to access data past default 12-byte data array.  A
 patch against trunk is attached.

 I didn't have a chance to try it with the problematic user, but still would
 like someone to review the patch and comment on it.

 --
 Alex
 PS: is there more appropriate way to increment IntPtr value w/o using
 ToInt64()?


You could use a loop and Marshal.ReadByte (IntPtr ptr, int offset);

Alan.




 ___
 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] Mono 2.4 for ARM

2009-06-30 Thread Jon Shemitz

Many thanks. --with-tls=pthread got me past my first hurdle.

 

Alas, now I get 

 

mini-arm.h:28:2: error: #error At least one of ARM_FPU_NONE or
ARM_FPU_FPA or ARM_FPU_VFP must be defined.

 

and I can't seem to get past that. I've tried 

 

./configure --disable-mcs-build --with-tls=pthread ARM_FPU_NONE=1

 

and

 

make ARM_FPU_NONE=1

 

and

 

ARM_FPU_NONE=1 make 

 

and

 

export ARM_FPU_NONE=1

make

 

and I keep getting the same error. What do I have to do to enable
software floating point (gnueabi)?

 



From: Zoltan Varga [mailto:var...@gmail.com] 
Sent: Monday, June 29, 2009 6:36 PM
To: Jon Shemitz
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Mono 2.4 for ARM

 

Hi,

  Try mono 2.4.2, or pass --with-tls=pthread to configure.

 Zoltan

On Tue, Jun 30, 2009 at 1:59 AM, Jon Shemitz
jon.shem...@access-company.com wrote:

I'm trying to build Mono 2.4 for an ARM device, following the
instructions at http://mono-project.com/Mono:ARM and using an existing
Scratchbox configuration. 

I downloaded mono-2.4.tar.bz2 and extracted it with `tar xjf`. The
host-mono part went fine, but when I tried to do the Scratchbox part, I
had no arm-mono directory. When I tried to 

 ./configure --disable-mcs-build
 make 
 make install DESTDIR=`pwd`/tmptree

in the mono-2.4 directory, `make` gave me a lot of warnings, and finally
a series of undefined reference to `GC_local_malloc' errors,
culminating in 

collect2: ld returned 1 exit status

make[3]: *** [pedump] Error 1

make[3]: Leaving directory
`/home/jon/src/dev/alp/cross/mono-2.4/mono/metadata'

make[2]: *** [all-recursive] Error 1

make[2]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4/mono'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4'

make: *** [all] Error 2

Are there more up-to-date build instructions somewhere? Is ARM only
supported for 1.x? Or am I just too stupid to get Mono running on our
platform?


___
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] Mono 2.4 for ARM

2009-06-30 Thread Koushik K. Dutta

Use:

make -DARM_FPU_NONE


On 6/30/09 3:39 PM, Jon Shemitz jon.shem...@access-company.com wrote:

Many thanks. --with-tls=pthread got me past my first hurdle.

Alas, now I get

mini-arm.h:28:2: error: #error At least one of ARM_FPU_NONE or ARM_FPU_FPA or 
ARM_FPU_VFP must be defined.

and I can't seem to get past that. I've tried

./configure --disable-mcs-build --with-tls=pthread ARM_FPU_NONE=1

and

make ARM_FPU_NONE=1

and

ARM_FPU_NONE=1 make

and

export ARM_FPU_NONE=1
make

and I keep getting the same error. What do I have to do to enable software 
floating point (gnueabi)?




From: Zoltan Varga [mailto:var...@gmail.com]
Sent: Monday, June 29, 2009 6:36 PM
To: Jon Shemitz
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Mono 2.4 for ARM

Hi,

  Try mono 2.4.2, or pass --with-tls=pthread to configure.

Zoltan

On Tue, Jun 30, 2009 at 1:59 AM, Jon Shemitz jon.shem...@access-company.com 
wrote:

I'm trying to build Mono 2.4 for an ARM device, following the instructions at 
http://mono-project.com/Mono:ARM and using an existing Scratchbox configuration.

I downloaded mono-2.4.tar.bz2 and extracted it with `tar xjf`. The host-mono 
part went fine, but when I tried to do the Scratchbox part, I had no arm-mono 
directory. When I tried to
 ./configure --disable-mcs-build
 make
 make install DESTDIR=`pwd`/tmptree
in the mono-2.4 directory, `make` gave me a lot of warnings, and finally a 
series of undefined reference to `GC_local_malloc' errors, culminating in

collect2: ld returned 1 exit status

make[3]: *** [pedump] Error 1

make[3]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4/mono/metadata'

make[2]: *** [all-recursive] Error 1

make[2]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4/mono'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4'

make: *** [all] Error 2

Are there more up-to-date build instructions somewhere? Is ARM only supported 
for 1.x? Or am I just too stupid to get Mono running on our platform?


___
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] Mono 2.4 for ARM

2009-06-30 Thread Jon Shemitz

I tried 

 

make -D ARM_FPU_NONE

 

but not

 

make -DARM_FPU_NONE

 

however, on Ubuntu 8.04, both give me

 

make: invalid option -- D

 



From: Koushik K. Dutta [mailto:ko...@koushikdutta.com] 
Sent: Tuesday, June 30, 2009 3:54 PM
To: Jon Shemitz; Zoltan Varga
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Mono 2.4 for ARM

 

Use:

make -DARM_FPU_NONE 


On 6/30/09 3:39 PM, Jon Shemitz jon.shem...@access-company.com
wrote:

Many thanks. --with-tls=pthread got me past my first hurdle.
 
Alas, now I get 
 
mini-arm.h:28:2: error: #error At least one of ARM_FPU_NONE or
ARM_FPU_FPA or ARM_FPU_VFP must be defined.
 
and I can't seem to get past that. I've tried 
 
./configure --disable-mcs-build --with-tls=pthread ARM_FPU_NONE=1
 
and
 
make ARM_FPU_NONE=1
 
and
 
ARM_FPU_NONE=1 make 
 
and
 
export ARM_FPU_NONE=1
make
 
and I keep getting the same error. What do I have to do to enable
software floating point (gnueabi)?
 



From: Zoltan Varga [mailto:var...@gmail.com] 
Sent: Monday, June 29, 2009 6:36 PM
To: Jon Shemitz
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Mono 2.4 for ARM

Hi,

  Try mono 2.4.2, or pass --with-tls=pthread to configure.

Zoltan

On Tue, Jun 30, 2009 at 1:59 AM, Jon Shemitz
jon.shem...@access-company.com wrote:

I'm trying to build Mono 2.4 for an ARM device, following the
instructions at http://mono-project.com/Mono:ARM and using an existing
Scratchbox configuration. 

I downloaded mono-2.4.tar.bz2 and extracted it with `tar xjf`. The
host-mono part went fine, but when I tried to do the Scratchbox part, I
had no arm-mono directory. When I tried to 
 ./configure --disable-mcs-build
 make 
 make install DESTDIR=`pwd`/tmptree
in the mono-2.4 directory, `make` gave me a lot of warnings, and finally
a series of undefined reference to `GC_local_malloc' errors,
culminating in 

collect2: ld returned 1 exit status

make[3]: *** [pedump] Error 1

make[3]: Leaving directory
`/home/jon/src/dev/alp/cross/mono-2.4/mono/metadata'

make[2]: *** [all-recursive] Error 1

make[2]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4/mono'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4'

make: *** [all] Error 2

Are there more up-to-date build instructions somewhere? Is ARM only
supported for 1.x? Or am I just too stupid to get Mono running on our
platform?


___
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] Mono 2.4 for ARM

2009-06-30 Thread Zoltan Varga

Hi,

Use:
./configure ...  CFLAGS=-DARM_FPU_NONE

On Wed, Jul 1, 2009 at 12:39 AM, Jon Shemitz jon.shem...@access-company.com
 wrote:

  Many thanks. --with-tls=pthread got me past my first hurdle.



 Alas, now I get



 mini-arm.h:28:2: error: #error At least one of ARM_FPU_NONE or ARM_FPU_FPA
 or ARM_FPU_VFP must be defined.



 and I can’t seem to get past that. I’ve tried



 ./configure --disable-mcs-build --with-tls=pthread ARM_FPU_NONE=1



 and



 make ARM_FPU_NONE=1



 and



 ARM_FPU_NONE=1 make



 and



 export ARM_FPU_NONE=1

 make



 and I keep getting the same error. What do I have to do to enable software
 floating point (gnueabi)?


  --

 *From:* Zoltan Varga [mailto:var...@gmail.com]
 *Sent:* Monday, June 29, 2009 6:36 PM
 *To:* Jon Shemitz
 *Cc:* mono-devel-list@lists.ximian.com
 *Subject:* Re: [Mono-dev] Mono 2.4 for ARM



 Hi,

   Try mono 2.4.2, or pass --with-tls=pthread to configure.

  Zoltan

 On Tue, Jun 30, 2009 at 1:59 AM, Jon Shemitz 
 jon.shem...@access-company.com wrote:

 I’m trying to build Mono 2.4 for an ARM device, following the instructions
 at http://mono-project.com/Mono:ARM and using an existing Scratchbox
 configuration.

 I downloaded mono-2.4.tar.bz2 and extracted it with `tar xjf`. The
 host-mono part went fine, but when I tried to do the Scratchbox part, I had
 no “arm-mono” directory. When I tried to

  ./configure --disable-mcs-build

  make

  make install DESTDIR=`pwd`/tmptree

 in the mono-2.4 directory, `make` gave me a lot of warnings, and finally a
 series of “undefined reference to `GC_local_malloc'” errors, culminating in

 collect2: ld returned 1 exit status

 make[3]: *** [pedump] Error 1

 make[3]: Leaving directory
 `/home/jon/src/dev/alp/cross/mono-2.4/mono/metadata'

 make[2]: *** [all-recursive] Error 1

 make[2]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4/mono'

 make[1]: *** [all-recursive] Error 1

 make[1]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4'

 make: *** [all] Error 2

 Are there more up-to-date build instructions somewhere? Is ARM only
 supported for 1.x? Or am I just too stupid to get Mono running on our
 platform?


 ___
 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] Mono 2.4 for ARM

2009-06-30 Thread Jon Shemitz

Excellent - thanks!

 

Now I get as far as 

 

MCS [net_2_0] convert.exe

make[2]: *** [convert.exe] Error 1

And I suspect that that is going to have to be between me and our
Scratchbox maintainer: I have gmcs outside of Scratchbox but not inside
it.

 

(I also suspect that I've been a bit spoiled by (once upon a time)
Delphi and Visual Studio, and (now) by having a build engineer who
maintains our Jamrules - this ./configure  make stuff is not anything
I'm used to.)

 



From: Zoltan Varga [mailto:var...@gmail.com] 
Sent: Tuesday, June 30, 2009 4:19 PM
To: Jon Shemitz
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Mono 2.4 for ARM

 

Hi,

Use:
./configure ...  CFLAGS=-DARM_FPU_NONE 

On Wed, Jul 1, 2009 at 12:39 AM, Jon Shemitz
jon.shem...@access-company.com wrote:

Many thanks. --with-tls=pthread got me past my first hurdle.

 

Alas, now I get 

 

mini-arm.h:28:2: error: #error At least one of ARM_FPU_NONE or
ARM_FPU_FPA or ARM_FPU_VFP must be defined.

 

and I can't seem to get past that. I've tried 

 

./configure --disable-mcs-build --with-tls=pthread ARM_FPU_NONE=1

 

and

 

make ARM_FPU_NONE=1

 

and

 

ARM_FPU_NONE=1 make 

 

and

 

export ARM_FPU_NONE=1

make

 

and I keep getting the same error. What do I have to do to enable
software floating point (gnueabi)?

 



From: Zoltan Varga [mailto:var...@gmail.com] 
Sent: Monday, June 29, 2009 6:36 PM
To: Jon Shemitz
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Mono 2.4 for ARM

 

Hi,

  Try mono 2.4.2, or pass --with-tls=pthread to configure.

 Zoltan

On Tue, Jun 30, 2009 at 1:59 AM, Jon Shemitz
jon.shem...@access-company.com wrote:

I'm trying to build Mono 2.4 for an ARM device, following the
instructions at http://mono-project.com/Mono:ARM and using an existing
Scratchbox configuration. 

I downloaded mono-2.4.tar.bz2 and extracted it with `tar xjf`. The
host-mono part went fine, but when I tried to do the Scratchbox part, I
had no arm-mono directory. When I tried to 

 ./configure --disable-mcs-build
 make 
 make install DESTDIR=`pwd`/tmptree

in the mono-2.4 directory, `make` gave me a lot of warnings, and finally
a series of undefined reference to `GC_local_malloc' errors,
culminating in 

collect2: ld returned 1 exit status

make[3]: *** [pedump] Error 1

make[3]: Leaving directory
`/home/jon/src/dev/alp/cross/mono-2.4/mono/metadata'

make[2]: *** [all-recursive] Error 1

make[2]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4/mono'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4'

make: *** [all] Error 2

Are there more up-to-date build instructions somewhere? Is ARM only
supported for 1.x? Or am I just too stupid to get Mono running on our
platform?


___
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] Array and IEnumerable

2009-06-30 Thread Yopmaster


Hi,

I think your issue is due to another huge difference between Mono and .NET
which leads to this kind of error. Here is an example:

Let us consider Human and Child so that Child is derived from Human:

  class Child : Human {}

If now you create the List of type

  ListChild children;

In .NET, children will also implement the type ListHuman:

  children is ListChild
   true
  children is ListHuman
   true

But in Mono it will not be the case:

  children is ListChild
   true
  children is ListHuman
   false

The only way to fix it would be to use some #if MONO / #else /
#endif...

In your case
  Human would be System.Array
  Child would be System.String[]
  List would be System.Array.InternalEnumerator

Does it answer to you question ?

If somebody from the mono programming could read this post and fix the
issue... (and by the way thank you for the great pieace of software that
Mono is)



I'm running Mono 2.4 on Windows and am getting a similar error - is there
any solution to this bug ?
System.Array.InternalEnumeratorSystem.String[] doesn't imple
ment interface System.Collections.Generic.IEnumeratorSystem.Array
**
ERROR:mini-trampolines.c:67:mono_convert_imt_slot_to_vtable_slot: code
should no
t be reached

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.


cheers,

   Elise




-- 
View this message in context: 
http://www.nabble.com/Array-and-IEnumerable-tp18146456p24283208.html
Sent from the Mono - Dev mailing list archive at Nabble.com.

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

Re: [Mono-dev] Array and IEnumerable

2009-06-30 Thread Michael Hutchinson

On Tue, Jun 30, 2009 at 10:30 PM, Yopmastertrouve.anto...@mac.com wrote:
 I think your issue is due to another huge difference between Mono and .NET
 which leads to this kind of error. Here is an example:

 Let us consider Human and Child so that Child is derived from Human:

  class Child : Human {}

 If now you create the List of type

  ListChild children;

 In .NET, children will also implement the type ListHuman:

  children is ListChild
   true
  children is ListHuman
   true

This is incorrect. ListSubclass cannot be cast to ListSuperclass on .NET.

Some examples like this can be solved by generic
covariance/contravariance in .NET 4.0. See
http://themonkeysgrinder.blogspot.com/2009/02/c-4-is-now.html for some
explanations. However, since System.Generic.Collections.ListT both
accepts and returns objects of type T, I don't believe it could be
made variant.

-- 
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] Array and IEnumerable

2009-06-30 Thread Trouve Antoine


On 平成 21/07/01, at 13:55, Trouve Antoine wrote:

 On å¹³æ 21/07/01, at 13:26, Michael Hutchinson wrote:

 On Tue, Jun 30, 2009 at 10:30 PM, Yopmastertrouve.anto...@mac.com  
 wrote:
 I think your issue is due to another huge difference between Mono  
 and .NET
 which leads to this kind of error. Here is an example:

 Let us consider Human and Child so that Child is derived  
 from Human:

 class Child : Human {}

 If now you create the List of type

 ListChild children;

 In .NET, children will also implement the type ListHuman:

 children is ListChild
  true
 children is ListHuman
  true

 This is incorrect. ListSubclass cannot be cast to  
 ListSuperclass on .NET.

 Some examples like this can be solved by generic
 covariance/contravariance in .NET 4.0. See
 http://themonkeysgrinder.blogspot.com/2009/02/c-4-is-now.html for  
 some
 explanations. However, since System.Generic.Collections.ListT both
 accepts and returns objects of type T, I don't believe it could be
 made variant.

 -- 
 Michael Hutchinson
 http://mjhutchinson.com

 Ho, you're right. I think this behaviour has changed since .NET 2.0.
 I've just checked and one of my old project do not compile anymore.
 ... or I might have missed something.
I have missed something and written too fast: this projects works in  
the case I use my old interfaces (e.g. IList instead of List)
It the point explained in your link as variance right ? By the way I  
remember it was not supported by Mono 1.3 or something.
I tested and it works with gmcs 2.4 (and 1.9 since I've just tested).

 Thank you for your link about covariance/contravariance, seems  
 interesting...


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

Re: [Mono-dev] Array and IEnumerable

2009-06-30 Thread Trouve Antoine

On 平成 21/07/01, at 13:26, Michael Hutchinson wrote:

 On Tue, Jun 30, 2009 at 10:30 PM, Yopmastertrouve.anto...@mac.com  
 wrote:
 I think your issue is due to another huge difference between Mono  
 and .NET
 which leads to this kind of error. Here is an example:

 Let us consider Human and Child so that Child is derived from  
 Human:

  class Child : Human {}

 If now you create the List of type

  ListChild children;

 In .NET, children will also implement the type ListHuman:

  children is ListChild
   true
  children is ListHuman
   true

 This is incorrect. ListSubclass cannot be cast to ListSuperclass  
 on .NET.

 Some examples like this can be solved by generic
 covariance/contravariance in .NET 4.0. See
 http://themonkeysgrinder.blogspot.com/2009/02/c-4-is-now.html for some
 explanations. However, since System.Generic.Collections.ListT both
 accepts and returns objects of type T, I don't believe it could be
 made variant.

 -- 
 Michael Hutchinson
 http://mjhutchinson.com

Ho, you're right. I think this behaviour has changed since .NET 2.0.
I've just checked and one of my old project do not compile anymore.
... or I might have missed something.

Thank you for your link about covariance/contravariance, seems  
interesting...

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

Re: [Mono-dev] [PATCH] Handle more gracefully invalid generic instantiations

Re: [Mono-dev] [PATCH] Handle more gracefully invalid generic instantiations

Re: [Mono-dev] [PATCH] CultureInfo_construct datetime_format and number_format fix for Windows.

Re: [Mono-dev] [PATCH] Simple implementation of network interface properties for Mac OS X

Re: [Mono-dev] [PATCH] Simple implementation of network interface properties for Mac OS X

Re: [Mono-dev] Mono 2.4 for ARM

Re: [Mono-dev] Mono 2.4 for ARM

Re: [Mono-dev] Mono 2.4 for ARM

Re: [Mono-dev] Mono 2.4 for ARM

Re: [Mono-dev] Mono 2.4 for ARM

Re: [Mono-dev] Array and IEnumerable

Re: [Mono-dev] Array and IEnumerable

Re: [Mono-dev] Array and IEnumerable

Re: [Mono-dev] Array and IEnumerable

14 matches

Site Navigation

Mail list logo

Footer information