From ympostor at clix.pt  Thu Jun  1 03:13:39 2006
From: ympostor at clix.pt (Ympostor)
Date: Thu, 01 Jun 2006 09:13:39 +0200
Subject: [Mono-dev] Re: Ambiguous matching in method resolution
In-Reply-To: <0a7c01c684fa$fb557510$c900a8c0@beardtongue>
References: <447DBEBE.5030505@fluggo.com><0a3d01c684dc$21e2c8a0$c900a8c0@beardtongue><dd99b8c80605311149h54144a88p98aa0108aa3c7d0@mail.gmail.com><0a4c01c684f4$93b99ea0$c900a8c0@beardtongue>	<0a7001c684f5$b1aa74b0$c900a8c0@beardtongue>
	<0a7c01c684fa$fb557510$c900a8c0@beardtongue>
Message-ID: <447E93A3.5040807@clix.pt>

pablosantosluac at terra.es escribi?:
> And more info yet.
> 
> The methods that seem to have trouble are the following:
> 
> - The server is "publishing" several interfaces under different "service 
> names" by remoting.
> 
> - There are methods with the same name and different signatures on 
> different interfaces.
> 
> - These methods are the ones causing trouble (not even overloaded 
> methods on the same interface, but methods with the same name on 
> different ones)

Just wondering... I have also experimented this exception when using 
Remoting and methods with the same name (overloaded). Have you tested 
the scenario Windows+MS.NET vs Windows+MS.NET? If yes and it works, the 
objective is to find a small testcase where the behaviour differs from 
one runtime to another.

Regards.

-- 



From robertj at gmx.net  Thu Jun  1 03:33:30 2006
From: robertj at gmx.net (Robert Jordan)
Date: Thu, 01 Jun 2006 09:33:30 +0200
Subject: [Mono-dev] Re: Ambiguous matching in method resolution
In-Reply-To: <447E93A3.5040807@clix.pt>
References: <447DBEBE.5030505@fluggo.com><0a3d01c684dc$21e2c8a0$c900a8c0@beardtongue><dd99b8c80605311149h54144a88p98aa0108aa3c7d0@mail.gmail.com><0a4c01c684f4$93b99ea0$c900a8c0@beardtongue>	<0a7001c684f5$b1aa74b0$c900a8c0@beardtongue>	<0a7c01c684fa$fb557510$c900a8c0@beardtongue>
	<447E93A3.5040807@clix.pt>
Message-ID: <e5m58a$n2k$1@sea.gmane.org>

Ympostor wrote:
> pablosantosluac at terra.es escribi?:
>> And more info yet.
>>
>> The methods that seem to have trouble are the following:
>>
>> - The server is "publishing" several interfaces under different 
>> "service names" by remoting.
>>
>> - There are methods with the same name and different signatures on 
>> different interfaces.
>>
>> - These methods are the ones causing trouble (not even overloaded 
>> methods on the same interface, but methods with the same name on 
>> different ones)
> 
> Just wondering... I have also experimented this exception when using 
> Remoting and methods with the same name (overloaded). Have you tested 
> the scenario Windows+MS.NET vs Windows+MS.NET? If yes and it works, the 
> objective is to find a small testcase where the behaviour differs from 
> one runtime to another.

It looks like this bug:

http://bugzilla.ximian.com/show_bug.cgi?id=77191

Robert



From pablosantosluac at terra.es  Thu Jun  1 04:33:19 2006
From: pablosantosluac at terra.es (pablosantosluac at terra.es)
Date: Thu, 1 Jun 2006 10:33:19 +0200
Subject: [Mono-dev] Re: Ambiguous matching in method resolution
References: <447DBEBE.5030505@fluggo.com><0a3d01c684dc$21e2c8a0$c900a8c0@beardtongue><dd99b8c80605311149h54144a88p98aa0108aa3c7d0@mail.gmail.com><0a4c01c684f4$93b99ea0$c900a8c0@beardtongue>	<0a7001c684f5$b1aa74b0$c900a8c0@beardtongue>	<0a7c01c684fa$fb557510$c900a8c0@beardtongue><447E93A3.5040807@clix.pt>
	<e5m58a$n2k$1@sea.gmane.org>
Message-ID: <0a8f01c68556$09f8f4b0$c900a8c0@beardtongue>

Well, the funny thing is that the problems I detected are between methods 
in... different interfaces!!


----- Original Message ----- 
From: "Robert Jordan" <robertj at gmx.net>
To: <mono-devel-list at lists.ximian.com>
Sent: Thursday, June 01, 2006 9:33 AM
Subject: [Mono-dev] Re: Ambiguous matching in method resolution


> Ympostor wrote:
>> pablosantosluac at terra.es escribi?:
>>> And more info yet.
>>>
>>> The methods that seem to have trouble are the following:
>>>
>>> - The server is "publishing" several interfaces under different "service 
>>> names" by remoting.
>>>
>>> - There are methods with the same name and different signatures on 
>>> different interfaces.
>>>
>>> - These methods are the ones causing trouble (not even overloaded 
>>> methods on the same interface, but methods with the same name on 
>>> different ones)
>>
>> Just wondering... I have also experimented this exception when using 
>> Remoting and methods with the same name (overloaded). Have you tested the 
>> scenario Windows+MS.NET vs Windows+MS.NET? If yes and it works, the 
>> objective is to find a small testcase where the behaviour differs from 
>> one runtime to another.
>
> It looks like this bug:
>
> http://bugzilla.ximian.com/show_bug.cgi?id=77191
>
> Robert
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list 



From eyala at mainsoft.com  Thu Jun  1 05:37:06 2006
From: eyala at mainsoft.com (Eyal Alaluf)
Date: Thu, 1 Jun 2006 12:37:06 +0300 (IDT)
Subject: [Mono-dev] Re: Ambiguous matching in method resolution
In-Reply-To: <0a8f01c68556$09f8f4b0$c900a8c0@beardtongue>
References: <447DBEBE.5030505@fluggo.com><0a3d01c684dc$21e2c8a0$c900a8c0@beardtongue><dd99b8c80605311149h54144a88p98aa0108aa3c7d0@mail.gmail.com><0a4c01c684f4$93b99ea0$c900a8c0@beardtongue>
	<0a7001c684f5$b1aa74b0$c900a8c0@beardtongue>
	<0a7c01c684fa$fb557510$c900a8c0@beardtongue><447E93A3.5040807@clix.pt><e5m58a$n2k$1@sea.gmane.org>
	<0a8f01c68556$09f8f4b0$c900a8c0@beardtongue>
Message-ID: <Pine.GSO.4.60.0606011236010.13367@yen>

Hi.

Are the interfaces implemented by the same class? This could explain quite a bit, actually.

Eyal.

On Thu, 1 Jun 2006 pablosantosluac at terra.es wrote:

> Date: Thu, 1 Jun 2006 10:33:19 +0200
> From: pablosantosluac at terra.es
> To: mono-devel-list at lists.ximian.com, Robert Jordan <robertj at gmx.net>
> Subject: Re: [Mono-dev] Re: Ambiguous matching in method resolution
> 
> Well, the funny thing is that the problems I detected are between methods 
> in... different interfaces!!
>
>
> ----- Original Message ----- From: "Robert Jordan" <robertj at gmx.net>
> To: <mono-devel-list at lists.ximian.com>
> Sent: Thursday, June 01, 2006 9:33 AM
> Subject: [Mono-dev] Re: Ambiguous matching in method resolution
>
>
>> Ympostor wrote:
>>> pablosantosluac at terra.es escribi?:
>>>> And more info yet.
>>>> 
>>>> The methods that seem to have trouble are the following:
>>>> 
>>>> - The server is "publishing" several interfaces under different 
>>>> "service names" by remoting.
>>>> 
>>>> - There are methods with the same name and different signatures on 
>>>> different interfaces.
>>>> 
>>>> - These methods are the ones causing trouble (not even overloaded 
>>>> methods on the same interface, but methods with the same name on 
>>>> different ones)
>>> 
>>> Just wondering... I have also experimented this exception when using 
>>> Remoting and methods with the same name (overloaded). Have you tested 
>>> the scenario Windows+MS.NET vs Windows+MS.NET? If yes and it works, the 
>>> objective is to find a small testcase where the behaviour differs from 
>>> one runtime to another.
>> 
>> It looks like this bug:
>> 
>> http://bugzilla.ximian.com/show_bug.cgi?id=77191
>> 
>> Robert
>> 
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list 
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>

From pablosantosluac at terra.es  Thu Jun  1 05:45:38 2006
From: pablosantosluac at terra.es (pablosantosluac at terra.es)
Date: Thu, 1 Jun 2006 11:45:38 +0200
Subject: [Mono-dev] Re: Ambiguous matching in method resolution
References: <447DBEBE.5030505@fluggo.com><0a3d01c684dc$21e2c8a0$c900a8c0@beardtongue><dd99b8c80605311149h54144a88p98aa0108aa3c7d0@mail.gmail.com><0a4c01c684f4$93b99ea0$c900a8c0@beardtongue>
	<0a7001c684f5$b1aa74b0$c900a8c0@beardtongue>
	<0a7c01c684fa$fb557510$c900a8c0@beardtongue><447E93A3.5040807@clix.pt><e5m58a$n2k$1@sea.gmane.org>
	<0a8f01c68556$09f8f4b0$c900a8c0@beardtongue>
	<Pine.GSO.4.60.0606011236010.13367@yen>
Message-ID: <0ee401c68560$239d64f0$c900a8c0@beardtongue>

Hi,

No, every interface is implemented by a different class.

Do you think is better to rename all the methods or wait for a solution?

pablo

----- Original Message ----- 
From: "Eyal Alaluf" <eyala at mainsoft.com>
To: <pablosantosluac at terra.es>
Cc: <mono-devel-list at lists.ximian.com>; "Robert Jordan" <robertj at gmx.net>
Sent: Thursday, June 01, 2006 11:37 AM
Subject: Re: [Mono-dev] Re: Ambiguous matching in method resolution


> Hi.
>
> Are the interfaces implemented by the same class? This could explain quite 
> a bit, actually.
>
> Eyal.
>
> On Thu, 1 Jun 2006 pablosantosluac at terra.es wrote:
>
>> Date: Thu, 1 Jun 2006 10:33:19 +0200
>> From: pablosantosluac at terra.es
>> To: mono-devel-list at lists.ximian.com, Robert Jordan <robertj at gmx.net>
>> Subject: Re: [Mono-dev] Re: Ambiguous matching in method resolution
>>
>> Well, the funny thing is that the problems I detected are between methods
>> in... different interfaces!!
>>
>>
>> ----- Original Message ----- From: "Robert Jordan" <robertj at gmx.net>
>> To: <mono-devel-list at lists.ximian.com>
>> Sent: Thursday, June 01, 2006 9:33 AM
>> Subject: [Mono-dev] Re: Ambiguous matching in method resolution
>>
>>
>>> Ympostor wrote:
>>>> pablosantosluac at terra.es escribi?:
>>>>> And more info yet.
>>>>>
>>>>> The methods that seem to have trouble are the following:
>>>>>
>>>>> - The server is "publishing" several interfaces under different
>>>>> "service names" by remoting.
>>>>>
>>>>> - There are methods with the same name and different signatures on
>>>>> different interfaces.
>>>>>
>>>>> - These methods are the ones causing trouble (not even overloaded
>>>>> methods on the same interface, but methods with the same name on
>>>>> different ones)
>>>>
>>>> Just wondering... I have also experimented this exception when using
>>>> Remoting and methods with the same name (overloaded). Have you tested
>>>> the scenario Windows+MS.NET vs Windows+MS.NET? If yes and it works, the
>>>> objective is to find a small testcase where the behaviour differs from
>>>> one runtime to another.
>>>
>>> It looks like this bug:
>>>
>>> http://bugzilla.ximian.com/show_bug.cgi?id=77191
>>>
>>> Robert
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> 



From eyala at mainsoft.com  Thu Jun  1 05:55:16 2006
From: eyala at mainsoft.com (Eyal Alaluf)
Date: Thu, 1 Jun 2006 12:55:16 +0300 (IDT)
Subject: [Mono-dev] Re: Ambiguous matching in method resolution
In-Reply-To: <0ee401c68560$239d64f0$c900a8c0@beardtongue>
References: <447DBEBE.5030505@fluggo.com><0a3d01c684dc$21e2c8a0$c900a8c0@beardtongue><dd99b8c80605311149h54144a88p98aa0108aa3c7d0@mail.gmail.com><0a4c01c684f4$93b99ea0$c900a8c0@beardtongue>
	<0a7001c684f5$b1aa74b0$c900a8c0@beardtongue>
	<0a7c01c684fa$fb557510$c900a8c0@beardtongue><447E93A3.5040807@clix.pt><e5m58a$n2k$1@sea.gmane.org>
	<0a8f01c68556$09f8f4b0$c900a8c0@beardtongue>
	<Pine.GSO.4.60.0606011236010.13367@yen>
	<0ee401c68560$239d64f0$c900a8c0@beardtongue>
Message-ID: <Pine.GSO.4.60.0606011253330.13367@yen>

>From my experience it's better to reduce the application to a small sample. During this effort you may stumble upon extra factors that are part of the bug that would be easier to workaround and important for getting the bug fixed.

Eyal.

On Thu, 1 Jun 2006 pablosantosluac at terra.es wrote:

> Date: Thu, 1 Jun 2006 11:45:38 +0200
> From: pablosantosluac at terra.es
> To: Eyal Alaluf <eyala at mainsoft.com>
> Cc: mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-dev] Re: Ambiguous matching in method resolution
> 
> Hi,
>
> No, every interface is implemented by a different class.
>
> Do you think is better to rename all the methods or wait for a solution?
>
> pablo
>
> ----- Original Message ----- From: "Eyal Alaluf" <eyala at mainsoft.com>
> To: <pablosantosluac at terra.es>
> Cc: <mono-devel-list at lists.ximian.com>; "Robert Jordan" <robertj at gmx.net>
> Sent: Thursday, June 01, 2006 11:37 AM
> Subject: Re: [Mono-dev] Re: Ambiguous matching in method resolution
>
>
>> Hi.
>> 
>> Are the interfaces implemented by the same class? This could explain quite 
>> a bit, actually.
>> 
>> Eyal.
>> 
>> On Thu, 1 Jun 2006 pablosantosluac at terra.es wrote:
>> 
>>> Date: Thu, 1 Jun 2006 10:33:19 +0200
>>> From: pablosantosluac at terra.es
>>> To: mono-devel-list at lists.ximian.com, Robert Jordan <robertj at gmx.net>
>>> Subject: Re: [Mono-dev] Re: Ambiguous matching in method resolution
>>> 
>>> Well, the funny thing is that the problems I detected are between 
>>> methods
>>> in... different interfaces!!
>>> 
>>> 
>>> ----- Original Message ----- From: "Robert Jordan" <robertj at gmx.net>
>>> To: <mono-devel-list at lists.ximian.com>
>>> Sent: Thursday, June 01, 2006 9:33 AM
>>> Subject: [Mono-dev] Re: Ambiguous matching in method resolution
>>> 
>>> 
>>>> Ympostor wrote:
>>>>> pablosantosluac at terra.es escribi?:
>>>>>> And more info yet.
>>>>>> 
>>>>>> The methods that seem to have trouble are the following:
>>>>>> 
>>>>>> - The server is "publishing" several interfaces under different
>>>>>> "service names" by remoting.
>>>>>> 
>>>>>> - There are methods with the same name and different signatures on
>>>>>> different interfaces.
>>>>>> 
>>>>>> - These methods are the ones causing trouble (not even overloaded
>>>>>> methods on the same interface, but methods with the same name on
>>>>>> different ones)
>>>>> 
>>>>> Just wondering... I have also experimented this exception when using
>>>>> Remoting and methods with the same name (overloaded). Have you 
>>>>> tested
>>>>> the scenario Windows+MS.NET vs Windows+MS.NET? If yes and it works, 
>>>>> the
>>>>> objective is to find a small testcase where the behaviour differs 
>>>>> from
>>>>> one runtime to another.
>>>> 
>>>> It looks like this bug:
>>>> 
>>>> http://bugzilla.ximian.com/show_bug.cgi?id=77191
>>>> 
>>>> Robert
>>>> 
>>>> _______________________________________________
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list at lists.ximian.com
>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> 
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> 
>
>

From robertj at gmx.net  Thu Jun  1 05:59:58 2006
From: robertj at gmx.net (Robert Jordan)
Date: Thu, 01 Jun 2006 11:59:58 +0200
Subject: [Mono-dev] Re: Ambiguous matching in method resolution
In-Reply-To: <0ee401c68560$239d64f0$c900a8c0@beardtongue>
References: <447DBEBE.5030505@fluggo.com><0a3d01c684dc$21e2c8a0$c900a8c0@beardtongue><dd99b8c80605311149h54144a88p98aa0108aa3c7d0@mail.gmail.com><0a4c01c684f4$93b99ea0$c900a8c0@beardtongue>	<0a7001c684f5$b1aa74b0$c900a8c0@beardtongue>	<0a7c01c684fa$fb557510$c900a8c0@beardtongue><447E93A3.5040807@clix.pt><e5m58a$n2k$1@sea.gmane.org>	<0a8f01c68556$09f8f4b0$c900a8c0@beardtongue>	<Pine.GSO.4.60.0606011236010.13367@yen>
	<0ee401c68560$239d64f0$c900a8c0@beardtongue>
Message-ID: <e5mdqu$r5h$2@sea.gmane.org>

pablosantosluac at terra.es wrote:
> Hi,
> 
> No, every interface is implemented by a different class.
> 
> Do you think is better to rename all the methods or wait for a solution?

You may use the patch that is attached to this bug.

Robert


> 
> pablo
> 
> ----- Original Message ----- From: "Eyal Alaluf" <eyala at mainsoft.com>
> To: <pablosantosluac at terra.es>
> Cc: <mono-devel-list at lists.ximian.com>; "Robert Jordan" <robertj at gmx.net>
> Sent: Thursday, June 01, 2006 11:37 AM
> Subject: Re: [Mono-dev] Re: Ambiguous matching in method resolution
> 
> 
>> Hi.
>>
>> Are the interfaces implemented by the same class? This could explain 
>> quite a bit, actually.
>>
>> Eyal.
>>
>> On Thu, 1 Jun 2006 pablosantosluac at terra.es wrote:
>>
>>> Date: Thu, 1 Jun 2006 10:33:19 +0200
>>> From: pablosantosluac at terra.es
>>> To: mono-devel-list at lists.ximian.com, Robert Jordan <robertj at gmx.net>
>>> Subject: Re: [Mono-dev] Re: Ambiguous matching in method resolution
>>>
>>> Well, the funny thing is that the problems I detected are between 
>>> methods
>>> in... different interfaces!!
>>>
>>>
>>> ----- Original Message ----- From: "Robert Jordan" <robertj at gmx.net>
>>> To: <mono-devel-list at lists.ximian.com>
>>> Sent: Thursday, June 01, 2006 9:33 AM
>>> Subject: [Mono-dev] Re: Ambiguous matching in method resolution
>>>
>>>
>>>> Ympostor wrote:
>>>>> pablosantosluac at terra.es escribi?:
>>>>>> And more info yet.
>>>>>>
>>>>>> The methods that seem to have trouble are the following:
>>>>>>
>>>>>> - The server is "publishing" several interfaces under different
>>>>>> "service names" by remoting.
>>>>>>
>>>>>> - There are methods with the same name and different signatures on
>>>>>> different interfaces.
>>>>>>
>>>>>> - These methods are the ones causing trouble (not even overloaded
>>>>>> methods on the same interface, but methods with the same name on
>>>>>> different ones)
>>>>>
>>>>> Just wondering... I have also experimented this exception when using
>>>>> Remoting and methods with the same name (overloaded). Have you tested
>>>>> the scenario Windows+MS.NET vs Windows+MS.NET? If yes and it works, 
>>>>> the
>>>>> objective is to find a small testcase where the behaviour differs from
>>>>> one runtime to another.
>>>>
>>>> It looks like this bug:
>>>>
>>>> http://bugzilla.ximian.com/show_bug.cgi?id=77191
>>>>
>>>> Robert
>>>>
>>>> _______________________________________________
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list at lists.ximian.com
>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>



From gert.driesen at telenet.be  Thu Jun  1 10:09:05 2006
From: gert.driesen at telenet.be (Gert Driesen)
Date: Thu, 01 Jun 2006 16:09:05 +0200
Subject: [Mono-dev] [PATCH] Class status pages update
Message-ID: <1149170945.19218.11.camel@pc52212b.home.be>

Hi,

The attached patch adds class status pages for the following assemblies:

* System.Configuation (2.0)
* System.ServiceProcess (1.1 and 2.0)
* System.Transactions (2.0)

There are two parts to this update:

- A patch for the update-status script, index-1.1.src and index-2.0.src.

  This patch should be applied in trunk/release/buildbot/scripts

- A (gzipped) tar containing the masterinfos for 1.1 and 2.0

  The files in that archive should be integrated in these archives:

  http://mono.ximian.com/masterinfos/masterinfos-1.1.tar.gz
  http://mono.ximian.com/masterinfos/masterinfos-2.0.tar.gz

I can take care of committing the patch in trunk/release (after I've
gotton approval to do this ofcourse), but who can take care of updates
the masterinfos tars ?

Gert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: classstatus.patch
Type: text/x-patch
Size: 3773 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060601/c3d472b8/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: masterinfos.tar.gz
Type: application/x-compressed-tar
Size: 32559 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060601/c3d472b8/attachment-0001.bin 

From gonzalo at novell.com  Thu Jun  1 14:12:09 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Thu, 01 Jun 2006 14:12:09 -0400
Subject: [Mono-dev] [PATCH] Class status pages update
In-Reply-To: <1149170945.19218.11.camel@pc52212b.home.be>
References: <1149170945.19218.11.camel@pc52212b.home.be>
Message-ID: <1149185529.14539.4.camel@lalo.micasa>

On Thu, 2006-06-01 at 16:09 +0200, Gert Driesen wrote:
[...]
> I can take care of committing the patch in trunk/release (after I've
> gotton approval to do this ofcourse), but who can take care of updates
> the masterinfos tars ?

I'll take care of updating the tar.gz's at the server.

-Gonzalo




From gonzalo at novell.com  Thu Jun  1 14:17:39 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Thu, 01 Jun 2006 14:17:39 -0400
Subject: [Mono-dev] [PATCH] Make mod_mono restart mod-mono-server
In-Reply-To: <002901c683db$d3d47330$0100a8c0@kornelpal.hu>
References: <002901c683db$d3d47330$0100a8c0@kornelpal.hu>
Message-ID: <1149185859.14539.7.camel@lalo.micasa>

On Tue, 2006-05-30 at 13:25 +0200, Korn?l P?l wrote:
> Hi,
> 
> When mono crashes for example because of a missing assembly mod-mono-server 
> will not be restarted automatically that causes Service Unavailable error 
> pages.
> 
> The attached patch restarts mod-mono-server if the socket cannot be opened.
> 
> This solution may not be the best but I think there is a need for something 
> like this.

That feature was already in mod_mono quite some time ago (and also
mod-mono-server wasn't started until the first request was made) and was
removed because when using the worker MPM model, apache always
"segfaulted".

-Gonzalo




From gonzalo at novell.com  Thu Jun  1 14:36:24 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Thu, 01 Jun 2006 14:36:24 -0400
Subject: [Mono-dev] [patch] System.Web.HttpApplication.InitOnce
In-Reply-To: <DA63C6E8B207E748B20D46DFED7B772D03098A0B@dhost002-45.dex002.intermedia.net>
References: <DA63C6E8B207E748B20D46DFED7B772D03098A0B@dhost002-45.dex002.intermedia.net>
Message-ID: <1149186984.14539.9.camel@lalo.micasa>

On Wed, 2006-05-31 at 08:13 -0700, Andrew Skiba wrote:
[...]
> If no one objects, I will commit.

Don't commit. It's a hack that fixes the problem for you, but we don't
know why that happens.

-Gonzalo




From joe at otee.dk  Thu Jun  1 18:15:46 2006
From: joe at otee.dk (Joachim Ante)
Date: Fri, 02 Jun 2006 00:15:46 +0200
Subject: [Mono-dev] PPC build broken
Message-ID: <C0A533B2.2BF40%joe@otee.dk>

Hi,

Building on ppc seems to be broken.
I tried with the daily tarball package
http://mono.ximian.com/daily/mono-1.1.15.20060601.tar.gz

Is anyone else seeing this?

Joachim Ante

-----

exceptions-ppc.c:557: error: parse error before "else"
exceptions-ppc.c:567: warning: type defaults to `int' in declaration of
`trace'
exceptions-ppc.c:567: error: `fname' undeclared here (not in a function)
exceptions-ppc.c:567: warning: initialization from incompatible pointer type
exceptions-ppc.c:567: error: initializer element is not constant
exceptions-ppc.c:567: warning: data definition has no type or storage class
exceptions-ppc.c:568: warning: type defaults to `int' in declaration of
`g_free'
exceptions-ppc.c:568: warning: parameter names (without types) in function
declaration
exceptions-ppc.c:568: error: conflicting types for `g_free'
/Users/joe/unity/Tools/build_mono/dep_prefix/include/glib-2.0/glib/gmem.h:52
: error: previous declaration of `g_free'
exceptions-ppc.c:568: warning: data definition has no type or storage class
exceptions-ppc.c:569: error: parse error before '}' token
exceptions-ppc.c:582: error: parse error before '&' token
exceptions-ppc.c:583: error: parse error before '&' token
exceptions-ppc.c:584: warning: type defaults to `int' in declaration of
`lmf'
exceptions-ppc.c:584: error: invalid type argument of `->'
exceptions-ppc.c:584: warning: data definition has no type or storage class
exceptions-ppc.c:586: error: parse error before "return"
exceptions-ppc.c: In function `ves_icall_get_frame_info':
exceptions-ppc.c:690: error: `location' undeclared (first use in this
function)




From Dan at nadx.co.uk  Thu Jun  1 21:04:57 2006
From: Dan at nadx.co.uk (Dan Mullineux)
Date: Fri, 02 Jun 2006 02:04:57 +0100
Subject: [Mono-dev] SybaseClient TDS and Sybase 11 Language error
Message-ID: <447F8EB9.5010406@nadx.co.uk>

Whilst spiking a proof of concept of mono on Sybase 11 I couldnt connect 
to the server
 
I tracked it down to tds.language="us_english", this errors in the 
connection with:
 
Mono.Data.SybaseClient.SybaseException: Internal error occurred while 
converting characters.
 
cant work out why, because its the default language on the server.
 
Still by allowing tds.language=null before connecting everything is ok, 
have not checked this on newer versions of sybase.
 
so from revision 61396. in mono.myrealbox.com
 
Tds.cs - protected void SetLanguage (string language)
 
1524c1524
<                               language = "us_english";
---
 >                               language = null;

SybaseConnection.cs - private void SetProperties (NameValueCollection 
parameters)

478a479
 >                       parms.Language = null;

Dan Mull



From john.luke at gmail.com  Thu Jun  1 23:19:51 2006
From: john.luke at gmail.com (John Luke)
Date: Thu, 01 Jun 2006 23:19:51 -0400
Subject: [Mono-dev] patch for MWF and gtk colors
Message-ID: <1149218391.13708.4.camel@shark.cfl.rr.com>

Hello,

A small patch for MWF to read the gtk colors without the gtk dev
packages installed.

Of course, I am not sure if you intentionally disabled it or something.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dllimport.patch
Type: text/x-patch
Size: 1759 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060601/1b58ec13/attachment.bin 

From peter at novonyx.com  Thu Jun  1 23:36:33 2006
From: peter at novonyx.com (Peter Dennis Bartok)
Date: Thu, 1 Jun 2006 21:36:33 -0600
Subject: [Mono-dev] patch for MWF and gtk colors
Message-ID: <10da01c685f5$bf5e0710$0200a8c0@schnukipc>

Nothing intentionally disabled. Just ignorance when writing the original 
DllImports.

Thanks for the patch, looks good, please commit.

Cheers,
  Peter

-----Original Message-----
From: "John Luke" <john.luke at gmail.com>
To: <mono-devel-list at lists.ximian.com>
Date: Thursday, 01 June, 2006 21:24
Subject: [Mono-dev] patch for MWF and gtk colors


>Hello,
>
>A small patch for MWF to read the gtk colors without the gtk dev
>packages installed.
>
>Of course, I am not sure if you intentionally disabled it or something.
> 



From monodanmorg at yahoo.com  Fri Jun  2 14:20:23 2006
From: monodanmorg at yahoo.com (Daniel Morgan)
Date: Fri, 2 Jun 2006 11:20:23 -0700 (PDT)
Subject: [Mono-dev] SybaseClient TDS and Sybase 11 Language error
In-Reply-To: <447F8EB9.5010406@nadx.co.uk>
Message-ID: <20060602182023.56532.qmail@web30804.mail.mud.yahoo.com>

Is there a bug in Bugzilla for this already?  If not, can you add the bug to http://bugzilla.ximian.com/ to make sure the patch does not get lost?
 
Good to see that someone can use Sybase 11 databases with System.Data.SybaseClient.  I will need to update the mono' wiki about that.  
 
Do you use Sybase ASA too?  If yes, maybe you can debug why SQL Anywhere does not work with System.Data.SybaseClient.  
 
By the way, we use unified diffs.  I think this is turned on via -u when using diff.


----- Original Message ----
From: Dan Mullineux <Dan at nadx.co.uk>
To: mono-devel-list at lists.ximian.com
Sent: Thursday, June 1, 2006 9:04:57 PM
Subject: [Mono-dev] SybaseClient TDS and Sybase 11 Language error


Whilst spiking a proof of concept of mono on Sybase 11 I couldnt connect 
to the server

I tracked it down to tds.language="us_english", this errors in the 
connection with:

Mono.Data.SybaseClient.SybaseException: Internal error occurred while 
converting characters.

cant work out why, because its the default language on the server.

Still by allowing tds.language=null before connecting everything is ok, 
have not checked this on newer versions of sybase.

so from revision 61396. in mono.myrealbox.com

Tds.cs - protected void SetLanguage (string language)

1524c1524
<                               language = "us_english";
---
>                               language = null;

SybaseConnection.cs - private void SetProperties (NameValueCollection 
parameters)

478a479
>                       parms.Language = null;

Dan Mull

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060602/363956af/attachment.html 

From Jonathan.Chambers at ansys.com  Fri Jun  2 16:08:42 2006
From: Jonathan.Chambers at ansys.com (Jonathan S. Chambers)
Date: Fri, 2 Jun 2006 16:08:42 -0400
Subject: [Mono-dev] Variant patch
Message-ID: <BDBFCADE470D2B4A841D51412D2D915D038CCF05@canonsburgexch2.win.ansys.com>

Here is a patch to add Variant support to mono for basic types. This
works for pinvoke and implements two Variant methods in the Marshal
class. I didn't #ifdef anything for windows since I'm not using any
windows specific calls; let me know if I should. Please review.

 

Thanks,

 

Jonathan S. Chambers

Software Development Engineer

ANSYS, Inc.

Phone: 724.514.3682

Fax: 724.514.3114

E-mail: jonathan.chambers at ansys.com <mailto:jonathan.chambers at ansys.com>


 

___________________________________________________

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the
material from any computer.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060602/c2841d7f/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: variant_final.diff
Type: application/octet-stream
Size: 9802 bytes
Desc: variant_final.diff
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060602/c2841d7f/attachment.obj 

From vargaz at gmail.com  Fri Jun  2 20:12:30 2006
From: vargaz at gmail.com (Zoltan Varga)
Date: Sat, 3 Jun 2006 02:12:30 +0200
Subject: [Mono-dev] Variant patch
In-Reply-To: <BDBFCADE470D2B4A841D51412D2D915D038CCF05@canonsburgexch2.win.ansys.com>
References: <BDBFCADE470D2B4A841D51412D2D915D038CCF05@canonsburgexch2.win.ansys.com>
Message-ID: <295e750a0606021712y5bb2bf1dtc15f7969827d630c@mail.gmail.com>

                             Hey,

  The patch looks fine. Some tests would be useful, tough. Also, you
should increase
the corlib version number in System/Environment.cs and in
metadata/appdomain.c because
of the new Variant class.

               Zoltan

On 6/2/06, Jonathan S. Chambers <Jonathan.Chambers at ansys.com> wrote:
>
>
>
>
> Here is a patch to add Variant support to mono for basic types. This works
> for pinvoke and implements two Variant methods in the Marshal class. I
> didn't #ifdef anything for windows since I'm not using any windows specific
> calls; let me know if I should. Please review.
>
>
>
> Thanks,
>
>
>
> Jonathan S. Chambers
>
> Software Development Engineer
>
> ANSYS, Inc.
>
> Phone: 724.514.3682
>
> Fax: 724.514.3114
>
> E-mail: jonathan.chambers at ansys.com
>
>
>
> ___________________________________________________
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete the material from any
> computer.
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>


From duncan at novell.com  Sat Jun  3 18:04:44 2006
From: duncan at novell.com (Duncan Mak)
Date: Sat, 03 Jun 2006 18:04:44 -0400
Subject: [Mono-dev] Patch for fixing binary search
Message-ID: <1149372284.16587.27.camel@diphthong.a-chinaman.com>

Hello,

As pointed out by this blog post by Joshua Bloch:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

The current by-the-book implementation of BinarySearch has an integer
overflow bug due to this:

	int mid = (low + high) / 2;

This bug manifests itself when (low + high) > Int32.MaxValue.

Here's a patch for fixing this in Array, Array<T> and ArrayList.

Duncan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-binary-search.patch
Type: text/x-patch
Size: 2272 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060603/67cf1df2/attachment.bin 

From navitux at gmail.com  Sat Jun  3 22:07:03 2006
From: navitux at gmail.com (=?iso-8859-1?q?Iv=E1n_Herrero?=)
Date: Sun, 4 Jun 2006 04:07:03 +0200
Subject: [Mono-dev] modified classes compile but don't find method on running
Message-ID: <200606040407.03920.navitux@gmail.com>

Hi. I've been hacking the sources to provide support to reference the element 
to sign in a xml doc with an xpath expression. For that, I've modified the 
Reference.cs and SignedXml.cs classes. When I recompile the code of mono and 
make install it, the new method doesn't appear in monodevelop. However, I've 
managed to compile it from the command line, but when I run the test code 
that use the new method, this is not found, and it crashes:

	navitux at darkness:~/Projects/firmado/firmado$ 			 
	mcs -r:System.Security -r:Mono.Security -r:System.Xml Main.cs
	Compilation succeeded - 6 warning(s)

	navitux at darkness:~/Projects/firmado/firmado$ ./Main.exe
	 ** (./Main.exe:25186): WARNING **: Missing member SetXPathReference in type 	
Reference, 
assembly /usr/lib/mono/gac/System.Security/1.0.5000.0__b03f5f7f11d50a3a/System.Security.dll

	Unhandled Exception: System.MissingMethodException: Method not 	
found: 'System.Security.Cryptography.Xml.Reference.SetXPathReference'.
	in <0x00000> <unknown method>
	in <0x00039> firmado.MainClass:Main (System.String[] args)

I'm quite surprised with the error, searching the library in 
gac/System.Security/1.0.500..., which seems not to be in the standard library 
tree. Added to that, depending on the compiler used (mcs, gmcs), the library 
used is in 1.0.500000... or 2.0.0.0__b03f5f7f11d50a3a folder.

Could you put some light into this so I can test and improve these hacks?
Thanks,
Iv?n.


From usergroup at cornetdesign.com  Sun Jun  4 12:06:48 2006
From: usergroup at cornetdesign.com (Cory Foy)
Date: Sun, 04 Jun 2006 11:06:48 -0500
Subject: [Mono-dev] CurrentCulture Empty?
Message-ID: <44830518.8000802@cornetdesign.com>

Hi All,

We noticed that our tests in NUnit around CultureInfo were failing with 
an empty culture info. I was going to dig through the Mono source, but 
CultureInfo is apparantly not the most straightforward thing to pull.

Do I need to open a bug report on this?

Thanks!

Cory

-----

foyc at dilbert ~/workspace/monobugs $ mono -V
Mono JIT compiler version 1.1.15, (C) 2002-2005 Novell, Inc and 
Contributors. www.mono-project.com
         TLS:           normal
         GC:            Included Boehm (with typed GC)
         SIGSEGV:       normal
         Disabled:      none

foyc at dilbert ~/workspace/monobugs $ cat CultureBug.cs
using System;
using System.Globalization;

public class TestCultureInfo
{
         public static void Main(String[] args)
         {
                 Console.WriteLine("Current Culture: " + 
CultureInfo.CurrentCulture.ToString());
                 Console.WriteLine("Current UICulture: " + 
CultureInfo.CurrentUICulture.ToString());
         }
}

foyc at dilbert ~/workspace/monobugs $ mcs CultureBug.cs

foyc at dilbert ~/workspace/monobugs $ mono CultureBug.exe
Current Culture:
Current UICulture:


From russell at russellsprojects.com  Sun Jun  4 14:50:52 2006
From: russell at russellsprojects.com (Russell Morris)
Date: Sun, 04 Jun 2006 14:50:52 -0400
Subject: [Mono-dev] Cecil.FlowAnalysis and exception handler blocks
Message-ID: <44832B8C.3020503@russellsprojects.com>

Hi all,

I'd like to update the code in Cecil.FlowAnalysis.ControlFlow so that it 
can make sense of exception handling blocks.  Currently, the 
FlowGraphBuilder in here refuses to deal with functions that have 
exception handling blocks.

At first glance, I think that a new class would be introduced to 
represent the exception handling blocks themselves.  This new class 
would contain information about the type of exception handling block it 
represented (catch, fault, finally, or filter), and a pointer to one (or 
more for catch blocks) InstructionBlocks that served as the entry point 
to the handler(s).

Each InstructionBlock would also have a reference to a lookup table that 
could return a stack of exception handling block classes (mentioned 
above) for any given instruction in the function.  The stack would 
represent the exception handler blocks that could potentially be invoked 
if the given instruction threw an exception (a stack because exception 
handling blocks can be nested in one another).

I'm interested in knowing if anyone out there is currently working in 
this area of Cecil, and would have anything to add to this analysis.

Thanks,

Russ



From Yota_VGA at praisenet.darktech.org  Sun Jun  4 17:10:19 2006
From: Yota_VGA at praisenet.darktech.org (Fulvio Satta)
Date: Sun, 4 Jun 2006 23:10:19 +0200
Subject: [Mono-dev] C APIs for signatures
Message-ID: <200606042310.32989.Yota_VGA@praisenet.darktech.org>

Hi, this is my first post in this ml.
I want to know the APIs (for embedding mono) for discover the autenticode sign 
of a PE, if exists.
Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060604/8543fd51/attachment.bin 

From bmaurer at ximian.com  Sun Jun  4 17:41:46 2006
From: bmaurer at ximian.com (Ben Maurer)
Date: Sun, 04 Jun 2006 14:41:46 -0700
Subject: [Mono-dev] Patch for fixing binary search
In-Reply-To: <1149372284.16587.27.camel@diphthong.a-chinaman.com>
References: <1149372284.16587.27.camel@diphthong.a-chinaman.com>
Message-ID: <1149457306.12700.16.camel@localhost>

Hey,

This also exists for qsort
        
        object objPivot = keys.GetValueImpl ((low + high) / 2);

-- Ben

On Sat, 2006-06-03 at 18:04 -0400, Duncan Mak wrote:
> Hello,
> 
> As pointed out by this blog post by Joshua Bloch:
> 
> http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
> 
> The current by-the-book implementation of BinarySearch has an integer
> overflow bug due to this:
> 
> 	int mid = (low + high) / 2;
> 
> This bug manifests itself when (low + high) > Int32.MaxValue.
> 
> Here's a patch for fixing this in Array, Array<T> and ArrayList.
> 
> Duncan.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From duncan at novell.com  Sun Jun  4 20:50:08 2006
From: duncan at novell.com (Duncan Mak)
Date: Sun, 04 Jun 2006 20:50:08 -0400
Subject: [Mono-dev] Patch for fixing binary search
In-Reply-To: <1149457306.12700.16.camel@localhost>
References: <1149372284.16587.27.camel@diphthong.a-chinaman.com>
	<1149457306.12700.16.camel@localhost>
Message-ID: <1149468608.16587.46.camel@diphthong.a-chinaman.com>

On Sun, 2006-06-04 at 14:41 -0700, Ben Maurer wrote:
> Hey,
> 
> This also exists for qsort
>         
>         object objPivot = keys.GetValueImpl ((low + high) / 2);

Good call.

Here's v2.

Duncan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-binary-search-v2.patch
Type: text/x-patch
Size: 3254 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060604/57d1080d/attachment.bin 

From atomb at soe.ucsc.edu  Sun Jun  4 23:28:17 2006
From: atomb at soe.ucsc.edu (Aaron Tomb)
Date: Sun, 4 Jun 2006 20:28:17 -0700
Subject: [Mono-dev] Cecil.FlowAnalysis and exception handler blocks
In-Reply-To: <44832B8C.3020503@russellsprojects.com>
References: <44832B8C.3020503@russellsprojects.com>
Message-ID: <20060605032816.GA15721@sundance.cse.ucsc.edu>

There's some code in the null dereference analysis portion of Gendarme
that deals with control flow graphs, with some minimal (and possibly
incorrect) support for exceptions. It might be worth looking at, however
incomplete it is.

Also, if Cecil.FlowAnalysis.ControlFlow gets to the point where it can
handle exceptions well, it might be worth updating the null dereference
code to use it, instead of the CFG code I wrote.

Aaron

On Sun, Jun 04, 2006 at 02:50:52PM -0400, Russell Morris wrote:
> Hi all,
> 
> I'd like to update the code in Cecil.FlowAnalysis.ControlFlow so that it 
> can make sense of exception handling blocks.  Currently, the 
> FlowGraphBuilder in here refuses to deal with functions that have 
> exception handling blocks.
> 
> At first glance, I think that a new class would be introduced to 
> represent the exception handling blocks themselves.  This new class 
> would contain information about the type of exception handling block it 
> represented (catch, fault, finally, or filter), and a pointer to one (or 
> more for catch blocks) InstructionBlocks that served as the entry point 
> to the handler(s).
> 
> Each InstructionBlock would also have a reference to a lookup table that 
> could return a stack of exception handling block classes (mentioned 
> above) for any given instruction in the function.  The stack would 
> represent the exception handler blocks that could potentially be invoked 
> if the given instruction threw an exception (a stack because exception 
> handling blocks can be nested in one another).
> 
> I'm interested in knowing if anyone out there is currently working in 
> this area of Cecil, and would have anything to add to this analysis.
> 
> Thanks,
> 
> Russ
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list


From miguel at novell.com  Mon Jun  5 00:42:12 2006
From: miguel at novell.com (Miguel de Icaza)
Date: Mon, 05 Jun 2006 00:42:12 -0400
Subject: [Mono-dev] Serialization strategies for compatibility.
Message-ID: <1149482532.12303.900.camel@linux.site>

Hello,

    Last week Gonzalo fixed some of the serialization for the "Color"
struct in Mono to enable serialization of certain objects for
Windows.Forms applications.   Some of the fixes are relatively
straightforward, these involved changing the internal representation to
match the MS implementation.

    But one change which was particularly annoying was one dealing with
the way that MS Color is serialized.  They have a concept of "Known
Colors", and if a flag in the serialization is set, the color is
initialized from a known color index.   

    The idea is fine, but mixed with serialization it means that we do
not get a chance to compute the color RGB values in advance, but have
instead to compute the values on demand, the first time the values are
accessed.   For the current code changes that we had to do, look for the
"R" property for example:

http://svn.myrealbox.com/viewcvs/trunk/mcs/class/System.Drawing/System.Drawing/Color.cs?rev=61426&view=auto

    Now, it is debatable whether optimizing Color is an issue at all,
but I ran into a new feature of the .NET Framework 2.0 that might help:
"Versioning Tolerance", the hacks are fairly simple and are described
here:

http://www.codeguru.com/csharp/.net/net_general/netframeworkclasses/article.php/c9297/

and here:

http://msdn2.microsoft.com/en-us/library/ms229752.aspx

    These particular hooks would allow us to implement a fast "Color",
for instance, we can use the [OnDeserialized] attribute and compute the
ARGB values as soon as the type has been de-serialized, avoiding
completely the ugly test that we currently have in place.

    Now, there are two problems:

	* It is only available in 2.0.

	* The new hooks do not cope well with differently-named fields.

    Since this stuff is genuinely useful, I was considering whether we
could make our 1.1 implementation support it, but to avoid exposing a
non-existent 1.1 type, we could do a name-based attribute lookup on the
methods and if we find that there is such an attribute, we could perform
the same tasks that 2.0 does.   This means that 1.1 assemblies could get
the 2.0 "hooks" by including their own copy of the attribute.   The only
issue here is whether this would not have a negative performance
impact.  

    The second issue is: how do we cope with deserialization in the
future without having to change our internals extensively?   And I think
that if we extend the serialization framework we can do this.

    We could introduce some *extra* attributes that are specific to
Mono, and that are applied to the type.  If such attribute is found, it
would instruct the deserializer to not perform the manual
deserialization/serialization, but instead use an ISerializable-like
approach on that given class, this would give us the control we need.

    Now in .NET 1.1 SP-N I noticed that they introduced some changes.
Some classes now implemented some new interfaces that were not present
in .NET 1.1.   My question is: what is the justification to add new
implemented interfaces to classes, and could we get away by just
sprinkling "ISerializable" on our classes, or would that be considered a
massive breach of API compatibility?    

Miguel.


From martin.goodrich at ntlworld.com  Sun Jun  4 05:02:00 2006
From: martin.goodrich at ntlworld.com (Martin Paul Goodrich)
Date: Sun, 04 Jun 2006 10:02:00 +0100
Subject: [Mono-dev] mono frustration
In-Reply-To: 1300.10.10.10.67.1145352292.squirrel@poshta
Message-ID: <1149411720.3419.13.camel@localhost.localdomain>

Hi Paul,

I've just been trying to install the monodevelop IDE and associated
utilities for FC5 as per your excellent instructions on the mono-develop
mailing list.

However, it seems that the links based upon
http://www.smmp.salford.ac.uk/packages have all been discontinued; have
they been located elsewhere?

I have to say that I'm a little disappointed that the FC5 release team
are taking so long to release the monodevelop package as an RPM for
install on FC5. I would have thought that with the current world focus
on C#/.NET it would assume a higher priority than it currently is.

Anyway, any help you could give would be gratefully acknowledged.

Best regards,
Martin Goodrich






From xiii29 at free.fr  Mon Jun  5 06:10:03 2006
From: xiii29 at free.fr (xiii29)
Date: Mon, 05 Jun 2006 12:10:03 +0200
Subject: [Mono-dev] NHibernate + DynamicProxies + Mono trouble
Message-ID: <448402FB.1080400@free.fr>

Hello !

I'm working with NHibernate for my application. I have some trouble but 
step by step I'm able to find solution (Thanks to google).

The last one was a problem of compatibility between Mono and 
DynamicProxies (from castle project). All info are here : 
http://support.castleproject.org/jira/browse/DYNPROXY-21.

Now : I've this exception which seems coming from the mscorlib on mono ?

** 
(/donnees/Documents/Projets/MonoDevelop/NHibernate_Exemple/SourceCode/OrderSystem/OrderSystem.UI/bin/Debug/OrderSystem.UI.exe:10433): 
WARNING **: Missing member Equals in type OpCode, assembly 
/donnees/Applications/Dev/Mono/mono-1.1.13.4/lib/mono/1.0/mscorlib.dll

Unhandled Exception: NHibernate.LazyInitializationException: Failed to 
lazily initialize a collection ---> NHibernate.HibernateException: 
Creating a proxy instance failed ---> System.MissingMethodException: 
Method not found: 'System.Reflection.Emit.OpCode.Equals'.
in <0x00000> <unknown method>

But when I look in the methods ... I find it ...

ANy idea ?

Thanks



From mono at evain.net  Mon Jun  5 06:20:38 2006
From: mono at evain.net (Jb Evain)
Date: Mon, 5 Jun 2006 12:20:38 +0200
Subject: [Mono-dev] Cecil.FlowAnalysis and exception handler blocks
In-Reply-To: <44832B8C.3020503@russellsprojects.com>
References: <44832B8C.3020503@russellsprojects.com>
Message-ID: <F3E68B9F-B9A0-4CD1-A744-8E9601C74AC9@evain.net>

Hey Russel,

On Jun 4, 2006, at 8:50 PM, Russell Morris wrote:
> I'm interested in knowing if anyone out there is currently working  
> in this area of Cecil, and would have anything to add to this  
> analysis.

I'm working on it.
It should land soon in SVN.

Jb
3


From jonpryor at vt.edu  Mon Jun  5 07:13:27 2006
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Mon, 05 Jun 2006 07:13:27 -0400
Subject: [Mono-dev] Serialization strategies for compatibility.
In-Reply-To: <1149482532.12303.900.camel@linux.site>
References: <1149482532.12303.900.camel@linux.site>
Message-ID: <1149506007.3847.9.camel@melchior.magi>

On Mon, 2006-06-05 at 00:42 -0400, Miguel de Icaza wrote:
>     Now in .NET 1.1 SP-N I noticed that they introduced some changes.
> Some classes now implemented some new interfaces that were not present
> in .NET 1.1.   My question is: what is the justification to add new
> implemented interfaces to classes,

No idea.

>  and could we get away by just
> sprinkling "ISerializable" on our classes, or would that be considered a
> massive breach of API compatibility?    

It's only a breach of API compatibility if people find out about it. :-)

That is, if people know the class implements a given interface, they may
rely on that fact, which would hinder portability to .NET.

Further, there are three ways people would find out what interfaces a
type implements:

  - Documentation
  - Reflection
  - Reading Mono's Sources

Since Documentation follows .NET's types, no one would determine the new
interfaces only by reading the documentation, which leaves Reflection &
Mono's sources.

Microsoft has frequently said to treat Reflection with a grain of salt
(newly added members may cause exceptions to be generated in the future
due to newly created ambiguities, etc.), so it could be ignored.

And anyone reading the sources gets whatever they deserve. :-)

So just sprinkling ISerializable everywhere may be acceptable, as long
as it's not documented.

Alternatively, if Reflection is an important scenario, we'd need a way
to "hide" the interface from being returned by Reflection, which could
be done via an internal attribute:

	[HideFromReflection (typeof(ISerializable))]
	class Color : ISerializable { /* ... */ }

though this path may lead to madness as well.

Another shot against caring about Reflection is that Reflection will
return internal interfaces & attributes, so your approach of defining
additional internal attributes would still result in them being returned
by Reflection, thus (in principal) breaking "absolute compatibility
with .NET" (as types would be presented which aren't under .NET).

End result: I'd suggest just sprinkling ISerializable where needed and
_not_ documenting it.  It's an implementation detail, and not
significantly worse than the alternatives.

 - Jon




From paul at all-the-johnsons.co.uk  Mon Jun  5 07:34:45 2006
From: paul at all-the-johnsons.co.uk (PFJ)
Date: Mon, 05 Jun 2006 12:34:45 +0100
Subject: [Mono-dev] mono frustration
In-Reply-To: <1149411720.3419.13.camel@localhost.localdomain>
References: <1149411720.3419.13.camel@localhost.localdomain>
Message-ID: <1149507285.1013.29.camel@mrwibble.mrwobble>

On Sun, 2006-06-04 at 10:02 +0100, Martin Paul Goodrich wrote:
> Hi Paul,
> 
> I've just been trying to install the monodevelop IDE and associated
> utilities for FC5 as per your excellent instructions on the mono-develop
> mailing list.
> 
> However, it seems that the links based upon
> http://www.smmp.salford.ac.uk/packages have all been discontinued; have
> they been located elsewhere?

Yes - I'm moving job, so have moved the packages. I will be putting up
fresh builds tonight via my home website - there are plenty of fixes,
including one which sorts out the chomping of the mime encodings!

http://www.all-the-johnsons.co.uk/mono/rpms.html (or it may be .shtml -
can't remember!)

The good news is that MD is almost in, ikvm is already in FE which means
just boo and gtksourceview-sharp need approval - progress is slow, but
it is moving.

TTFN

Paul
-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who



From robertj at gmx.net  Mon Jun  5 07:35:42 2006
From: robertj at gmx.net (Robert Jordan)
Date: Mon, 05 Jun 2006 13:35:42 +0200
Subject: [Mono-dev] Re: Serialization strategies for compatibility.
In-Reply-To: <1149482532.12303.900.camel@linux.site>
References: <1149482532.12303.900.camel@linux.site>
Message-ID: <e614uc$je0$1@sea.gmane.org>

Hi,

>     These particular hooks would allow us to implement a fast "Color",
> for instance, we can use the [OnDeserialized] attribute and compute the
> ARGB values as soon as the type has been de-serialized, avoiding
> completely the ugly test that we currently have in place.
> 
>     Now, there are two problems:
> 
> 	* It is only available in 2.0.

I've implemented 2.0 serialization a couple of days ago. It still
needs some unit tests and a complete interoperatibility test.
I'll finish them by the end of the week, if I'll not discover
that the reflective approach of calling the new hooks is
too slow ... (see below).

> 
> 	* The new hooks do not cope well with differently-named fields.

Indeed, it's a bit clumsy:

[NonSerialized] type monoFieldName;
                 type msnetFieldName;

[OnSerializing]
void Serialize (StreamingContext context)
{
     msnetFieldName = monoFieldName;
}

[OnDeserialized]
void Deserialize (StreamingContext context)
{
     monoFieldName = msnetFieldName;
}


>     Since this stuff is genuinely useful, I was considering whether we
> could make our 1.1 implementation support it, but to avoid exposing a
> non-existent 1.1 type, we could do a name-based attribute lookup on the
> methods and if we find that there is such an attribute, we could perform
> the same tasks that 2.0 does.   This means that 1.1 assemblies could get
> the 2.0 "hooks" by including their own copy of the attribute.   The only
> issue here is whether this would not have a negative performance
> impact.  

The additional performance loss can be neglected, because it's probably
bad enough already:

// 2.0
foreach (MethodInfo mi in type.GetMethods (...)) {
     if (params match StreamingContext)
         methodInfo.GetCustomAttributes (
             typeof (OnDeserializedAttribute))
         cache the MethodInfo
}

vs.

// 1.0
foreach (MethodInfo mi in type.GetMethods (...)) {
     if (params match StreamingContext)
         foreach (Attribute a in mi.GetCustomAttributes ()) {
             if (a.FullName.EndsWith (".OnDeserializedAttribute")) ...
                 cache the MethodInfo
}

which must be done only once per type.

I guess a code generator will be necessary to optimize this.


>     The second issue is: how do we cope with deserialization in the
> future without having to change our internals extensively?   And I think
> that if we extend the serialization framework we can do this.
> 
>     We could introduce some *extra* attributes that are specific to
> Mono, and that are applied to the type.  If such attribute is found, it
> would instruct the deserializer to not perform the manual
> deserialization/serialization, but instead use an ISerializable-like
> approach on that given class, this would give us the control we need.
> 
>     Now in .NET 1.1 SP-N I noticed that they introduced some changes.
> Some classes now implemented some new interfaces that were not present
> in .NET 1.1.   My question is: what is the justification to add new
> implemented interfaces to classes, and could we get away by just
> sprinkling "ISerializable" on our classes, or would that be considered a
> massive breach of API compatibility?    

I'd go for an extra attribute that could be attached on
the type (like [Serialized]), and that expects the same
semantics like ISerializable (method GetObjectData and
.ctor(SerializationInfo, StreamingContext)).


My concern with those solutions is: how do they fit
in the CAS? Are there some hidden security implications?

Robert



From mwelham at gmail.com  Mon Jun  5 07:36:46 2006
From: mwelham at gmail.com (Mike Welham)
Date: Mon, 5 Jun 2006 13:36:46 +0200
Subject: [Mono-dev] Serialization strategies for compatibility.
In-Reply-To: <1149506007.3847.9.camel@melchior.magi>
References: <1149482532.12303.900.camel@linux.site>
	<1149506007.3847.9.camel@melchior.magi>
Message-ID: <de64bb540606050436o7cf674e6q864f6a980d8e10b0@mail.gmail.com>

> >     Now in .NET 1.1 SP-N I noticed that they introduced some changes.
> > Some classes now implemented some new interfaces that were not present
> > in .NET 1.1.   My question is: what is the justification to add new
> > implemented interfaces to classes,
>
> No idea.
>

Big fixes is one possible reason. (IIRC System.Threading.WaitHandle
neglected to implement IDisposable initially. It does in 2.0 and now
maybe in 1.1 SP-N.)

> >  and could we get away by just
> > sprinkling "ISerializable" on our classes, or would that be considered a
> > massive breach of API compatibility?
>
> It's only a breach of API compatibility if people find out about it. :-)
>
> That is, if people know the class implements a given interface, they may
> rely on that fact, which would hinder portability to .NET.
>

...

>
> So just sprinkling ISerializable everywhere may be acceptable, as long
> as it's not documented.
>

In general I agree, but ISerializable is a bit of a special case due
to remoting. It is unlkiely but conceivable that somewhere in remoting
plumbing (in Mono or another tool) somebody might "if(x is
ISerializable)...".

It might be worth considering an IMonoSerializable interface?

Mike


From andrews at mainsoft.com  Mon Jun  5 08:13:24 2006
From: andrews at mainsoft.com (Andrew Skiba)
Date: Mon, 5 Jun 2006 05:13:24 -0700
Subject: [Mono-dev] [patch] System.Web.HttpApplication.InitOnce
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03098DC6@dhost002-45.dex002.intermedia.net>

> Don't commit. It's a hack that fixes the problem for you, but 
> we don't know why that happens.
> 

That happens because HttpContext.Current is set in
HttpRuntime.RealProcessRequest, and when HttpApplication.Start runs in a
different thread, HttpContext.Current is null. I explained it in more
details here: http://bugzilla.ximian.com/show_bug.cgi?id=78583 To
reproduce the bug cd to System.Web/Test/standalone/hosting/test1 and
make run-test.

Andrew.


From kornelpal at gmail.com  Mon Jun  5 08:27:51 2006
From: kornelpal at gmail.com (=?ISO-8859-1?B?S29ybulsIFDhbA==?=)
Date: Mon, 5 Jun 2006 14:27:51 +0200
Subject: [Mono-dev] Serialization strategies for compatibility.
References: <1149482532.12303.900.camel@linux.site><1149506007.3847.9.camel@melchior.magi>
	<de64bb540606050436o7cf674e6q864f6a980d8e10b0@mail.gmail.com>
Message-ID: <006701c6889b$77d31b30$0100a8c0@kornelpal.hu>

>> >     Now in .NET 1.1 SP-N I noticed that they introduced some changes.
>> > Some classes now implemented some new interfaces that were not present
>> > in .NET 1.1.   My question is: what is the justification to add new
>> > implemented interfaces to classes,
>>
>> No idea.
>>
>
> Big fixes is one possible reason. (IIRC System.Threading.WaitHandle
> neglected to implement IDisposable initially. It does in 2.0 and now
> maybe in 1.1 SP-N.)

System.Threading.WaitHandle implements IDisposable at least since MS.NET 1.0 
RTM.

Some System.Runtime.InteropServices interfaces prefixed with _ were added in 
MS.NET 1.1 SP1 for more proper COM interop support.

Another exapmle is System.Web.HttpResponse.TransmitFile method that was 
added to MS.NET 1.0 and MS.NET 1.1 by a hotfix and later Service Packs 
include it:
http://support.microsoft.com/kb/823409/en-us

Regarding such post-RTM API changes I suggest to implement the API of the 
latest MS.NET Service Packs available because this is what people usually 
use and Microsoft probable evaluated the drawbacks of such changes and the 
should be fully backward compatible.

Korn?l 



From sebastien.pouliot at gmail.com  Mon Jun  5 09:11:08 2006
From: sebastien.pouliot at gmail.com (Sebastien Pouliot)
Date: Mon, 05 Jun 2006 09:11:08 -0400
Subject: [Mono-dev] C APIs for signatures
In-Reply-To: <200606042310.32989.Yota_VGA@praisenet.darktech.org>
References: <200606042310.32989.Yota_VGA@praisenet.darktech.org>
Message-ID: <1149513069.9712.84.camel@poupou.home>

Hello Fulvio,

On Sun, 2006-06-04 at 23:10 +0200, Fulvio Satta wrote:
> Hi, this is my first post in this ml.

Welcome!

> I want to know the APIs (for embedding mono) for discover the autenticode sign 
> of a PE, if exists.

Not quite sure what you want exactly.

Do you want to embed Mono into your application and verify (not sign)
authenticode signature ? 

or you may want to sign PE files using the Mono runtime ?

Anyway Mono support(*) signing PE files using authenticode by supplying
the same tools as Microsoft (makecert, cert2spc, signcode, chktrust).
The biggest difference is that all Mono tools are fully managed (and can
run on the MS runtime too).

(*) What Mono doesn't currently support (but some people did it) is
signing CAB files (which aren't PE files).
-- 
Sebastien Pouliot  <sebastien at ximian.com>
Blog: http://pages.infinit.net/ctech/



From lluis at ximian.com  Mon Jun  5 09:15:52 2006
From: lluis at ximian.com (Lluis Sanchez)
Date: Mon, 05 Jun 2006 15:15:52 +0200
Subject: [Mono-dev] Serialization strategies for compatibility.
In-Reply-To: <1149482532.12303.900.camel@linux.site>
References: <1149482532.12303.900.camel@linux.site>
Message-ID: <1149513353.4768.32.camel@portatil.aticatac>

El dl 05 de 06 del 2006 a les 00:42 -0400, en/na Miguel de Icaza va
escriure:
(snip)
>     Since this stuff is genuinely useful, I was considering whether we
> could make our 1.1 implementation support it, but to avoid exposing a
> non-existent 1.1 type, we could do a name-based attribute lookup on the
> methods and if we find that there is such an attribute, we could perform
> the same tasks that 2.0 does.   This means that 1.1 assemblies could get
> the 2.0 "hooks" by including their own copy of the attribute.   The only
> issue here is whether this would not have a negative performance
> impact.  
> 
>     The second issue is: how do we cope with deserialization in the
> future without having to change our internals extensively?   And I think
> that if we extend the serialization framework we can do this.
> 
>     We could introduce some *extra* attributes that are specific to
> Mono, and that are applied to the type.  If such attribute is found, it
> would instruct the deserializer to not perform the manual
> deserialization/serialization, but instead use an ISerializable-like
> approach on that given class, this would give us the control we need.

One problem of using Mono-specific hooks (or using 2.0 hooks in 1.1) is
that we can't force custom formatters to use those hooks, so we can't
guarantee that formatters other than BinaryFormatter or SoapFormatter
would be able to deserialize Color objects. We can implement this logic
in ObjectManager, which has a high probability of being used by custom
formatters, but it use is not mandatory.

> 
>     Now in .NET 1.1 SP-N I noticed that they introduced some changes.
> Some classes now implemented some new interfaces that were not present
> in .NET 1.1.   My question is: what is the justification to add new
> implemented interfaces to classes, and could we get away by just
> sprinkling "ISerializable" on our classes, or would that be considered a
> massive breach of API compatibility?

The API would be different, but I don't see how this change could break
existing code.

Lluis.





From paul at all-the-johnsons.co.uk  Mon Jun  5 09:17:28 2006
From: paul at all-the-johnsons.co.uk (PFJ)
Date: Mon, 05 Jun 2006 14:17:28 +0100
Subject: [Mono-dev] mono frustration
In-Reply-To: <1149507285.1013.29.camel@mrwibble.mrwobble>
References: <1149411720.3419.13.camel@localhost.localdomain>
	<1149507285.1013.29.camel@mrwibble.mrwobble>
Message-ID: <1149513448.1013.49.camel@mrwibble.mrwobble>

Hi,

> > I've just been trying to install the monodevelop IDE and associated
> > utilities for FC5 as per your excellent instructions on the mono-develop
> > mailing list.

> Yes - I'm moving job, so have moved the packages. I will be putting up
> fresh builds tonight via my home website - there are plenty of fixes,
> including one which sorts out the chomping of the mime encodings!

I've uploaded the 64 bit versions of the rpms - the 32 bit versions will
be around later today.

http://www.all-the-johnsons.co.uk/mono/rpms.html

Please remember, other than ikvm, all of these packages have not been
yet added to the official Fedora Extras yum repository. If you find a
problem, you can file bugs by going to the following bugs at
bugzilla.redhat.com

178901 - gtksourceview-sharp
178904 - monodevelop
189092 - boo
189093 - mono-debugger
193957 - nant

monodoc seems to have vanished currently!

TTFN

Paul
-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who



From lluis at ximian.com  Mon Jun  5 09:27:47 2006
From: lluis at ximian.com (Lluis Sanchez)
Date: Mon, 05 Jun 2006 15:27:47 +0200
Subject: [Mono-dev] Serialization strategies for compatibility.
In-Reply-To: <de64bb540606050436o7cf674e6q864f6a980d8e10b0@mail.gmail.com>
References: <1149482532.12303.900.camel@linux.site>
	<1149506007.3847.9.camel@melchior.magi>
	<de64bb540606050436o7cf674e6q864f6a980d8e10b0@mail.gmail.com>
Message-ID: <1149514067.4768.37.camel@portatil.aticatac>

> In general I agree, but ISerializable is a bit of a special case due
> to remoting. It is unlkiely but conceivable that somewhere in remoting
> plumbing (in Mono or another tool) somebody might "if(x is
> ISerializable)...".

There is no such code in remoting, and even if it was I don't see how it
could be a problem. Objects serialized with field serialization or with
the ISerializable interface have the same binary format.

> 
> It might be worth considering an IMonoSerializable interface?
> 
> Mike
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From mwelham at gmail.com  Mon Jun  5 09:41:06 2006
From: mwelham at gmail.com (Mike Welham)
Date: Mon, 5 Jun 2006 15:41:06 +0200
Subject: [Mono-dev] Serialization strategies for compatibility.
In-Reply-To: <006701c6889b$77d31b30$0100a8c0@kornelpal.hu>
References: <1149482532.12303.900.camel@linux.site>
	<1149506007.3847.9.camel@melchior.magi>
	<de64bb540606050436o7cf674e6q864f6a980d8e10b0@mail.gmail.com>
	<006701c6889b$77d31b30$0100a8c0@kornelpal.hu>
Message-ID: <de64bb540606050641x5d90a0a7r47ce6e1bf713938a@mail.gmail.com>

> >> >     Now in .NET 1.1 SP-N I noticed that they introduced some changes.
> >> > Some classes now implemented some new interfaces that were not present
> >> > in .NET 1.1.   My question is: what is the justification to add new
> >> > implemented interfaces to classes,
> >>
> >> No idea.
> >>
> >
> > Big fixes is one possible reason. (IIRC System.Threading.WaitHandle
> > neglected to implement IDisposable initially. It does in 2.0 and now
> > maybe in 1.1 SP-N.)
>
> System.Threading.WaitHandle implements IDisposable at least since MS.NET 1.0
> RTM.
>

Sorry, remembered incorrectly. .NET Compact Framework 1.0 was where
IDisposable was left off WaitHandle.

Mike


From paul at all-the-johnsons.co.uk  Mon Jun  5 09:51:09 2006
From: paul at all-the-johnsons.co.uk (PFJ)
Date: Mon, 05 Jun 2006 14:51:09 +0100
Subject: [Mono-dev] mono frustration
In-Reply-To: <1149513448.1013.49.camel@mrwibble.mrwobble>
References: <1149411720.3419.13.camel@localhost.localdomain>
	<1149507285.1013.29.camel@mrwibble.mrwobble>
	<1149513448.1013.49.camel@mrwibble.mrwobble>
Message-ID: <1149515470.1013.63.camel@mrwibble.mrwobble>

Hi,

> 178901 - gtksourceview-sharp
> 178904 - monodevelop
> 189092 - boo
> 189093 - mono-debugger
> 193957 - nant

194054 - monodoc
-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who



From js at hotfeet.ch  Mon Jun  5 11:01:29 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Mon, 05 Jun 2006 17:01:29 +0200
Subject: [Mono-dev] Patch for HttpRequest.cs
Message-ID: <1149519689.21364.8.camel@leonardo.hotfeet.ch>

Hi,

Did anyone had a chance to look at the patches? Is there anything I can
do the speed up the process?
http://lists.ximian.com/pipermail/mono-devel-list/2006-May/018667.html

And there's a bug I've filed almost 4 months ago, including an "naive"
patch. Did anyone look at it?
http://bugzilla.ximian.com/show_bug.cgi?id=77769


- Juraj



From gonzalo at novell.com  Mon Jun  5 14:04:58 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Mon, 05 Jun 2006 14:04:58 -0400
Subject: [Mono-dev] Patch for HttpRequest.cs
In-Reply-To: <1149519689.21364.8.camel@leonardo.hotfeet.ch>
References: <1149519689.21364.8.camel@leonardo.hotfeet.ch>
Message-ID: <1149530698.5140.30.camel@lalo.micasa>

On Mon, 2006-06-05 at 17:01 +0200, Juraj Skripsky wrote:
> Hi,
> 
> Did anyone had a chance to look at the patches? Is there anything I can
> do the speed up the process?
> http://lists.ximian.com/pipermail/mono-devel-list/2006-May/018667.html

Somehow I didn't get that email.

In the patch for HttpUtility:
-			return ParseQueryString (query, Encoding.UTF8);
+			return ParseQueryString (query, Encoding.Default);

MS documentation explicitly mentions UTF8 as the encoding used for
ParseQueryString (string). Please add a comment that refers to the test
that proves the documentations is wrong.

Feel free to commit the three patches after that.

Thanks.

-Gonzalo




From paul at all-the-johnsons.co.uk  Mon Jun  5 17:55:21 2006
From: paul at all-the-johnsons.co.uk (Paul)
Date: Mon, 05 Jun 2006 22:55:21 +0100
Subject: [Mono-dev] Fedora Core 5 rpms now available for Monodevelop
Message-ID: <1149544521.24462.14.camel@T7.Linux>

Hi,

http://www.all-the-johnsons.co.uk/mono/rpms.html

With the exception of ikvm and monodoc, the rest are awaiting
authorisation to be included into Fedora Extras. They are not currently
part of FE and all reports of problems should be sent directly to me.

The site contains the latest builds for both x86 and x86_64
architectures. The src rpms and spec files are all available from
http://www.knox.net.nz/~nodoid

(except ikvm and monodoc which can be found in the FE area of the fedora
core ftp site).

If you use the spec files and build on anything other than an x86 or
x86_64 bit system and want the rpms hosting, please let me know.

Instructions:

1. Download the lot
2. su
3a (if you have never installed them before) rpm -ihv *.rpm
3b (if you have a previous version in there) rpm -Uhv *.rpm

Currently there is a bug in the version of gtk shipped with both FC5 and
rawhide. This prevents monodevelop from running currently.

TTFN

Paul
-- 
ich liebe Ashleigh, eins zwei drei 
ich liebe Ashleigh, auf meinem Knee zu h?pfen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060605/eef616b2/attachment.bin 

From rusminsusanto at yahoo.com  Mon Jun  5 20:32:10 2006
From: rusminsusanto at yahoo.com (Rusmin Susanto)
Date: Mon, 5 Jun 2006 17:32:10 -0700 (PDT)
Subject: [Mono-dev] Problem with System.Reflection.Emit
In-Reply-To: <1149515470.1013.63.camel@mrwibble.mrwobble>
Message-ID: <20060606003210.73663.qmail@web60824.mail.yahoo.com>

Hi.
  I am trying to improve performance by using System.Reflection.Emit. Here is what I do:
  - I have a class (let's call it vector). It has a 1D array of double for holding the data.
  - The Vector class has operators (+, -, etc.). In the overloaded operators, I build the expression tree. I am trying to emulate expression template trick.
  - To copy the result of calculation to the destination Vector, I define a function Assign().
  - The function Assign() will emit the opcodes based on expression that is passed. It only emit the opcodes when it's executed for the first time. The next time, it just execute the opcode.
The pseudo code of Assign() looks like this:
   
  void Assign(Expression pex)
{
 if (the opcodes don't exist)
 {
  Emit opcodes for expression pex.
 }
   execute the emitted opcodes
}
  
The main program looks like this:
  Vector v1 = new Vector(300); // create vector with 300 elements
Vector v2 = new Vector(300); // create vector with 300 elements
Vector v3 = new Vector(300); // create vector with 300 elements
Vector v4 = new Vector(300); // create vector with 300 elements
Vector v5 = new Vector(300); // create vector with 300 elements
Vector v6 = new Vector(300); // create vector with 300 elements
Vector result = new Vector(300);  // create vector with 300 elements
  result.Assign(v1 + v2 - v3 + v4 - v5 + v6);  // copy the result.
   
  To find out the performance, I execute Assign() 100000 times and measure the execution time.
   
  for(int i = 0; i < 100000; i++)
 result.Assign(v1 + v2 - v3 + v4 - v5 + v6);
   
  To compare the speed, I also define another function Assign2() and execute it also 100000 times. Here is the implementation:
   
  void Assign2(Vector v1, Vector v2, Vector v3, Vector v4, Vector v5, Vector v6)
{
 for(int i = 0; i < m_size; i++)
 {
  m_data[i] = v1.m_data[i]+v2.m_data[i]-v3.m_data[i]+v4.m_data[i]-v5.m_data[i]+v6.m_data[i];
 }
}
   
  I expect Assign (using Reflection.Emit) to outperform Assign2 because Assign() basically unrolls the loop. 
   
  But I am very surprised to find out that Assign2 is almost 3 times faster than Assign(). I tried this in on mono 1.1.13.8
  
How can this happen? I thought Reflection.Emit is superior.
Am I doing something wrong? Does it have something to do with memory or cache or ????
   
  Can someone help me?
   
  The opcodes that I emitted is pretty much the same as the opcodes in Assign2 because I monodis Assign2() and then basically "copy" the opcodes to Assign()
   
  I don't mind to go down to opcodes level as long as I can get the performance. But the result has been dissapointing so far.
   
  Thank you for your attention.
   
  
Rusmin

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060605/713cc520/attachment.html 

From Jonathan.Chambers at ansys.com  Mon Jun  5 23:27:15 2006
From: Jonathan.Chambers at ansys.com (Jonathan S. Chambers)
Date: Mon, 5 Jun 2006 23:27:15 -0400
Subject: [Mono-dev] Variant patch
Message-ID: <BDBFCADE470D2B4A841D51412D2D915D03FE562C@canonsburgexch2.win.ansys.com>

Here is the previous patch plus an incremented corlib, ChangeLog entries, and a series of tests for both BSTR and VARIANT marshalling on windows.

Thanks,
Jonathan


-----Original Message-----
From:	mono-devel-list-bounces at lists.ximian.com on behalf of Zoltan Varga
Sent:	Fri 6/2/2006 8:12 PM
To:	Jonathan S. Chambers
Cc:	mono-devel-list at lists.ximian.com
Subject:	Re: [Mono-dev] Variant patch

                             Hey,

  The patch looks fine. Some tests would be useful, tough. Also, you
should increase
the corlib version number in System/Environment.cs and in
metadata/appdomain.c because
of the new Variant class.

               Zoltan

On 6/2/06, Jonathan S. Chambers <Jonathan.Chambers at ansys.com> wrote:
>
>
>
>
> Here is a patch to add Variant support to mono for basic types. This works
> for pinvoke and implements two Variant methods in the Marshal class. I
> didn't #ifdef anything for windows since I'm not using any windows specific
> calls; let me know if I should. Please review.
>
>
>
> Thanks,
>
>
>
> Jonathan S. Chambers
>
> Software Development Engineer
>
> ANSYS, Inc.
>
> Phone: 724.514.3682
>
> Fax: 724.514.3114
>
> E-mail: jonathan.chambers at ansys.com
>
>
>
> ___________________________________________________
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete the material from any
> computer.
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list




-------------- next part --------------
A non-text attachment was scrubbed...
Name: variant2.diff
Type: application/octet-stream
Size: 24159 bytes
Desc: variant2.diff
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060605/36eb510d/attachment.obj 

From marek.sieradzki at gmail.com  Tue Jun  6 04:33:31 2006
From: marek.sieradzki at gmail.com (Marek Sieradzki)
Date: Tue, 06 Jun 2006 10:33:31 +0200
Subject: [Mono-dev] Variant patch
In-Reply-To: <BDBFCADE470D2B4A841D51412D2D915D03FE562C@canonsburgexch2.win.ansys.com>
References: <BDBFCADE470D2B4A841D51412D2D915D03FE562C@canonsburgexch2.win.ansys.com>
Message-ID: <1149582811.5196.2.camel@k5m10marek.cl.wroc.pl>

Dnia 05-06-2006, pon o godzinie 23:27 -0400, Jonathan S. Chambers
napisa?(a):
> Here is the previous patch plus an incremented corlib, ChangeLog entries, and a series of tests for both BSTR and VARIANT marshalling on windows.
You have changed formatting in
mcs/class/corlib/System.Runtime.InteropServices/Marshal.cs
(GetComSlotForMethodInfo ()) (btw to wrong format).
-- 
Marek Sieradzki <marek.sieradzki at gmail.com>



From mwelham at gmail.com  Tue Jun  6 04:54:42 2006
From: mwelham at gmail.com (Mike Welham)
Date: Tue, 6 Jun 2006 10:54:42 +0200
Subject: [Mono-dev] Serialization strategies for compatibility.
In-Reply-To: <1149514067.4768.37.camel@portatil.aticatac>
References: <1149482532.12303.900.camel@linux.site>
	<1149506007.3847.9.camel@melchior.magi>
	<de64bb540606050436o7cf674e6q864f6a980d8e10b0@mail.gmail.com>
	<1149514067.4768.37.camel@portatil.aticatac>
Message-ID: <de64bb540606060154o5b28bdaev1a7889a19acd4d49@mail.gmail.com>

> > In general I agree, but ISerializable is a bit of a special case due
> > to remoting. It is unlkiely but conceivable that somewhere in remoting
> > plumbing (in Mono or another tool) somebody might "if(x is
> > ISerializable)...".
>
> There is no such code in remoting, and even if it was I don't see how it
> could be a problem. Objects serialized with field serialization or with
> the ISerializable interface have the same binary format.
>

A quick grep shows SoapWriter.cs in
System.Runtime.Serialization.Formatters.Soap is doing this:

private void SerializeObject(object currentObject, long currentObjectId)
{
    ...
     if(currentObject is ISerializable || surrogate != null)
needsSerializationInfo = true;
    ...
}

Also, field serialization will only have the same binary format as an
ISerializable implementation if GetObjectData is careful to make it
the same.

As you say though, this is not an issue if we're careful to ensure
that types where (against API) we add ISerializable we ensure the
serializad binary format matches Microsoft's.

Best Regards

Mike


From vargaz at gmail.com  Tue Jun  6 05:39:05 2006
From: vargaz at gmail.com (Zoltan Varga)
Date: Tue, 6 Jun 2006 11:39:05 +0200
Subject: [Mono-dev] Variant patch
In-Reply-To: <BDBFCADE470D2B4A841D51412D2D915D03FE562C@canonsburgexch2.win.ansys.com>
References: <BDBFCADE470D2B4A841D51412D2D915D03FE562C@canonsburgexch2.win.ansys.com>
Message-ID: <295e750a0606060239y7e8631b4s1afe04649855f499@mail.gmail.com>

                                                 Hi,

  This is ok to check in.

                    Zoltan

On 6/6/06, Jonathan S. Chambers <Jonathan.Chambers at ansys.com> wrote:
> Here is the previous patch plus an incremented corlib, ChangeLog entries, and a series of tests for both BSTR and VARIANT marshalling on windows.
>
> Thanks,
> Jonathan
>
>
> -----Original Message-----
> From:   mono-devel-list-bounces at lists.ximian.com on behalf of Zoltan Varga
> Sent:   Fri 6/2/2006 8:12 PM
> To:     Jonathan S. Chambers
> Cc:     mono-devel-list at lists.ximian.com
> Subject:        Re: [Mono-dev] Variant patch
>
>                              Hey,
>
>   The patch looks fine. Some tests would be useful, tough. Also, you
> should increase
> the corlib version number in System/Environment.cs and in
> metadata/appdomain.c because
> of the new Variant class.
>
>                Zoltan
>
> On 6/2/06, Jonathan S. Chambers <Jonathan.Chambers at ansys.com> wrote:
> >
> >
> >
> >
> > Here is a patch to add Variant support to mono for basic types. This works
> > for pinvoke and implements two Variant methods in the Marshal class. I
> > didn't #ifdef anything for windows since I'm not using any windows specific
> > calls; let me know if I should. Please review.
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Jonathan S. Chambers
> >
> > Software Development Engineer
> >
> > ANSYS, Inc.
> >
> > Phone: 724.514.3682
> >
> > Fax: 724.514.3114
> >
> > E-mail: jonathan.chambers at ansys.com
> >
> >
> >
> > ___________________________________________________
> >
> > The information transmitted is intended only for the person or entity to
> > which it is addressed and may contain confidential and/or privileged
> > material. Any review, retransmission, dissemination or other use of, or
> > taking of any action in reliance upon, this information by persons or
> > entities other than the intended recipient is prohibited. If you received
> > this in error, please contact the sender and delete the material from any
> > computer.
> >
> >
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
> >
> >
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>
>
>
>


From lluis at ximian.com  Tue Jun  6 06:12:35 2006
From: lluis at ximian.com (Lluis Sanchez)
Date: Tue, 06 Jun 2006 12:12:35 +0200
Subject: [Mono-dev] Serialization strategies for compatibility.
In-Reply-To: <de64bb540606060154o5b28bdaev1a7889a19acd4d49@mail.gmail.com>
References: <1149482532.12303.900.camel@linux.site>
	<1149506007.3847.9.camel@melchior.magi>
	<de64bb540606050436o7cf674e6q864f6a980d8e10b0@mail.gmail.com>
	<1149514067.4768.37.camel@portatil.aticatac>
	<de64bb540606060154o5b28bdaev1a7889a19acd4d49@mail.gmail.com>
Message-ID: <1149588756.4801.77.camel@portatil.aticatac>

El dt 06 de 06 del 2006 a les 10:54 +0200, en/na Mike Welham va
escriure:
> > > In general I agree, but ISerializable is a bit of a special case due
> > > to remoting. It is unlkiely but conceivable that somewhere in remoting
> > > plumbing (in Mono or another tool) somebody might "if(x is
> > > ISerializable)...".
> >
> > There is no such code in remoting, and even if it was I don't see how it
> > could be a problem. Objects serialized with field serialization or with
> > the ISerializable interface have the same binary format.
> >
> 
> A quick grep shows SoapWriter.cs in
> System.Runtime.Serialization.Formatters.Soap is doing this:
> 
> private void SerializeObject(object currentObject, long currentObjectId)
> {
>     ...
>      if(currentObject is ISerializable || surrogate != null)
> needsSerializationInfo = true;
>     ...
> }

This is not remoting code, it's the implementation of a formatter.
Formatters are general purpose serializers, and remoting just happens to
use them to serialize messages. And of course formatters need to check
for ISerializable. 

> 
> Also, field serialization will only have the same binary format as an
> ISerializable implementation if GetObjectData is careful to make it
> the same.

The binary format is the same. Fields, types and values are codified in
the same way, that's what I mean. Of course, if GetObjectData returns
different member names, the serialized content will be different.

> 
> As you say though, this is not an issue if we're careful to ensure
> that types where (against API) we add ISerializable we ensure the
> serializad binary format matches Microsoft's.
> 
> Best Regards
> 
> Mike



From sebastien.pouliot at gmail.com  Tue Jun  6 08:20:16 2006
From: sebastien.pouliot at gmail.com (Sebastien Pouliot)
Date: Tue, 06 Jun 2006 08:20:16 -0400
Subject: [Mono-dev] C APIs for signatures
In-Reply-To: <200606052147.03878.Yota_VGA@praisenet.darktech.org>
References: <200606042310.32989.Yota_VGA@praisenet.darktech.org>
	<1149513069.9712.84.camel@poupou.home>
	<200606052147.03878.Yota_VGA@praisenet.darktech.org>
Message-ID: <1149596417.9712.112.camel@poupou.home>

Hello Fulvio,

Please always c.c. the mailing list in your replies, other people may be
interested in the answers.

On Mon, 2006-06-05 at 21:47 +0200, Fulvio Satta wrote:
> Alle 15:11, luned? 5 giugno 2006, Sebastien Pouliot ha scritto:
...
> Firstly thanks :)
> Secondly, I want only verify an autenticode signature, and obtain some 
> informations from this, for example the signer name.
> I'm not interessed to sign an app.

There is no C API to do what you want, but you can probably make one
using 'cilc' [1].

Other choices would be to call a Mono application, like chktrust [2],
from your C application or to port the C# code to C.

[1] http://tirania.org/blog/archive/2004/Dec-13.html
[2]
http://svn.myrealbox.com/viewcvs/trunk/mcs/tools/security/chktrust.cs?rev=37601&view=markup
-- 
Sebastien Pouliot  <sebastien at ximian.com>
Blog: http://pages.infinit.net/ctech/



From kostat at mainsoft.com  Tue Jun  6 08:35:12 2006
From: kostat at mainsoft.com (Konstantin Triger)
Date: Tue, 6 Jun 2006 05:35:12 -0700
Subject: [Mono-dev] [PATCH] System.Web: enable themes for files not in app
	root
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03098F52@dhost002-45.dex002.intermedia.net>

Hello,

 

Since the App_Themes is an application root subfolder, we should access it using ~/App_Themes and not ./App_Themes.

The attached patch fixes this.

 

If no one objects I'll commit.

 

Regards,

Konstantin Triger

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060606/8f824a0a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NonRootFilesTheme.patch
Type: application/octet-stream
Size: 2258 bytes
Desc: NonRootFilesTheme.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060606/8f824a0a/attachment.obj 

From Jonathan.Chambers at ansys.com  Tue Jun  6 09:47:45 2006
From: Jonathan.Chambers at ansys.com (Jonathan S. Chambers)
Date: Tue, 6 Jun 2006 09:47:45 -0400
Subject: [Mono-dev] Variant patch
Message-ID: <BDBFCADE470D2B4A841D51412D2D915D038CCF13@canonsburgexch2.win.ansys.com>

Committed (with fix to formatting Marek spotted). Thanks.

- Jonathan

> -----Original Message-----
> From: Zoltan Varga [mailto:vargaz at gmail.com]
> Sent: Tuesday, June 06, 2006 5:39 AM
> To: Jonathan S. Chambers
> Cc: mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-dev] Variant patch
> 
>                                                  Hi,
> 
>   This is ok to check in.
> 
>                     Zoltan
> 
> On 6/6/06, Jonathan S. Chambers <Jonathan.Chambers at ansys.com> wrote:
> > Here is the previous patch plus an incremented corlib, ChangeLog
> entries, and a series of tests for both BSTR and VARIANT marshalling
on
> windows.
> >
> > Thanks,
> > Jonathan
> >
> >
> > -----Original Message-----
> > From:   mono-devel-list-bounces at lists.ximian.com on behalf of Zoltan
> Varga
> > Sent:   Fri 6/2/2006 8:12 PM
> > To:     Jonathan S. Chambers
> > Cc:     mono-devel-list at lists.ximian.com
> > Subject:        Re: [Mono-dev] Variant patch
> >
> >                              Hey,
> >
> >   The patch looks fine. Some tests would be useful, tough. Also, you
> > should increase
> > the corlib version number in System/Environment.cs and in
> > metadata/appdomain.c because
> > of the new Variant class.
> >
> >                Zoltan
> >
> > On 6/2/06, Jonathan S. Chambers <Jonathan.Chambers at ansys.com> wrote:
> > >
> > >
> > >
> > >
> > > Here is a patch to add Variant support to mono for basic types.
This
> works
> > > for pinvoke and implements two Variant methods in the Marshal
class. I
> > > didn't #ifdef anything for windows since I'm not using any windows
> specific
> > > calls; let me know if I should. Please review.
> > >
> > >
> > >
> > > Thanks,
> > >
> > >
> > >
> > > Jonathan S. Chambers
> > >
> > > Software Development Engineer
> > >
> > > ANSYS, Inc.
> > >
> > > Phone: 724.514.3682
> > >
> > > Fax: 724.514.3114
> > >
> > > E-mail: jonathan.chambers at ansys.com
> > >
> > >
> > >
> > > ___________________________________________________
> > >
> > > The information transmitted is intended only for the person or
entity
> to
> > > which it is addressed and may contain confidential and/or
privileged
> > > material. Any review, retransmission, dissemination or other use
of,
> or
> > > taking of any action in reliance upon, this information by persons
or
> > > entities other than the intended recipient is prohibited. If you
> received
> > > this in error, please contact the sender and delete the material
from
> any
> > > computer.
> > >
> > >
> > > _______________________________________________
> > > Mono-devel-list mailing list
> > > Mono-devel-list at lists.ximian.com
> > > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> > >
> > >
> > >
> > >
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
> >
> >
> >
> >
> >




From L.Saliou at napier.ac.uk  Tue Jun  6 12:22:02 2006
From: L.Saliou at napier.ac.uk (Saliou, Lionel)
Date: Tue, 6 Jun 2006 17:22:02 +0100
Subject: [Mono-dev] mono contains a bug for version 1.1.13-6 and 1.1.14 ;
	This might be the case for version above 1.1.8-3
Message-ID: <735F04A99D358E468A16EDB64FC0455599E836@EVS1.napier-mail.napier.ac.uk>

Dear all,

I have been developping a bunch of client/server applications for my research. In a nutshell, the client is tasked to contact the servers around the network, have them perform a bunch of tasks, retrieve/archive the results, and close the connection. All the application are developped in C# .NET; the client application typically runs on a Windows XP type machine whereas the servers run on Ubuntu Linux hosts (both Breezy Badger and Dapper Drake). The linux hosts all have custom kernells to 'enhance' performance.

So far I have developped and tested my applications on a computer running Ubuntu Dreezy 5.10 and mono-1.1.8-3 (default version available with Breezy), and everything works fine. However, if I do run the applications using another version of mono (1.1.13-6 [default version of Dapper) or 1.1.14), my applications crash. Apparently, this is due to some event within my applications that is not handled????  Here is a sample of what is going on using version 1.1.8-3 in the first instance then 1.1.14

[SCREEN CAPTURE]
[mono versions]
lionel at arthemis:~/Projects/dotNetTest$ mono -V
Mono JIT compiler version 1.1.14, (C) 2002-2005 Novell, Inc and Contributors. ww w.mono-project.com
        TLS:           normal
        GC:            Included Boehm (with typed GC)
        SIGSEGV:       normal
        Disabled:      none
lionel at arthemis:~/Projects/dotNetTest$ which mono
/home/lionel/mono-1.1.14/bin/mono
lionel at arthemis:~/Projects/dotNetTest$ sudo mono -V
Mono JIT compiler version 1.1.8.3, (C) 2002-2005 Novell, Inc and Contributors. w ww.mono-project.com
        TLS:           __thread
        GC:            Included Boehm (with typed GC)
        SIGSEGV      : normal
        Globalization: normal
lionel at arthemis:~/Projects/dotNetTest$ sudo which mono
/usr/bin/mono
[/mono versions]
[TEST 1]
lionel at arthemis:~/Projects/dotNetTest$ ls
CMCSNetworking.dll  CMCSUtilities.dll  LinuxSlave_v4.exe  old
lionel at arthemis:~/Projects/dotNetTest$ which sudo mono
/usr/bin/mono
lionel at arthemis:~/Projects/dotNetTest$ sudo mono LinuxSlave_v4.exe
Note, this application is a test ...
Linux Slave v4> hping
Starting HPing Service...
This machine Name : arthemis
This machine IP Address : *.*.*.13
Server is online on port :2048
Starting up Server...
Maximum allowed number of connection : 1
Note, this application is a test ...
Linux Slave v4>
Receiving connection requestion from Client (*.*.*.87:1569)
message =*.*.*.87 -c 20|2
strParameters = *.*.*.87 -c 20
iNbOfIteration = 2

--- *.*.*.87 hping statistic ---
20 packets transmitted, 20 packets received, 0% packet loss
round-trip min/avg/max = 0.5/0.6/0.8 ms
[output from HPING omitted]

--- *.*.*.87 hping statistic ---
20 packets transmitted, 20 packets received, 0% packet loss
round-trip min/avg/max = 0.5/0.5/0.7 ms
[output from HPING omitted]
Breaking out!
Management pool number : 0

Linux Slave v4>
[/TEST 1]

[TEST 2]
lionel at arthemis:~/Projects/dotNetTest$ ls
CMCSNetworking.dll  CMCSUtilities.dll  LinuxSlave_v4.exe  old
lionel at arthemis:~/Projects/dotNetTest$ which mono
/home/lionel/mono-1.1.14/bin/mono
lionel at arthemis:~/Projects/dotNetTest$ sudo ~/mono-1.1.14/bin/mono LinuxSlave_v4.exe
Note, this application is a test ...
Linux Slave v4> hping
Starting HPing Service...
This machine Name : arthemis
This machine IP Address : *.*.*.13
Server is online on port :2048
Starting up Server...
Maximum allowed number of connection : 1
Note, this application is a test ...
Linux Slave v4>
Receiving connection requestion from Client (*.*.*.87:1432)
message =*.*.*.87 -c 20|2
strParameters = *.*.*.87 -c 20
iNbOfIteration = 2

--- *.*.*.87 hping statistic ---
20 packets transmitted, 20 packets received, 0% packet loss
round-trip min/avg/max = 0.5/0.6/0.8 ms
[output from HPING omitted]

--- *.*.*.87 hping statistic ---
20 packets transmitted, 20 packets received, 0% packet loss
round-trip min/avg/max = 0.5/0.5/0.7 ms
[output from HPING omitted]
Breaking out!
Management pool number : 0

Unhandled Exception: System.NotImplementedException: The requested feature is not implemented.in <0x0001d> System.Threading.Thread:Interrupt ()
in <0x0001d> CMCS.Networking.GenServerReceive:Stop ()
in <0x0001d> CMCS.Networking.Connection:Stop ()
in <0x0009a> CMCS.Networking.GenericServer:manageClientPool (CMCS.Networking.myEventArgs sender)in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_myEventArgs (CMCS.Networking.myEventArgs)in <0x00011> CMCS.Networking.Connection:serverNotice (CMCS.Networking.myEventArgs Evt)in <0x0000d> CMCS.Networking.Connection:serverReceive_LostConnection (CMCS.Networking.myEventArgs Evt)in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_myEventArgs (CMCS.Networking.myEventArgs)in <0x00011> CMCS.Networking.GenServerReceive:lostConnectionNotify (CMCS.Networking.myEventArgs Evt)in <0x0016c> CMCS.Networking.GenServerReceive:Run ()
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void ()
[/TEST 2]
[/SCREEN CAPTURE]

I could live with a warning but not with a problem that stops my applications from cleaning/closing the underlying sockets and so on. As you can see my applications are configured to accept one connection at a time, hence the client comes back from the next batch of task it gets rejected puting my experiments in jeopardy. Please note that the exact same error occurs in 1.1.13-6 (Dapper Drake), and also note that once 1.1.8-3 is installed on Ubuntu Dapper Drake the application demonstrated in the above WORKS!

Now, I admit the CMCS dlls that you see in the above have been developped by yours trully. They allow using TCP connections transparently, and ONE event is used/raised to trigger the connection pool management (without this features my programs don't clean their connection pool and thus I can easily be DDoS'd ). They also force developpers to respect the various protocols that I defined. But frankly, I don't see why my stuff would work on mono-1.1.8-3 but not on other versions, such as 1.1.13 and 1.1.14 .

To make sure that this is not due to the compiler, LinuxSlaves have been compiled under both Windows XP (using Visual Studio 2003) and MonoDevelop... but not that does not seem to change anything.

Honnestly, I don't have the first clue about what is wrong! However, my fellow researchers and I would like to have this fixed for all version of mono because otherwise that will force us to "freeze" our test bench which could become problematic in the long run.

I do hope that there is a simple fix to this.

Thanks a lot.

Lionel

This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the 
University's system is subject to routine monitoring and filtering by the University. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060606/8f82d11d/attachment.html 

From vargaz at gmail.com  Tue Jun  6 12:45:41 2006
From: vargaz at gmail.com (Zoltan Varga)
Date: Tue, 6 Jun 2006 18:45:41 +0200
Subject: [Mono-dev] mono contains a bug for version 1.1.13-6 and 1.1.14 ;
	This might be the case for version above 1.1.8-3
In-Reply-To: <735F04A99D358E468A16EDB64FC0455599E836@EVS1.napier-mail.napier.ac.uk>
References: <735F04A99D358E468A16EDB64FC0455599E836@EVS1.napier-mail.napier.ac.uk>
Message-ID: <295e750a0606060945j2a294d3eiec5295721daccff6@mail.gmail.com>

                                   Hi,

  Your application depends on the Thread.Interrupt () method which is not
implemented in mono. In previous versions, it did nothing, in later versions it
throws a NotImplementedException to alert users to the fact that it is not
implemented.

            Zoltan


On 6/6/06, Saliou, Lionel <L.Saliou at napier.ac.uk> wrote:
>
>
>
> Dear all,
>
>  I have been developping a bunch of client/server applications for my
> research. In a nutshell, the client is tasked to contact the servers around
> the network, have them perform a bunch of tasks, retrieve/archive the
> results, and close the connection. All the application are developped in C#
> .NET; the client application typically runs on a Windows XP type machine
> whereas the servers run on Ubuntu Linux hosts (both Breezy Badger and Dapper
> Drake). The linux hosts all have custom kernells to 'enhance' performance.
>
>  So far I have developped and tested my applications on a computer running
> Ubuntu Dreezy 5.10 and mono-1.1.8-3 (default version available with Breezy),
> and everything works fine. However, if I do run the applications using
> another version of mono (1.1.13-6 [default version of Dapper) or 1.1.14), my
> applications crash. Apparently, this is due to some event within my
> applications that is not handled????  Here is a sample of what is going on
> using version 1.1.8-3 in the first instance then 1.1.14
>
>  [SCREEN CAPTURE]
>  [mono versions]
>  lionel at arthemis:~/Projects/dotNetTest$ mono -V
>  Mono JIT compiler version 1.1.14, (C) 2002-2005 Novell, Inc and
> Contributors. ww w.mono-project.com
>          TLS:           normal
>          GC:            Included Boehm (with typed GC)
>          SIGSEGV:       normal
>          Disabled:      none
>  lionel at arthemis:~/Projects/dotNetTest$ which mono
>  /home/lionel/mono-1.1.14/bin/mono
>  lionel at arthemis:~/Projects/dotNetTest$ sudo mono -V
>  Mono JIT compiler version 1.1.8.3, (C) 2002-2005 Novell, Inc and
> Contributors. w ww.mono-project.com
>          TLS:           __thread
>          GC:            Included Boehm (with typed GC)
>          SIGSEGV      : normal
>          Globalization: normal
>  lionel at arthemis:~/Projects/dotNetTest$ sudo which mono
>  /usr/bin/mono
>  [/mono versions]
>  [TEST 1]
>  lionel at arthemis:~/Projects/dotNetTest$ ls
>  CMCSNetworking.dll  CMCSUtilities.dll  LinuxSlave_v4.exe  old
>  lionel at arthemis:~/Projects/dotNetTest$ which sudo mono
>  /usr/bin/mono
>  lionel at arthemis:~/Projects/dotNetTest$ sudo mono LinuxSlave_v4.exe
>  Note, this application is a test ...
>  Linux Slave v4> hping
>  Starting HPing Service...
>  This machine Name : arthemis
>  This machine IP Address : *.*.*.13
>  Server is online on port :2048
>  Starting up Server...
>  Maximum allowed number of connection : 1
>  Note, this application is a test ...
>  Linux Slave v4>
>  Receiving connection requestion from Client (*.*.*.87:1569)
>  message =*.*.*.87 -c 20|2
>  strParameters = *.*.*.87 -c 20
>  iNbOfIteration = 2
>
>  --- *.*.*.87 hping statistic ---
>  20 packets transmitted, 20 packets received, 0% packet loss
>  round-trip min/avg/max = 0.5/0.6/0.8 ms
>  [output from HPING omitted]
>
>  --- *.*.*.87 hping statistic ---
>  20 packets transmitted, 20 packets received, 0% packet loss
>  round-trip min/avg/max = 0.5/0.5/0.7 ms
>  [output from HPING omitted]
>  Breaking out!
>  Management pool number : 0
>
>  Linux Slave v4>
>  [/TEST 1]
>
>  [TEST 2]
>  lionel at arthemis:~/Projects/dotNetTest$ ls
>  CMCSNetworking.dll  CMCSUtilities.dll  LinuxSlave_v4.exe  old
>  lionel at arthemis:~/Projects/dotNetTest$ which mono
>  /home/lionel/mono-1.1.14/bin/mono
>  lionel at arthemis:~/Projects/dotNetTest$ sudo ~/mono-1.1.14/bin/mono
> LinuxSlave_v4.exe
>  Note, this application is a test ...
>  Linux Slave v4> hping
>  Starting HPing Service...
>  This machine Name : arthemis
>  This machine IP Address : *.*.*.13
>  Server is online on port :2048
>  Starting up Server...
>  Maximum allowed number of connection : 1
>  Note, this application is a test ...
>  Linux Slave v4>
>  Receiving connection requestion from Client (*.*.*.87:1432)
>  message =*.*.*.87 -c 20|2
>  strParameters = *.*.*.87 -c 20
>  iNbOfIteration = 2
>
>  --- *.*.*.87 hping statistic ---
>  20 packets transmitted, 20 packets received, 0% packet loss
>  round-trip min/avg/max = 0.5/0.6/0.8 ms
>  [output from HPING omitted]
>
>  --- *.*.*.87 hping statistic ---
>  20 packets transmitted, 20 packets received, 0% packet loss
>  round-trip min/avg/max = 0.5/0.5/0.7 ms
>  [output from HPING omitted]
>  Breaking out!
>  Management pool number : 0
>
>  Unhandled Exception: System.NotImplementedException: The requested feature
> is not implemented.in <0x0001d>
> System.Threading.Thread:Interrupt ()
>  in <0x0001d> CMCS.Networking.GenServerReceive:Stop ()
>  in <0x0001d> CMCS.Networking.Connection:Stop ()
>  in <0x0009a>
> CMCS.Networking.GenericServer:manageClientPool
> (CMCS.Networking.myEventArgs sender)in (wrapper delegate-invoke)
> System.MulticastDelegate:invoke_void_myEventArgs
> (CMCS.Networking.myEventArgs)in <0x00011>
> CMCS.Networking.Connection:serverNotice
> (CMCS.Networking.myEventArgs Evt)in <0x0000d>
> CMCS.Networking.Connection:serverReceive_LostConnection
> (CMCS.Networking.myEventArgs Evt)in (wrapper delegate-invoke)
> System.MulticastDelegate:invoke_void_myEventArgs
> (CMCS.Networking.myEventArgs)in <0x00011>
> CMCS.Networking.GenServerReceive:lostConnectionNotify
> (CMCS.Networking.myEventArgs Evt)in <0x0016c>
> CMCS.Networking.GenServerReceive:Run ()
>  in (wrapper delegate-invoke)
> System.MulticastDelegate:invoke_void ()
>  [/TEST 2]
>  [/SCREEN CAPTURE]
>
>  I could live with a warning but not with a problem that stops my
> applications from cleaning/closing the underlying sockets and so on. As you
> can see my applications are configured to accept one connection at a time,
> hence the client comes back from the next batch of task it gets rejected
> puting my experiments in jeopardy. Please note that the exact same error
> occurs in 1.1.13-6 (Dapper Drake), and also note that once 1.1.8-3 is
> installed on Ubuntu Dapper Drake the application demonstrated in the above
> WORKS!
>
>  Now, I admit the CMCS dlls that you see in the above have been developped
> by yours trully. They allow using TCP connections transparently, and ONE
> event is used/raised to trigger the connection pool management (without this
> features my programs don't clean their connection pool and thus I can easily
> be DDoS'd ). They also force developpers to respect the various protocols
> that I defined. But frankly, I don't see why my stuff would work on
> mono-1.1.8-3 but not on other versions, such as 1.1.13 and 1.1.14 .
>
>  To make sure that this is not due to the compiler, LinuxSlaves have been
> compiled under both Windows XP (using Visual Studio 2003) and MonoDevelop...
> but not that does not seem to change anything.
>
>  Honnestly, I don't have the first clue about what is wrong! However, my
> fellow researchers and I would like to have this fixed for all version of
> mono because otherwise that will force us to "freeze" our test bench which
> could become problematic in the long run.
>
>  I do hope that there is a simple fix to this.
>
>  Thanks a lot.
>
>  Lionel This message is intended for the addressee(s) only and should not be
> read, copied or disclosed to anyone else outwith the University without the
> permission of the sender.
> It is your responsibility to ensure that this message and any attachments
> are scanned for viruses or other defects. Napier University does not accept
> liability for any loss
> or damage which may result from this email or any attachment, or for errors
> or omissions arising after it was sent. Email is not a secure medium. Email
> entering the
> University's system is subject to routine monitoring and filtering by the
> University.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>


From L.Saliou at napier.ac.uk  Tue Jun  6 13:21:58 2006
From: L.Saliou at napier.ac.uk (Saliou, Lionel)
Date: Tue, 6 Jun 2006 18:21:58 +0100
Subject: [Mono-dev] mono contains a bug for version 1.1.13-6 and 1.1.14 ;
	This might be the case for version above 1.1.8-3
Message-ID: <735F04A99D358E468A16EDB64FC0455503616B34@EVS1.napier-mail.napier.ac.uk>

@Zoltan, thank you very much for your prompt answer. That said, I
stunned to read your message as the class status (cf.
www.go-mono.com/mono-todo.html ->
http://mono.ximian.com/class-status/mono-HEAD-vs-fx-1-1/class-status-Sys
tem.html) says that System.Threading is 100% completed... and since
Thread is part of System.Threading it should work, or am I reading the
wrong resource? Or do I not understand the documentation?

Finally, what should I do to get around this problem? 

Cheers,

Lionel
This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the 
University's system is subject to routine monitoring and filtering by the University. 


From vargaz at gmail.com  Tue Jun  6 14:06:17 2006
From: vargaz at gmail.com (Zoltan Varga)
Date: Tue, 6 Jun 2006 20:06:17 +0200
Subject: [Mono-dev] mono contains a bug for version 1.1.13-6 and 1.1.14 ;
	This might be the case for version above 1.1.8-3
In-Reply-To: <735F04A99D358E468A16EDB64FC0455503616B34@EVS1.napier-mail.napier.ac.uk>
References: <735F04A99D358E468A16EDB64FC0455503616B34@EVS1.napier-mail.napier.ac.uk>
Message-ID: <295e750a0606061106w4ac93aeak680944295cd07174@mail.gmail.com>

                           Hi,

  System.Threading.Thread is in the mscorlib assembly, not in the
System assembly.

As for a replacement for Thread.Interrupt, you can use either:
- setting a flag and have the thread check it regularly (polling)
- use Thread.Abort () which is implemented on mono, then swallow the abort
  exception using Thread.ResetAbort ().

               Zoltan

On 6/6/06, Saliou, Lionel <L.Saliou at napier.ac.uk> wrote:
> @Zoltan, thank you very much for your prompt answer. That said, I
> stunned to read your message as the class status (cf.
> www.go-mono.com/mono-todo.html ->
> http://mono.ximian.com/class-status/mono-HEAD-vs-fx-1-1/class-status-Sys
> tem.html) says that System.Threading is 100% completed... and since
> Thread is part of System.Threading it should work, or am I reading the
> wrong resource? Or do I not understand the documentation?
>
> Finally, what should I do to get around this problem?
>
> Cheers,
>
> Lionel
> This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender.
> It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss
> or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the
> University's system is subject to routine monitoring and filtering by the University.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>


From Yota_VGA at praisenet.darktech.org  Tue Jun  6 14:14:37 2006
From: Yota_VGA at praisenet.darktech.org (Fulvio Satta)
Date: Tue, 6 Jun 2006 20:14:37 +0200
Subject: [Mono-dev] C APIs for signatures
In-Reply-To: <1149596417.9712.112.camel@poupou.home>
References: <200606042310.32989.Yota_VGA@praisenet.darktech.org>
	<200606052147.03878.Yota_VGA@praisenet.darktech.org>
	<1149596417.9712.112.camel@poupou.home>
Message-ID: <200606062014.38944.Yota_VGA@praisenet.darktech.org>

Alle 14:20, marted? 6 giugno 2006, Sebastien Pouliot ha scritto:
> Hello Fulvio,
>
> Please always c.c. the mailing list in your replies, other people may be
> interested in the answers.

Yes, you're right. It was a slip :)

> On Mon, 2006-06-05 at 21:47 +0200, Fulvio Satta wrote:
> > Alle 15:11, luned? 5 giugno 2006, Sebastien Pouliot ha scritto:
>
> ...
>
> > Firstly thanks :)
> > Secondly, I want only verify an autenticode signature, and obtain some
> > informations from this, for example the signer name.
> > I'm not interessed to sign an app.
>
> There is no C API to do what you want, but you can probably make one
> using 'cilc' [1].
>
> Other choices would be to call a Mono application, like chktrust [2],
> from your C application or to port the C# code to C.
>
> [1] http://tirania.org/blog/archive/2004/Dec-13.html
> [2]
> http://svn.myrealbox.com/viewcvs/trunk/mcs/tools/security/chktrust.cs?rev=3
>7601&view=markup

Uhm, ok, I understand. Thanks a lot :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060606/9004aee4/attachment.bin 

From pablosantosluac at terra.es  Tue Jun  6 15:32:14 2006
From: pablosantosluac at terra.es (pablosantosluac at terra.es)
Date: Tue, 6 Jun 2006 21:32:14 +0200
Subject: [Mono-dev] mono-service again
References: <735F04A99D358E468A16EDB64FC0455503616B34@EVS1.napier-mail.napier.ac.uk>
	<295e750a0606061106w4ac93aeak680944295cd07174@mail.gmail.com>
Message-ID: <08bc01c6899f$ea9eaa30$c900a8c0@beardtongue>

Hi all,

I found this question last december in the list, but nobody posted a 
reply...

So, here it goes: whenever I try to launch a service with mono-service I get 
the following on syslog:

"Number of parameter does not match expected count"

Don't know where is the wrong parameter. It runs on Windows/.NET. It fails 
on mono 1.1.15/Linux... Recompiled with mono and it still fails...

What can I do?

cheers,

pablo 



From kornelpal at gmail.com  Tue Jun  6 15:33:50 2006
From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=)
Date: Tue, 6 Jun 2006 21:33:50 +0200
Subject: [Mono-dev] [PATCH] Consts.cs: Update VsFileVersion and remove
	RuntimeVersion
Message-ID: <008e01c689a0$24cb1720$0100a8c0@kornelpal.hu>

Hi,

Previously I defined VsFileVersion as the version of RTM releases because 
cscompmgd.dll was not updated by service packs. Other files using 
VsFileVersion in their version info resource were updated however so I think 
it's better to update VsFileVersion.

On the other hand I reallized that there is no use to have RuntimeVersion 
just for Environment.Version as it should have the same value as 
FxFileVersion.

In addition System.Drawing is incorrectly using RuntimeVersion instead of 
FxFileVersion so I think having RuntimeVersion has more disadvantages than 
advantages.

If nobody objects I'll commit the patch.

Korn?l 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Consts.diff
Type: application/octet-stream
Size: 2751 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060606/da2057db/attachment.obj 

From kornelpal at gmail.com  Tue Jun  6 17:32:24 2006
From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=)
Date: Tue, 6 Jun 2006 23:32:24 +0200
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
Message-ID: <001601c689b0$bc444d00$0100a8c0@kornelpal.hu>

Hi,

ByteEncoding.GetString() currently uses StringBuilder that is very slow. I 
modified it to use InternalAllocateStr and unsafe code that makes is much 
faster.

Please review and approve the patch.

Korn?l 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ByteEncoding.diff
Type: application/octet-stream
Size: 3410 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060606/f4b88fed/attachment.obj 

From robertj at gmx.net  Tue Jun  6 20:45:55 2006
From: robertj at gmx.net (Robert Jordan)
Date: Wed, 07 Jun 2006 02:45:55 +0200
Subject: [Mono-dev] [PATCH] NET_2_0 Serialization Callbacks
Message-ID: <e657k2$ktq$1@sea.gmane.org>

Hey,

I've attached the patches to this bug:

http://bugzilla.ximian.com/show_bug.cgi?id=78594

The code could be used for 1.1 as well (the 1.1 support
is commented out). However, as Lluis wrote, the
formatters must cope with these changes. Ours do, but
custom formatters do not.

There is an unsolved issue with the callbacks:

MS.NET's Type Loader does not load a type which has
more than one method marked with the same attribute:

The sample

class T
{
	[OnDeserializing]
	void A (StreamingContext ctx)
	{
	}

	[OnDeserializing]
	void B (StreamingContext ctx)
	{
	}
}

leads to a TypeLoadException. The loader also checks whether
the method has the proper signature.

Where do we implement this?

Robert



From miguel at ximian.com  Wed Jun  7 00:48:29 2006
From: miguel at ximian.com (Miguel de Icaza)
Date: Wed, 07 Jun 2006 00:48:29 -0400
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
In-Reply-To: <001601c689b0$bc444d00$0100a8c0@kornelpal.hu>
References: <001601c689b0$bc444d00$0100a8c0@kornelpal.hu>
Message-ID: <1149655709.6167.156.camel@linux.site>

Hello Kornel,

> ByteEncoding.GetString() currently uses StringBuilder that is very slow. I 
> modified it to use InternalAllocateStr and unsafe code that makes is much 
> faster.
> 
> Please review and approve the patch.

Am not sure that poking at the internals and using InternalAllocateStr
is a good idea.   One possibility would be to use "Friend Assemblies",
although that is only supported in the 2.0 profile, not in 1.0.

Although today Mono does not enforce at runtime accessibility, this is
something that we intend to fix, which means that access to internal
methods will at some point broken.   So this would be one of those
things we would have to fix.

(Today we do violate this rule when using dynamic method invocation, and
we would have to find solutions for the places where we do).

Miguel.


From miguel at ximian.com  Wed Jun  7 01:07:45 2006
From: miguel at ximian.com (Miguel de Icaza)
Date: Wed, 07 Jun 2006 01:07:45 -0400
Subject: [Mono-dev] Re: Serialization strategies for compatibility.
In-Reply-To: <e614uc$je0$1@sea.gmane.org>
References: <1149482532.12303.900.camel@linux.site>
	<e614uc$je0$1@sea.gmane.org>
Message-ID: <1149656865.6167.162.camel@linux.site>

Hello!

> I've implemented 2.0 serialization a couple of days ago. It still
> needs some unit tests and a complete interoperatibility test.
> I'll finish them by the end of the week, if I'll not discover
> that the reflective approach of calling the new hooks is
> too slow ... (see below).

That is fantastic, I was going to put that on my todo list.

I saw the bug report with the patch (78594)

> > 	* The new hooks do not cope well with differently-named fields.
> 
> Indeed, it's a bit clumsy:

I guess am hoping that we will reach the consensus that "Sprinkling
ISerializable on [Serializable] classes that we cant make compatible is
OK".

> I'd go for an extra attribute that could be attached on
> the type (like [Serialized]), and that expects the same
> semantics like ISerializable (method GetObjectData and
> ctor(SerializationInfo, StreamingContext)).

These lookups are also fairly expensive.

In fact the runtime actually "fakes" [Serializable] (well, they call
them synthesized attributes, or something like that), and the
"Serializable" bit is actually turned into a bit in the method
definition for fast lookup.

Miguel.


From miguel at ximian.com  Wed Jun  7 01:34:10 2006
From: miguel at ximian.com (Miguel de Icaza)
Date: Wed, 07 Jun 2006 01:34:10 -0400
Subject: [Mono-dev] Patch for fixing binary search
In-Reply-To: <1149468608.16587.46.camel@diphthong.a-chinaman.com>
References: <1149372284.16587.27.camel@diphthong.a-chinaman.com>
	<1149457306.12700.16.camel@localhost>
	<1149468608.16587.46.camel@diphthong.a-chinaman.com>
Message-ID: <1149658450.6167.164.camel@linux.site>

Hello,

> Good call.
> 
> Here's v2.

It is worth reading Morten Welinder's blog entry follow up.

Miguel


From ympostor at clix.pt  Wed Jun  7 04:09:48 2006
From: ympostor at clix.pt (Ympostor)
Date: Wed, 07 Jun 2006 10:09:48 +0200
Subject: [Mono-dev] [OT] Thread hijacking (was: Re: mono-service again)
In-Reply-To: <08bc01c6899f$ea9eaa30$c900a8c0@beardtongue>
References: <735F04A99D358E468A16EDB64FC0455503616B34@EVS1.napier-mail.napier.ac.uk>	<295e750a0606061106w4ac93aeak680944295cd07174@mail.gmail.com>
	<08bc01c6899f$ea9eaa30$c900a8c0@beardtongue>
Message-ID: <448689CC.5080502@clix.pt>

pablosantosluac at terra.es escribi?:
> Hi all,
> ...

Hello. Sorry for the Off-Topic but this is the second message from you 
in which I see you are making Thread Hijacking [1].

For the cleanliness of the list, please stop doing it.

Regards.

-- 
[1] http://en.wikipedia.org/wiki/Thread_hijacking



From kornelpal at gmail.com  Wed Jun  7 04:59:26 2006
From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=)
Date: Wed, 7 Jun 2006 10:59:26 +0200
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
References: <001601c689b0$bc444d00$0100a8c0@kornelpal.hu>
	<1149655709.6167.156.camel@linux.site>
Message-ID: <005901c68a10$afa39140$0100a8c0@kornelpal.hu>

Hi,

I understand the nature of your problem, but I if you are speaking about CAS 
I think it is not a so big problem. SRE is intended to access non-public 
members as well as public members. When enabling security 
ReflectionPermission controls whether code can access private members of 
other assemblies but this should not be a problem as I18N is part of the 
class library so it can have FullTrust without problems. Problems may occur 
in case of executable like mcs.exe but when signing them and granting them 
FullTrust based on public key there should not be problems. Of course 
granting full trust to a public key whose private key is public may may 
imply security problems but this could be solved by restricting the scope of 
this key to the directories of Mono.

Note that I attached a corrected patch because the previous one ignored the 
index parameter by mistake.

Some performance tests:

Before:
length, conversion: time
1, byte[]: 11578
1, byte[] int int: 12282
4, byte[]: 12609
4, byte[] int int: 12687
1024, byte[]: 37125
1024, byte[] int int: 37844
1048576, byte[]: 23875
1048576, byte[] int int: 24125

After:
length, conversion: time
1, byte[]: 3235
1, byte[] int int: 3203
4, byte[]: 3734
4, byte[] int int: 3797
1024, byte[]: 13297
1024, byte[] int int: 13234
1048576, byte[]: 5937
1048576, byte[] int int: 5844

The test program is attached.

Korn?l

----- Original Message ----- 
From: "Miguel de Icaza" <miguel at ximian.com>
To: "Korn?l P?l" <kornelpal at gmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, June 07, 2006 6:48 AM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()


> Hello Kornel,
>
>> ByteEncoding.GetString() currently uses StringBuilder that is very slow. 
>> I
>> modified it to use InternalAllocateStr and unsafe code that makes is much
>> faster.
>>
>> Please review and approve the patch.
>
> Am not sure that poking at the internals and using InternalAllocateStr
> is a good idea.   One possibility would be to use "Friend Assemblies",
> although that is only supported in the 2.0 profile, not in 1.0.
>
> Although today Mono does not enforce at runtime accessibility, this is
> something that we intend to fix, which means that access to internal
> methods will at some point broken.   So this would be one of those
> things we would have to fix.
>
> (Today we do violate this rule when using dynamic method invocation, and
> we would have to find solutions for the places where we do).
>
> Miguel. 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ByteEncodingPerformance.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060607/f88bfc94/attachment.pl 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ByteEncoding.diff
Type: application/octet-stream
Size: 3360 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060607/f88bfc94/attachment.obj 

From paul at all-the-johnsons.co.uk  Wed Jun  7 05:24:04 2006
From: paul at all-the-johnsons.co.uk (PFJ)
Date: Wed, 07 Jun 2006 10:24:04 +0100
Subject: [Mono-dev] Passing values into the default.build boo script
Message-ID: <1149672244.14694.15.camel@mrwibble.mrwobble>

Hi,

Is there a way to pass values into the default.build script for
boo-0.7.6.2237?

I'm packaging it for Fedora Extras and it's a pain to have to manually
edit the default.build, create a patch, apply the patch etc each time I
alter the spec file (or some other part of the package).

Usually on a spec file, I can define things like bindir, libdir etc and
pass them directly in as they're accepted parameters for make. nant is a
different kettle of fish, so some guidance would be appreciated.

TTFN

Paul
-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who



From js at hotfeet.ch  Wed Jun  7 05:45:04 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Wed, 07 Jun 2006 11:45:04 +0200
Subject: [Mono-dev] Patch for HttpException.cs
Message-ID: <1149673505.3038.11.camel@leonardo.hotfeet.ch>

Hi,

The attached patch "beautifies" the complication error page. If multiple
errors were shown, they all appeared on a single line. The patch puts
them on separate lines.

May I commit (with changelog entry, of course)?

- Juraj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HttpException.patch
Type: text/x-patch
Size: 792 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060607/e0cff855/attachment.bin 

From kostat at mainsoft.com  Wed Jun  7 05:59:08 2006
From: kostat at mainsoft.com (Konstantin Triger)
Date: Wed, 7 Jun 2006 02:59:08 -0700
Subject: [Mono-dev] [PATCH] Fix bubbling GridRowView events
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03136736@dhost002-45.dex002.intermedia.net>

Hello,

 

While bubbling the GridRowView events, we assume that the row index comes from CommandArgument, what is not the case.

The attached patch sets this index from GridRowView if CommandArgument does not contain this information.

 

If no one objects I?ll commit.

 

Regards,

Konstantin Triger

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060607/c929d079/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gridviewbubble.patch
Type: application/octet-stream
Size: 663 bytes
Desc: gridviewbubble.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060607/c929d079/attachment.obj 

From pablosantosluac at terra.es  Wed Jun  7 06:06:41 2006
From: pablosantosluac at terra.es (pablosantosluac at terra.es)
Date: Wed, 7 Jun 2006 12:06:41 +0200
Subject: [Mono-dev] mono-service again (BUG FIX)
References: <735F04A99D358E468A16EDB64FC0455503616B34@EVS1.napier-mail.napier.ac.uk>	<295e750a0606061106w4ac93aeak680944295cd07174@mail.gmail.com><08bc01c6899f$ea9eaa30$c900a8c0@beardtongue>
	<448689CC.5080502@clix.pt>
Message-ID: <09a501c68a1a$134af4a0$c900a8c0@beardtongue>

Hi,

First of all I don't understand why I'm supposed to be doing 
thread-hijacking. Is not this the place to post questions about 
mono-service?

Anyway, it seems there is a bug in mono-service. Whenever it tries to launch 
a service application it raises an exception in mono-service.cs at method 
StartService.

The code is doing something like:

string [] service_args = new string [0];

entry.Invoke(null, service_args);


return 0;

And it raises the exception I posted in a previous email.

Doing the following:

string [] service_args = new string [0];

object[] obj = new object[1];

obj[0] = service_args;

entry.Invoke(null, obj);


return 0;



The problem seems to be solved.

I replaced the mono-service.exe on my Fedora4/mono-1.1.15 and now it works.

Regards,



pablo



----- Original Message ----- 
From: "Ympostor" <ympostor at clix.pt>
To: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, June 07, 2006 10:09 AM
Subject: [Mono-dev] [OT] Thread hijacking (was: Re: mono-service again)


> pablosantosluac at terra.es escribi?:
>> Hi all,
>> ...
>
> Hello. Sorry for the Off-Topic but this is the second message from you in 
> which I see you are making Thread Hijacking [1].
>
> For the cleanliness of the list, please stop doing it.
>
> Regards.
>
> -- 
> [1] http://en.wikipedia.org/wiki/Thread_hijacking
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list 



From rchavik at attglobal.net  Wed Jun  7 06:55:40 2006
From: rchavik at attglobal.net (Rachman Chavik)
Date: Wed, 07 Jun 2006 17:55:40 +0700
Subject: [Mono-dev] mono-service again (BUG FIX)
In-Reply-To: <09a501c68a1a$134af4a0$c900a8c0@beardtongue>
References: <735F04A99D358E468A16EDB64FC0455503616B34@EVS1.napier-mail.napier.ac.uk>	<295e750a0606061106w4ac93aeak680944295cd07174@mail.gmail.com><08bc01c6899f$ea9eaa30$c900a8c0@beardtongue>	<448689CC.5080502@clix.pt>
	<09a501c68a1a$134af4a0$c900a8c0@beardtongue>
Message-ID: <4486B0AC.1090702@attglobal.net>

He's referring to http://en.wikipedia.org/wiki/Thread_hijacking.

Excerpts from that site:
Many people find that they are scolded on a list or newsgroup for thread
hijacking despite the fact that they changed the subject line, which
would seem to them to create a new thread. Most news and mail readers
use other headers such as References: to track and build the thread of
messages by message ID, and changing the subject line does not change
the actual threading.

Regards,


pablosantosluac at terra.es wrote:
> Hi,
> 
> First of all I don't understand why I'm supposed to be doing
> thread-hijacking. Is not this the place to post questions about
> mono-service?
> 
> Anyway, it seems there is a bug in mono-service. Whenever it tries to
> launch a service application it raises an exception in mono-service.cs
> at method StartService.
> 
> The code is doing something like:
> 
> string [] service_args = new string [0];
> 
> entry.Invoke(null, service_args);
> 
> 
> return 0;
> 
> And it raises the exception I posted in a previous email.
> 
> Doing the following:
> 
> string [] service_args = new string [0];
> 
> object[] obj = new object[1];
> 
> obj[0] = service_args;
> 
> entry.Invoke(null, obj);
> 
> 
> return 0;
> 
> 
> 
> The problem seems to be solved.
> 
> I replaced the mono-service.exe on my Fedora4/mono-1.1.15 and now it works.
> 
> Regards,
> 
> 
> 
> pablo
> 
> 
> 
> ----- Original Message ----- From: "Ympostor" <ympostor at clix.pt>
> To: <mono-devel-list at lists.ximian.com>
> Sent: Wednesday, June 07, 2006 10:09 AM
> Subject: [Mono-dev] [OT] Thread hijacking (was: Re: mono-service again)
> 
> 
>> pablosantosluac at terra.es escribi?:
>>> Hi all,
>>> ...
>>
>> Hello. Sorry for the Off-Topic but this is the second message from you
>> in which I see you are making Thread Hijacking [1].
>>
>> For the cleanliness of the list, please stop doing it.
>>
>> Regards.
>>
>> -- 
>> [1] http://en.wikipedia.org/wiki/Thread_hijacking
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


-- 
Rachman Chavik
email: rchavik at attglobal.net
email: rachman at chavik.com
email: rchavik at etc-group.com
www: http://www.chavik.com


From pablosantosluac at terra.es  Wed Jun  7 07:05:18 2006
From: pablosantosluac at terra.es (pablosantosluac at terra.es)
Date: Wed, 7 Jun 2006 13:05:18 +0200
Subject: [Mono-dev] mono-service possible bug fix
Message-ID: <09d901c68a22$43b19330$c900a8c0@beardtongue>

Hi all,

Sorry for my previous thread hijacking. Didn't realize about it.

Well, it seems there is a bug in mono-service. Whenever it tries to
launch a service application it raises an exception in mono-service.cs
at method StartService.

The code is doing something like:

string [] service_args = new string [0];

entry.Invoke(null, service_args);

 return 0;

And it raises the exception "Number of parameter does not match expected 
count"

 Doing the following changes the problem seems to be solved.


string [] service_args = new string [0];

 object[] obj = new object[1];

 obj[0] = service_args;

 entry.Invoke(null, obj);


return 0;



I replaced the mono-service.exe on my Fedora4/mono-1.1.15 and now it works.

Regards,


 pablo



From joerg.rosenkranz at gmail.com  Wed Jun  7 07:41:12 2006
From: joerg.rosenkranz at gmail.com (=?ISO-8859-1?Q?J=F6rg_Rosenkranz?=)
Date: Wed, 7 Jun 2006 13:41:12 +0200
Subject: [Mono-dev] mono-service again (BUG FIX)
In-Reply-To: <09a501c68a1a$134af4a0$c900a8c0@beardtongue>
References: <735F04A99D358E468A16EDB64FC0455503616B34@EVS1.napier-mail.napier.ac.uk>
	<295e750a0606061106w4ac93aeak680944295cd07174@mail.gmail.com>
	<08bc01c6899f$ea9eaa30$c900a8c0@beardtongue>
	<448689CC.5080502@clix.pt>
	<09a501c68a1a$134af4a0$c900a8c0@beardtongue>
Message-ID: <cebf8d110606070441g2afd1050n6ee93eb61614fcd1@mail.gmail.com>

Hi Pablo,

Thanks for spotting this bug. I don't have a test environment here so
could you please test if the following change works for you too?

    entry.Invoke (null, null);

I have attached a patch to change this line.
How is the entry point of your service defined? My services always
worked with this implementation of mono-service. The Main function
looks like:

    static void Main()

Joerg.


2006/6/7, pablosantosluac at terra.es <pablosantosluac at terra.es>:
> Anyway, it seems there is a bug in mono-service. Whenever it tries to launch
> a service application it raises an exception in mono-service.cs at method
> StartService.
>
> The code is doing something like:
>
> string [] service_args = new string [0];
>
> entry.Invoke(null, service_args);
>
>
> return 0;
>
> And it raises the exception I posted in a previous email.
>
> Doing the following:
>
> string [] service_args = new string [0];
>
> object[] obj = new object[1];
>
> obj[0] = service_args;
>
> entry.Invoke(null, obj);
>
>
> return 0;
>
>
>
> The problem seems to be solved.
>
> I replaced the mono-service.exe on my Fedora4/mono-1.1.15 and now it works.
>
> Regards,
>
>
>
> pablo
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mono-service.patch
Type: application/octet-stream
Size: 350 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060607/ff6b80fb/attachment.obj 

From robertj at gmx.net  Wed Jun  7 07:51:59 2006
From: robertj at gmx.net (Robert Jordan)
Date: Wed, 07 Jun 2006 13:51:59 +0200
Subject: [Mono-dev] [PATCH] Re: mono-service possible bug fix
In-Reply-To: <09d901c68a22$43b19330$c900a8c0@beardtongue>
References: <09d901c68a22$43b19330$c900a8c0@beardtongue>
Message-ID: <e66el0$ekh$1@sea.gmane.org>

pablosantosluac at terra.es wrote:
> Hi all,
> 
> Sorry for my previous thread hijacking. Didn't realize about it.
> 
> Well, it seems there is a bug in mono-service. Whenever it tries to
> launch a service application it raises an exception in mono-service.cs
> at method StartService.
> 
> The code is doing something like:
> 
> string [] service_args = new string [0];
> 
> entry.Invoke(null, service_args);
> 
> return 0;
> 
> And it raises the exception "Number of parameter does not match expected 
> count"
> 
> Doing the following changes the problem seems to be solved.
> 
> 
> string [] service_args = new string [0];
> 
> object[] obj = new object[1];
> 
> obj[0] = service_args;
> 
> entry.Invoke(null, obj);
> 
> 
> return 0;
> 
> 
> 
> I replaced the mono-service.exe on my Fedora4/mono-1.1.15 and now it works.

It might work with your service but it fails if the service
assembly has an entry point with an empty parameter list
(static void Main ()).

The attached patch works for both entry points.

Robert

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mono-service.diff
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060607/4e4cc392/attachment.pl 

From kornelpal at gmail.com  Wed Jun  7 07:58:00 2006
From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=)
Date: Wed, 7 Jun 2006 13:58:00 +0200
Subject: [Mono-dev] [PATCH] mono-service: Use AppDomain.ExecuteAssembly
	instead of MethodInfo.Invoke
Message-ID: <001601c68a29$a423a710$0100a8c0@kornelpal.hu>

Hi,

This fixes the bug reported by Pablo. AppDomain.ExecuteAssembly uses the 
same method to execute the assembly as the runtime so assemblies that can be 
executed using the runtime are guaranted to be executable by mono-service as 
well.

Please review and approve the patch.

Pablo: Please try this patch. (Use patch < mono-service.diff in the 
directory of mono-service.cs. Also note that you should patch the original 
mono-service.cs rather than your version.)

Korn?l 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mono-service.diff
Type: application/octet-stream
Size: 1121 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060607/5b766f21/attachment.obj 

From pablosantosluac at terra.es  Wed Jun  7 08:12:23 2006
From: pablosantosluac at terra.es (pablosantosluac at terra.es)
Date: Wed, 7 Jun 2006 14:12:23 +0200
Subject: [Mono-dev] Re: [PATCH] mono-service: Use AppDomain.ExecuteAssembly
	instead of MethodInfo.Invoke
References: <001601c68a29$a423a710$0100a8c0@kornelpal.hu>
Message-ID: <0a3901c68a2b$a282b660$c900a8c0@beardtongue>

Hi,

It works for me! :-)

Thanks,

pablo

----- Original Message ----- 
From: "Korn?l P?l" <kornelpal at gmail.com>
To: <mono-devel-list at lists.ximian.com>
Cc: <pablosantosluac at terra.es>
Sent: Wednesday, June 07, 2006 1:58 PM
Subject: [PATCH] mono-service: Use AppDomain.ExecuteAssembly instead of 
MethodInfo.Invoke


> Hi,
>
> This fixes the bug reported by Pablo. AppDomain.ExecuteAssembly uses the
> same method to execute the assembly as the runtime so assemblies that can 
> be
> executed using the runtime are guaranted to be executable by mono-service 
> as
> well.
>
> Please review and approve the patch.
>
> Pablo: Please try this patch. (Use patch < mono-service.diff in the
> directory of mono-service.cs. Also note that you should patch the original
> mono-service.cs rather than your version.)
>
> Korn?l
> 



From joerg.rosenkranz at gmail.com  Wed Jun  7 08:25:53 2006
From: joerg.rosenkranz at gmail.com (=?ISO-8859-1?Q?J=F6rg_Rosenkranz?=)
Date: Wed, 7 Jun 2006 14:25:53 +0200
Subject: [Mono-dev] [PATCH] mono-service: Use AppDomain.ExecuteAssembly
	instead of MethodInfo.Invoke
In-Reply-To: <001601c68a29$a423a710$0100a8c0@kornelpal.hu>
References: <001601c68a29$a423a710$0100a8c0@kornelpal.hu>
Message-ID: <cebf8d110606070525p2baa1848ndbfa7cd42a710c90@mail.gmail.com>

Hi Kornel,

2006/6/7, Korn?l P?l <kornelpal at gmail.com>:
>
> This fixes the bug reported by Pablo. AppDomain.ExecuteAssembly uses the
> same method to execute the assembly as the runtime so assemblies that can be
> executed using the runtime are guaranted to be executable by mono-service as
> well.
>

I have no objections if this leaves the callback and the signal handlers intact.

Joerg.


From kornelpal at gmail.com  Wed Jun  7 08:47:09 2006
From: kornelpal at gmail.com (=?ISO-8859-1?B?S29ybulsIFDhbA==?=)
Date: Wed, 7 Jun 2006 14:47:09 +0200
Subject: [Mono-dev] [PATCH] mono-service: Use AppDomain.ExecuteAssembly
	instead of MethodInfo.Invoke
References: <001601c68a29$a423a710$0100a8c0@kornelpal.hu>
	<cebf8d110606070525p2baa1848ndbfa7cd42a710c90@mail.gmail.com>
Message-ID: <004b01c68a30$84ea9ff0$0100a8c0@kornelpal.hu>

Hi,

Neither the callback nor the signal handlers are affected so I committed the 
patch. Note that evidence is affected by the method so added 
AppDomain.CurrentDomain.Evidence parameter to ensure that evidence is not 
changed altough currently it has no effect because the default evidence is 
used.

Korn?l

----- Original Message ----- 
From: "J?rg Rosenkranz" <joerg.rosenkranz at gmail.com>
To: "Korn?l P?l" <kornelpal at gmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, June 07, 2006 2:25 PM
Subject: Re: [Mono-dev] [PATCH] mono-service: Use AppDomain.ExecuteAssembly 
instead of MethodInfo.Invoke


Hi Kornel,

2006/6/7, Korn?l P?l <kornelpal at gmail.com>:
>
> This fixes the bug reported by Pablo. AppDomain.ExecuteAssembly uses the
> same method to execute the assembly as the runtime so assemblies that can 
> be
> executed using the runtime are guaranted to be executable by mono-service 
> as
> well.
>

I have no objections if this leaves the callback and the signal handlers 
intact.

Joerg. 



From cristian.vanti at tiscali.it  Wed Jun  7 09:37:28 2006
From: cristian.vanti at tiscali.it (Cristian Vanti)
Date: Wed, 07 Jun 2006 15:37:28 +0200
Subject: [Mono-dev] [Fwd: Got SIGSEGV on Response.Redirect]
Message-ID: <4486D698.7050608@tiscali.it>


I always get a SIGSEGV in a simple aspx method doing a Response.Redirect

this is the code (VB compiled with VisualStudio2003)

Private Sub cmdCancel_Click(ByVal sender As Object, ByVal e As 
EventArgs) Handles cmdCancel.Click
 Try
   Response.Redirect(NavigateURL(), True)
 Catch exc As Exception             'Module failed to load
   ProcessModuleLoadException(Me, exc)
 End Try
End Sub

(I tried Redirect(url,False) with same results)

and this is what I get:
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

Stacktrace:

in DotNetNuke.Modules.Links.EditLinks:cmdCancel_Click 
(object,System.EventArgs) <0xffffffff>
in DotNetNuke.Modules.Links.EditLinks:cmdCancel_Click 
(object,System.EventArgs) <0x5a>
in (wrapper delegate-invoke) 
System.MulticastDelegate:invoke_void_object_EventArgs 
(object,System.EventArgs) <0x154e2d8>
in System.Web.UI.WebControls.LinkButton:OnClick (System.EventArgs) <0x50>
in 
System.Web.UI.WebControls.LinkButton:System.Web.UI.IPostBackEventHandler.RaisePostBackEvent 
(string) <0x45>
in System.Web.UI.Page:RaisePostBackEvent 
(System.Web.UI.IPostBackEventHandler,string) <0x13>
in System.Web.UI.Page:RaisePostBackEvents () <0x11d>
in System.Web.UI.Page:InternalProcessRequest () <0x1ee>
in System.Web.UI.Page:ProcessRequest (System.Web.HttpContext) <0xa1>
in <Pipeline>__1:MoveNext () <0xfe3>
in System.Web.HttpApplication:Tick () <0x1c>
in System.Web.HttpApplication:Start (object) <0xcf>
in 
System.Web.HttpApplication:System.Web.IHttpAsyncHandler.BeginProcessRequest 
(System.Web.HttpContext,System.AsyncCallback,object) <0x68>
in System.Web.HttpRuntime:RealProcessRequest (object) <0x1a8>
in System.Web.HttpRuntime:ProcessRequest (System.Web.HttpWorkerRequest) 
<0x2c>
in Mono.WebServer.MonoWorkerRequest:ProcessRequest () <0xa>
in Mono.WebServer.BaseApplicationHost:ProcessRequest 
(Mono.WebServer.MonoWorkerRequest) <0x43>
in Mono.WebServer.XSPApplicationHost:ProcessRequest 
(int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) 
<0x37f>
in (wrapper remoting-invoke-with-check) 
Mono.WebServer.XSPApplicationHost:ProcessRequest 
(int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) 
<0xfffffab2>
in (wrapper xdomain-dispatch) 
Mono.WebServer.XSPApplicationHost:ProcessRequest 
(object,byte[]&,byte[]&,int,long,int,long,int,string,string,string,string,byte[],string) 
<0xfffee3be>
in (wrapper xdomain-invoke) 
Mono.WebServer.XSPApplicationHost:ProcessRequest 
(int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) 
<0xffffff3d>
in (wrapper remoting-invoke-with-check) 
Mono.WebServer.XSPApplicationHost:ProcessRequest 
(int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) 
<0xffcdfc7b>
in Mono.WebServer.XSPWorker:InnerRun (object) <0x563>
in Mono.WebServer.XSPWorker:Run (object) <0x22>
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object 
(object) <0xffffff95>
in (wrapper runtime-invoke) System.Object:runtime_invoke_void_object 
(object,intptr,intptr,intptr) <0x7e89867>

Native stacktrace:

       /usr/bin/mono(mono_handle_native_sigsegv+0xbb) [0x8153d0b]
       /usr/bin/mono [0x813e66f]
       /lib/tls/libpthread.so.0 [0xae3880]
       /usr/bin/mono(mono_branch_optimize_exception_target+0xdf) 
[0x815473f]
       /usr/bin/mono(mono_arch_output_basic_block+0x22af) [0x80690ff]
       /usr/bin/mono(mono_codegen+0xa5) [0x813c475]
       /usr/bin/mono [0x813d217]
       /usr/bin/mono [0x813dc5e]
       /usr/bin/mono [0x813e0c2]
       /usr/bin/mono [0x813e25a]
       /usr/bin/mono(mono_compile_method+0x3a) [0x80d636a]
       /usr/bin/mono(mono_magic_trampoline+0x1a) [0x815519a]
       [0x60e032]
       [0x1e90592]
       [0x33de829]
       [0x33de766]
       [0x1a15ad4]
       [0x1a15aae]
       [0x5a3fe57]
       [0x5a3cd82]
       [0x1e8f124]
       [0x1e8e085]
       [0x1e890d8]
       [0x1e88f21]
       [0x75c719]
       [0x75c24d]
       [0x75c20b]
       [0x75bd2c]
       [0x5e8d48]
       [0x5e8169]
       [0x5e7ab3]
       [0x5d5b67]
       [0x5d597e]
       [0x2b54fc]
       [0x2b4dd3]
       [0x2b4d8c]
       [0x2b4ce6]
       /usr/bin/mono [0x813e520]
       /usr/bin/mono(mono_runtime_invoke+0x27) [0x80d7b67]
       /usr/bin/mono(mono_runtime_invoke_array+0x270) [0x80d9050]
       /usr/bin/mono(mono_message_invoke+0xc5) [0x80dac15]
       /usr/bin/mono [0x80a611f]
       /usr/bin/mono [0x80a6949]
       /usr/bin/mono [0x809a922]
       /usr/bin/mono [0x80f6ef7]
       /usr/bin/mono [0x8115ba5]
       /lib/tls/libpthread.so.0 [0xadd371]
       /lib/tls/libc.so.6(__clone+0x5e) [0x1d99be]

I use Centos 4.1 and Mono 1.1.15.0

Please, help me.

bye
cristian




From gonzalo at novell.com  Wed Jun  7 11:02:04 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Wed, 07 Jun 2006 11:02:04 -0400
Subject: [Mono-dev] Patch for HttpException.cs
In-Reply-To: <1149673505.3038.11.camel@leonardo.hotfeet.ch>
References: <1149673505.3038.11.camel@leonardo.hotfeet.ch>
Message-ID: <1149692524.4133.10.camel@lalo.micasa>

On Wed, 2006-06-07 at 11:45 +0200, Juraj Skripsky wrote:
> Hi,
> 
> The attached patch "beautifies" the complication error page. If multiple
> errors were shown, they all appeared on a single line. The patch puts
> them on separate lines.
> 
> May I commit (with changelog entry, of course)?

Please, commit.
Thanks.

-Gonzalo




From brilliantjoe at gmail.com  Wed Jun  7 12:04:00 2006
From: brilliantjoe at gmail.com (Joey Libby)
Date: Wed, 7 Jun 2006 13:04:00 -0300
Subject: [Mono-dev] Resolving RVA of method calls in external libraries
Message-ID: <e08d115a0606070904i4bdfc353ja328eb433f0296d1@mail.gmail.com>

Hi, I was wondering if anyone could explaint to me how the metadata tokens
that point to a method in an external library are resolved to find the
metadata entry for that method in the given library and from that the RVA of
the method. All I currently see is that there is a reference to the name and
library name in the metadata of the main cli program. Thanks in advance.

-- 
Joey Libby
MCS Program
University of New Brunswick
Fredericton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060607/4fce7eb5/attachment.html 

From eyala at mainsoft.com  Wed Jun  7 12:04:22 2006
From: eyala at mainsoft.com (Eyal Alaluf)
Date: Wed, 7 Jun 2006 19:04:22 +0300 (IDT)
Subject: [Mono-Dev] Cecil bug with Custom Attributes with enum parameters
Message-ID: <Pine.GSO.4.60.0606071837470.13367@yen>

Hi, JB.

I stumbled upon a critical problem with custom attributes that have enums in their
ctor.  For instance:
     [System.AttributeUsage(System.AttributeTargets.Class,AllowMultiple=true)]
The problem is as follows -
     * Custom attribute signatures aren't self contained. They depend on
       interpreting the parameters of the custom attribute ctor referenced in the
       signature.
     * If a parameter is an int32 then 4 bytes in little endian are read, etc.
     * If the parameter is an enum - one has to find out the enum underlying type
       and read the value from the Blob according to its underlying type (e.g. int).
     * Now when the enum comes from another assembly, Cecil only has a TypeReference
       to it and actually has no idea that it's an enum and definitely not what
       is the underlying type.
     * The code at Mono.Cecil.Signatures/SignatureReader.cs:746 method
       CustomAttrib.Elem ReadElem (byte [] data, BinaryReader br,
                                   TypeReferenceelemType, ref bool read) says:
         default : // enum
             read = false;
             return elem;
       which means that the custom attribute is not fully processed.
     * The result is that we get a CustomAttribute without the values for the ctor
       parameters and without the values for the named parameters.

I understand that the main difficulty is that the only way to find the enum's
underlying type is to actually load the enum's assembly (which could be another
assembly then the currently processed assembly).
We are currently doing this for all TypeReferences we encounter. We are using Cecil
itself to load the referenced assembly and look for the referenced type. Currently
Cecil tries to process each assembly independently of other assemblies and this
goes strongly against this design.

Do you have any plans to resolve this issue? (I assume from the comment in the code
that you are familiar with it)
What is the design you are looking for in this case? If you want to have Cecil
loading the Enum we can contribute our Resolver that is Cecil based.

Thanks, Eyal.


From zac at zacbowling.com  Wed Jun  7 12:38:08 2006
From: zac at zacbowling.com (Zac Bowling)
Date: Wed, 07 Jun 2006 11:38:08 -0500
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
In-Reply-To: <001601c689b0$bc444d00$0100a8c0@kornelpal.hu>
References: <001601c689b0$bc444d00$0100a8c0@kornelpal.hu>
Message-ID: <1149698288.13518.3.camel@localhost.localdomain>

Cute. The second function doesn't look like it needs to be marked unsafe
though. 

On Tue, 2006-06-06 at 23:32 +0200, Korn?l P?l wrote:
> Hi,
> 
> ByteEncoding.GetString() currently uses StringBuilder that is very slow. I 
> modified it to use InternalAllocateStr and unsafe code that makes is much 
> faster.
> 
> Please review and approve the patch.
> 
> Korn?l 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-- 
Zac Bowling <zac at zacbowling.com>



From kornelpal at gmail.com  Wed Jun  7 12:42:50 2006
From: kornelpal at gmail.com (=?iso-8859-1?B?S29ybulsIFDhbA==?=)
Date: Wed, 7 Jun 2006 18:42:50 +0200
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
References: <001601c689b0$bc444d00$0100a8c0@kornelpal.hu>
	<1149698288.13518.3.camel@localhost.localdomain>
Message-ID: <00c401c68a51$6b740ef0$0100a8c0@kornelpal.hu>

Hi,

Right.:) But I posted a modified version in the response (the list is CC) to 
Miguel's objections because I forgot to deal with the index parameter. And 
this unnecessary unsafe marker is removed from that updated version. The 
message also includes a performance comparsion.

Korn?l

----- Original Message ----- 
From: "Zac Bowling" <zac at zacbowling.com>
To: "Korn?l P?l" <kornelpal at gmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, June 07, 2006 6:38 PM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()


> Cute. The second function doesn't look like it needs to be marked unsafe
> though.
>
> On Tue, 2006-06-06 at 23:32 +0200, Korn?l P?l wrote:
>> Hi,
>>
>> ByteEncoding.GetString() currently uses StringBuilder that is very slow. 
>> I
>> modified it to use InternalAllocateStr and unsafe code that makes is much
>> faster.
>>
>> Please review and approve the patch.
>>
>> Korn?l
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> -- 
> Zac Bowling <zac at zacbowling.com>
> 



From mono at evain.net  Wed Jun  7 13:59:12 2006
From: mono at evain.net (Jb Evain)
Date: Wed, 07 Jun 2006 19:59:12 +0200
Subject: [Mono-Dev] Cecil bug with Custom Attributes with enum parameters
In-Reply-To: <Pine.GSO.4.60.0606071837470.13367@yen>
References: <Pine.GSO.4.60.0606071837470.13367@yen>
Message-ID: <448713F0.6020508@evain.net>

Hi Eyal,

 > Do you have any plans to resolve this issue? (I assume from the comment
 > in the code
 > that you are familiar with it)
 > What is the design you are looking for in this case? If you want to have
 > Cecil
 > loading the Enum we can contribute our Resolver that is Cecil based.

The plan is indeed to load the assembly which contains the type 
definition. If you can contribute your resolver, I'll see how I can 
integrate it. Then I'll add some kind of ForceLoad method if the custom 
attribute is not readable at first try.

Thanks,

Jb



From zac at zacbowling.com  Wed Jun  7 18:34:48 2006
From: zac at zacbowling.com (Zac Bowling)
Date: Wed, 07 Jun 2006 17:34:48 -0500
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
In-Reply-To: <00c401c68a51$6b740ef0$0100a8c0@kornelpal.hu>
References: <001601c689b0$bc444d00$0100a8c0@kornelpal.hu>
	<1149698288.13518.3.camel@localhost.localdomain>
	<00c401c68a51$6b740ef0$0100a8c0@kornelpal.hu>
Message-ID: <1149719689.13518.5.camel@localhost.localdomain>

opps... your other email didn't get threaded in my evolution. sorry bout
that...

On Wed, 2006-06-07 at 18:42 +0200, Korn?l P?l wrote:
> Hi,
> 
> Right.:) But I posted a modified version in the response (the list is CC) to 
> Miguel's objections because I forgot to deal with the index parameter. And 
> this unnecessary unsafe marker is removed from that updated version. The 
> message also includes a performance comparsion.
> 
> Korn?l
> 
> ----- Original Message ----- 
> From: "Zac Bowling" <zac at zacbowling.com>
> To: "Korn?l P?l" <kornelpal at gmail.com>
> Cc: <mono-devel-list at lists.ximian.com>
> Sent: Wednesday, June 07, 2006 6:38 PM
> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
> 
> 
> > Cute. The second function doesn't look like it needs to be marked unsafe
> > though.
> >
> > On Tue, 2006-06-06 at 23:32 +0200, Korn?l P?l wrote:
> >> Hi,
> >>
> >> ByteEncoding.GetString() currently uses StringBuilder that is very slow. 
> >> I
> >> modified it to use InternalAllocateStr and unsafe code that makes is much
> >> faster.
> >>
> >> Please review and approve the patch.
> >>
> >> Korn?l
> >> _______________________________________________
> >> Mono-devel-list mailing list
> >> Mono-devel-list at lists.ximian.com
> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> > -- 
> > Zac Bowling <zac at zacbowling.com>
> > 
> 
> 
-- 
Zac Bowling <zac at zacbowling.com>



From rusminsusanto at yahoo.com  Wed Jun  7 19:10:58 2006
From: rusminsusanto at yahoo.com (Rusmin Susanto)
Date: Wed, 7 Jun 2006 16:10:58 -0700 (PDT)
Subject: [Mono-dev] C++ code as Internal call
Message-ID: <20060607231058.28099.qmail@web60815.mail.yahoo.com>

As far as I know, Mono is written in C. Internal calls are also written in C. If I have a cool library/package that is written in C++, how do I define it in Mono without having to re-write the library/package in C? I've tried this few times but it seems that it's not working with g++.
   
   
   
  Regards

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060607/54f634b8/attachment.html 

From vargaz at gmail.com  Wed Jun  7 19:35:07 2006
From: vargaz at gmail.com (Zoltan Varga)
Date: Thu, 8 Jun 2006 01:35:07 +0200
Subject: [Mono-dev] C++ code as Internal call
In-Reply-To: <20060607231058.28099.qmail@web60815.mail.yahoo.com>
References: <20060607231058.28099.qmail@web60815.mail.yahoo.com>
Message-ID: <295e750a0606071635p10b0c7b8jc837e8ea9002c2b7@mail.gmail.com>

                                   Hi,

  Read this, especially the section "Invoking Unmanaged Code":

http://www.mono-project.com/Interop_with_Native_Libraries

   Zoltan

On 6/8/06, Rusmin Susanto <rusminsusanto at yahoo.com> wrote:
>
> As far as I know, Mono is written in C. Internal calls are also written in
> C. If I have a cool library/package that is written in C++, how do I define
> it in Mono without having to re-write the library/package in C? I've tried
> this few times but it seems that it's not working with g++.
>
>
>
> Regards
>
>
>  __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>


From usergroup at cornetdesign.com  Wed Jun  7 19:53:08 2006
From: usergroup at cornetdesign.com (Cory Foy)
Date: Wed, 07 Jun 2006 18:53:08 -0500
Subject: [Mono-dev] CurrentCulture Empty?
In-Reply-To: <44830518.8000802@cornetdesign.com>
References: <44830518.8000802@cornetdesign.com>
Message-ID: <448766E4.9050200@cornetdesign.com>

Can anyone provide some info about whether CultureInfo should be 
working? Thanks!

Cory

Cory Foy wrote:
> Hi All,
> 
> We noticed that our tests in NUnit around CultureInfo were failing with 
> an empty culture info. I was going to dig through the Mono source, but 
> CultureInfo is apparantly not the most straightforward thing to pull.
> 
> Do I need to open a bug report on this?
> 
> Thanks!
> 
> Cory
> 
> -----
> 
> foyc at dilbert ~/workspace/monobugs $ mono -V
> Mono JIT compiler version 1.1.15, (C) 2002-2005 Novell, Inc and 
> Contributors. www.mono-project.com
>         TLS:           normal
>         GC:            Included Boehm (with typed GC)
>         SIGSEGV:       normal
>         Disabled:      none
> 
> foyc at dilbert ~/workspace/monobugs $ cat CultureBug.cs
> using System;
> using System.Globalization;
> 
> public class TestCultureInfo
> {
>         public static void Main(String[] args)
>         {
>                 Console.WriteLine("Current Culture: " + 
> CultureInfo.CurrentCulture.ToString());
>                 Console.WriteLine("Current UICulture: " + 
> CultureInfo.CurrentUICulture.ToString());
>         }
> }
> 
> foyc at dilbert ~/workspace/monobugs $ mcs CultureBug.cs
> 
> foyc at dilbert ~/workspace/monobugs $ mono CultureBug.exe
> Current Culture:
> Current UICulture:
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 

-- 
Cory Foy
http://www.cornetdesign.com


From vargaz at gmail.com  Wed Jun  7 20:10:21 2006
From: vargaz at gmail.com (Zoltan Varga)
Date: Thu, 8 Jun 2006 02:10:21 +0200
Subject: [Mono-dev] CurrentCulture Empty?
In-Reply-To: <44830518.8000802@cornetdesign.com>
References: <44830518.8000802@cornetdesign.com>
Message-ID: <295e750a0606071710q2a4c869i4af247a06c667d61@mail.gmail.com>

                  Hi,

  Its not empty, its CultureInfo.InvariantCulture, which has no name, so
ToString () will return an empty string for it.

         Zoltan

On 6/4/06, Cory Foy <usergroup at cornetdesign.com> wrote:
> Hi All,
>
> We noticed that our tests in NUnit around CultureInfo were failing with
> an empty culture info. I was going to dig through the Mono source, but
> CultureInfo is apparantly not the most straightforward thing to pull.
>
> Do I need to open a bug report on this?
>
> Thanks!
>
> Cory
>
> -----
>
> foyc at dilbert ~/workspace/monobugs $ mono -V
> Mono JIT compiler version 1.1.15, (C) 2002-2005 Novell, Inc and
> Contributors. www.mono-project.com
>          TLS:           normal
>          GC:            Included Boehm (with typed GC)
>          SIGSEGV:       normal
>          Disabled:      none
>
> foyc at dilbert ~/workspace/monobugs $ cat CultureBug.cs
> using System;
> using System.Globalization;
>
> public class TestCultureInfo
> {
>          public static void Main(String[] args)
>          {
>                  Console.WriteLine("Current Culture: " +
> CultureInfo.CurrentCulture.ToString());
>                  Console.WriteLine("Current UICulture: " +
> CultureInfo.CurrentUICulture.ToString());
>          }
> }
>
> foyc at dilbert ~/workspace/monobugs $ mcs CultureBug.cs
>
> foyc at dilbert ~/workspace/monobugs $ mono CultureBug.exe
> Current Culture:
> Current UICulture:
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>


From Jonathan.Chambers at ansys.com  Wed Jun  7 22:45:55 2006
From: Jonathan.Chambers at ansys.com (Jonathan S. Chambers)
Date: Wed, 7 Jun 2006 22:45:55 -0400
Subject: [Mono-dev] Marshal.GetComSlotForMethodInfo Patch
Message-ID: <BDBFCADE470D2B4A841D51412D2D915D03FE5632@canonsburgexch2.win.ansys.com>

Here is an implementation (withtests) of Marshal.GetComSlotForMethodInfo. Please review.

Thanks,
Jonathan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: getcomslotformethodinfo.diff
Type: application/octet-stream
Size: 8320 bytes
Desc: getcomslotformethodinfo.diff
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060607/a63a53ab/attachment.obj 

From sdale at rm.com  Thu Jun  8 04:00:48 2006
From: sdale at rm.com (Simon Dale)
Date: Thu, 8 Jun 2006 09:00:48 +0100
Subject: [Mono-dev] CallContext and Remoting
Message-ID: <416F947BF5BA9E40B5F9AA649422212E03DB0813@ex-mail2.internal.rmplc.net>

Hi,
 
I'm trying to create an application where the object being provided by the server can determine the origin of the client. I've not found any way of doing this apart from using a CallContext specified at the client to contain the client's DNS name.
 
I've made this work with Visual Studio 2005, but keep getting an exception when I try to connect to the server with a Mono client. Ideally, the client will be Mono and the server MS .NET.
 
Has anyone done anything similar and experienced similar problems?
 
The exception is pasted below.
 
Thanks,
 
Simon
 
Exception:
 
Unhandled Exception: System.Runtime.Remoting.RemotingException: Server encountered an internal error. For more information, turn off customErrors in the server's .config file.
Server stack trace:

Exception rethrown at [0]:
in <0x006df> System.Runtime.Remoting.Proxies.RealProxy:PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception exc, System.Object[] out_args)
______________________________________________________________________

You might be interested in this...

Professor Tim Brighouse describes the key features shared by successful schools in his new book - Download your copy now

http://www.rm.com/Generic.asp?cref=GP650420&Srcurl=ICS0505
______________________________________________________________________
 
Visit our Website at http://www.rm.com

This message is confidential. You should not copy it or disclose its contents to anyone. You may use and apply the information for the intended purpose only. Internet communications are not secure; therefore, RM does not accept legal responsibility for the contents of this message. Any views or opinions presented are those of the author only and not of RM. If this email has come to you in error, please delete it, along with any attachments. Please note that RM may intercept incoming and outgoing email communications. 

Freedom of Information Act 2000
This email and any attachments may contain confidential information belonging to RM.  Where the email and any attachments do contain information of a confidential nature, including without limitation information relating to trade secrets, special terms or prices these shall be deemed for the purpose of the Freedom of Information Act 2000 as information provided in confidence by RM and the disclosure of which would be prejudicial to RM's commercial interests.

This email has been scanned for viruses by Trend ScanMail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060608/524bc04f/attachment.html 

From dsuarezv at codicesoftware.com  Thu Jun  8 04:31:47 2006
From: dsuarezv at codicesoftware.com (=?iso-8859-1?Q?David_Su=E1rez?=)
Date: Thu, 8 Jun 2006 10:31:47 +0200
Subject: [Mono-dev] CallContext and Remoting
In-Reply-To: <416F947BF5BA9E40B5F9AA649422212E03DB0813@ex-mail2.internal.rmplc.net>
Message-ID: <200606081033512.SM70024@mtrpor01>

Maybe you can turn off customerrors as suggested by the handler, so we can
see more information on the exception. Setup your remoting channel using a
config file like this (modify portnumber). Important part is the
customerrors setting
 
<configuration>
    <system.runtime.remoting>
        <application>
            <channels>
                <channel ref="tcp" port="8084">
                </channel>
            </channels>
        </application>
        <customErrors mode="Off" />
    </system.runtime.remoting>
</configuration>
 
Cheers, 
 
David
 

  _____  

De: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] En nombre de Simon Dale
Enviado el: jueves, 08 de junio de 2006 10:01
Para: mono-devel-list at lists.ximian.com
Asunto: [Mono-dev] CallContext and Remoting


Hi,
 
I'm trying to create an application where the object being provided by the
server can determine the origin of the client. I've not found any way of
doing this apart from using a CallContext specified at the client to contain
the client's DNS name.
 
I've made this work with Visual Studio 2005, but keep getting an exception
when I try to connect to the server with a Mono client. Ideally, the client
will be Mono and the server MS .NET.
 
Has anyone done anything similar and experienced similar problems?
 
The exception is pasted below.
 
Thanks,
 
Simon
 
Exception:
 
Unhandled Exception: System.Runtime.Remoting.RemotingException: Server
encountered an internal error. For more information, turn off customErrors
in the server's .config file.
Server stack trace:

Exception rethrown at [0]:
in <0x006df> System.Runtime.Remoting.Proxies.RealProxy:PrivateInvoke
(System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg,
System.Exception exc, System.Object[] out_args)

You might be interested in this... 
Professor Tim Brighouse describes the key features shared by successful
schools in his new book - Download
<http://www.rm.com/Generic.asp?cref=GP650420&Srcurl=ICS0505> your copy now 

Visit our Website at www.rm.com 

This message is confidential. You should not copy it or disclose its
contents to anyone. You may use and apply the information for the intended
purpose only. Internet communications are not secure; therefore, RM does not
accept legal responsibility for the contents of this message. Any views or
opinions presented are those of the author only and not of RM. If this email
has come to you in error, please delete it, along with any attachments.
Please note that RM may intercept incoming and outgoing email
communications. 

Freedom of Information Act 2000 
This email and any attachments may contain confidential information
belonging to RM. Where the email and any attachments do contain information
of a confidential nature, including without limitation information relating
to trade secrets, special terms or prices these shall be deemed for the
purpose of the Freedom of Information Act 2000 as information provided in
confidence by RM and the disclosure of which would be prejudicial to RM's
commercial interests. 

This email has been scanned for viruses by Trend ScanMail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060608/64e0c7b4/attachment.html 

From jonpryor at vt.edu  Thu Jun  8 07:22:31 2006
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Thu, 08 Jun 2006 07:22:31 -0400
Subject: [Mono-dev] Resolving RVA of method calls in external libraries
In-Reply-To: <e08d115a0606070904i4bdfc353ja328eb433f0296d1@mail.gmail.com>
References: <e08d115a0606070904i4bdfc353ja328eb433f0296d1@mail.gmail.com>
Message-ID: <1149765752.3847.35.camel@melchior.magi>

On Wed, 2006-06-07 at 13:04 -0300, Joey Libby wrote:
> Hi, I was wondering if anyone could explaint to me how the metadata
> tokens that point to a method in an external library are resolved to
> find the metadata entry for that method in the given library and from
> that the RVA of the method. All I currently see is that there is a
> reference to the name and library name in the metadata of the main cli
> program. Thanks in advance. 

The RVA of the target method is never resolved by mono.  The RVA of the
target method is resolved by the operating system's dynamic linker, and
an RVA may in fact never be involved (IIRC ELF doesn't use RVAs, so the
RVA terminology is incorrect under most Unix platforms).

What instead happens is that the method name + library name are
extracted from the assembly metadata, the specified library is loaded
(ultimately via dlopen(3) or LoadLibrary()), and the specified method is
retrieved (ultimately via dlsym(3) or GetProcAddress()).  Mono doesn't
actually using any of these APIs, but instead uses the GModule API
(g_module_open(), g_module_name(), etc.), which in turn uses these
underlying APIs.

 - Jon




From vargaz at gmail.com  Thu Jun  8 08:23:49 2006
From: vargaz at gmail.com (Zoltan Varga)
Date: Thu, 8 Jun 2006 14:23:49 +0200
Subject: [Mono-dev] Marshal.GetComSlotForMethodInfo Patch
In-Reply-To: <BDBFCADE470D2B4A841D51412D2D915D03FE5632@canonsburgexch2.win.ansys.com>
References: <BDBFCADE470D2B4A841D51412D2D915D03FE5632@canonsburgexch2.win.ansys.com>
Message-ID: <295e750a0606080523m6a391a50x6acffaf3b16b555e@mail.gmail.com>

Hi,

This looks ok to check in. Please use 'if (cinfo) {' style indentation.

              Zoltan

On 6/8/06, Jonathan S. Chambers <Jonathan.Chambers at ansys.com> wrote:
> Here is an implementation (withtests) of Marshal.GetComSlotForMethodInfo. Please review.
>
> Thanks,
> Jonathan
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>


From Jonathan.Chambers at ansys.com  Thu Jun  8 09:20:47 2006
From: Jonathan.Chambers at ansys.com (Jonathan S. Chambers)
Date: Thu, 8 Jun 2006 09:20:47 -0400
Subject: [Mono-dev] Marshal.GetComSlotForMethodInfo Patch
Message-ID: <BDBFCADE470D2B4A841D51412D2D915D038CCF27@canonsburgexch2.win.ansys.com>

Committed with style change. Thanks.

- Jonathan

> -----Original Message-----
> From: Zoltan Varga [mailto:vargaz at gmail.com]
> Sent: Thursday, June 08, 2006 8:24 AM
> To: Jonathan S. Chambers
> Cc: Mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-dev] Marshal.GetComSlotForMethodInfo Patch
> 
> Hi,
> 
> This looks ok to check in. Please use 'if (cinfo) {' style
indentation.
> 
>               Zoltan
> 
> On 6/8/06, Jonathan S. Chambers <Jonathan.Chambers at ansys.com> wrote:
> > Here is an implementation (withtests) of
> Marshal.GetComSlotForMethodInfo. Please review.
> >
> > Thanks,
> > Jonathan
> >
> >
> >
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
> >
> >




From kostat at mainsoft.com  Thu Jun  8 11:00:59 2006
From: kostat at mainsoft.com (Konstantin Triger)
Date: Thu, 8 Jun 2006 08:00:59 -0700
Subject: [Mono-dev] [PATCH] System.Web, fix for
	ObjectDataSourceView.OldValuesParameterFormatString
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03136912@dhost002-45.dex002.intermedia.net>

Hello,

 

The attached patch and test case ensure that the default value for OldValuesParameterFormatString is as documented "{0}".

 

If no one objects I'll commit.

 

Regards,

Konstantin Triger

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060608/012b2a8c/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OldValuesParameterFormatString.patch
Type: application/octet-stream
Size: 8010 bytes
Desc: OldValuesParameterFormatString.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060608/012b2a8c/attachment.obj 

From subscription.sapi at apsystems.it  Thu Jun  8 11:37:50 2006
From: subscription.sapi at apsystems.it (APS)
Date: Thu, 08 Jun 2006 17:37:50 +0200
Subject: [Mono-dev] Invalid escape selecting table rows
Message-ID: <7.0.0.16.0.20060608171626.00adfa68@apsystems.it>

Hi guys,
I've a datatable containing a list of urls.
I select them using

Tables[0].Select("(PAGE='\wsngmono\Categ.aspx' OR 
PAGE='/wsngmono/Categ.aspx') AND (CONTROL='' OR CONTROL IS NULL) AND 
ENABLED=0")

and I obtain this error:

System.Data.SyntaxErrorException: Invalid escape sequence: '\s'.
in <0x00118> Mono.Data.SqlExpressions.Tokenizer:ProcessEscapes (Char c)
in <0x000cc> Mono.Data.SqlExpressions.Tokenizer:ReadString (Char 
terminator, Boolean canEscape)
in <0x0015b> Mono.Data.SqlExpressions.Tokenizer:ParseToken ()
in <0x00030> Mono.Data.SqlExpressions.Tokenizer:advance ()
in <0x00274> Mono.Data.SqlExpressions.Parser:yyparse (yyInput yyLex)
in <0x00112> Mono.Data.SqlExpressions.Parser:Compile (System.String sqlExpr)
in <0x000dd> System.Data.DataTable:Select (System.String 
filterExpression, System.String sort, DataViewRowState recordStates)
in <0x00014> System.Data.DataTable:Select (System.String filterExpression)

Apparently there's no escape sequence in the query, I'm doing something wrong?



From robertj at gmx.net  Thu Jun  8 11:55:27 2006
From: robertj at gmx.net (Robert Jordan)
Date: Thu, 08 Jun 2006 17:55:27 +0200
Subject: [Mono-dev] Re: Invalid escape selecting table rows
In-Reply-To: <7.0.0.16.0.20060608171626.00adfa68@apsystems.it>
References: <7.0.0.16.0.20060608171626.00adfa68@apsystems.it>
Message-ID: <e69h9g$inb$1@sea.gmane.org>

> I select them using
> 
> Tables[0].Select("(PAGE='\wsngmono\Categ.aspx' OR 
> PAGE='/wsngmono/Categ.aspx') AND (CONTROL='' OR CONTROL IS NULL) AND 
> ENABLED=0")
> 
> and I obtain this error:
> 
> System.Data.SyntaxErrorException: Invalid escape sequence: '\s'.
> in <0x00118> Mono.Data.SqlExpressions.Tokenizer:ProcessEscapes (Char c)
> in <0x000cc> Mono.Data.SqlExpressions.Tokenizer:ReadString (Char 
> terminator, Boolean canEscape)
> in <0x0015b> Mono.Data.SqlExpressions.Tokenizer:ParseToken ()
> in <0x00030> Mono.Data.SqlExpressions.Tokenizer:advance ()
> in <0x00274> Mono.Data.SqlExpressions.Parser:yyparse (yyInput yyLex)
> in <0x00112> Mono.Data.SqlExpressions.Parser:Compile (System.String 
> sqlExpr)
> in <0x000dd> System.Data.DataTable:Select (System.String 
> filterExpression, System.String sort, DataViewRowState recordStates)
> in <0x00014> System.Data.DataTable:Select (System.String filterExpression)
> 
> Apparently there's no escape sequence in the query, I'm doing something 
> wrong?


Escape all "\" with "\\".

Robert



From rodrigobamboo at gmail.com  Thu Jun  8 13:22:46 2006
From: rodrigobamboo at gmail.com (Rodrigo B. de Oliveira)
Date: Thu, 8 Jun 2006 14:22:46 -0300
Subject: [Mono-dev] Passing values into the default.build boo script
In-Reply-To: <1149672244.14694.15.camel@mrwibble.mrwobble>
References: <1149672244.14694.15.camel@mrwibble.mrwobble>
Message-ID: <5917478b0606081022x33126fd9id8807ce0f1fc9c5c@mail.gmail.com>

On 6/7/06, PFJ <paul at all-the-johnsons.co.uk> wrote:
> Hi,
>

Hi!

> Is there a way to pass values into the default.build script for
> boo-0.7.6.2237?
>

Yes, you can use -D:propertyName=propertyValue and override any
properties you want.

> I'm packaging it for Fedora Extras...

Great. Thanks!
-- 
bamboo
*** See you at the first global db4o User Conference in London, July
10 and 11, 2006 ***
http://www.db4o.com/about/productinformation/events/duc2006/


From paul at all-the-johnsons.co.uk  Thu Jun  8 17:22:51 2006
From: paul at all-the-johnsons.co.uk (Paul)
Date: Thu, 08 Jun 2006 22:22:51 +0100
Subject: [Mono-dev] Passing values into the default.build boo script
In-Reply-To: <5917478b0606081022x33126fd9id8807ce0f1fc9c5c@mail.gmail.com>
References: <1149672244.14694.15.camel@mrwibble.mrwobble>
	<5917478b0606081022x33126fd9id8807ce0f1fc9c5c@mail.gmail.com>
Message-ID: <4488952B.6070209@all-the-johnsons.co.uk>

Hi,
>> Is there a way to pass values into the default.build script for
>> boo-0.7.6.2237?
> Yes, you can use -D:propertyName=propertyValue and override any
> properties you want.
Well, most of them ;-)

>> I'm packaging it for Fedora Extras...
>
> Great. Thanks!
It's slow going - mainly as currently to get things to work properly I 
have to meddle with _libdir so that things always go into /usr/lib 
rather than /usr/lib64 for 64 bit architecture. I've noticed the spec 
files on the go-mono website all make the packages as noarch. Is this 
really the only sure fire way to ensure everything is picked up (such as 
boo, ikvm et al for monodevelop)?

TTFN

Paul

P.S. http://www.all-the-johnsons.co.uk/mono/rpms.html have the x86 and 
x86_64 binaries for various mono packages (including the new boo and nant)



From Jonathan.Chambers at ansys.com  Thu Jun  8 22:29:18 2006
From: Jonathan.Chambers at ansys.com (Jonathan S. Chambers)
Date: Thu, 8 Jun 2006 22:29:18 -0400
Subject: [Mono-dev] mono in VS
Message-ID: <BDBFCADE470D2B4A841D51412D2D915D03FE5638@canonsburgexch2.win.ansys.com>

Here's three minor changes to help mono build in VS (one issue I introduced).

Thanks,
Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vs.diff
Type: application/octet-stream
Size: 1915 bytes
Desc: vs.diff
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060608/b62f31fe/attachment.obj 

From zac at zacbowling.com  Fri Jun  9 00:00:00 2006
From: zac at zacbowling.com (Zac Bowling)
Date: Thu, 08 Jun 2006 23:00:00 -0500
Subject: [Mono-dev] C++ code as Internal call
In-Reply-To: <295e750a0606071635p10b0c7b8jc837e8ea9002c2b7@mail.gmail.com>
References: <20060607231058.28099.qmail@web60815.mail.yahoo.com>
	<295e750a0606071635p10b0c7b8jc837e8ea9002c2b7@mail.gmail.com>
Message-ID: <1149825600.6489.17.camel@localhost.localdomain>

Yah,

After to you read that article there is a niche with p/invoking C++. 
You can't safely invoke into C++ libraries unless the functions you want
are exported as C functions (using "extern 'C' {...}"). The vtable and
name mangling differences between each C++ compiler (since they are not
standardized except on IA64 platforms) make this a very very complicated
and ultimately unmaintainable to make part of pinvoke it self (I know, I
tried :-P). There are a few tricks to make it work it on static
functions that only work on one compiler at a time (using the entry
point argument), but they are very dangerous and will break very easily.
So if the library you want to call doesn't provide standard C exports on
its own, then the best solution is write a wrapper library in C++ that
does.

Hope that helps.

----
Zac Bowling
http://zacbowling.com

On Thu, 2006-06-08 at 01:35 +0200, Zoltan Varga wrote:
>                                    Hi,
> 
>   Read this, especially the section "Invoking Unmanaged Code":
> 
> http://www.mono-project.com/Interop_with_Native_Libraries
> 
>    Zoltan
> 
> On 6/8/06, Rusmin Susanto <rusminsusanto at yahoo.com> wrote:
> >
> > As far as I know, Mono is written in C. Internal calls are also written in
> > C. If I have a cool library/package that is written in C++, how do I define
> > it in Mono without having to re-write the library/package in C? I've tried
> > this few times but it seems that it's not working with g++.
> >
> >
> >
> > Regards
> >
> >
> >  __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
> >
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
-- 
Zac Bowling <zac at zacbowling.com>



From miguel at ximian.com  Fri Jun  9 00:11:55 2006
From: miguel at ximian.com (Miguel de Icaza)
Date: Fri, 09 Jun 2006 00:11:55 -0400
Subject: [Mono-dev] mono in VS
In-Reply-To: <BDBFCADE470D2B4A841D51412D2D915D03FE5638@canonsburgexch2.win.ansys.com>
References: <BDBFCADE470D2B4A841D51412D2D915D03FE5638@canonsburgexch2.win.ansys.com>
Message-ID: <1149826315.6167.351.camel@linux.site>

Hello,

> Here's three minor changes to help mono build in VS (one issue I introduced).

The first two patches look fine, and I understand what they do.

But what does the third do?

(And they need ChangeLogs)



From jfernandez at igalia.com  Fri Jun  9 02:27:37 2006
From: jfernandez at igalia.com (Javier Fernandez)
Date: Fri, 9 Jun 2006 08:27:37 +0200
Subject: [Mono-dev] [jfernandez@igalia.com: [Mono-list] Problems serializing
	'object' classes]
Message-ID: <20060609062736.GA6517@maestria.local.igalia.com>

----- Forwarded message from Javier Fernandez <jfernandez at igalia.com> -----

X-Original-To: mono-list at lists.ximian.com
From: Javier Fernandez <jfernandez at igalia.com>
To: mono-list at lists.ximian.com
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on 
	frontgate.ximian.com
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,RM_bw_Generic,
	SPF_HELO_PASS,SPF_PASS version=3.0.3
Subject: [Mono-list] Problems serializing 'object' classes 
X-BeenThere: mono-list at lists.ximian.com
X-Mailman-Version: 2.1.5
List-Id: Mono Developer Discussion List <mono-list.lists.ximian.com>
List-Unsubscribe: <http://lists.ximian.com/mailman/listinfo/mono-list>,
	<mailto:mono-list-request at lists.ximian.com?subject=unsubscribe>
List-Archive: <http://lists.ximian.com/pipermail/mono-list>
List-Post: <mailto:mono-list at lists.ximian.com>
List-Help: <mailto:mono-list-request at lists.ximian.com?subject=help>
List-Subscribe: <http://lists.ximian.com/mailman/listinfo/mono-list>,
	<mailto:mono-list-request at lists.ximian.com?subject=subscribe>

Hi,
I've developed a SOAP server using gsoap (2.7) and i'm trying 
to build a C# client based on Mono .Net specification.

I've used Mico (2.3.11) to generate the WSDL from an IDL file.
The gsoap C client runs fine, but when i tried to build the C#
client i found some problems. 

The C# generated stub define the following structures : 

/// <remarks/>
[System.Xml.Serialization.SoapType("CORBA.Any", Namespace="http://www.omg.org/IDL-Mapped/")]
public class CORBAAny {

    /// <remarks/>
    public CORBATypeCode type;

    /// <remarks/>
    public int __type;

    /// <remarks/>
    public object value;
}

/// <remarks/>
[System.Xml.Serialization.SoapType("CORBA.TypeCode", Namespace="http://www.omg.org/IDL-Mapped/")]
public class CORBATypeCode {

    /// <remarks/>
    [System.Xml.Serialization.SoapElement(DataType="anyURI")]
    public string definition;

    /// <remarks/>
    public string type_name;
}

The '_type' field was manually aded to the WSDL specification. This is a limitation
of gsoap, that needs information about the type of the generic value. In C# was 
defined as 'object' class; in C it was defined as 'void *' . 

These clases are used to define abstract classes. For instance, 

ConcreteClass {

	int att1
	int att2
}
 
AbstractClass {
 
	int att1;
	CORBAAny concrete;
}


When i tried to serialize the AbstractClass class, the 'concrete'
field arrives to the gsoap server as undefined values. The normal 
attributes of the concrete class are serialized corectly. 

I don't undertand why this kind of objects are not serialized
correctly. 

Could anyone help me ?
Thanks, 


-- 
Javier Fern?ndez Garc?a-Boente
Ingeniero en Inform?tica                 
mailto:jfernandez at igalia.com                    
Igalia S.L. http://www.igalia.com
Telf. +34 981 91 39 91  
Fax.  +34 981 91 39 49
 
_______________________________________________
Mono-list maillist  -  Mono-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


----- End forwarded message -----

-- 
Javier Fern?ndez Garc?a-Boente
Ingeniero en Inform?tica                 
mailto:jfernandez at igalia.com                    
Igalia S.L. http://www.igalia.com
Telf. +34 981 91 39 91  
Fax.  +34 981 91 39 49
 


From subscription.sapi at apsystems.it  Fri Jun  9 03:20:21 2006
From: subscription.sapi at apsystems.it (APS)
Date: Fri, 09 Jun 2006 09:20:21 +0200
Subject: [Mono-dev] Re: Invalid escape selecting table rows
Message-ID: <7.0.0.16.0.20060609092012.0433ab28@apsystems.it>

I explained me in a bad way.

(PAGE='\wsngmono\Categ.aspx' OR PAGE='/wsngmono/Categ.aspx') AND 
(CONTROL='' OR CONTROL IS NULL) AND ENABLED=0

is the search I want to do, I want to search a string containing 
'\wsngmono\categ.aspx'

In c# code I've done

Tables[0].Select("(PAGE='\\wsngmono\\Categ.aspx' OR 
PAGE='/wsngmono/Categ.aspx') AND (CONTROL='' OR CONTROL IS NULL) AND 
ENABLED=0")

otherwise there would be a compilation error.
I think that replacing '\' with '\\' it's wrong cause it would search 
a string with a double '\' in it, btw I tried with

Tables[0].Select("(PAGE='\\\\wsngmono\\\\Categ.aspx' OR 
PAGE='/wsngmono/Categ.aspx') AND (CONTROL='' OR CONTROL IS NULL) AND 
ENABLED=0")

and the error change..but not much

System.Data.SyntaxErrorException: Invalid escape sequence: '\w'

Maybe mono understand '\' in sql code as escape sequence?
Thanks in advance for helping me.


At 17.55 08/06/2006, Robert Jordan wrote:
>>I select them using
>>Tables[0].Select("(PAGE='\wsngmono\Categ.aspx' OR 
>>PAGE='/wsngmono/Categ.aspx') AND (CONTROL='' OR CONTROL IS NULL) 
>>AND ENABLED=0")
>>and I obtain this error:
>>System.Data.SyntaxErrorException: Invalid escape sequence: '\s'.
>>in <0x00118> Mono.Data.SqlExpressions.Tokenizer:ProcessEscapes (Char c)
>>in <0x000cc> Mono.Data.SqlExpressions.Tokenizer:ReadString (Char 
>>terminator, Boolean canEscape)
>>in <0x0015b> Mono.Data.SqlExpressions.Tokenizer:ParseToken ()
>>in <0x00030> Mono.Data.SqlExpressions.Tokenizer:advance ()
>>in <0x00274> Mono.Data.SqlExpressions.Parser:yyparse (yyInput yyLex)
>>in <0x00112> Mono.Data.SqlExpressions.Parser:Compile (System.String sqlExpr)
>>in <0x000dd> System.Data.DataTable:Select (System.String 
>>filterExpression, System.String sort, DataViewRowState recordStates)
>>in <0x00014> System.Data.DataTable:Select (System.String filterExpression)
>>Apparently there's no escape sequence in the query, I'm doing 
>>something wrong?
>
>
>Escape all "\" with "\\".
>
>Robert
>
>_______________________________________________
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-devel-list



From rusminsusanto at yahoo.com  Fri Jun  9 03:45:20 2006
From: rusminsusanto at yahoo.com (Rusmin Susanto)
Date: Fri, 9 Jun 2006 00:45:20 -0700 (PDT)
Subject: [Mono-dev] Optimization at opcode level
Message-ID: <20060609074520.44046.qmail@web60824.mail.yahoo.com>

Hello,
   
  I know that there are plenty of guidelines on optimization techniques in writing C# code.
   
  Does anyone know where can I find information on optimization at opcodes level (what I mean is intermediate language)? 
Or can someone give suggestions/tricks on optimizations when writing code at opcode level?
   
  I know that different languages produce slightly different opcodes. Thus, if the JIT engine is the same, I assume that different language has slightly different performance depending on the generated opcode.
   
  I would like to learn more about writing code in opcodes level. So, any information will be appreciated.
  Thanks.
   
  
Rusmin

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060609/02875802/attachment.html 

From js at hotfeet.ch  Fri Jun  9 04:46:35 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Fri, 09 Jun 2006 10:46:35 +0200
Subject: [Mono-dev] Re: Invalid escape selecting table rows
In-Reply-To: <7.0.0.16.0.20060608182248.041c2588@apsystems.it>
References: <7.0.0.16.0.20060608182248.041c2588@apsystems.it>
Message-ID: <1149842796.2610.36.camel@leonardo.hotfeet.ch>

Hi,

This really seems to be a bug. I'll look into it.

- Juraj


On Fri, 2006-06-09 at 09:20 +0200, APS wrote:
> I explained me in a bad way.
> 
> (PAGE='\wsngmono\Categ.aspx' OR PAGE='/wsngmono/Categ.aspx') AND 
> (CONTROL='' OR CONTROL IS NULL) AND ENABLED=0
> 
> is the search I want to do, I want to search a string containing 
> '\wsngmono\categ.aspx'
> 
> In c# code I've done
> 
> Tables[0].Select("(PAGE='\\wsngmono\\Categ.aspx' OR 
> PAGE='/wsngmono/Categ.aspx') AND (CONTROL='' OR CONTROL IS NULL) AND 
> ENABLED=0")
> 
> otherwise there would be a compilation error.
> I think that replacing '\' with '\\' it's wrong cause it would search 
> a string with a double '\' in it, btw I tried with
> 
> Tables[0].Select("(PAGE='\\\\wsngmono\\\\Categ.aspx' OR 
> PAGE='/wsngmono/Categ.aspx') AND (CONTROL='' OR CONTROL IS NULL) AND 
> ENABLED=0")
> 
> and the error change..but not much
> 
> System.Data.SyntaxErrorException: Invalid escape sequence: '\w'
> 
> Maybe mono understand '\' in sql code as escape sequence?
> Thanks in advance for helping me.
> 
> 
> At 17.55 08/06/2006, Robert Jordan wrote:
> >>I select them using
> >>Tables[0].Select("(PAGE='\wsngmono\Categ.aspx' OR 
> >>PAGE='/wsngmono/Categ.aspx') AND (CONTROL='' OR CONTROL IS NULL) 
> >>AND ENABLED=0")
> >>and I obtain this error:
> >>System.Data.SyntaxErrorException: Invalid escape sequence: '\s'.
> >>in <0x00118> Mono.Data.SqlExpressions.Tokenizer:ProcessEscapes (Char c)
> >>in <0x000cc> Mono.Data.SqlExpressions.Tokenizer:ReadString (Char 
> >>terminator, Boolean canEscape)
> >>in <0x0015b> Mono.Data.SqlExpressions.Tokenizer:ParseToken ()
> >>in <0x00030> Mono.Data.SqlExpressions.Tokenizer:advance ()
> >>in <0x00274> Mono.Data.SqlExpressions.Parser:yyparse (yyInput yyLex)
> >>in <0x00112> Mono.Data.SqlExpressions.Parser:Compile (System.String sqlExpr)
> >>in <0x000dd> System.Data.DataTable:Select (System.String 
> >>filterExpression, System.String sort, DataViewRowState recordStates)
> >>in <0x00014> System.Data.DataTable:Select (System.String filterExpression)
> >>Apparently there's no escape sequence in the query, I'm doing 
> >>something wrong?
> >
> >
> >Escape all "\" with "\\".
> >
> >Robert
> >
> >_______________________________________________
> >Mono-devel-list mailing list
> >Mono-devel-list at lists.ximian.com
> >http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From js at hotfeet.ch  Fri Jun  9 05:20:59 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Fri, 09 Jun 2006 11:20:59 +0200
Subject: [Mono-dev] Re: Invalid escape selecting table rows
In-Reply-To: <7.0.0.16.0.20060608182248.041c2588@apsystems.it>
References: <7.0.0.16.0.20060608182248.041c2588@apsystems.it>
Message-ID: <1149844859.2610.40.camel@leonardo.hotfeet.ch>

Hi,

The fix for this is in SVN now.
If you want, I can send you a System.Data.dll with the fix applied.

- Juraj


On Fri, 2006-06-09 at 09:20 +0200, APS wrote:
> I explained me in a bad way.
> 
> (PAGE='\wsngmono\Categ.aspx' OR PAGE='/wsngmono/Categ.aspx') AND 
> (CONTROL='' OR CONTROL IS NULL) AND ENABLED=0
> 
> is the search I want to do, I want to search a string containing 
> '\wsngmono\categ.aspx'
> 
> In c# code I've done
> 
> Tables[0].Select("(PAGE='\\wsngmono\\Categ.aspx' OR 
> PAGE='/wsngmono/Categ.aspx') AND (CONTROL='' OR CONTROL IS NULL) AND 
> ENABLED=0")
> 
> otherwise there would be a compilation error.
> I think that replacing '\' with '\\' it's wrong cause it would search 
> a string with a double '\' in it, btw I tried with
> 
> Tables[0].Select("(PAGE='\\\\wsngmono\\\\Categ.aspx' OR 
> PAGE='/wsngmono/Categ.aspx') AND (CONTROL='' OR CONTROL IS NULL) AND 
> ENABLED=0")
> 
> and the error change..but not much
> 
> System.Data.SyntaxErrorException: Invalid escape sequence: '\w'
> 
> Maybe mono understand '\' in sql code as escape sequence?
> Thanks in advance for helping me.
> 
> 
> At 17.55 08/06/2006, Robert Jordan wrote:
> >>I select them using
> >>Tables[0].Select("(PAGE='\wsngmono\Categ.aspx' OR 
> >>PAGE='/wsngmono/Categ.aspx') AND (CONTROL='' OR CONTROL IS NULL) 
> >>AND ENABLED=0")
> >>and I obtain this error:
> >>System.Data.SyntaxErrorException: Invalid escape sequence: '\s'.
> >>in <0x00118> Mono.Data.SqlExpressions.Tokenizer:ProcessEscapes (Char c)
> >>in <0x000cc> Mono.Data.SqlExpressions.Tokenizer:ReadString (Char 
> >>terminator, Boolean canEscape)
> >>in <0x0015b> Mono.Data.SqlExpressions.Tokenizer:ParseToken ()
> >>in <0x00030> Mono.Data.SqlExpressions.Tokenizer:advance ()
> >>in <0x00274> Mono.Data.SqlExpressions.Parser:yyparse (yyInput yyLex)
> >>in <0x00112> Mono.Data.SqlExpressions.Parser:Compile (System.String sqlExpr)
> >>in <0x000dd> System.Data.DataTable:Select (System.String 
> >>filterExpression, System.String sort, DataViewRowState recordStates)
> >>in <0x00014> System.Data.DataTable:Select (System.String filterExpression)
> >>Apparently there's no escape sequence in the query, I'm doing 
> >>something wrong?
> >
> >
> >Escape all "\" with "\\".
> >
> >Robert
> >
> >_______________________________________________
> >Mono-devel-list mailing list
> >Mono-devel-list at lists.ximian.com
> >http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?=  Fri Jun  9 05:28:48 2006
From: =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?=)
Date: Fri, 09 Jun 2006 11:28:48 +0200
Subject: [Mono-dev] Bug with Serialization of Nullable type
Message-ID: <44893F50.1050800@gmail.com>

Hello.

I filed a bug about Serialization:

http://bugzilla.ximian.com/show_bug.cgi?id=78611

I have made some research and I have proposed a small change to solve 
it, but I don't have experience or knowledge to determine if it's correct.

Any help would be appreciated.

Thanks.

	Andr?s G. Aragoneses	[ knocte ]

-- 



From cristian.vanti at spair.it  Wed Jun  7 09:17:40 2006
From: cristian.vanti at spair.it (Cristian Vanti)
Date: Wed, 07 Jun 2006 15:17:40 +0200
Subject: [Mono-dev] Got SIGSEGV on Response.Redirect 
Message-ID: <4486D1F4.6000200@spair.it>

I always get a SIGSEGV in a simple aspx method doing a Response.Redirect

this is the code (VB compiled with VisualStudio2003)

Private Sub cmdCancel_Click(ByVal sender As Object, ByVal e As 
EventArgs) Handles cmdCancel.Click
  Try
    Response.Redirect(NavigateURL(), True)
  Catch exc As Exception             'Module failed to load
    ProcessModuleLoadException(Me, exc)
  End Try
End Sub

(I tried Redirect(url,False) with same results)

and this is what I get:
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

Stacktrace:

in DotNetNuke.Modules.Links.EditLinks:cmdCancel_Click 
(object,System.EventArgs) <0xffffffff>
in DotNetNuke.Modules.Links.EditLinks:cmdCancel_Click 
(object,System.EventArgs) <0x5a>
in (wrapper delegate-invoke) 
System.MulticastDelegate:invoke_void_object_EventArgs 
(object,System.EventArgs) <0x154e2d8>
in System.Web.UI.WebControls.LinkButton:OnClick (System.EventArgs) <0x50>
in 
System.Web.UI.WebControls.LinkButton:System.Web.UI.IPostBackEventHandler.RaisePostBackEvent 
(string) <0x45>
in System.Web.UI.Page:RaisePostBackEvent 
(System.Web.UI.IPostBackEventHandler,string) <0x13>
in System.Web.UI.Page:RaisePostBackEvents () <0x11d>
in System.Web.UI.Page:InternalProcessRequest () <0x1ee>
in System.Web.UI.Page:ProcessRequest (System.Web.HttpContext) <0xa1>
in <Pipeline>__1:MoveNext () <0xfe3>
in System.Web.HttpApplication:Tick () <0x1c>
in System.Web.HttpApplication:Start (object) <0xcf>
in 
System.Web.HttpApplication:System.Web.IHttpAsyncHandler.BeginProcessRequest 
(System.Web.HttpContext,System.AsyncCallback,object) <0x68>
in System.Web.HttpRuntime:RealProcessRequest (object) <0x1a8>
in System.Web.HttpRuntime:ProcessRequest (System.Web.HttpWorkerRequest) 
<0x2c>
in Mono.WebServer.MonoWorkerRequest:ProcessRequest () <0xa>
in Mono.WebServer.BaseApplicationHost:ProcessRequest 
(Mono.WebServer.MonoWorkerRequest) <0x43>
in Mono.WebServer.XSPApplicationHost:ProcessRequest 
(int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) 
<0x37f>
in (wrapper remoting-invoke-with-check) 
Mono.WebServer.XSPApplicationHost:ProcessRequest 
(int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) 
<0xfffffab2>
in (wrapper xdomain-dispatch) 
Mono.WebServer.XSPApplicationHost:ProcessRequest 
(object,byte[]&,byte[]&,int,long,int,long,int,string,string,string,string,byte[],string) 
<0xfffee3be>
in (wrapper xdomain-invoke) 
Mono.WebServer.XSPApplicationHost:ProcessRequest 
(int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) 
<0xffffff3d>
in (wrapper remoting-invoke-with-check) 
Mono.WebServer.XSPApplicationHost:ProcessRequest 
(int,long,int,long,int,string,string,string,string,byte[],string,intptr,Mono.WebServer.SslInformations) 
<0xffcdfc7b>
in Mono.WebServer.XSPWorker:InnerRun (object) <0x563>
in Mono.WebServer.XSPWorker:Run (object) <0x22>
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object 
(object) <0xffffff95>
in (wrapper runtime-invoke) System.Object:runtime_invoke_void_object 
(object,intptr,intptr,intptr) <0x7e89867>

Native stacktrace:

        /usr/bin/mono(mono_handle_native_sigsegv+0xbb) [0x8153d0b]
        /usr/bin/mono [0x813e66f]
        /lib/tls/libpthread.so.0 [0xae3880]
        /usr/bin/mono(mono_branch_optimize_exception_target+0xdf) 
[0x815473f]
        /usr/bin/mono(mono_arch_output_basic_block+0x22af) [0x80690ff]
        /usr/bin/mono(mono_codegen+0xa5) [0x813c475]
        /usr/bin/mono [0x813d217]
        /usr/bin/mono [0x813dc5e]
        /usr/bin/mono [0x813e0c2]
        /usr/bin/mono [0x813e25a]
        /usr/bin/mono(mono_compile_method+0x3a) [0x80d636a]
        /usr/bin/mono(mono_magic_trampoline+0x1a) [0x815519a]
        [0x60e032]
        [0x1e90592]
        [0x33de829]
        [0x33de766]
        [0x1a15ad4]
        [0x1a15aae]
        [0x5a3fe57]
        [0x5a3cd82]
        [0x1e8f124]
        [0x1e8e085]
        [0x1e890d8]
        [0x1e88f21]
        [0x75c719]
        [0x75c24d]
        [0x75c20b]
        [0x75bd2c]
        [0x5e8d48]
        [0x5e8169]
        [0x5e7ab3]
        [0x5d5b67]
        [0x5d597e]
        [0x2b54fc]
        [0x2b4dd3]
        [0x2b4d8c]
        [0x2b4ce6]
        /usr/bin/mono [0x813e520]
        /usr/bin/mono(mono_runtime_invoke+0x27) [0x80d7b67]
        /usr/bin/mono(mono_runtime_invoke_array+0x270) [0x80d9050]
        /usr/bin/mono(mono_message_invoke+0xc5) [0x80dac15]
        /usr/bin/mono [0x80a611f]
        /usr/bin/mono [0x80a6949]
        /usr/bin/mono [0x809a922]
        /usr/bin/mono [0x80f6ef7]
        /usr/bin/mono [0x8115ba5]
        /lib/tls/libpthread.so.0 [0xadd371]
        /lib/tls/libc.so.6(__clone+0x5e) [0x1d99be]

I use Centos 4.1 and Mono 1.1.15.0

Please, help me.

bye
cristian


From Jonathan.Chambers at ansys.com  Fri Jun  9 07:33:41 2006
From: Jonathan.Chambers at ansys.com (Jonathan S. Chambers)
Date: Fri, 9 Jun 2006 07:33:41 -0400
Subject: [Mono-dev] mono in VS
Message-ID: <BDBFCADE470D2B4A841D51412D2D915D03FE5639@canonsburgexch2.win.ansys.com>

Specifically, the error I get from the MS compiler is :

1>.\mono\mini\mini-exceptions.c(86) : error C2036: 'gpointer' : unknown size

I don't think it likes the addition with the gpointer (ji->code_start). 

- Jonathan


-----Original Message-----
From:	Miguel de Icaza [mailto:miguel at ximian.com]
Sent:	Fri 6/9/2006 12:11 AM
To:	Jonathan S. Chambers
Cc:	mono-devel-list at ximian.com
Subject:	Re: [Mono-dev] mono in VS

Hello,

> Here's three minor changes to help mono build in VS (one issue I introduced).

The first two patches look fine, and I understand what they do.

But what does the third do?

(And they need ChangeLogs)






From kornelpal at gmail.com  Fri Jun  9 07:50:41 2006
From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=)
Date: Fri, 9 Jun 2006 13:50:41 +0200
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
Message-ID: <006c01c68bba$effc8700$0100a8c0@kornelpal.hu>

Hi,

Invoking non-public methods using SRE is widely used by our class library, 
it is supported by the ECMA standards so I don't really understand what you 
mean on "access to internal methods will at some point broken".

Note that even using "new string ((char) 0, length)" is faster than the 
current implementation.

Please approve the patch or please be more specific regarding your 
objections.

Korn?l

----- Original Message ----- 
From: "Korn?l P?l" <kornelpal at gmail.com>
To: "Miguel de Icaza" <miguel at ximian.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, June 07, 2006 10:59 AM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()


> Hi,
>
> I understand the nature of your problem, but I if you are speaking about
> CAS
> I think it is not a so big problem. SRE is intended to access non-public
> members as well as public members. When enabling security
> ReflectionPermission controls whether code can access private members of
> other assemblies but this should not be a problem as I18N is part of the
> class library so it can have FullTrust without problems. Problems may
> occur
> in case of executable like mcs.exe but when signing them and granting them
> FullTrust based on public key there should not be problems. Of course
> granting full trust to a public key whose private key is public may may
> imply security problems but this could be solved by restricting the scope
> of
> this key to the directories of Mono.
>
> Note that I attached a corrected patch because the previous one ignored
> the
> index parameter by mistake.
>
> Some performance tests:
>
> Before:
> length, conversion: time
> 1, byte[]: 11578
> 1, byte[] int int: 12282
> 4, byte[]: 12609
> 4, byte[] int int: 12687
> 1024, byte[]: 37125
> 1024, byte[] int int: 37844
> 1048576, byte[]: 23875
> 1048576, byte[] int int: 24125
>
> After:
> length, conversion: time
> 1, byte[]: 3235
> 1, byte[] int int: 3203
> 4, byte[]: 3734
> 4, byte[] int int: 3797
> 1024, byte[]: 13297
> 1024, byte[] int int: 13234
> 1048576, byte[]: 5937
> 1048576, byte[] int int: 5844
>
> The test program is attached.
>
> Korn?l
>
> ----- Original Message ----- 
> From: "Miguel de Icaza" <miguel at ximian.com>
> To: "Korn?l P?l" <kornelpal at gmail.com>
> Cc: <mono-devel-list at lists.ximian.com>
> Sent: Wednesday, June 07, 2006 6:48 AM
> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
>
>
>> Hello Kornel,
>>
>>> ByteEncoding.GetString() currently uses StringBuilder that is very slow.
>>> I
>>> modified it to use InternalAllocateStr and unsafe code that makes is
>>> much
>>> faster.
>>>
>>> Please review and approve the patch.
>>
>> Am not sure that poking at the internals and using InternalAllocateStr
>> is a good idea.   One possibility would be to use "Friend Assemblies",
>> although that is only supported in the 2.0 profile, not in 1.0.
>>
>> Although today Mono does not enforce at runtime accessibility, this is
>> something that we intend to fix, which means that access to internal
>> methods will at some point broken.   So this would be one of those
>> things we would have to fix.
>>
>> (Today we do violate this rule when using dynamic method invocation, and
>> we would have to find solutions for the places where we do).
>>
>> Miguel.
>



From miguel at ximian.com  Fri Jun  9 08:01:39 2006
From: miguel at ximian.com (Miguel de Icaza)
Date: Fri, 09 Jun 2006 08:01:39 -0400
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
In-Reply-To: <006c01c68bba$effc8700$0100a8c0@kornelpal.hu>
References: <006c01c68bba$effc8700$0100a8c0@kornelpal.hu>
Message-ID: <1149854499.6167.374.camel@linux.site>

Hello,

> Invoking non-public methods using SRE is widely used by our class library, 
> it is supported by the ECMA standards so I don't really understand what you 
> mean on "access to internal methods will at some point broken".

As I said, this might be something that we will fix in the future, and
although it works today, it does not mean it will work today, I do not
want to add more dependencies that might prevent us from fixing it in
the future.

Besides, poking at string internals is not something am very excited
about supporting nor encouraging.  The last time we did something
"unsafe" like this, it was reviewed over and over, and it turned out to
be buggy, it took months to track the mysterious bug because the
conditions were very hard to reproduce.

> Note that even using "new string ((char) 0, length)" is faster than the 
> current implementation.

That part of the patch is fine with me.

Miguel


From kornelpal at gmail.com  Fri Jun  9 08:24:30 2006
From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=)
Date: Fri, 9 Jun 2006 14:24:30 +0200
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
References: <006c01c68bba$effc8700$0100a8c0@kornelpal.hu>
	<1149854499.6167.374.camel@linux.site>
Message-ID: <008601c68bbf$a9a4ebd0$0100a8c0@kornelpal.hu>

OK, now I understan your problem.

Please review this modified patch.

Korn?l

----- Original Message ----- 
From: "Miguel de Icaza" <miguel at ximian.com>
To: "Korn?l P?l" <kornelpal at gmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Friday, June 09, 2006 2:01 PM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()


> Hello,
>
>> Invoking non-public methods using SRE is widely used by our class 
>> library,
>> it is supported by the ECMA standards so I don't really understand what 
>> you
>> mean on "access to internal methods will at some point broken".
>
> As I said, this might be something that we will fix in the future, and
> although it works today, it does not mean it will work today, I do not
> want to add more dependencies that might prevent us from fixing it in
> the future.
>
> Besides, poking at string internals is not something am very excited
> about supporting nor encouraging.  The last time we did something
> "unsafe" like this, it was reviewed over and over, and it turned out to
> be buggy, it took months to track the mysterious bug because the
> conditions were very hard to reproduce.
>
>> Note that even using "new string ((char) 0, length)" is faster than the
>> current implementation.
>
> That part of the patch is fine with me.
>
> Miguel 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ByteEncoding.diff
Type: application/octet-stream
Size: 1796 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060609/4cc38b4a/attachment.obj 

From robertj at gmx.net  Fri Jun  9 08:35:34 2006
From: robertj at gmx.net (Robert Jordan)
Date: Fri, 09 Jun 2006 14:35:34 +0200
Subject: [Mono-dev] Re: [PATCH] NET_2_0 Serialization Callbacks
In-Reply-To: <e657k2$ktq$1@sea.gmane.org>
References: <e657k2$ktq$1@sea.gmane.org>
Message-ID: <e6bpum$1bu$1@sea.gmane.org>

Robert Jordan wrote:
> Hey,
> 
> I've attached the patches to this bug:
> 
> http://bugzilla.ximian.com/show_bug.cgi?id=78594
> 
> The code could be used for 1.1 as well (the 1.1 support
> is commented out). However, as Lluis wrote, the
> formatters must cope with these changes. Ours do, but
> custom formatters do not.
> 
> There is an unsolved issue with the callbacks:
> 
> MS.NET's Type Loader does not load a type which has
> more than one method marked with the same attribute:
> 
> The sample
> 
> class T
> {
>     [OnDeserializing]
>     void A (StreamingContext ctx)
>     {
>     }
> 
>     [OnDeserializing]
>     void B (StreamingContext ctx)
>     {
>     }
> }
> 
> leads to a TypeLoadException. The loader also checks whether
> the method has the proper signature.
> 
> Where do we implement this?

Okay, MS.NET's PEVerify reports this as an error as well, so I guess
it should be done in Mono's verifier. Any objections?

Robert



From john.luke at gmail.com  Fri Jun  9 12:28:25 2006
From: john.luke at gmail.com (John Luke)
Date: Fri, 09 Jun 2006 12:28:25 -0400
Subject: [Mono-dev] WebRequest/Configuration bug in 2.0
Message-ID: <1149870505.17028.4.camel@localhost>

Hello,

It seems that if you have a .config file for your app containing dllmaps
creating a WebRequest will fail.  I think it is specific to 2.0
configuration stuff. (Originally found by trying to use the banshee
podcast plugin).  Let me know if you want it in bugzilla instead.

Unhandled Exception: System.TypeInitializationException: An exception
was thrown by the type initializer for System.Net.WebRequest --->
System.Configuration.ConfigurationErrorsException: Unrecognized
configuration section <dllmap> ()
(/usr/local/etc/mono/2.0/machine.config line 2)
  at System.Configuration.ConfigInfo.ThrowException (System.String text,
System.Xml.XmlTextReader reader) [0x00000]
  at System.Configuration.SectionGroupInfo.ReadContent
(System.Xml.XmlTextReader reader, System.Configuration.Configuration
config, Boolean overrideAllowed, Boolean root) [0x00000]
  at System.Configuration.SectionGroupInfo.ReadRootData
(System.Xml.XmlTextReader reader, System.Configuration.Configuration
config, Boolean overrideAllowed) [0x00000]
  at System.Configuration.Configuration.ReadConfigFile
(System.Xml.XmlTextReader reader, System.String fileName) [0x00000]
  at System.Configuration.Configuration.Load () [0x00000]
  at System.Configuration.Configuration.Init (IConfigSystem system,
System.String configPath, System.Configuration.Configuration parent)
[0x00000]
  at System.Configuration.Configuration..ctor
(System.Configuration.InternalConfigurationSystem system, System.String
locationSubPath) [0x00000]
  at System.Configuration.InternalConfigurationFactory.Create
(System.Type typeConfigHost, System.Object[]
hostInitConfigurationParams) [0x00000]
  at
System.Configuration.ConfigurationManager.OpenExeConfigurationInternal
(ConfigurationUserLevel userLevel, System.Reflection.Assembly
calling_assembly, System.String exePath) [0x00000]
  at
System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection (System.String configKey) [0x00000]
  at System.Configuration.ConfigurationManager.GetSection (System.String
sectionName) [0x00000]
  at System.Net.WebRequest..cctor () [0x00000] --- End of inner
exception stack trace ---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.cs
Type: text/x-csharp
Size: 607 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060609/933e748c/attachment.bin 
-------------- next part --------------
<configuration>
	<dllmap dll="libglib-2.0.so" target="libglib-2.0.so.0" />
	<dllmap dll="libgobject-2.0-0.dll" target="libgobject-2.0.so.0" />
	<dllmap dll="libgtk-win32-2.0-0.dll" target="libgtk-x11-2.0.so.0" />
	<dllmap dll="libbonobo-2.so" target="libbonobo-2.so.0" />
	<dllmap dll="gdk-x11-2.0" target="libgdk-x11-2.0.so.0" />
	<dllmap dll="libbanshee" target="/usr/local/lib/banshee/libbanshee.so" />
	<dllmap dll="libX11" target="libX11.so.6" />
</configuration>

From Jonathan.Chambers at ansys.com  Fri Jun  9 13:54:01 2006
From: Jonathan.Chambers at ansys.com (Jonathan S. Chambers)
Date: Fri, 9 Jun 2006 13:54:01 -0400
Subject: [Mono-dev] Mono is VS II
Message-ID: <BDBFCADE470D2B4A841D51412D2D915D05707FBF@canonsburgexch2.win.ansys.com>

Here's another patch for building mono in VS. g_unsetenv and g_setenv
are not defined in the VS build. Let me know if the #ifdef's could be
made better/clearer. I think there was also a minor leak in the icall
method; if the user was unsetting an environment variable the method
returned without freeing the utf8_name variable.

Note the whitespace change at the bottom of Environment.cs is removing
spaces from the end of the lines.

I also implemented the User and Machine level options for
Set/GetEnvironmentVariable using the registry on Windows.

Thanks,
Jonathan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: envvar.diff
Type: application/octet-stream
Size: 8790 bytes
Desc: envvar.diff
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060609/c5020938/attachment.obj 

From Jonathan.Chambers at ansys.com  Fri Jun  9 14:12:10 2006
From: Jonathan.Chambers at ansys.com (Jonathan S. Chambers)
Date: Fri, 9 Jun 2006 14:12:10 -0400
Subject: [Mono-dev] Mono is VS II
Message-ID: <BDBFCADE470D2B4A841D51412D2D915D05707FC1@canonsburgexch2.win.ansys.com>

Here's a better patch, thanks to robertj. It opens the registry subkey
in one call instead of 5 for machine level environment variables.

Thanks,
Jonathan

> -----Original Message-----
> From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-
> bounces at lists.ximian.com] On Behalf Of Jonathan S. Chambers
> Sent: Friday, June 09, 2006 1:54 PM
> To: mono-devel-list at lists.ximian.com
> Subject: [Mono-dev] Mono is VS II
> 
> Here's another patch for building mono in VS. g_unsetenv and g_setenv
> are not defined in the VS build. Let me know if the #ifdef's could be
> made better/clearer. I think there was also a minor leak in the icall
> method; if the user was unsetting an environment variable the method
> returned without freeing the utf8_name variable.
> 
> Note the whitespace change at the bottom of Environment.cs is removing
> spaces from the end of the lines.
> 
> I also implemented the User and Machine level options for
> Set/GetEnvironmentVariable using the registry on Windows.
> 
> Thanks,
> Jonathan
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: envvar.diff
Type: application/octet-stream
Size: 8148 bytes
Desc: envvar.diff
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060609/460436b6/attachment.obj 

From zac at zacbowling.com  Fri Jun  9 16:09:21 2006
From: zac at zacbowling.com (Zac Bowling)
Date: Fri, 09 Jun 2006 15:09:21 -0500
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
In-Reply-To: <008601c68bbf$a9a4ebd0$0100a8c0@kornelpal.hu>
References: <006c01c68bba$effc8700$0100a8c0@kornelpal.hu>
	<1149854499.6167.374.camel@linux.site>
	<008601c68bbf$a9a4ebd0$0100a8c0@kornelpal.hu>
Message-ID: <1149883761.6489.38.camel@localhost.localdomain>

Looks good from what I can tell. 

Sort of makes me think we should have a nice universal facility for
casting a string to byte array just for us to use internally (not for
the public to use because it can be an unsafe operation unless you know
what you are doing and why microsoft never added toByteArray() and the
ctor String(byte[]) functions in .NET as compared to Java). Maybe we
could make what we did in the Unicode (utf16/ucs2) encoding more generic
inside the string class? Something like the following functions:

internal String(byte[] val, bool bigEndian);
internal String(byte[] val); //assumes native
internal byte[] ToByteArray(bool bigEndian);
internal byte[] ToNativeByteArray();
or
internal static byte[] StringToByteArray(bool bigEndian);
internal static byte[] StringToNativeByteArray();
internal static String StringFromNativeByteArray(byte[] val);
internal static String StringFromByteArray(byte[] val, bool bigEndian);

Zac Bowling
http://zacbowling.com/ 

On Fri, 2006-06-09 at 14:24 +0200, Korn?l P?l wrote:
> OK, now I understan your problem.
> 
> Please review this modified patch.
> 
> Korn?l
> 
> ----- Original Message ----- 
> From: "Miguel de Icaza" <miguel at ximian.com>
> To: "Korn?l P?l" <kornelpal at gmail.com>
> Cc: <mono-devel-list at lists.ximian.com>
> Sent: Friday, June 09, 2006 2:01 PM
> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
> 
> 
> > Hello,
> >
> >> Invoking non-public methods using SRE is widely used by our class 
> >> library,
> >> it is supported by the ECMA standards so I don't really understand what 
> >> you
> >> mean on "access to internal methods will at some point broken".
> >
> > As I said, this might be something that we will fix in the future, and
> > although it works today, it does not mean it will work today, I do not
> > want to add more dependencies that might prevent us from fixing it in
> > the future.
> >
> > Besides, poking at string internals is not something am very excited
> > about supporting nor encouraging.  The last time we did something
> > "unsafe" like this, it was reviewed over and over, and it turned out to
> > be buggy, it took months to track the mysterious bug because the
> > conditions were very hard to reproduce.
> >
> >> Note that even using "new string ((char) 0, length)" is faster than the
> >> current implementation.
> >
> > That part of the patch is fine with me.
> >
> > Miguel 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-- 
Zac Bowling <zac at zacbowling.com>



From kornelpal at gmail.com  Fri Jun  9 16:15:56 2006
From: kornelpal at gmail.com (=?ISO-8859-1?B?S29ybulsIFDhbA==?=)
Date: Fri, 9 Jun 2006 22:15:56 +0200
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
References: <006c01c68bba$effc8700$0100a8c0@kornelpal.hu>
	<1149854499.6167.374.camel@linux.site>
	<008601c68bbf$a9a4ebd0$0100a8c0@kornelpal.hu>
	<1149883761.6489.38.camel@localhost.localdomain>
Message-ID: <000701c68c01$85678dd0$0100a8c0@kornelpal.hu>

UnicodeEncoding does this.;)

The thing you call native byte array is what Encoding.Default does.

Korn?l

----- Original Message ----- 
From: "Zac Bowling" <zac at zacbowling.com>
To: "Korn?l P?l" <kornelpal at gmail.com>
Cc: "Miguel de Icaza" <miguel at ximian.com>; 
<mono-devel-list at lists.ximian.com>
Sent: Friday, June 09, 2006 10:09 PM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()


> Looks good from what I can tell.
>
> Sort of makes me think we should have a nice universal facility for
> casting a string to byte array just for us to use internally (not for
> the public to use because it can be an unsafe operation unless you know
> what you are doing and why microsoft never added toByteArray() and the
> ctor String(byte[]) functions in .NET as compared to Java). Maybe we
> could make what we did in the Unicode (utf16/ucs2) encoding more generic
> inside the string class? Something like the following functions:
>
> internal String(byte[] val, bool bigEndian);
> internal String(byte[] val); //assumes native
> internal byte[] ToByteArray(bool bigEndian);
> internal byte[] ToNativeByteArray();
> or
> internal static byte[] StringToByteArray(bool bigEndian);
> internal static byte[] StringToNativeByteArray();
> internal static String StringFromNativeByteArray(byte[] val);
> internal static String StringFromByteArray(byte[] val, bool bigEndian);
>
> Zac Bowling
> http://zacbowling.com/
>
> On Fri, 2006-06-09 at 14:24 +0200, Korn?l P?l wrote:
>> OK, now I understan your problem.
>>
>> Please review this modified patch.
>>
>> Korn?l
>>
>> ----- Original Message ----- 
>> From: "Miguel de Icaza" <miguel at ximian.com>
>> To: "Korn?l P?l" <kornelpal at gmail.com>
>> Cc: <mono-devel-list at lists.ximian.com>
>> Sent: Friday, June 09, 2006 2:01 PM
>> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
>>
>>
>> > Hello,
>> >
>> >> Invoking non-public methods using SRE is widely used by our class
>> >> library,
>> >> it is supported by the ECMA standards so I don't really understand 
>> >> what
>> >> you
>> >> mean on "access to internal methods will at some point broken".
>> >
>> > As I said, this might be something that we will fix in the future, and
>> > although it works today, it does not mean it will work today, I do not
>> > want to add more dependencies that might prevent us from fixing it in
>> > the future.
>> >
>> > Besides, poking at string internals is not something am very excited
>> > about supporting nor encouraging.  The last time we did something
>> > "unsafe" like this, it was reviewed over and over, and it turned out to
>> > be buggy, it took months to track the mysterious bug because the
>> > conditions were very hard to reproduce.
>> >
>> >> Note that even using "new string ((char) 0, length)" is faster than 
>> >> the
>> >> current implementation.
>> >
>> > That part of the patch is fine with me.
>> >
>> > Miguel
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> -- 
> Zac Bowling <zac at zacbowling.com>
> 



From contact at i-nz.net  Fri Jun  9 16:28:58 2006
From: contact at i-nz.net (Ivan N. Zlatev)
Date: Fri, 09 Jun 2006 23:28:58 +0300
Subject: [Mono-dev] Misc Patches and 2.0 Updates. Application for svn
	developer access?
Message-ID: <1149884939.20462.35.camel@linux.site>

Hello,

This is my first post to this list, so "Hi everyone!" :). A short
introduction... I am a student and I've decided to dedicate my summer on
Mono (development). I am interested in developing a MWF designer, but to
achieve this, I need to implement the design-time support in Mono. I've
already done some work, but there is so much more to do. 

Anyway in here I just wanted to post a few patches and updates of mine.
Hopefully they will satisfy your requirements. Also I would like to
apply for developer svn access, if possible?

The patch: http://www.i-nz.net/files/code/mono/2006-06-09/patch.diff
The new files: http://www.i-nz.net/files/code/mono/2006-06-09/class%20-%
20new%20files.tar.gz
The changes: http://www.i-nz.net/files/code/mono/2006-06-09/changes

class/System/System.ComponentModel
NEW:
    CustomTypeDescriptor.cs
    INestedContainer.cs
    INestedSite.cs
    NestedContainer.cs
    TypeDescriptionProvider.cs
    TypeDescriptionProviderAttribute.cs
    WeakReferenceHashtable.cs
UPDATES:
    Container.cs - Fixed Add/Remove behaviour.
    TypeDescriptor.cs - Implemented NET_2_0 Associations.
    MemberDescriptor.cs - Added GetInvocationTarget and fixed
GetInvokee.


class/System/System.ComponentModel.Design
NEW:
    IComponentInitializer.cs
    ITreeDesigner.cs
UPDATES:
    ServiceContainer.cs - NET_2_0 Update.


class/System.Design/System.ComponentModel.Design
NEW:
    LoadedEventArgs.cs


class/System/Test/System.ComponentModel
UPDATES:
    TypeDescriptorTests.cs - Added a test for NET_2_0 Associations.


-- 
Ivan N. Zlatev

Web: http://www.i-nZ.net
GPG Key: http://files.i-nZ.net/i-nZ.asc
"It's all some kind of whacked out conspiracy."



From zac at zacbowling.com  Fri Jun  9 16:43:14 2006
From: zac at zacbowling.com (Zac Bowling)
Date: Fri, 09 Jun 2006 15:43:14 -0500
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
In-Reply-To: <000701c68c01$85678dd0$0100a8c0@kornelpal.hu>
References: <006c01c68bba$effc8700$0100a8c0@kornelpal.hu>
	<1149854499.6167.374.camel@linux.site>
	<008601c68bbf$a9a4ebd0$0100a8c0@kornelpal.hu>
	<1149883761.6489.38.camel@localhost.localdomain>
	<000701c68c01$85678dd0$0100a8c0@kornelpal.hu>
Message-ID: <1149885794.6489.43.camel@localhost.localdomain>

Yah I remember that about 4 or 5 months ago. :-P I was the one that
pointed how slow it was and had that first patch to use memcopy from the
string function :-)

I'm just thinking that moving it to the string class might be better. I
almost remember there were some other places where this would really
useful in corelib (but might be thinking of the jscript string functions
or something).

Zac Bowling
http://zacbowling.com/ 

On Fri, 2006-06-09 at 22:15 +0200, Korn?l P?l wrote:
> UnicodeEncoding does this.;)
> 
> The thing you call native byte array is what Encoding.Default does.
> 
> Korn?l
> 
> ----- Original Message ----- 
> From: "Zac Bowling" <zac at zacbowling.com>
> To: "Korn?l P?l" <kornelpal at gmail.com>
> Cc: "Miguel de Icaza" <miguel at ximian.com>; 
> <mono-devel-list at lists.ximian.com>
> Sent: Friday, June 09, 2006 10:09 PM
> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
> 
> 
> > Looks good from what I can tell.
> >
> > Sort of makes me think we should have a nice universal facility for
> > casting a string to byte array just for us to use internally (not for
> > the public to use because it can be an unsafe operation unless you know
> > what you are doing and why microsoft never added toByteArray() and the
> > ctor String(byte[]) functions in .NET as compared to Java). Maybe we
> > could make what we did in the Unicode (utf16/ucs2) encoding more generic
> > inside the string class? Something like the following functions:
> >
> > internal String(byte[] val, bool bigEndian);
> > internal String(byte[] val); //assumes native
> > internal byte[] ToByteArray(bool bigEndian);
> > internal byte[] ToNativeByteArray();
> > or
> > internal static byte[] StringToByteArray(bool bigEndian);
> > internal static byte[] StringToNativeByteArray();
> > internal static String StringFromNativeByteArray(byte[] val);
> > internal static String StringFromByteArray(byte[] val, bool bigEndian);
> >
> > Zac Bowling
> > http://zacbowling.com/
> >
> > On Fri, 2006-06-09 at 14:24 +0200, Korn?l P?l wrote:
> >> OK, now I understan your problem.
> >>
> >> Please review this modified patch.
> >>
> >> Korn?l
> >>
> >> ----- Original Message ----- 
> >> From: "Miguel de Icaza" <miguel at ximian.com>
> >> To: "Korn?l P?l" <kornelpal at gmail.com>
> >> Cc: <mono-devel-list at lists.ximian.com>
> >> Sent: Friday, June 09, 2006 2:01 PM
> >> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
> >>
> >>
> >> > Hello,
> >> >
> >> >> Invoking non-public methods using SRE is widely used by our class
> >> >> library,
> >> >> it is supported by the ECMA standards so I don't really understand 
> >> >> what
> >> >> you
> >> >> mean on "access to internal methods will at some point broken".
> >> >
> >> > As I said, this might be something that we will fix in the future, and
> >> > although it works today, it does not mean it will work today, I do not
> >> > want to add more dependencies that might prevent us from fixing it in
> >> > the future.
> >> >
> >> > Besides, poking at string internals is not something am very excited
> >> > about supporting nor encouraging.  The last time we did something
> >> > "unsafe" like this, it was reviewed over and over, and it turned out to
> >> > be buggy, it took months to track the mysterious bug because the
> >> > conditions were very hard to reproduce.
> >> >
> >> >> Note that even using "new string ((char) 0, length)" is faster than 
> >> >> the
> >> >> current implementation.
> >> >
> >> > That part of the patch is fine with me.
> >> >
> >> > Miguel
> >> _______________________________________________
> >> Mono-devel-list mailing list
> >> Mono-devel-list at lists.ximian.com
> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> > -- 
> > Zac Bowling <zac at zacbowling.com>
> > 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
-- 
Zac Bowling <zac at zacbowling.com>



From trupill at yahoo.es  Fri Jun  9 16:46:04 2006
From: trupill at yahoo.es (Alejandro Serrano)
Date: Fri, 09 Jun 2006 22:46:04 +0200
Subject: [Mono-dev] Misc Patches and 2.0 Updates. Application for svn
	developer access?
In-Reply-To: <1149884939.20462.35.camel@linux.site>
References: <1149884939.20462.35.camel@linux.site>
Message-ID: <4489DE0C.6020107@yahoo.es>

That seems a really interesting work! I'm not one of the managers of 
Mono, but I would like to know whether you are following the same 
conventions as in Microsoft CLI implementation, so it could be possible 
to use the form designer as in Windows.
Also, are you using Managed Windows Forms? I would like to work on 
bindings for MonoDevelop if it could be possible, although I think the 
space between MWF and GTK# is as big as an abism.

Ivan N. Zlatev escribi?:
> Hello,
>
> This is my first post to this list, so "Hi everyone!" :). A short
> introduction... I am a student and I've decided to dedicate my summer on
> Mono (development). I am interested in developing a MWF designer, but to
> achieve this, I need to implement the design-time support in Mono. I've
> already done some work, but there is so much more to do. 
>
> Anyway in here I just wanted to post a few patches and updates of mine.
> Hopefully they will satisfy your requirements. Also I would like to
> apply for developer svn access, if possible?
>
> The patch: http://www.i-nz.net/files/code/mono/2006-06-09/patch.diff
> The new files: http://www.i-nz.net/files/code/mono/2006-06-09/class%20-%
> 20new%20files.tar.gz
> The changes: http://www.i-nz.net/files/code/mono/2006-06-09/changes
>   

		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. 
http://es.voice.yahoo.com


From kornelpal at gmail.com  Fri Jun  9 16:52:35 2006
From: kornelpal at gmail.com (=?ISO-8859-1?B?S29ybulsIFDhbA==?=)
Date: Fri, 9 Jun 2006 22:52:35 +0200
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
References: <006c01c68bba$effc8700$0100a8c0@kornelpal.hu>
	<1149854499.6167.374.camel@linux.site>
	<008601c68bbf$a9a4ebd0$0100a8c0@kornelpal.hu>
	<1149883761.6489.38.camel@localhost.localdomain>
	<000701c68c01$85678dd0$0100a8c0@kornelpal.hu>
	<1149885794.6489.43.camel@localhost.localdomain>
Message-ID: <001001c68c06$a42aab30$0100a8c0@kornelpal.hu>

I know that you know that's why I only referenced UnicodeEncoding instead of 
an explanation.:)

There is no need to add such methods because UnicodeEncoding does exactly 
this. Converting string <-> byte[] is simply not possible without memcpy as 
it has different underlaying structures.

Korn?l

----- Original Message ----- 
From: "Zac Bowling" <zac at zacbowling.com>
To: "Korn?l P?l" <kornelpal at gmail.com>
Cc: "Miguel de Icaza" <miguel at ximian.com>; 
<mono-devel-list at lists.ximian.com>
Sent: Friday, June 09, 2006 10:43 PM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()


> Yah I remember that about 4 or 5 months ago. :-P I was the one that
> pointed how slow it was and had that first patch to use memcopy from the
> string function :-)
>
> I'm just thinking that moving it to the string class might be better. I
> almost remember there were some other places where this would really
> useful in corelib (but might be thinking of the jscript string functions
> or something).
>
> Zac Bowling
> http://zacbowling.com/
>
> On Fri, 2006-06-09 at 22:15 +0200, Korn?l P?l wrote:
>> UnicodeEncoding does this.;)
>>
>> The thing you call native byte array is what Encoding.Default does.
>>
>> Korn?l
>>
>> ----- Original Message ----- 
>> From: "Zac Bowling" <zac at zacbowling.com>
>> To: "Korn?l P?l" <kornelpal at gmail.com>
>> Cc: "Miguel de Icaza" <miguel at ximian.com>;
>> <mono-devel-list at lists.ximian.com>
>> Sent: Friday, June 09, 2006 10:09 PM
>> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
>>
>>
>> > Looks good from what I can tell.
>> >
>> > Sort of makes me think we should have a nice universal facility for
>> > casting a string to byte array just for us to use internally (not for
>> > the public to use because it can be an unsafe operation unless you know
>> > what you are doing and why microsoft never added toByteArray() and the
>> > ctor String(byte[]) functions in .NET as compared to Java). Maybe we
>> > could make what we did in the Unicode (utf16/ucs2) encoding more 
>> > generic
>> > inside the string class? Something like the following functions:
>> >
>> > internal String(byte[] val, bool bigEndian);
>> > internal String(byte[] val); //assumes native
>> > internal byte[] ToByteArray(bool bigEndian);
>> > internal byte[] ToNativeByteArray();
>> > or
>> > internal static byte[] StringToByteArray(bool bigEndian);
>> > internal static byte[] StringToNativeByteArray();
>> > internal static String StringFromNativeByteArray(byte[] val);
>> > internal static String StringFromByteArray(byte[] val, bool bigEndian);
>> >
>> > Zac Bowling
>> > http://zacbowling.com/
>> >
>> > On Fri, 2006-06-09 at 14:24 +0200, Korn?l P?l wrote:
>> >> OK, now I understan your problem.
>> >>
>> >> Please review this modified patch.
>> >>
>> >> Korn?l
>> >>
>> >> ----- Original Message ----- 
>> >> From: "Miguel de Icaza" <miguel at ximian.com>
>> >> To: "Korn?l P?l" <kornelpal at gmail.com>
>> >> Cc: <mono-devel-list at lists.ximian.com>
>> >> Sent: Friday, June 09, 2006 2:01 PM
>> >> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
>> >>
>> >>
>> >> > Hello,
>> >> >
>> >> >> Invoking non-public methods using SRE is widely used by our class
>> >> >> library,
>> >> >> it is supported by the ECMA standards so I don't really understand
>> >> >> what
>> >> >> you
>> >> >> mean on "access to internal methods will at some point broken".
>> >> >
>> >> > As I said, this might be something that we will fix in the future, 
>> >> > and
>> >> > although it works today, it does not mean it will work today, I do 
>> >> > not
>> >> > want to add more dependencies that might prevent us from fixing it 
>> >> > in
>> >> > the future.
>> >> >
>> >> > Besides, poking at string internals is not something am very excited
>> >> > about supporting nor encouraging.  The last time we did something
>> >> > "unsafe" like this, it was reviewed over and over, and it turned out 
>> >> > to
>> >> > be buggy, it took months to track the mysterious bug because the
>> >> > conditions were very hard to reproduce.
>> >> >
>> >> >> Note that even using "new string ((char) 0, length)" is faster than
>> >> >> the
>> >> >> current implementation.
>> >> >
>> >> > That part of the patch is fine with me.
>> >> >
>> >> > Miguel
>> >> _______________________________________________
>> >> Mono-devel-list mailing list
>> >> Mono-devel-list at lists.ximian.com
>> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> > -- 
>> > Zac Bowling <zac at zacbowling.com>
>> >
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
> -- 
> Zac Bowling <zac at zacbowling.com>
> 



From contact at i-nz.net  Fri Jun  9 17:08:50 2006
From: contact at i-nz.net (Ivan N. Zlatev)
Date: Sat, 10 Jun 2006 00:08:50 +0300
Subject: [Mono-dev] Misc Patches and 2.0 Updates. Application for svn
	developer access?
In-Reply-To: <4489DE0C.6020107@yahoo.es>
References: <1149884939.20462.35.camel@linux.site> <4489DE0C.6020107@yahoo.es>
Message-ID: <1149887330.20462.54.camel@linux.site>

On Fri, 2006-06-09 at 22:46 +0200, Alejandro Serrano wrote:
> That seems a really interesting work! I'm not one of the managers of 
> Mono, but I would like to know whether you are following the same 
> conventions as in Microsoft CLI implementation, so it could be possible 
> to use the form designer as in Windows.
> Also, are you using Managed Windows Forms? I would like to work on 
> bindings for MonoDevelop if it could be possible, although I think the 
> space between MWF and GTK# is as big as an abism.

Well. I am working on the 2.0 DesignerSurface and DesignerSurfaceManager
(the underlying designerhost and services etc) and in parallel on the
1.1 ComponentDesigner stuff and up (controldesigner, usercontroldesigner
and so on). So it's not an ugly hack what I am planning to achieve. I am
going to implement everything required in System.ComponentModel.Design,
System.ComponentModel, System.Windows.Forms.Design, etc. There is much
work and to be fair I am not a pro in the area, BUT I have printed (and
read) almost every article on the subject. I serously doubt there will
be an easy way to integrate properly a MWF designer in MD. Infact it is
indeed really early to talk about integration of any kind :).

-- 
Ivan N. Zlatev

Web: http://www.i-nZ.net
GPG Key: http://files.i-nZ.net/i-nZ.asc
"It's all some kind of whacked out conspiracy."



From atsushi at ximian.com  Sat Jun 10 02:45:43 2006
From: atsushi at ximian.com (Atsushi Eno)
Date: Sat, 10 Jun 2006 15:45:43 +0900
Subject: [Mono-dev] WebRequest/Configuration bug in 2.0
In-Reply-To: <1149870505.17028.4.camel@localhost>
References: <1149870505.17028.4.camel@localhost>
Message-ID: <448A6A97.4000203@ximian.com>

Hi,

Just fixed in svn. Thanks.

Atsushi Eno

John Luke wrote:
> Hello,
> 
> It seems that if you have a .config file for your app containing dllmaps
> creating a WebRequest will fail.  I think it is specific to 2.0
> configuration stuff. (Originally found by trying to use the banshee
> podcast plugin).  Let me know if you want it in bugzilla instead.
> 
> Unhandled Exception: System.TypeInitializationException: An exception
> was thrown by the type initializer for System.Net.WebRequest --->
> System.Configuration.ConfigurationErrorsException: Unrecognized
> configuration section <dllmap> ()
> (/usr/local/etc/mono/2.0/machine.config line 2)
>   at System.Configuration.ConfigInfo.ThrowException (System.String text,
> System.Xml.XmlTextReader reader) [0x00000]
>   at System.Configuration.SectionGroupInfo.ReadContent
> (System.Xml.XmlTextReader reader, System.Configuration.Configuration
> config, Boolean overrideAllowed, Boolean root) [0x00000]
>   at System.Configuration.SectionGroupInfo.ReadRootData
> (System.Xml.XmlTextReader reader, System.Configuration.Configuration
> config, Boolean overrideAllowed) [0x00000]
>   at System.Configuration.Configuration.ReadConfigFile
> (System.Xml.XmlTextReader reader, System.String fileName) [0x00000]
>   at System.Configuration.Configuration.Load () [0x00000]
>   at System.Configuration.Configuration.Init (IConfigSystem system,
> System.String configPath, System.Configuration.Configuration parent)
> [0x00000]
>   at System.Configuration.Configuration..ctor
> (System.Configuration.InternalConfigurationSystem system, System.String
> locationSubPath) [0x00000]
>   at System.Configuration.InternalConfigurationFactory.Create
> (System.Type typeConfigHost, System.Object[]
> hostInitConfigurationParams) [0x00000]
>   at
> System.Configuration.ConfigurationManager.OpenExeConfigurationInternal
> (ConfigurationUserLevel userLevel, System.Reflection.Assembly
> calling_assembly, System.String exePath) [0x00000]
>   at
> System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection (System.String configKey) [0x00000]
>   at System.Configuration.ConfigurationManager.GetSection (System.String
> sectionName) [0x00000]
>   at System.Net.WebRequest..cctor () [0x00000] --- End of inner
> exception stack trace ---



From miguel at ximian.com  Sat Jun 10 14:40:30 2006
From: miguel at ximian.com (Miguel de Icaza)
Date: Sat, 10 Jun 2006 14:40:30 -0400
Subject: [Mono-dev] Misc Patches and 2.0 Updates. Application for svn
	developer access?
In-Reply-To: <1149887330.20462.54.camel@linux.site>
References: <1149884939.20462.35.camel@linux.site>
	<4489DE0C.6020107@yahoo.es>  <1149887330.20462.54.camel@linux.site>
Message-ID: <1149964830.6167.470.camel@linux.site>

Hello,

> Well. I am working on the 2.0 DesignerSurface and DesignerSurfaceManager
> (the underlying designerhost and services etc) and in parallel on the
> 1.1 ComponentDesigner stuff and up (controldesigner, usercontroldesigner
> and so on). So it's not an ugly hack what I am planning to achieve. I am
> going to implement everything required in System.ComponentModel.Design,
> System.ComponentModel, System.Windows.Forms.Design, etc. There is much
> work and to be fair I am not a pro in the area, BUT I have printed (and
> read) almost every article on the subject. I serously doubt there will
> be an easy way to integrate properly a MWF designer in MD. Infact it is
> indeed really early to talk about integration of any kind :).

I agree that integration talks are probably too early to discuss at this
point, it will probably require some hard-core hacking in the MWF and
Gtk# cores to get them talking to each other.   Not impossible, but it
should not be the early goal.

In my opinion, the most important thing to do for a GUI designer is not
really in the System.ComponentModel class libraries, but in writing the
actual designer: the stuff that paints the host (Window), drag and drop
of controls, showing the editing handles, etc.

Miguel.


From trupill at yahoo.es  Sat Jun 10 14:50:39 2006
From: trupill at yahoo.es (Alejandro Serrano)
Date: Sat, 10 Jun 2006 20:50:39 +0200
Subject: [Mono-dev] Misc Patches and 2.0 Updates. Application for svn
	developer access?
In-Reply-To: <1149964830.6167.470.camel@linux.site>
References: <1149884939.20462.35.camel@linux.site>	 <4489DE0C.6020107@yahoo.es>
	<1149887330.20462.54.camel@linux.site>
	<1149964830.6167.470.camel@linux.site>
Message-ID: <448B147F.6010804@yahoo.es>

Miguel de Icaza escribi?:
> Hello,
> I agree that integration talks are probably too early to discuss at this
> point, it will probably require some hard-core hacking in the MWF and
> Gtk# cores to get them talking to each other.   Not impossible, but it
> should not be the early goal.
>   
Yes, integration is very far. But designers are always thought as being 
part of a larger unit, such a development environment. Of course, if MWF 
comes to that degree of functionality, I think we could ever get 
SharpDevelop running in Mono.
> In my opinion, the most important thing to do for a GUI designer is not
> really in the System.ComponentModel class libraries, but in writing the
> actual designer: the stuff that paints the host (Window), drag and drop
> of controls, showing the editing handles, etc.
>   
 From my point of view it's better to start designing it as in 
System.Windows.Forms implementation from Mcrisoft to allow 
compatibility. I think think it is a good idea to have a "hack" for 
Mono, I would prefer the same implementation.

		
______________________________________________ 
LLama Gratis a cualquier PC del Mundo. 
Llamadas a fijos y m?viles desde 1 c?ntimo por minuto. 
http://es.voice.yahoo.com


From vargaz at gmail.com  Sat Jun 10 15:33:15 2006
From: vargaz at gmail.com (Zoltan Varga)
Date: Sat, 10 Jun 2006 21:33:15 +0200
Subject: [Mono-dev] Mono is VS II
In-Reply-To: <BDBFCADE470D2B4A841D51412D2D915D05707FC1@canonsburgexch2.win.ansys.com>
References: <AcaL7bGwLEmgHlajSI+L5xfhrSmqnwAAloGg>
	<BDBFCADE470D2B4A841D51412D2D915D05707FC1@canonsburgexch2.win.ansys.com>
Message-ID: <295e750a0606101233x1608f37agaacfad0cdf413904@mail.gmail.com>

                                  Hi,

  The icall.c changes look ok to me. The Environment.cs change are mostly fine
too, but I think you should put back the NotImplementedExceptions () when
not running on windows instead of returning empty arrays and such.

                   Zoltan

On 6/9/06, Jonathan S. Chambers <Jonathan.Chambers at ansys.com> wrote:
> Here's a better patch, thanks to robertj. It opens the registry subkey
> in one call instead of 5 for machine level environment variables.
>
> Thanks,
> Jonathan
>
> > -----Original Message-----
> > From: mono-devel-list-bounces at lists.ximian.com
> [mailto:mono-devel-list-
> > bounces at lists.ximian.com] On Behalf Of Jonathan S. Chambers
> > Sent: Friday, June 09, 2006 1:54 PM
> > To: mono-devel-list at lists.ximian.com
> > Subject: [Mono-dev] Mono is VS II
> >
> > Here's another patch for building mono in VS. g_unsetenv and g_setenv
> > are not defined in the VS build. Let me know if the #ifdef's could be
> > made better/clearer. I think there was also a minor leak in the icall
> > method; if the user was unsetting an environment variable the method
> > returned without freeing the utf8_name variable.
> >
> > Note the whitespace change at the bottom of Environment.cs is removing
> > spaces from the end of the lines.
> >
> > I also implemented the User and Machine level options for
> > Set/GetEnvironmentVariable using the registry on Windows.
> >
> > Thanks,
> > Jonathan
> >
> >
>
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>


From andrews at mainsoft.com  Sun Jun 11 07:46:42 2006
From: andrews at mainsoft.com (Andrew Skiba)
Date: Sun, 11 Jun 2006 04:46:42 -0700
Subject: [Mono-dev] [PATCH] menu cssclass test and fix
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03136ABE@dhost002-45.dex002.intermedia.net>

Hello,

Please see the attachments for the test and the fix for it. Please
notice, that this nunit test must be run with net_2_0 profile. If no one
objects, I will commit.

Andrew.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: menuclass.test.patch
Type: application/octet-stream
Size: 2710 bytes
Desc: menuclass.test.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060611/cf6cf2fb/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: menuclass.patch
Type: application/octet-stream
Size: 514 bytes
Desc: menuclass.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060611/cf6cf2fb/attachment-0001.obj 

From almann.goo at gmail.com  Sun Jun 11 09:48:32 2006
From: almann.goo at gmail.com (Almann T. Goo)
Date: Sun, 11 Jun 2006 23:48:32 +1000
Subject: [Mono-dev] Abort with Non-Typical Exception Handler Layout on Mono
	1.1.13.6
Message-ID: <7e9b97090606110648n4742f89dl3c682cbb2b4157b0@mail.gmail.com>

I am working on exception handler translation for JaCIL (CLI to JVM
byte-code compiler) so I've been writing some sample cases in CIL to better
understand the handler semantics in the CLI.  When running up this CIL code
in Mono 1.1.13.6, the run time aborted on an assertion error.

    T_START:
        ldstr   "Start"
        call    void [mscorlib]System.Console::WriteLine(string)
        leave.s COMPLETE
    T1_END:
        nop
    T2_END:

    COMPLETE:
        ret

    F1_START:
        ldstr   "Finally1"
        call    void [mscorlib]System.Console::WriteLine(string)
        endfinally
    F1_END:

    F2_START:
        ldstr   "Finally2"
        call    void [mscorlib]System.Console::WriteLine(string)
        endfinally
    F2_END:

    .try T_START to T1_END finally handler F1_START to F1_END
    .try T_START to T2_END finally handler F2_START to F2_END

The error returned when trying to execute this code in Mono is:

$ mono sample.exe

** ERROR **: file mini.c: line 9517 (mini_method_compile): assertion failed:
(tblock->native_offset)
aborting...
Aborted

If I move the method return and its label past the last finally handler the
above code works (probably how most compilers would probably generate this
type of code).  From what I understand of ECMA-335, it is legitimate to have
this case, and it indeed works in .NET Framework and Portable .NET as shown
below:

D:\tmp> sample.exe
Start
Finally1
Finally2

I could be missing something in ECMA-335 (which has parts of the handler
spec in Partitions I, II, and III making more room for confusion) and PNet
and .NET Framework are just simply lax in this regard.  This is certainly
not a show stopper for my work, but I was wondering if anyone else has run
into anything similar on Mono with regard to exception handlers.

Best regards,
Almann

-- 
Almann T. Goo
almann.goo at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060611/c82e9e83/attachment.html 

From andrews at mainsoft.com  Sun Jun 11 10:00:46 2006
From: andrews at mainsoft.com (Andrew Skiba)
Date: Sun, 11 Jun 2006 07:00:46 -0700
Subject: [Mono-dev] [PATCH] menu cssclass test and fix - NEW
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03136AFC@dhost002-45.dex002.intermedia.net>

Please use this test and patch instead of the previous. There is a new
assert in the test, and there is fix in the patch for this assert. If no
one objects, I will commit.

> -----Original Message-----
> From: mono-devel-list-bounces at lists.ximian.com 
> [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf 
> Of Andrew Skiba
> Sent: Sunday, June 11, 2006 14:47
> To: mono-devel-list at lists.ximian.com
> Subject: [Mono-dev] [PATCH] menu cssclass test and fix
> 
> Hello,
> 
> Please see the attachments for the test and the fix for it. 
> Please notice, that this nunit test must be run with net_2_0 
> profile. If no one objects, I will commit.
> 
> Andrew.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: menuclass.test.patch
Type: application/octet-stream
Size: 2977 bytes
Desc: menuclass.test.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060611/8ce7e1f5/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: menuclass.patch
Type: application/octet-stream
Size: 879 bytes
Desc: menuclass.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060611/8ce7e1f5/attachment-0001.obj 

From kostat at mainsoft.com  Sun Jun 11 11:37:43 2006
From: kostat at mainsoft.com (Konstantin Triger)
Date: Sun, 11 Jun 2006 08:37:43 -0700
Subject: [Mono-dev] [PATCH] System.Web.UI.WebControls/ObjectDataSourceView.cs
	- raise the OnDataSourceViewChanged event
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03136B16@dhost002-45.dex002.intermedia.net>

Hello,

 

When an ObjectDataSourceView changes, it should raise an OnDataSourceViewChanged event. The attached patch fixes that.

 

If no one objects, I'll commit.

 

Regards,

Konstantin Triger

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060611/2eae34a5/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OnDataSourceViewChanged.patch
Type: application/octet-stream
Size: 812 bytes
Desc: OnDataSourceViewChanged.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060611/2eae34a5/attachment.obj 

From robertj at gmx.net  Sun Jun 11 12:56:01 2006
From: robertj at gmx.net (Robert Jordan)
Date: Sun, 11 Jun 2006 18:56:01 +0200
Subject: [Mono-dev] Re: Abort with Non-Typical Exception Handler Layout on
	Mono 1.1.13.6
In-Reply-To: <7e9b97090606110648n4742f89dl3c682cbb2b4157b0@mail.gmail.com>
References: <7e9b97090606110648n4742f89dl3c682cbb2b4157b0@mail.gmail.com>
Message-ID: <e6hhv1$kkg$1@sea.gmane.org>

Almann T. Goo wrote:
> I am working on exception handler translation for JaCIL (CLI to JVM
> byte-code compiler) so I've been writing some sample cases in CIL to better
> understand the handler semantics in the CLI.  When running up this CIL code
> in Mono 1.1.13.6, the run time aborted on an assertion error.

Maybe the code doesn't pass verification. Test the assembly with pedump
or MS.NET's PEVerify.

Robert


> 
>    T_START:
>        ldstr   "Start"
>        call    void [mscorlib]System.Console::WriteLine(string)
>        leave.s COMPLETE
>    T1_END:
>        nop
>    T2_END:
> 
>    COMPLETE:
>        ret
> 
>    F1_START:
>        ldstr   "Finally1"
>        call    void [mscorlib]System.Console::WriteLine(string)
>        endfinally
>    F1_END:
> 
>    F2_START:
>        ldstr   "Finally2"
>        call    void [mscorlib]System.Console::WriteLine(string)
>        endfinally
>    F2_END:
> 
>    .try T_START to T1_END finally handler F1_START to F1_END
>    .try T_START to T2_END finally handler F2_START to F2_END
> 
> The error returned when trying to execute this code in Mono is:
> 
> $ mono sample.exe
> 
> ** ERROR **: file mini.c: line 9517 (mini_method_compile): assertion 
> failed:
> (tblock->native_offset)
> aborting...
> Aborted
> 
> If I move the method return and its label past the last finally handler the
> above code works (probably how most compilers would probably generate this
> type of code).  From what I understand of ECMA-335, it is legitimate to 
> have
> this case, and it indeed works in .NET Framework and Portable .NET as shown
> below:
> 
> D:\tmp> sample.exe
> Start
> Finally1
> Finally2
> 
> I could be missing something in ECMA-335 (which has parts of the handler
> spec in Partitions I, II, and III making more room for confusion) and PNet
> and .NET Framework are just simply lax in this regard.  This is certainly
> not a show stopper for my work, but I was wondering if anyone else has run
> into anything similar on Mono with regard to exception handlers.
> 
> Best regards,
> Almann
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From almann.goo at gmail.com  Sun Jun 11 20:29:49 2006
From: almann.goo at gmail.com (Almann T. Goo)
Date: Mon, 12 Jun 2006 10:29:49 +1000
Subject: [Mono-dev] Re: Abort with Non-Typical Exception Handler Layout on
	Mono 1.1.13.6
In-Reply-To: <e6hhv1$kkg$1@sea.gmane.org>
References: <7e9b97090606110648n4742f89dl3c682cbb2b4157b0@mail.gmail.com>
	<e6hhv1$kkg$1@sea.gmane.org>
Message-ID: <7e9b97090606111729j6323cbf1wb7ed7cbb79b6136a@mail.gmail.com>

On 6/12/06, Robert Jordan <robertj at gmx.net> wrote:
>
> Maybe the code doesn't pass verification. Test the assembly with pedump
> or MS.NET's PEVerify.
>

I ran this with PEVerify and got a couple of errors (I had changed the name
of the assembly so I wouldn't get confused with my other example cases):

Microsoft (R) .NET Framework PE Verifier  Version 1.1.4322.573
Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.

[IL]: Error: [d:\tmp\cs\middle.exe : Middle::Main] [exception #0x00000000]
Lexical nesting.
[IL]: Error: [d:\tmp\cs\middle.exe : Middle::Main] [offset 0x00000000]
fallthru the end of an exception block
2 Errors Verifying middle.exe

On closer inspection of ECMA-335, the reason for the first error was that my
previous code violates 12.4.2.7 of Partition I.  Specifically, the paragraph
regarding lexical nesting of protected blocks.  The reason for the second
error is a control fall through violation by the nop (that is unreachable in
my example), this violates 12.4.2.8.1 of Partition I which states that "exit
from a protected block cannot be accomplished via fall through."  Even
though the nop is unreachable, this is incorrect IL--easy to fix with a
leave that is still unreachable.

Based on that, I have re-formulated my examples and managed to get PEVerify
passable examples that still abort in Mono 1.1.13.6.

D:\tmp\cs>peverify sample.exe

Microsoft (R) .NET Framework PE Verifier  Version 1.1.4322.573
Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.

All Classes and Methods in sample.exe Verified

D:\tmp\cs>peverify sample2.exe

Microsoft (R) .NET Framework PE Verifier  Version 1.1.4322.573
Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.

All Classes and Methods in sample2.exe Verified

D:\tmp\cs>sample.exe
Start
Finally1
Finally2

D:\tmp\cs>sample2.exe
Start
Finally1

In Mono the following happens (same as with the original example):

$ mono sample2.exe

** ERROR **: file mini.c: line 9517 (mini_method_compile): assertion failed:
(tblock->native_offset)
aborting...
Aborted

$ mono sample.exe

** ERROR **: file mini.c: line 9517 (mini_method_compile): assertion failed:
(tblock->native_offset)
aborting...
Aborted

I have attached two CIL assembly source files that compile to the examples
used above.  They pass PEVerify and abort in Mono--I believe these two
examples are compliant to the ECMA-335 specification.

Best regards,
Almann

-- 
Almann T. Goo
almann.goo at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060612/8bb5df1a/attachment.html 
-------------- next part --------------
.assembly extern mscorlib {
    .ver 1:0:5000:0
}
.assembly sample2
{
    .ver  0:0:0:0
}
.module sample2.exe

.class public auto ansi beforefieldinit Sample
{
  .method public hidebysig static void Main(string[] args) cil managed
  {
    .entrypoint
    .maxstack  8

    T_START:
        ldstr   "Start"
        call    void [mscorlib]System.Console::WriteLine(string)
        leave.s COMPLETE
    T1_END:

    COMPLETE:
        ret

    F1_START:
        ldstr   "Finally1"
        call    void [mscorlib]System.Console::WriteLine(string)
        endfinally
    F1_END:

    .try T_START to T1_END finally handler F1_START to F1_END

  }
}
-------------- next part --------------
.assembly extern mscorlib {
    .ver 1:0:5000:0
}
.assembly sample
{
    .ver  0:0:0:0
}
.module sample.exe

.class public auto ansi beforefieldinit Sample
{
  .method public hidebysig static void Main(string[] args) cil managed
  {
    .entrypoint
    .maxstack  8

    T_START:
        ldstr   "Start"
        call    void [mscorlib]System.Console::WriteLine(string)
        leave.s COMPLETE
    T1_END:
    F1_START:
        ldstr   "Finally1"
        call    void [mscorlib]System.Console::WriteLine(string)
        endfinally
    F1_END:
        leave.s COMPLETE
    T2_END:

    COMPLETE:
        ret

    F2_START:
        ldstr   "Finally2"
        call    void [mscorlib]System.Console::WriteLine(string)
        endfinally
    F2_END:

    .try T_START to T1_END finally handler F1_START to F1_END
    .try T_START to T2_END finally handler F2_START to F2_END

  }
}

From andrews at mainsoft.com  Mon Jun 12 08:48:25 2006
From: andrews at mainsoft.com (Andrew Skiba)
Date: Mon, 12 Jun 2006 05:48:25 -0700
Subject: [Mono-dev] [PATCH] UrlPropertyAttribute support for
	PageThemeCompiler
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03136BEC@dhost002-45.dex002.intermedia.net>

Hello,

The attached test reveils the missing functionality in PageThemeCompiler
and the attached patch provides it. In addition to the test here is some
documentation on the issue (see Theme Graphics and Other Resources) :
http://msdn2.microsoft.com/en-us/library/ykzx33wh.aspx

if no one objects, I will commit.

Andrew.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UrlProperty.patch
Type: application/octet-stream
Size: 1774 bytes
Desc: UrlProperty.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060612/30a83572/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UrlProperty.test.patch
Type: application/octet-stream
Size: 5553 bytes
Desc: UrlProperty.test.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060612/30a83572/attachment-0001.obj 

From vargaz at gmail.com  Mon Jun 12 10:17:42 2006
From: vargaz at gmail.com (Zoltan Varga)
Date: Mon, 12 Jun 2006 16:17:42 +0200
Subject: [Mono-dev] Re: Abort with Non-Typical Exception Handler Layout on
	Mono 1.1.13.6
In-Reply-To: <7e9b97090606111729j6323cbf1wb7ed7cbb79b6136a@mail.gmail.com>
References: <7e9b97090606110648n4742f89dl3c682cbb2b4157b0@mail.gmail.com>
	<e6hhv1$kkg$1@sea.gmane.org>
	<7e9b97090606111729j6323cbf1wb7ed7cbb79b6136a@mail.gmail.com>
Message-ID: <295e750a0606120717x7e6099b0xd51726e5c50fca69@mail.gmail.com>

Hi,

 This is now fixed in SVN.

       Zoltan

On 6/12/06, Almann T. Goo <almann.goo at gmail.com> wrote:
> On 6/12/06, Robert Jordan <robertj at gmx.net> wrote:
> > Maybe the code doesn't pass verification. Test the assembly with pedump
> > or MS.NET's PEVerify.
> >
>
> I ran this with PEVerify and got a couple of errors (I had changed the name
> of the assembly so I wouldn't get confused with my other example cases):
>
> Microsoft (R) .NET Framework PE Verifier  Version 1.1.4322.573
>  Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.
>
>  [IL]: Error: [d:\tmp\cs\middle.exe : Middle::Main] [exception #0x00000000]
> Lexic al nesting.
> [IL]: Error: [d:\tmp\cs\middle.exe : Middle::Main] [offset 0x00000000]
> fallthru the end of an exception block
>  2 Errors Verifying middle.exe
>
> On closer inspection of ECMA-335, the reason for the first error was that my
> previous code violates 12.4.2.7 of Partition I.  Specifically, the paragraph
> regarding lexical nesting of protected blocks.  The reason for the second
> error is a control fall through violation by the nop (that is unreachable in
> my example), this violates 12.4.2.8.1 of Partition I which states that "exit
> from a protected block cannot be accomplished via fall through."  Even
> though the nop is unreachable, this is incorrect IL--easy to fix with a
> leave that is still unreachable.
>
> Based on that, I have re-formulated my examples and managed to get PEVerify
> passable examples that still abort in Mono 1.1.13.6.
>
> D:\tmp\cs>peverify sample.exe
>
> Microsoft (R) .NET Framework PE Verifier  Version 1.1.4322.573
>  Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.
>
> All Classes and Methods in sample.exe Verified
>
> D:\tmp\cs>peverify sample2.exe
>
> Microsoft (R) .NET Framework PE Verifier  Version 1.1.4322.573
>  Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.
>
> All Classes and Methods in sample2.exe Verified
>
> D:\tmp\cs>sample.exe
>  Start
> Finally1
>  Finally2
>
> D:\tmp\cs> sample2.exe
> Start
>  Finally1
>
> In Mono the following happens (same as with the original example):
>
> $ mono sample2.exe
>
> ** ERROR **: file mini.c: line 9517 (mini_method_compile): assertion failed:
> (tblock->native_offset)
> aborting...
>  Aborted
>
> $ mono sample.exe
>
>  ** ERROR **: file mini.c: line 9517 (mini_method_compile): assertion
> failed: (tblock->native_offset)
>  aborting...
> Aborted
>
> I have attached two CIL assembly source files that compile to the examples
> used above.  They pass PEVerify and abort in Mono--I believe these two
> examples are compliant to the ECMA-335 specification.
>
> Best regards,
> Almann
>
> --
> Almann T. Goo
> almann.goo at gmail.com
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>


From eyala at mainsoft.com  Mon Jun 12 11:38:30 2006
From: eyala at mainsoft.com (Eyal Alaluf)
Date: Mon, 12 Jun 2006 18:38:30 +0300 (IDT)
Subject: [Mono-Dev] Cecil bug with Custom Attributes with enum parameters
In-Reply-To: <448713F0.6020508@evain.net>
References: <Pine.GSO.4.60.0606071837470.13367@yen>
	<448713F0.6020508@evain.net>
Message-ID: <Pine.GSO.4.60.0606121814020.20476@yen>

Hi, JB.

Attached is a patch containing the assembly resolver and its usage to resolve
the actual enum type definition ad the enum underlying type.
Several notes about the patch:
    * The resolver is very simple. It searches for <assembly name>.dll in a
      given search path.
        * It doesn't handle issues that may come to mind like thread safety,
          circular dependencies between assemblies, etc.`
    * Since Cecil does not have a search path defined, I made the resolver
      optional as a public field of AssemblyFactory.
    * I also declared an interface for the resolver that will allow more
      complex and customized implementation.
    * I'd recommend adding the "GetEnumUnderlyingType" as a public service.
      Maybe it makes sense to define an IEnumTypeDfinition and add to it an
      "UnderlyingType" property?

I can propose as an alternative design:
    1. Delay load the custom attributes
    2. Provide a way to resolve all the type references in the assembly.
         * Add an "ITypeDefinition TypeDef" property to "ITypeReference".
         * After initial load of the assembly, the developer can loop over the
           assembly's type references and set this property to the resolved type.
    3. The custom attribute code will use the new property whenever it has an
       unresolved type reference.
As this design is more complex and not developer friendly, I didn't follow it
through. Its advantage is that it avoids very nicely the issues of locking and
circular dependencies.
I'd welcome your comments.

Eyal.

On Wed, 7 Jun 2006, Jb Evain wrote:

> Date: Wed, 07 Jun 2006 19:59:12 +0200
> From: Jb Evain <mono at evain.net>
> To: Eyal Alaluf <eyala at mainsoft.com>
> Cc: Vladislav Spivak <spivak at mainsoft.com>, mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-Dev] Cecil bug with Custom Attributes with enum parameters
> 
> Hi Eyal,
>
>> Do you have any plans to resolve this issue? (I assume from the comment
>> in the code
>> that you are familiar with it)
>> What is the design you are looking for in this case? If you want to have
>> Cecil
>> loading the Enum we can contribute our Resolver that is Cecil based.
>
> The plan is indeed to load the assembly which contains the type definition. 
> If you can contribute your resolver, I'll see how I can integrate it. Then 
> I'll add some kind of ForceLoad method if the custom attribute is not 
> readable at first try.
>
> Thanks,
>
> Jb
>
>
-------------- next part --------------
Index: Mono.Cecil/AssemblyResolver.cs

===================================================================

--- Mono.Cecil/AssemblyResolver.cs	(revision 0)

+++ Mono.Cecil/AssemblyResolver.cs	(revision 0)

@@ -0,0 +1,76 @@

+//

+// AssemblyResolver.cs

+//

+// Author:

+//   Eyal Alaluf (eyala at mainsoft.com), Vladislav Spivak (spivak at mainsoft.com)

+//

+// (C) 2006 Mainsoft Co.

+//

+// Permission is hereby granted, free of charge, to any person obtaining

+// a copy of this software and associated documentation files (the

+// "Software"), to deal in the Software without restriction, including

+// without limitation the rights to use, copy, modify, merge, publish,

+// distribute, sublicense, and/or sell copies of the Software, and to

+// permit persons to whom the Software is furnished to do so, subject to

+// the following conditions:

+//

+// The above copyright notice and this permission notice shall be

+// included in all copies or substantial portions of the Software.

+//

+// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

+// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

+// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND

+// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE

+// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION

+// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION

+// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

+//

+

+using System;

+using System.Collections;

+using System.IO;

+

+namespace Mono.Cecil

+{

+	/// <summary>

+	/// Summary description for Resolver.

+	/// </summary>

+	/// 

+

+	public class AssemblyResolver : IAssemblyResolver

+	{

+		private readonly string [] _libpath;		

+		private readonly Hashtable _asmdefs = new Hashtable();

+

+		public AssemblyResolver(string libpath)

+		{

+			_libpath = libpath.Split(';');

+		}

+

+		public IAssemblyDefinition GetAssembly(string name)

+		{

+			if (_asmdefs.ContainsKey(name))

+				return (IAssemblyDefinition)_asmdefs[name];

+

+			foreach(string dir in _libpath)

+			{

+				//try dlls first

+				string finalname = null;

+				if (File.Exists(dir+"\\"+name + ".dll"))

+					finalname = dir+"\\"+name + ".dll";

+				else if (File.Exists(dir+"\\"+name + ".exe"))

+					finalname = dir+"\\"+name + ".exe";

+				else if (File.Exists(dir+"\\"+name))

+					finalname = dir+"\\"+name;

+				else

+					continue;

+

+				IAssemblyDefinition asm = AssemblyFactory.GetAssembly (finalname);

+				_asmdefs.Add(name, asm);

+				return asm;

+			}

+

+			throw new FileNotFoundException(name + ".dll");

+		}

+	}

+}

Index: Mono.Cecil/AssemblyFactory.cs

===================================================================

--- Mono.Cecil/AssemblyFactory.cs	(revision 61523)

+++ Mono.Cecil/AssemblyFactory.cs	(working copy)

@@ -37,6 +37,8 @@

 
 	public sealed class AssemblyFactory {
 
+		public static IAssemblyResolver Resolver;
+
 		AssemblyFactory ()
 		{
 		}
Index: Mono.Cecil/IAssemblyResolver.cs

===================================================================

--- Mono.Cecil/IAssemblyResolver.cs	(revision 0)

+++ Mono.Cecil/IAssemblyResolver.cs	(revision 0)

@@ -0,0 +1,41 @@

+//

+// IAssemblyResolver.cs

+//

+// Author:

+//   Eyal Alaluf (eyala at mainsoft.com)

+//

+// (C) 2006 Mainsoft Co.

+//

+// Permission is hereby granted, free of charge, to any person obtaining

+// a copy of this software and associated documentation files (the

+// "Software"), to deal in the Software without restriction, including

+// without limitation the rights to use, copy, modify, merge, publish,

+// distribute, sublicense, and/or sell copies of the Software, and to

+// permit persons to whom the Software is furnished to do so, subject to

+// the following conditions:

+//

+// The above copyright notice and this permission notice shall be

+// included in all copies or substantial portions of the Software.

+//

+// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

+// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

+// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND

+// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE

+// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION

+// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION

+// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

+//

+

+using System;

+

+namespace Mono.Cecil

+{

+	/// <summary>

+	/// Summary description for Resolver.

+	/// </summary>

+	/// 

+	public interface IAssemblyResolver  

+	{

+		IAssemblyDefinition GetAssembly(string name);

+	}

+}

Index: Mono.Cecil.Signatures/SignatureReader.cs

===================================================================

--- Mono.Cecil.Signatures/SignatureReader.cs	(revision 61523)

+++ Mono.Cecil.Signatures/SignatureReader.cs	(working copy)

@@ -700,13 +700,35 @@

 					byte [] bytes = br.ReadBytes (length);
 					elem.Value = Encoding.UTF8.GetString (bytes, 0, bytes.Length);
 				}
-
 				return elem;
 			}
 
 			elem.String = elem.Type = elem.BoxedValueType = false;
+			if (!readSimpleValue(br, ref elem, elem.ElemType)) {
+				ITypeReference typeRef = GetEnumUnderlyingType(elem.ElemType);
+				if (typeRef == null || !readSimpleValue(br, ref elem, typeRef))
+					read = false;
+			}
 
-			switch (elemName) {
+			return elem;
+		}
+
+		private ITypeReference GetEnumUnderlyingType(ITypeReference enumType)
+		{
+			ITypeDefinition type = enumType as ITypeDefinition;
+			if (type == null && AssemblyFactory.Resolver != null) 
+			{
+				IAssemblyDefinition asm = AssemblyFactory.Resolver.GetAssembly(enumType.Scope.Name);
+				type = asm.MainModule.Types[enumType.FullName];
+			}
+			if (type != null && type.IsEnum)
+				return type.Fields.GetField("value__").FieldType;
+			return null;
+		}
+
+		bool readSimpleValue(BinaryReader br, ref CustomAttrib.Elem elem, ITypeReference type)
+		{
+			switch (type.FullName) {
 			case Constants.Boolean :
 				elem.Value = br.ReadByte () == 1;
 				break;
@@ -744,12 +766,10 @@

 				elem.Value = br.ReadUInt64 ();
 				break;
 			default : // enum
-				read = false;
-				return elem;
+				return false;
 			}
-
 			elem.Simple = true;
-			return elem;
+			return true;
 		}
 
 		// elem in named args, only have an ElementType

From eyala at mainsoft.com  Mon Jun 12 12:24:59 2006
From: eyala at mainsoft.com (Eyal Alaluf)
Date: Mon, 12 Jun 2006 19:24:59 +0300 (IDT)
Subject: [Mono-Dev] Cecil bug with Custom Attributes with enum parameters
In-Reply-To: <Pine.GSO.4.60.0606121814020.20476@yen>
References: <Pine.GSO.4.60.0606071837470.13367@yen>
	<448713F0.6020508@evain.net>
	<Pine.GSO.4.60.0606121814020.20476@yen>
Message-ID: <Pine.GSO.4.60.0606121923200.20476@yen>

Attaching changes to makefiles as well.

Date: Mon, 12 Jun 2006 18:38:30 +0300 (IDT)
From: Eyal Alaluf <eyala at mainsoft.com>
To: Jb Evain <mono at evain.net>
Cc: Vladislav Spivak <spivak at mainsoft.com>, mono-devel-list at lists.ximian.com
Subject: Re: [Mono-Dev] Cecil bug with Custom Attributes with enum parameters

Hi, JB.

Attached is a patch containing the assembly resolver and its usage to resolve
the actual enum type definition ad the enum underlying type.
Several notes about the patch:
   * The resolver is very simple. It searches for <assembly name>.dll in a
     given search path.
       * It doesn't handle issues that may come to mind like thread safety,
         circular dependencies between assemblies, etc.`
   * Since Cecil does not have a search path defined, I made the resolver
     optional as a public field of AssemblyFactory.
   * I also declared an interface for the resolver that will allow more
     complex and customized implementation.
   * I'd recommend adding the "GetEnumUnderlyingType" as a public service.
     Maybe it makes sense to define an IEnumTypeDfinition and add to it an
     "UnderlyingType" property?

I can propose as an alternative design:
   1. Delay load the custom attributes
   2. Provide a way to resolve all the type references in the assembly.
        * Add an "ITypeDefinition TypeDef" property to "ITypeReference".
        * After initial load of the assembly, the developer can loop over the
          assembly's type references and set this property to the resolved 
type.
   3. The custom attribute code will use the new property whenever it has an
      unresolved type reference.
As this design is more complex and not developer friendly, I didn't follow it
through. Its advantage is that it avoids very nicely the issues of locking
and circular dependencies.
I'd welcome your comments.

Eyal.

On Wed, 7 Jun 2006, Jb Evain wrote:

> Date: Wed, 07 Jun 2006 19:59:12 +0200
> From: Jb Evain <mono at evain.net>
> To: Eyal Alaluf <eyala at mainsoft.com>
> Cc: Vladislav Spivak <spivak at mainsoft.com>, 
> mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-Dev] Cecil bug with Custom Attributes with enum 
> parameters
> 
> Hi Eyal,
> 
>> Do you have any plans to resolve this issue? (I assume from the comment
>> in the code
>> that you are familiar with it)
>> What is the design you are looking for in this case? If you want to have
>> Cecil
>> loading the Enum we can contribute our Resolver that is Cecil based.
> 
> The plan is indeed to load the assembly which contains the type 
> definition. If you can contribute your resolver, I'll see how I can 
> integrate it. Then I'll add some kind of ForceLoad method if the custom 
> attribute is not readable at first try.
> 
> Thanks,
> 
> Jb
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cecil.patch
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060612/87decefc/attachment.pl 
-------------- next part --------------
Index: Mono.Cecil.dll.sources

===================================================================

--- Mono.Cecil.dll.sources	(revision 61523)

+++ Mono.Cecil.dll.sources	(working copy)

@@ -118,6 +118,7 @@

 ./Mono.Cecil/ITypeDefinitionCollection.cs
 ./Mono.Cecil/ITypeReference.cs
 ./Mono.Cecil/ITypeReferenceCollection.cs
+./Mono.Cecil/IAssemblyResolver.cs
 ./Mono.Cecil/ITypeSpecification.cs
 ./Mono.Cecil/LinkedResource.cs
 ./Mono.Cecil/ManifestResourceAttributes.cs
@@ -172,6 +173,7 @@

 ./Mono.Cecil/TypeDefinitionCollection.cs
 ./Mono.Cecil/TypeReference.cs
 ./Mono.Cecil/TypeReferenceCollection.cs
+./Mono.Cecil/AssemblyResolver.cs
 ./Mono.Cecil/TypeSpecification.cs
 ./Mono.Cecil/VariantType.cs
 ./Mono.Cecil.Binary/BaseImageVisitor.cs
Index: Mono.Cecil.csproj

===================================================================

--- Mono.Cecil.csproj	(revision 61523)

+++ Mono.Cecil.csproj	(working copy)

@@ -310,6 +310,7 @@

     <Compile Include="Mono.Cecil\ITypeDefinitionCollection.cs" />

     <Compile Include="Mono.Cecil\ITypeReference.cs" />

     <Compile Include="Mono.Cecil\ITypeReferenceCollection.cs" />

+    <Compile Include="Mono.Cecil\ITypeResolver.cs" />

     <Compile Include="Mono.Cecil\ITypeSpecification.cs" />

     <Compile Include="Mono.Cecil\LinkedResource.cs" />

     <Compile Include="Mono.Cecil\ManifestResourceAttributes.cs" />

@@ -364,6 +365,7 @@

     <Compile Include="Mono.Cecil\TypeDefinitionCollection.cs" />

     <Compile Include="Mono.Cecil\TypeReference.cs" />

     <Compile Include="Mono.Cecil\TypeReferenceCollection.cs" />

+    <Compile Include="Mono.Cecil\TypeResolver.cs" />

     <Compile Include="Mono.Cecil\TypeSpecification.cs" />

     <Compile Include="Mono.Cecil\VariantType.cs" />

     <Compile Include="Mono.Xml\MiniParser.cs" />

@@ -386,4 +388,4 @@

   <ItemGroup>

     <Reference Include="System" />

   </ItemGroup>

-</Project>

\ No newline at end of file

+</Project>


From charlie at pooleconsulting.com  Mon Jun 12 14:08:48 2006
From: charlie at pooleconsulting.com (Charlie Poole)
Date: Mon, 12 Jun 2006 11:08:48 -0700
Subject: [Mono-dev] Ann: NUnit 2.4 Beta 1 Release
Message-ID: <003301c68e4b$433fe4b0$6400a8c0@FERRARI>

Hi All,

The first Beta of NUnit 2.4 is now available on from any of the usual
places:
    http://nunit.org/?p=download
    http://nunit.com/nunit/?p=download
    http://sourceforge.net/project/nunit

The NUnit team has spent a lot of time on this release and we're proud of
its new features. The crashing problems in the Alpha release have been fixed
and we feel it would be reasonable for developers to use the new release for
their individual testing. We recommend sticking with the production release
for your continuous integration or nightly test runs.

This note gives some of the highlights of the release. Full release notes
are available at
http://nunit.org?p=releaseNotes&r=2.4 or
http://nunit.com/nunit/?p=releaseNotes&r=2.4

GENERAL

* In addition to the .Net 1.1 and 2.0 Windows platforms, we now build and
test NUnit using the Mono 1.0 and 2.0 profiles on Windows and Linux. A
number of tests are currently excluded under Linux and we are continuing to
work on them. We believe the problems are solely in the tests, but we need
to get them working to be sure.

FRAMEWORK

* New asserts have been added, including CollectionAssert and FileAssert
classes.

* A new SetUpFixtureAttribute allows one-time initialization and cleanup for
all tests in a given namespace or across the entire assembly.

* ExpectedExceptionAttribute now allows verifying the message of an
exception based on a substring or a regular expression.

* There are several new options relating to how assemblies are loaded and
run.
   - Use of a separate AppDomain for each assembly
   - Merging of multiple assemblies in the test tree so that corresponding
namespaces in each assembly are combined. This option requires use of a
single AppDomain.
   - Elimination of the automatic namespace suites, so that a flat list of
fixtures is presented. This option may be combined with either of the other
two.

  NOTE: In the Beta release, only the first option is available using the
Console runner. All three are available in the Gui, through the Options
dialog.

* User fixture objects are no longer re-used across test runs. They are
created at the time the fixture is being executed and destroyed on
completion. If the fixture object implements IDisposeable, then Dispose is
called on it before it is released.

CONSOLE RUNNER

* When multiple assemblies are listed on the console runner command line,
they are loaded into separate AppDomains. This allows use of separate
configs for each assembly.

* The console runner writes its Trace output at all times, not just when run
under the debugger.

* The /include and /exclude options may now be combined.

GUI RUNNER

* The Gui runner is now called "nunit.exe"

* The test tree now uses bitmaps that are distinguishable without regard to
color. The actual bitmaps used may be tailored by the user by replacing the
files that contain them.

* A new 'Test' menu contains entries to run the selected test, all tests or
tests that failed on the last run. These are accessible by shortcut keys,
permitting single keystroke execution of the tests.

* The 'View' menu has been reorganized and contains added capabilities,
including changing the font of the display, switching to a new 'mini-gui'
display, and activating or deactivating various parts of the display.

* The properties dialog has been reorganized to use a single window and
displays more information about the test.

* A new option permits automatically re-running the tests when an assembly
has changed.

EXTENSIBILITY

* Add-ins may now be installed by copying them to the NUnit bin\addins
subdirectory.





From jaroslaw.pendowski at gmail.com  Mon Jun 12 16:52:19 2006
From: jaroslaw.pendowski at gmail.com (shw)
Date: Mon, 12 Jun 2006 22:52:19 +0200
Subject: [Mono-dev] DllImport on mono@linux
Message-ID: <efe3dca40606121352k70fc1273o50faad8f904b06cd@mail.gmail.com>

Hi!
I've made some app with mono. To generate and check serial numbers it
uses binary library.
On windows everything is working - on linux - not.

I've tried to compile some different ways and came to compile library with:
g++ -shared -fPIC -o libpossible-keys.so *.cpp

with this kind of compilation mono finds library, finds function but
still throws an error:

Mono-INFO: DllImport attempting to load: 'possible-keys'.
Mono-INFO: DllImport loading location: 'libpossible-keys.so'.
Mono-INFO: DllImport error loading library: 'libpossible-keys.so: nie
mo??na otworzy? pliku obiektu dzielonego: Nie ma takiego pliku ani
katalogu'. (in english it is sth like "couldn't open shared object
file: no file or directory")
Mono-INFO: DllImport loading library: './libpossible-keys.so'.
Mono-INFO: Searching for 'CreateActivation'.
Mono-INFO: Probing 'CreateActivation'.
Mono-INFO: Found as 'CreateActivation'.
Wrapper tester
*** glibc detected *** free(): invalid next size (fast): 0x0824cae0 ***

What is wrong?
The same code on Windows works, when i compile source without -shared
and run with sth like
./libpossible-keys.so arguments_to_generate_activation_key
it works, but as method with DllImport - not.

From vargaz at gmail.com  Mon Jun 12 16:58:15 2006
From: vargaz at gmail.com (Zoltan Varga)
Date: Mon, 12 Jun 2006 22:58:15 +0200
Subject: [Mono-dev] DllImport on mono@linux
In-Reply-To: <efe3dca40606121352k70fc1273o50faad8f904b06cd@mail.gmail.com>
References: <efe3dca40606121352k70fc1273o50faad8f904b06cd@mail.gmail.com>
Message-ID: <295e750a0606121358u7b7084cbt778cacb011c1837a@mail.gmail.com>

                               Hi,

  An assert in free () usually indicates memory usage problems in the managed
signature of your function. You should read:

http://www.mono-project.com/Interop_with_Native_Libraries

and possibly the MSDN docs about pinvoke as well, especially the memory
management rules (i.e. who frees what).

               Zoltan

On 6/12/06, shw <jaroslaw.pendowski at gmail.com> wrote:
> Hi!
> I've made some app with mono. To generate and check serial numbers it
> uses binary library.
> On windows everything is working - on linux - not.
>
> I've tried to compile some different ways and came to compile library with:
> g++ -shared -fPIC -o libpossible-keys.so *.cpp
>
> with this kind of compilation mono finds library, finds function but
> still throws an error:
>
> Mono-INFO: DllImport attempting to load: 'possible-keys'.
> Mono-INFO: DllImport loading location: 'libpossible-keys.so'.
> Mono-INFO: DllImport error loading library: 'libpossible-keys.so: nie
> mo??na otworzy? pliku obiektu dzielonego: Nie ma takiego pliku ani
> katalogu'. (in english it is sth like "couldn't open shared object
> file: no file or directory")
> Mono-INFO: DllImport loading library: './libpossible-keys.so'.
> Mono-INFO: Searching for 'CreateActivation'.
> Mono-INFO: Probing 'CreateActivation'.
> Mono-INFO: Found as 'CreateActivation'.
> Wrapper tester
> *** glibc detected *** free(): invalid next size (fast): 0x0824cae0 ***
>
> What is wrong?
> The same code on Windows works, when i compile source without -shared
> and run with sth like
> ./libpossible-keys.so arguments_to_generate_activation_key
> it works, but as method with DllImport - not.
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>

From robertj at gmx.net  Mon Jun 12 17:55:02 2006
From: robertj at gmx.net (Robert Jordan)
Date: Mon, 12 Jun 2006 23:55:02 +0200
Subject: [Mono-dev] Re: DllImport on mono@linux
In-Reply-To: <efe3dca40606121352k70fc1273o50faad8f904b06cd@mail.gmail.com>
References: <efe3dca40606121352k70fc1273o50faad8f904b06cd@mail.gmail.com>
Message-ID: <e6knrm$jm4$1@sea.gmane.org>

shw wrote:
> Hi!
> I've made some app with mono. To generate and check serial numbers it
> uses binary library.
> On windows everything is working - on linux - not.
> 
> I've tried to compile some different ways and came to compile library with:
> g++ -shared -fPIC -o libpossible-keys.so *.cpp
> 
> with this kind of compilation mono finds library, finds function but
> still throws an error:
> 
> Mono-INFO: DllImport attempting to load: 'possible-keys'.
> Mono-INFO: DllImport loading location: 'libpossible-keys.so'.
> Mono-INFO: DllImport error loading library: 'libpossible-keys.so: nie
> mo??na otworzy? pliku obiektu dzielonego: Nie ma takiego pliku ani
> katalogu'. (in english it is sth like "couldn't open shared object
> file: no file or directory")
> Mono-INFO: DllImport loading library: './libpossible-keys.so'.
> Mono-INFO: Searching for 'CreateActivation'.
> Mono-INFO: Probing 'CreateActivation'.
> Mono-INFO: Found as 'CreateActivation'.
> Wrapper tester
> *** glibc detected *** free(): invalid next size (fast): 0x0824cae0 ***
> 
> What is wrong?
> The same code on Windows works, when i compile source without -shared
> and run with sth like
> ./libpossible-keys.so arguments_to_generate_activation_key
> it works, but as method with DllImport - not.

This sounds to me like this bad sample:

// C
char *foo ()
{
	return "bar";
}

// C#
[DllImport(...)]
static extern string foo ();

The runtime always tries to release the returned pointer with free (),
when the managed signature has a string retval.

Of course, this doesn't work in the sample above, because "bar" is
a constant. MS.NET doesn't crash on that, maybe because Win32's
free () is able to detect this case.

Either return freeable memory (for the sample: return strdup ("bar"))
or change the signature to IntPtr foo () and marshal the retval
yourself.

Robert



From allan at counterpop.net  Mon Jun 12 18:20:21 2006
From: allan at counterpop.net (Allan Hsu)
Date: Mon, 12 Jun 2006 15:20:21 -0700
Subject: [Mono-dev] Re: [Mono-osx] anybody noticed a mach port leak?
In-Reply-To: <1149821769.6167.346.camel@linux.site>
References: <CEA516F0-7F67-41D3-8C1A-9367B4D41057@counterpop.net>
	<1149821769.6167.346.camel@linux.site>
Message-ID: <81DAE120-AD04-4436-984E-187EE0D633CB@counterpop.net>

On Jun 8, 2006, at 7:56 PM, Miguel de Icaza wrote:

>> I'm having a hard time tracking down a mach port leak in imeem. Some
>> roundabout debugging leads me to believe it's somewhere in the
>> networking-related portions of either our managed code or the Mono
>> runtime. Has anybody else noticed their mach port counts rising over
>> time? If so, what does your application do?
>
> A test case narrowing the problem would be the first step.

I've done some more investigation and I've filed a new bug and marked  
the old one as a duplicate of the new one:

http://bugs.ximian.com/show_bug.cgi?id=78628

It looks like the problem has to do with garbage collection and  
threading and it should effect just about anybody that uses threads  
under Mono on OS X. I attached a rough GC patch to the bug that  
halves the number of ports leaked in some situations, but does not  
entirely fix the problem. The patch also has a lot of whitespace  
changes I made so I could properly read the code (sorry about that).

At this point, I'm not sure what else to do. I'm wondering if the  
rest of the leaks could be caused by another place where  
mach_port_deallocate() isn't being called when it should be. I'm no  
mach expert, so I'm not sure where else to look.

	-Allan
--
Allan Hsu <allan at counterpop dot net>
1E64 E20F 34D9 CBA7 1300  1457 AC37 CBBB 0E92 C779



From alexmipego at gmail.com  Mon Jun 12 19:25:44 2006
From: alexmipego at gmail.com (Alexandre Miguel Pedro Gomes)
Date: Tue, 13 Jun 2006 00:25:44 +0100
Subject: [Mono-dev] Re: [Mono-osx] anybody noticed a mach port leak?
In-Reply-To: <81DAE120-AD04-4436-984E-187EE0D633CB@counterpop.net>
References: <CEA516F0-7F67-41D3-8C1A-9367B4D41057@counterpop.net>
	<1149821769.6167.346.camel@linux.site>
	<81DAE120-AD04-4436-984E-187EE0D633CB@counterpop.net>
Message-ID: <170f4a080606121625s7bb2443dr4023a526267a3b9e@mail.gmail.com>

Not a big fan of C, neither I do have a OS X machine to test but a simple
grep -R "mach_port" . shows that there is no deallocate.

On 6/12/06, Allan Hsu <allan at counterpop.net> wrote:
>
> On Jun 8, 2006, at 7:56 PM, Miguel de Icaza wrote:
>
> >> I'm having a hard time tracking down a mach port leak in imeem. Some
> >> roundabout debugging leads me to believe it's somewhere in the
> >> networking-related portions of either our managed code or the Mono
> >> runtime. Has anybody else noticed their mach port counts rising over
> >> time? If so, what does your application do?
> >
> > A test case narrowing the problem would be the first step.
>
> I've done some more investigation and I've filed a new bug and marked
> the old one as a duplicate of the new one:
>
> http://bugs.ximian.com/show_bug.cgi?id=78628
>
> It looks like the problem has to do with garbage collection and
> threading and it should effect just about anybody that uses threads
> under Mono on OS X. I attached a rough GC patch to the bug that
> halves the number of ports leaked in some situations, but does not
> entirely fix the problem. The patch also has a lot of whitespace
> changes I made so I could properly read the code (sorry about that).
>
> At this point, I'm not sure what else to do. I'm wondering if the
> rest of the leaks could be caused by another place where
> mach_port_deallocate() isn't being called when it should be. I'm no
> mach expert, so I'm not sure where else to look.
>
>         -Allan
> --
> Allan Hsu <allan at counterpop dot net>
> 1E64 E20F 34D9 CBA7 1300  1457 AC37 CBBB 0E92 C779
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>



-- 
Alexandre Gomes, Portugal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060613/7aed124f/attachment.html 

From mono-devel at fluggo.com  Mon Jun 12 20:44:52 2006
From: mono-devel at fluggo.com (Brian Crowell)
Date: Mon, 12 Jun 2006 19:44:52 -0500
Subject: [Mono-dev] Version-specific binding on non-strong-name assemblies:
	bug?
Message-ID: <448E0A84.8020707@fluggo.com>


I have an application that creates a new AppDomain under Mono. The application 
is under /home at the moment. It loads into this assembly, through a 
cross-AppDomain delegate, a file called hostee.dll, which lives in 
/var/lib/klotron-monitor/images. (The domain's ApplicationBase is set to this 
directory when it is created.)

hostee.dll references yet another assembly in /var/lib/klotron-monitor/images. 
However, if the version of that assembly does not match the version specified in 
hostee.dll, I get an assembly-not-found error, a SIGSEGV, a stack trace, a 
native stack trace, and then a command prompt:

===============================================================
Host Proxy: Loading common interface...
Host Proxy: Loading hostee...
/var/lib/klotron-monitor/images/hostee.dll

** (bin/MonitorHost.exe:13141): WARNING **: The following assembly referenced 
from /var/lib/klotron-monitor/images/hostee.dll could not be loaded:
      Assembly:   Clotron.MobileResource    (assemblyref_index=1)
      Version:    3.0.2354.22385
      Public Key: (none)
The assembly was not found in the Global Assembly Cache, a path listed in the 
MONO_PATH environment variable, or in the location of the executing assembly 
(/var/lib/klotron-monitor/images).


** (bin/MonitorHost.exe:13141): WARNING **: The class 
Clotron.MobileResource.Server.Interfaces.INetworkMonitorService could not be 
loaded, used in Clotron.MobileResource, Version=3.0.2354.22385, Culture=neutral

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

Stacktrace:

in (wrapper managed-to-native) System.Reflection.Assembly:InternalGetType 
(System.Reflection.Module,string,bool,bool) <0x4>
in (wrapper managed-to-native) System.Reflection.Assembly:InternalGetType 
(System.Reflection.Module,string,bool,bool) <0xffffffc6>
in System.Reflection.Assembly:GetType (string,bool,bool) (at 
/tmp/scratch/BUILD/mono-1.1.14/mcs/class/corlib/System.Reflection/Assembly.cs:341)
in System.Activator:CreateInstance 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
(at /tmp/scratch/BUILD/mono-1.1.14/mcs/class/corlib/System/Activator.cs:148)
in System.AppDomain:CreateInstance 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
(at /tmp/scratch/BUILD/mono-1.1.14/mcs/class/corlib/System/AppDomain.cs:291)
in (wrapper remoting-invoke-with-check) System.AppDomain:CreateInstance 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
<0xffffffb6>
in System.AppDomain:CreateInstanceAndUnwrap 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
(at /tmp/scratch/BUILD/mono-1.1.14/mcs/class/corlib/System/AppDomain.cs:311)
in (wrapper remoting-invoke-with-check) System.AppDomain:CreateInstanceAndUnwrap 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
<0xfffffdb4>
in (wrapper xdomain-dispatch) System.AppDomain:CreateInstanceAndUnwrap 
(object,byte[]&,byte[]&,string,string,bool) <0xfffe33be>
in (wrapper xdomain-invoke) System.AppDomain:CreateInstanceAndUnwrap 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
<0xffffff76>
in (wrapper remoting-invoke-with-check) System.AppDomain:CreateInstanceAndUnwrap 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
<0xfff9b350>
in Loader.Class1:LoadDomain (string) <0x1a8>
in Loader.Class1:LoadDefaultImageDomain () <0x59>
in Loader.Class1:ContactService () <0x432>
in Loader.Class1:HandleTimerElapsed (object,System.Timers.ElapsedEventArgs) <0x1c>
in (wrapper delegate-invoke) 
System.MulticastDelegate:invoke_void_object_ElapsedEventArgs 
(object,System.Timers.ElapsedEventArgs) <0xffffdd57>
in System.Timers.Timer:Callback (object) <0x1cf>
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object 
(object) <0xffffff95>
in (wrapper runtime-invoke) System.Object:runtime_invoke_void_object 
(object,intptr,intptr,intptr) <0xc72643cf>

Native stacktrace:

         mono(mono_handle_native_sigsegv+0xbb) [0x815385b]
         mono [0x813e1bf]
         [0xffffe440]
         mono [0x808b683]
         mono(mono_class_init+0x555) [0x808ed75]
         mono [0x80ee9ba]
         mono(mono_reflection_get_type+0x2b) [0x80eeb3b]
         mono [0x80c900e]
         [0x414cf04c]
         [0x414cefdf]
         [0x414dd1d2]
         [0x414dd11e]
         [0x414dd0ae]
         [0x414dcf77]
         [0x414dcf06]
         [0x414dcbcd]
         [0x414bfc7f]
         [0x414bfaaf]
         [0x4145ad59]
         [0x4145aad2]
         [0x40edc8fb]
         [0x40edc295]
         [0x40edc262]
         [0x40ed9f68]
         [0x40ed9d81]
         [0x40ed9cce]
         mono [0x813e070]
         mono(mono_runtime_invoke+0x27) [0x80d7847]
         mono(mono_runtime_invoke_array+0x270) [0x80d8d30]
         mono(mono_message_invoke+0xc5) [0x80da8f5]
         mono [0x80a5e6f]
         mono [0x80a6699]
         mono [0x809a7d2]
         mono [0x80f6a57]
         mono [0x81156b5]
         /lib/tls/libpthread.so.0 [0x400cf297]
         /lib/tls/libc.so.6(__clone+0x5e) [0x401ca37e]
Aborted
===============================================================

I was under the impression that when assemblies were not signed with strong 
names, they didn't get version checking. They clearly do here, though, because 
when the versions match, no stack trace is produced, and the application keeps 
moving.

What's the deal? Or is there something else I should be looking for?

--Brian



From miguel at ximian.com  Mon Jun 12 20:48:49 2006
From: miguel at ximian.com (Miguel de Icaza)
Date: Mon, 12 Jun 2006 20:48:49 -0400
Subject: [Mono-dev] Re: [Mono-osx] anybody noticed a mach port leak?
In-Reply-To: <170f4a080606121625s7bb2443dr4023a526267a3b9e@mail.gmail.com>
References: <CEA516F0-7F67-41D3-8C1A-9367B4D41057@counterpop.net>
	<1149821769.6167.346.camel@linux.site>
	<81DAE120-AD04-4436-984E-187EE0D633CB@counterpop.net>
	<170f4a080606121625s7bb2443dr4023a526267a3b9e@mail.gmail.com>
Message-ID: <1150159729.6167.642.camel@linux.site>


> Not a big fan of C, neither I do have a OS X machine to test but a
> simple grep -R "mach_port" . shows that there is no deallocate.

Mono never calls any mach_ routines directly, so no wonder you did not
find any mach_port calls.


From andrews at mainsoft.com  Tue Jun 13 03:30:28 2006
From: andrews at mainsoft.com (Andrew Skiba)
Date: Tue, 13 Jun 2006 00:30:28 -0700
Subject: [Mono-dev] [PATCH] System.Web.UI.WebControls.FormView test and patch
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03136CDE@dhost002-45.dex002.intermedia.net>

Hello,

Please review the attached test and fix for FormView control. The test
reveils a bug in FormView rendering. When <asp:FormView> has CssClass
attribute, the resulting <table> tag must have the corresponding class
attribute.

If no one objects, I will commit.

Andrew.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FormViewTest.patch
Type: application/octet-stream
Size: 2913 bytes
Desc: FormViewTest.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060613/8372cf0f/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FormView.patch
Type: application/octet-stream
Size: 567 bytes
Desc: FormView.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060613/8372cf0f/attachment-0001.obj 

From kornelpal at gmail.com  Tue Jun 13 06:22:13 2006
From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=)
Date: Tue, 13 Jun 2006 12:22:13 +0200
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
Message-ID: <007a01c68ed3$3e3e45f0$0100a8c0@kornelpal.hu>

Is this patch OK to commit?

Korn?l

----- Original Message ----- 
From: "Korn?l P?l" <kornelpal at gmail.com>
To: "Miguel de Icaza" <miguel at ximian.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Friday, June 09, 2006 2:24 PM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()


> OK, now I understan your problem.
>
> Please review this modified patch.
>
> Korn?l
>
> ----- Original Message ----- 
> From: "Miguel de Icaza" <miguel at ximian.com>
> To: "Korn?l P?l" <kornelpal at gmail.com>
> Cc: <mono-devel-list at lists.ximian.com>
> Sent: Friday, June 09, 2006 2:01 PM
> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
>
>
>> Hello,
>>
>>> Invoking non-public methods using SRE is widely used by our class
>>> library,
>>> it is supported by the ECMA standards so I don't really understand what
>>> you
>>> mean on "access to internal methods will at some point broken".
>>
>> As I said, this might be something that we will fix in the future, and
>> although it works today, it does not mean it will work today, I do not
>> want to add more dependencies that might prevent us from fixing it in
>> the future.
>>
>> Besides, poking at string internals is not something am very excited
>> about supporting nor encouraging.  The last time we did something
>> "unsafe" like this, it was reviewed over and over, and it turned out to
>> be buggy, it took months to track the mysterious bug because the
>> conditions were very hard to reproduce.
>>
>>> Note that even using "new string ((char) 0, length)" is faster than the
>>> current implementation.
>>
>> That part of the patch is fine with me.
>>
>> Miguel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ByteEncoding.diff
Type: application/octet-stream
Size: 1796 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060613/51049454/attachment.obj 

From atsushi at ximian.com  Tue Jun 13 10:10:42 2006
From: atsushi at ximian.com (Atsushi Eno)
Date: Tue, 13 Jun 2006 23:10:42 +0900
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
In-Reply-To: <007a01c68ed3$3e3e45f0$0100a8c0@kornelpal.hu>
References: <007a01c68ed3$3e3e45f0$0100a8c0@kornelpal.hu>
Message-ID: <448EC762.2030801@ximian.com>

I see no problem on this patch, so feel free to go ahead, though the
improvement is not obvious now. But it would be faster in general
cases.

Just an extra note, see bug #70841 to see concrete nonpublic method
access problem that Miguel was worried.

Atsushi Eno

Korn?l P?l wrote:
> Is this patch OK to commit?
> 
> Korn?l
> 
> ----- Original Message ----- From: "Korn?l P?l" <kornelpal at gmail.com>
> To: "Miguel de Icaza" <miguel at ximian.com>
> Cc: <mono-devel-list at lists.ximian.com>
> Sent: Friday, June 09, 2006 2:24 PM
> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
> 
> 
>> OK, now I understan your problem.
>>
>> Please review this modified patch.
>>
>> Korn?l
>>
>> ----- Original Message ----- From: "Miguel de Icaza" <miguel at ximian.com>
>> To: "Korn?l P?l" <kornelpal at gmail.com>
>> Cc: <mono-devel-list at lists.ximian.com>
>> Sent: Friday, June 09, 2006 2:01 PM
>> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
>>
>>
>>> Hello,
>>>
>>>> Invoking non-public methods using SRE is widely used by our class
>>>> library,
>>>> it is supported by the ECMA standards so I don't really understand what
>>>> you
>>>> mean on "access to internal methods will at some point broken".
>>>
>>> As I said, this might be something that we will fix in the future, and
>>> although it works today, it does not mean it will work today, I do not
>>> want to add more dependencies that might prevent us from fixing it in
>>> the future.
>>>
>>> Besides, poking at string internals is not something am very excited
>>> about supporting nor encouraging.  The last time we did something
>>> "unsafe" like this, it was reviewed over and over, and it turned out to
>>> be buggy, it took months to track the mysterious bug because the
>>> conditions were very hard to reproduce.
>>>
>>>> Note that even using "new string ((char) 0, length)" is faster than the
>>>> current implementation.
>>>
>>> That part of the patch is fine with me.
>>>
>>> Miguel
>>
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From js at hotfeet.ch  Tue Jun 13 10:11:14 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Tue, 13 Jun 2006 16:11:14 +0200
Subject: [Mono-dev] Patch for System.Web.UI.WebControls.Calendar
Message-ID: <1150207875.2540.46.camel@leonardo.hotfeet.ch>

Hi,

The attached patch fixes bug 
http://bugzilla.ximian.com/show_bug.cgi?id=78603

Is it okay to commit?

- Juraj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Calendar.patch
Type: text/x-patch
Size: 4114 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060613/f2e99c40/attachment.bin 

From gonzalo at novell.com  Tue Jun 13 10:58:15 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Tue, 13 Jun 2006 10:58:15 -0400
Subject: [Mono-dev] Bug in System.Web.UI.WebControls.BaseDataList
In-Reply-To: <DA63C6E8B207E748B20D46DFED7B772D0309821F@dhost002-45.dex002.intermedia.net>
References: <DA63C6E8B207E748B20D46DFED7B772D0309821F@dhost002-45.dex002.intermedia.net>
Message-ID: <1150210695.3886.2.camel@lalo.micasa>

On Wed, 2006-05-24 at 06:07 -0700, Vladimir Krasnov wrote:
> Hello,
> 
> There is a bug in BaseDataList, its method OnDataSourceViewChanged is
> not called when data source is changed.
> 
> Look attached sample that reproduces the bug and the patch that fixes
> it.
> I will commit if no one objects.

Your commit broke the 1.1 build and I've reverted it.

-Gonzalo




From andrews at mainsoft.com  Tue Jun 13 11:36:27 2006
From: andrews at mainsoft.com (Andrew Skiba)
Date: Tue, 13 Jun 2006 08:36:27 -0700
Subject: [Mono-dev] [PATCH] System.Web.UI.WebControls.FormView test and
	patch
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03136DBF@dhost002-45.dex002.intermedia.net>

The previous patch rendered empty cssclass attribute by mistake. This
test and fix handle this case.

If no one objects, I will commit.

Andrew. 

> -----Original Message-----
> From: mono-devel-list-bounces at lists.ximian.com 
> [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf 
> Of Andrew Skiba
> Sent: Tuesday, June 13, 2006 10:30
> To: mono-devel-list at lists.ximian.com
> Subject: [Mono-dev] [PATCH] 
> System.Web.UI.WebControls.FormView test and patch
> 
> Hello,
> 
> Please review the attached test and fix for FormView control. 
> The test reveils a bug in FormView rendering. When 
> <asp:FormView> has CssClass attribute, the resulting <table> 
> tag must have the corresponding class attribute.
> 
> If no one objects, I will commit.
> 
> Andrew.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FormViewTest.patch
Type: application/octet-stream
Size: 3266 bytes
Desc: FormViewTest.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060613/1f5cc869/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FormView.patch
Type: application/octet-stream
Size: 623 bytes
Desc: FormView.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060613/1f5cc869/attachment-0001.obj 

From mcastro at mcsoft.com.br  Tue Jun 13 12:09:12 2006
From: mcastro at mcsoft.com.br (=?ISO-8859-1?Q?Marco_Aur=E9lio_Castro?=)
Date: Tue, 13 Jun 2006 13:09:12 -0300
Subject: [Mono-dev] databinder works?
Message-ID: <448EE328.7070009@mcsoft.com.br>

Hello,
   
    I'm developing a site in Delphi 2006 to run in Mono and I tried to 
connect a Dataset with an edit box by DataBinder. The connection is
        text='<%# DataBinder.Eval(DataSet, 
"Tables[Clients].DefaultView.[0].Client") %>'

    It works in Windows, what is wrong here?

    The site returned the screen:
 

System.NotImplementedException: The requested feature is not implemented.
in <0x00021> System.Data.DataSet:get_Site ()
in <0x00107> System.ComponentModel.ComponentInfo:GetProperties ()
in <0x0000e> System.ComponentModel.Info:GetProperties (System.Attribute[] attributes)
in <0x001c6> System.ComponentModel.TypeDescriptor:GetProperties (System.Object component, System.Attribute[] attributes, Boolean noCustomTypeDesc)
in <0x00011> System.ComponentModel.TypeDescriptor:GetProperties (System.Object component, Boolean noCustomTypeDesc)
in <0x0000c> System.ComponentModel.TypeDescriptor:GetProperties (System.Object component)
in <0x00019> System.Web.UI.DataBinder:GetPropertyValue (System.Object container, System.String propName)
in <0x0029a> System.Web.UI.DataBinder:GetIndexedPropertyValue (System.Object container, System.String expr)
in <0x00097> System.Web.UI.DataBinder:Eval (System.Object container, System.String expression)
in <0x00050> ASP.DetalheCliente_aspx:__BuildControl_TextBox1_DB_0 (System.Object sender, System.EventArgs e)
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs)
in <0x00056> System.Web.UI.Control:OnDataBinding (System.EventArgs e)
in <0x00013> System.Web.UI.Control:DataBind ()
in <0x0006c> System.Web.UI.Control:DataBindChildren ()
in <0x00021> System.Web.UI.Control:DataBind ()
in <0x0006c> System.Web.UI.Control:DataBindChildren ()
in <0x00021> System.Web.UI.Control:DataBind ()
in <0x00192> DetalheCliente.TwebDetalheCliente:Page_Load (System.Object sender, System.EventArgs e)
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs)
in <0x00056> System.Web.UI.Control:OnLoad (System.EventArgs e)
in <0x00026> System.Web.UI.Control:LoadRecursive ()
in <0x00149> System.Web.UI.Page:InternalProcessRequest ()
in <0x000a9> System.Web.UI.Page:ProcessRequest (System.Web.HttpContext context)
in <0x00233> System.Web.HttpApplication+ExecuteHandlerState:Execute ()
in <0x0007c> System.Web.HttpApplication+StateMachine:ExecuteState (IStateHandler state, System.Boolean readysync)

	Thanks,

	Marco Castro



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 12/6/2006



From mhinks at gmail.com  Tue Jun 13 12:25:04 2006
From: mhinks at gmail.com (Martin Hinks)
Date: Tue, 13 Jun 2006 17:25:04 +0100
Subject: [Mono-dev] databinder works?
In-Reply-To: <448EE328.7070009@mcsoft.com.br>
References: <448EE328.7070009@mcsoft.com.br>
Message-ID: <7fb639590606130925k7aa3e603vd0009c1039db9ff2@mail.gmail.com>

If you read the first line of the exception it is fairly clear what
the problem is:

System.NotImplementedException: The requested feature is not implemented.

Unfortunately this portion of Mono has not yet been completed and so
is not implemented... yet.

On 6/13/06, Marco Aur?lio Castro <mcastro at mcsoft.com.br> wrote:
> Hello,
>
>     I'm developing a site in Delphi 2006 to run in Mono and I tried to
> connect a Dataset with an edit box by DataBinder. The connection is
>         text='<%# DataBinder.Eval(DataSet,
> "Tables[Clients].DefaultView.[0].Client") %>'
>
>     It works in Windows, what is wrong here?
>
>     The site returned the screen:
>
>
> System.NotImplementedException: The requested feature is not implemented.
> in <0x00021> System.Data.DataSet:get_Site ()
> in <0x00107> System.ComponentModel.ComponentInfo:GetProperties ()
> in <0x0000e> System.ComponentModel.Info:GetProperties (System.Attribute[] attributes)
> in <0x001c6> System.ComponentModel.TypeDescriptor:GetProperties (System.Object component, System.Attribute[] attributes, Boolean noCustomTypeDesc)
> in <0x00011> System.ComponentModel.TypeDescriptor:GetProperties (System.Object component, Boolean noCustomTypeDesc)
> in <0x0000c> System.ComponentModel.TypeDescriptor:GetProperties (System.Object component)
> in <0x00019> System.Web.UI.DataBinder:GetPropertyValue (System.Object container, System.String propName)
> in <0x0029a> System.Web.UI.DataBinder:GetIndexedPropertyValue (System.Object container, System.String expr)
> in <0x00097> System.Web.UI.DataBinder:Eval (System.Object container, System.String expression)
> in <0x00050> ASP.DetalheCliente_aspx:__BuildControl_TextBox1_DB_0 (System.Object sender, System.EventArgs e)
> in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs)
> in <0x00056> System.Web.UI.Control:OnDataBinding (System.EventArgs e)
> in <0x00013> System.Web.UI.Control:DataBind ()
> in <0x0006c> System.Web.UI.Control:DataBindChildren ()
> in <0x00021> System.Web.UI.Control:DataBind ()
> in <0x0006c> System.Web.UI.Control:DataBindChildren ()
> in <0x00021> System.Web.UI.Control:DataBind ()
> in <0x00192> DetalheCliente.TwebDetalheCliente:Page_Load (System.Object sender, System.EventArgs e)
> in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_EventArgs (object,System.EventArgs)
> in <0x00056> System.Web.UI.Control:OnLoad (System.EventArgs e)
> in <0x00026> System.Web.UI.Control:LoadRecursive ()
> in <0x00149> System.Web.UI.Page:InternalProcessRequest ()
> in <0x000a9> System.Web.UI.Page:ProcessRequest (System.Web.HttpContext context)
> in <0x00233> System.Web.HttpApplication+ExecuteHandlerState:Execute ()
> in <0x0007c> System.Web.HttpApplication+StateMachine:ExecuteState (IStateHandler state, System.Boolean readysync)
>
>         Thanks,
>
>         Marco Castro
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 12/6/2006
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>


-- 
Martin Hinks
http://www.m-s-d.net


From seurer at us.ibm.com  Tue Jun 13 13:03:42 2006
From: seurer at us.ibm.com (Bill Seurer)
Date: Tue, 13 Jun 2006 12:03:42 -0500
Subject: [Mono-dev] __powerpc__
In-Reply-To: <7fb639590606130925k7aa3e603vd0009c1039db9ff2@mail.gmail.com>
Message-ID: <OF5E0B73DA.9F005346-ON8625718C.005D27EA-8625718C.005DB96D@us.ibm.com>

In looking through some of the source for mono I see
      #ifdef __powerpc__
and similar conditional code based on __powerpc__ in a few places.
However, there is nothing in the current configuration stuff that defines
__powerpc__.  In an old configure I found it looks like it added
-D__powerpc__ to the CFLAGS.

So, is __powerpc__ still needed for compiling for power hardware or is it
deprecated?  And if it is still needed is it meant to be set manually (in
CFLAGS before running configure) or did I miss something?

Thanks!
--
Bill Seurer     IBM System i5 internal compiler development   Rochester, MN
Business: seurer at us.ibm.com                         Home: Bill at seurer.net
http://w3.rchland.ibm.com/~seurer/                  http://www.seurer.net



From d_erchoff at hotmail.com  Tue Jun 13 13:23:00 2006
From: d_erchoff at hotmail.com (Denis ERCHOFF)
Date: Tue, 13 Jun 2006 19:23:00 +0200
Subject: [Mono-dev] How to patch a compiled managed method code ?
In-Reply-To: <7fb639590606130925k7aa3e603vd0009c1039db9ff2@mail.gmail.com>
Message-ID: <BAY103-F33D2F01FDD5BE821B6D6F7878C0@phx.gbl>

Hi,

I have a function as

function Foo()
{
...

JUMP MethodRef.
}

Once this method compiled i want to patch it in memory. I want to replace 
the MethodRef with another MethodRef.

1) Having a MonoMethod pointer, how to retrieve the compiled block of this 
method ?
2) Are there some mono functions to parse a compiled block easily ?
3) How to retrieve the JUMP offset and how to patch it ?

Thanks.

Denis.




From Ympostor at clix.pt  Tue Jun 13 15:15:26 2006
From: Ympostor at clix.pt (Ympostor)
Date: Tue, 13 Jun 2006 21:15:26 +0200
Subject: [Mono-dev] [OT] Thread hijacking (was: Re: __powerpc__)
In-Reply-To: <OF5E0B73DA.9F005346-ON8625718C.005D27EA-8625718C.005DB96D@us.ibm.com>
References: <7fb639590606130925k7aa3e603vd0009c1039db9ff2@mail.gmail.com>
	<OF5E0B73DA.9F005346-ON8625718C.005D27EA-8625718C.005DB96D@us.ibm.com>
Message-ID: <e6n2ua$cfb$1@sea.gmane.org>

Hello Bill. Sorry for the Off-Topic but, please, for the cleanliness of
the list, try to avoid Thread Hijacking [1].

Regards.

-- 
[1] http://en.wikipedia.org/wiki/Thread_hijacking



From gonzalo at novell.com  Tue Jun 13 15:42:10 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Tue, 13 Jun 2006 15:42:10 -0400
Subject: [Mono-dev] Patch for System.Web.UI.WebControls.Calendar
In-Reply-To: <1150207875.2540.46.camel@leonardo.hotfeet.ch>
References: <1150207875.2540.46.camel@leonardo.hotfeet.ch>
Message-ID: <1150227730.14365.0.camel@lalo>

On Tue, 2006-06-13 at 16:11 +0200, Juraj Skripsky wrote:
> Hi,
> 
> The attached patch fixes bug 
> http://bugzilla.ximian.com/show_bug.cgi?id=78603
> 
> Is it okay to commit?

Please, do.
Thanks.

-Gonzalo




From gonzalo at novell.com  Tue Jun 13 15:43:02 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Tue, 13 Jun 2006 15:43:02 -0400
Subject: [Mono-dev] databinder works?
In-Reply-To: <448EE328.7070009@mcsoft.com.br>
References: <448EE328.7070009@mcsoft.com.br>
Message-ID: <1150227782.14365.2.camel@lalo>

On Tue, 2006-06-13 at 13:09 -0300, Marco Aur?lio Castro wrote:
> Hello,
>    
>     I'm developing a site in Delphi 2006 to run in Mono and I tried to 
> connect a Dataset with an edit box by DataBinder. The connection is
>         text='<%# DataBinder.Eval(DataSet, 
> "Tables[Clients].DefaultView.[0].Client") %>'
> 
>     It works in Windows, what is wrong here?
> 
>     The site returned the screen:
>  
> 
> System.NotImplementedException: The requested feature is not implemented.
> in <0x00021> System.Data.DataSet:get_Site ()

DataBinder works. If you look at the stacktrace, seems like DataSet.Site
is not implemented.

-Gonzalo




From kornelpal at gmail.com  Tue Jun 13 17:06:11 2006
From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=)
Date: Tue, 13 Jun 2006 23:06:11 +0200
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
References: <007a01c68ed3$3e3e45f0$0100a8c0@kornelpal.hu>
	<448EC762.2030801@ximian.com>
Message-ID: <01c501c68f2d$3459f9d0$0100a8c0@kornelpal.hu>

Hi,

I committed the patch. Note according to my test result this implementation
is about three times faster than the previous one so I consider it to be
obvious improvement. Of course this only affects ByteEncoding.GetString()
but other encodings were not using StringBuilder so they are faster altough
they could be improved using unsafe code but that requires some
infrastructural changes in I18N.

For the referenced bug:

When calling for example MethodInfo.Invoke or Delegate.CreateDelegate 
without ReflectionPermissionFlag.MemberAccess permission 
MethodAccessException has to be thrown. But I don't think that this is a 
mysterious bug. This behaviour is documented on MSDN and if you search for 
MethodAccessException you will find the methods that throw 
MethodAccessException with the description when they trow it.

Anyway the bug in Mono is that it doesn't enforce this check not that it 
grants ReflectionPermissionFlag.MemberAccess permission to code. If  we 
grant ReflectionPermissionFlag.MemberAccess permission (or full trust) to 
class library assemblies we can use reflection safely.

Korn?l

----- Original Message ----- 
From: "Atsushi Eno" <atsushi at ximian.com>
To: "Korn?l P?l" <kornelpal at gmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Tuesday, June 13, 2006 4:10 PM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()


>I see no problem on this patch, so feel free to go ahead, though the
> improvement is not obvious now. But it would be faster in general
> cases.
>
> Just an extra note, see bug #70841 to see concrete nonpublic method
> access problem that Miguel was worried.
>
> Atsushi Eno
>
> Korn?l P?l wrote:
>> Is this patch OK to commit?
>>
>> Korn?l
>>
>> ----- Original Message ----- From: "Korn?l P?l" <kornelpal at gmail.com>
>> To: "Miguel de Icaza" <miguel at ximian.com>
>> Cc: <mono-devel-list at lists.ximian.com>
>> Sent: Friday, June 09, 2006 2:24 PM
>> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
>>
>>
>>> OK, now I understan your problem.
>>>
>>> Please review this modified patch.
>>>
>>> Korn?l
>>>
>>> ----- Original Message ----- From: "Miguel de Icaza" <miguel at ximian.com>
>>> To: "Korn?l P?l" <kornelpal at gmail.com>
>>> Cc: <mono-devel-list at lists.ximian.com>
>>> Sent: Friday, June 09, 2006 2:01 PM
>>> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
>>>
>>>
>>>> Hello,
>>>>
>>>>> Invoking non-public methods using SRE is widely used by our class
>>>>> library,
>>>>> it is supported by the ECMA standards so I don't really understand
>>>>> what
>>>>> you
>>>>> mean on "access to internal methods will at some point broken".
>>>>
>>>> As I said, this might be something that we will fix in the future, and
>>>> although it works today, it does not mean it will work today, I do not
>>>> want to add more dependencies that might prevent us from fixing it in
>>>> the future.
>>>>
>>>> Besides, poking at string internals is not something am very excited
>>>> about supporting nor encouraging.  The last time we did something
>>>> "unsafe" like this, it was reviewed over and over, and it turned out to
>>>> be buggy, it took months to track the mysterious bug because the
>>>> conditions were very hard to reproduce.
>>>>
>>>>> Note that even using "new string ((char) 0, length)" is faster than
>>>>> the
>>>>> current implementation.
>>>>
>>>> That part of the patch is fine with me.
>>>>
>>>> Miguel
>>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>



From davem at davemloft.net  Tue Jun 13 17:27:06 2006
From: davem at davemloft.net (David Miller)
Date: Tue, 13 Jun 2006 14:27:06 -0700 (PDT)
Subject: [Mono-dev] __powerpc__
In-Reply-To: <OF5E0B73DA.9F005346-ON8625718C.005D27EA-8625718C.005DB96D@us.ibm.com>
References: <7fb639590606130925k7aa3e603vd0009c1039db9ff2@mail.gmail.com>
	<OF5E0B73DA.9F005346-ON8625718C.005D27EA-8625718C.005DB96D@us.ibm.com>
Message-ID: <20060613.142706.133764499.davem@davemloft.net>

From: Bill Seurer <seurer at us.ibm.com>
Date: Tue, 13 Jun 2006 12:03:42 -0500

> So, is __powerpc__ still needed for compiling for power hardware or is it
> deprecated?  And if it is still needed is it meant to be set manually (in
> CFLAGS before running configure) or did I miss something?

__powerpc__ is automatically defined by the compiler


From mono-devel at fluggo.com  Tue Jun 13 19:31:42 2006
From: mono-devel at fluggo.com (Brian Crowell)
Date: Tue, 13 Jun 2006 18:31:42 -0500
Subject: [Mono-dev] Version-specific binding - resolved, but real bugs
	found
In-Reply-To: <448E0A84.8020707@fluggo.com>
References: <448E0A84.8020707@fluggo.com>
Message-ID: <448F4ADE.3080904@fluggo.com>

Brian Crowell wrote that Mono said:
> ** (bin/MonitorHost.exe:13141): WARNING **: The following assembly 
> referenced from /var/lib/klotron-monitor/images/hostee.dll could not be 
> loaded:
>      Assembly:   Clotron.MobileResource    (assemblyref_index=1)
>      Version:    3.0.2354.22385
>      Public Key: (none)
> The assembly was not found in the Global Assembly Cache, a path listed 
> in the MONO_PATH environment variable, or in the location of the 
> executing assembly (/var/lib/klotron-monitor/images).

After digging deep into the Mono runtime (without a debugger!), I came to the 
conclusion that the assembly I was trying to load had actually been corrupted by 
something else I was doing. Unfortunately, just by the definition of the API, 
this comes out as a file-not-found error. Therefore, Mono was doing the right 
thing on this issue.

On a side note, I did discover that AppDomain.AssemblyLoad does not fire for 
implicitly-loaded assemblies (referenced ones), but does fire for 
explicitly-loaded and dynamic assemblies.

I also discovered that Mono does not like me reading the Assembly.CodeBase or 
Assembly.Location properties on dynamic assemblies. For Assembly.Location, the 
documentation implies that the property will be an empty string wherever it 
doesn't apply. Throwing an exception for these properties is counter-intuitive, 
especially when there isn't a IsDynamic property on Assembly to help you avoid 
the exception.

--Brian



From gonzalo at novell.com  Tue Jun 13 19:55:39 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Tue, 13 Jun 2006 19:55:39 -0400
Subject: [Mono-dev] Version-specific binding - resolved, but real bugs
	found
In-Reply-To: <448F4ADE.3080904@fluggo.com>
References: <448E0A84.8020707@fluggo.com>  <448F4ADE.3080904@fluggo.com>
Message-ID: <1150242939.2002.4.camel@localhost>

On Tue, 2006-06-13 at 18:31 -0500, Brian Crowell wrote:
[...]
> On a side note, I did discover that AppDomain.AssemblyLoad does not fire for 
> implicitly-loaded assemblies (referenced ones), but does fire for 
> explicitly-loaded and dynamic assemblies.
> 
> I also discovered that Mono does not like me reading the Assembly.CodeBase or 
> Assembly.Location properties on dynamic assemblies. For Assembly.Location, the 
> documentation implies that the property will be an empty string wherever it 
> doesn't apply. Throwing an exception for these properties is counter-intuitive, 
> especially when there isn't a IsDynamic property on Assembly to help you avoid 
> the exception.

Can you please file bug reports in bugzilla.ximian.com and attach a test
case for these problems?

Thanks.

-Gonzalo




From allan at counterpop.net  Tue Jun 13 20:16:01 2006
From: allan at counterpop.net (Allan Hsu)
Date: Tue, 13 Jun 2006 17:16:01 -0700
Subject: [Mono-dev] GC/threading-related mach port leak on OS X
Message-ID: <FADC50CB-EFE8-4F6A-B183-AE7EDEA3014F@counterpop.net>

I've been spending some time trying to fix a mach port leak that  
occurs under OS X. The bug (and the progress that I've been making)  
is logged here:

http://bugs.ximian.com/show_bug.cgi?id=78628

I've made a little progress by adding calls to mach_port_deallocate()  
in darwin_stop_world.c and attempting to use the libgc 6.6 release  
instead of the version of libgc that lives in Mono SVN.

I'm now a little stuck because I don't know enough about how the GC  
works to know where to look next. My most recent update in the  
bugzilla entry describes my suspicions on what I think is going on,  
but I don't know where the code in question lives (or how it works).

Can somebody with knowledge of the GC help me out here?

	-Allan
--
Allan Hsu <allan at counterpop dot net>
1E64 E20F 34D9 CBA7 1300  1457 AC37 CBBB 0E92 C779




From atsushi at ximian.com  Tue Jun 13 21:47:27 2006
From: atsushi at ximian.com (Atsushi Eno)
Date: Wed, 14 Jun 2006 10:47:27 +0900
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
In-Reply-To: <01c501c68f2d$3459f9d0$0100a8c0@kornelpal.hu>
References: <007a01c68ed3$3e3e45f0$0100a8c0@kornelpal.hu>
	<448EC762.2030801@ximian.com>
	<01c501c68f2d$3459f9d0$0100a8c0@kornelpal.hu>
Message-ID: <448F6AAF.2060502@ximian.com>

> I committed the patch. Note according to my test result this implementation
> is about three times faster than the previous one so I consider it to be
> obvious improvement. Of course this only affects ByteEncoding.GetString()
> but other encodings were not using StringBuilder so they are faster altough
> they could be improved using unsafe code but that requires some
> infrastructural changes in I18N.

No, you didn't post anything about the perf. result *after* the
change to remove improper reflection stuff.

> For the referenced bug:
> 
> When calling for example MethodInfo.Invoke or Delegate.CreateDelegate 
> without ReflectionPermissionFlag.MemberAccess permission 
> MethodAccessException has to be thrown. But I don't think that this is a 
> mysterious bug. This behaviour is documented on MSDN and if you search 
> for MethodAccessException you will find the methods that throw 
> MethodAccessException with the description when they trow it.

Well, I know. Otherwise it is too weird that I mentioned that
bug here.

Atsushi Eno


From allan at counterpop.net  Tue Jun 13 22:35:42 2006
From: allan at counterpop.net (Allan Hsu)
Date: Tue, 13 Jun 2006 19:35:42 -0700
Subject: [Mono-dev] GC/threading-related mach port leak on OS X
In-Reply-To: <FADC50CB-EFE8-4F6A-B183-AE7EDEA3014F@counterpop.net>
References: <FADC50CB-EFE8-4F6A-B183-AE7EDEA3014F@counterpop.net>
Message-ID: <33F4838E-1E27-4E13-A065-37D21C3395D3@counterpop.net>

On Jun 13, 2006, at 5:16 PM, Allan Hsu wrote:

> I've been spending some time trying to fix a mach port leak that  
> occurs under OS X. The bug (and the progress that I've been making)  
> is logged here:
>
> http://bugs.ximian.com/show_bug.cgi?id=78628

I think I've fixed this with a patch against libgc 6.6. I've attached  
the patch to the bug report. libgc 6.6 seems to fix one of the leaks  
I was seeing with libgc in Mono SVN, but it has other port leaks and  
memory leaks that are fixed in my patch.

Now... the question is, how do I get these fixes into Mono?

	-Allan

--
Allan Hsu <allan at counterpop dot net>
1E64 E20F 34D9 CBA7 1300  1457 AC37 CBBB 0E92 C779



From tcmichals at msn.com  Tue Jun 13 23:06:44 2006
From: tcmichals at msn.com (Tim Michals)
Date: Tue, 13 Jun 2006 22:06:44 -0500
Subject: [Mono-dev] Performance of Invoke
Message-ID: <BAY104-DAV116FAFC7973EED7F7E5E14A38D0@phx.gbl>

I've tested on .NET the performance of invoke compared to Delegate, Delegate 
is several orders of magnitude faster.  The problem I'm having is creating a 
delegate with the proper type, Delegate.CreateDelegate requires the delegate 
type to be defined.  But the base library only knows the base type not the 
class defined in the user code
For example...(This is a very basic pseudo code)   Looking for better 
perfomance then using Invoke..I read some methods of creating LCG but is 
that the only way?

//defined in class library
class fsmEvent{}
class fsm
{
    //events can be posted to the event queue and read from the dispatch 
loop from a thread...
    public Queue<fsmEvent>  QueueEvent;

 public void dispatchEvent()
 {
  .....
        fsmEv = Queue.dequeue();
      Type t= userFsm.GetType();
      MethodInfo mFsmEvent = t.GetMethod(  ... based on fsmEv type, match 
the parameter list)
    // invoke proper method
      mFsmEvent.Invoke(userFsm,new object[]{ fsmLoop.fsmEventList[0]});
   // Want to replace this is some type of Delegate for performance...

     }
}

// define in user library
class userFsmEvent : fsmEvent{}
class fsmTimerEvent : fsmEvent{}

class fsmUser
{
    public void hander1(fsmEvent ev){}
    public void handler2(fsmTimerEvent ev){}
    public void hander3(userFsmEvent ev){}

}

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060613/eac78905/attachment.html 

From kornelpal at gmail.com  Tue Jun 13 23:21:43 2006
From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=)
Date: Wed, 14 Jun 2006 05:21:43 +0200
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
References: <007a01c68ed3$3e3e45f0$0100a8c0@kornelpal.hu>
	<448EC762.2030801@ximian.com>
	<01c501c68f2d$3459f9d0$0100a8c0@kornelpal.hu>
	<448F6AAF.2060502@ximian.com>
Message-ID: <008001c68f61$aa299790$0100a8c0@kornelpal.hu>

Hi,

The results:
length, conversion: time
1, byte[]: 3391
1, byte[] int int: 3187
4, byte[]: 3641
4, byte[] int int: 3625
1024, byte[]: 14266
1024, byte[] int int: 14187
1048576, byte[]: 8703
1048576, byte[] int int: 8812

Altough I didn't attached performance tests for this patch it's still fast 
indeed. These seem to be a bit slower than the patch using reflection but I 
think it's still correct that this implementation is about three time faster 
than the previous implementation in SVN. Note there is little improvement on 
using InternalAllocateStr when is not called using call instruction. Using 
delegates is the fastest late binding solution but it's still way slower 
than call.

It may be improper to assume that there is an internal method called 
InternalAllocateStr even more improper to assume that strings can be 
modified but I don't think that using reflection to access non-public 
members is improper. If the code has ReflectionPermissionFlag.MemberAccess 
permission it works properly. Otherwise MethodAccessException is thrown that 
can be identified. If we believe that our class library has to work properly 
without full trust we should avoid unsafe code, P/Invoke and almost 
everything that requires more permissions than 
SecurityPermissionFlag.Execution. If we assume full trust however we can use 
unsafe code, P/Invoke, reflection as well as anything else in our class 
library. Note that MS.NET class library assemblies assume as well that they 
are executed with full trust. Also note that I'm not fighting for 
InternalAllocateStr I just speaking about reflection

I attached a test that shows the relation of reflection and CAS.

Korn?l

----- Original Message ----- 
From: "Atsushi Eno" <atsushi at ximian.com>
To: "Korn?l P?l" <kornelpal at gmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, June 14, 2006 3:47 AM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()


>> I committed the patch. Note according to my test result this 
>> implementation
>> is about three times faster than the previous one so I consider it to be
>> obvious improvement. Of course this only affects ByteEncoding.GetString()
>> but other encodings were not using StringBuilder so they are faster 
>> altough
>> they could be improved using unsafe code but that requires some
>> infrastructural changes in I18N.
>
> No, you didn't post anything about the perf. result *after* the
> change to remove improper reflection stuff.
>
>> For the referenced bug:
>>
>> When calling for example MethodInfo.Invoke or Delegate.CreateDelegate 
>> without ReflectionPermissionFlag.MemberAccess permission 
>> MethodAccessException has to be thrown. But I don't think that this is a 
>> mysterious bug. This behaviour is documented on MSDN and if you search 
>> for MethodAccessException you will find the methods that throw 
>> MethodAccessException with the description when they trow it.
>
> Well, I know. Otherwise it is too weird that I mentioned that
> bug here.
>
> Atsushi Eno 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: AllocateStringTest.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/1758ff31/attachment.pl 

From lists at ophion.org  Wed Jun 14 02:04:14 2006
From: lists at ophion.org (Rafael Ferreira)
Date: Tue, 13 Jun 2006 23:04:14 -0700
Subject: [Mono-dev] Single thread scheduler for Threading.Timers patch
Message-ID: <1150265055.26740.14.camel@stan.ophion.org>

Howdy, 

The attached patch changes the current Threading.Timer class to use a
single thread scheduler instead of the current 1 thread per timer logic.
I also spent a lot of time working on the Timer unit tests so they more
consistently pass as well as fixing the "NotWorking" tests. 

Some key features include:

* A single thread handles firing all timer jobs thus allowing a much
greater number of Timers to be defined - Fixing bug #65734
* Timer scheduler is only started after the first System.Threading.Timer
is created (lazy init)
* Timer scheduler thread dies if there are no more timer jobs in its Job
queue (early termination)
* Scheduler can spit out debug info by exporting the MONO_TIMER_DEBUG
environment variable

Of course, I don't expect this patch to be accepted without some degree
of scrutiny so comments/concerns are appreciated and I can commit the
code once we're all comfortable with it.  

Cheers, 

- raf



-------------- next part --------------
A non-text attachment was scrubbed...
Name: timer.patch
Type: text/x-patch
Size: 18279 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060613/46907583/attachment.bin 

From lists at ophion.org  Wed Jun 14 02:20:24 2006
From: lists at ophion.org (Rafael Ferreira)
Date: Tue, 13 Jun 2006 23:20:24 -0700
Subject: [Mono-dev] Single thread scheduler for Threading.Timers patch
In-Reply-To: <1150265055.26740.14.camel@stan.ophion.org>
References: <1150265055.26740.14.camel@stan.ophion.org>
Message-ID: <1150266024.26740.17.camel@stan.ophion.org>

I forgot to point out that I blogged about this here:

http://ophion.org/index.php?gadget=Blog&action=SingleView&id=9


- raf

btw, does anyone know what I need to do to add my blog to monologue? 



On Tue, 2006-06-13 at 23:04 -0700, Rafael Ferreira wrote:
> Howdy, 
> 
> The attached patch changes the current Threading.Timer class to use a
> single thread scheduler instead of the current 1 thread per timer logic.
> I also spent a lot of time working on the Timer unit tests so they more
> consistently pass as well as fixing the "NotWorking" tests. 
> 
> Some key features include:
> 
> * A single thread handles firing all timer jobs thus allowing a much
> greater number of Timers to be defined - Fixing bug #65734
> * Timer scheduler is only started after the first System.Threading.Timer
> is created (lazy init)
> * Timer scheduler thread dies if there are no more timer jobs in its Job
> queue (early termination)
> * Scheduler can spit out debug info by exporting the MONO_TIMER_DEBUG
> environment variable
> 
> Of course, I don't expect this patch to be accepted without some degree
> of scrutiny so comments/concerns are appreciated and I can commit the
> code once we're all comfortable with it.  
> 
> Cheers, 
> 
> - raf
> 
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From andrews at mainsoft.com  Wed Jun 14 04:07:29 2006
From: andrews at mainsoft.com (Andrew Skiba)
Date: Wed, 14 Jun 2006 01:07:29 -0700
Subject: [Mono-dev] I'm going to implement
	System.Web.UI.WebControls.FileUpload
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03136E8D@dhost002-45.dex002.intermedia.net>

Hello,

Please see the attachment for the skeleton of the class. As I will
progress with my implementation, I will commit to this class without
notification. Tests will be included.

Andrew.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FileUpload.cs
Type: application/octet-stream
Size: 2631 bytes
Desc: FileUpload.cs
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/4a68708b/attachment.obj 

From paul at all-the-johnsons.co.uk  Wed Jun 14 04:49:15 2006
From: paul at all-the-johnsons.co.uk (PFJ)
Date: Wed, 14 Jun 2006 09:49:15 +0100
Subject: [Mono-dev] Detecting if a dll or binary is platform independant
Message-ID: <1150274955.2678.10.camel@mrwibble.mrwobble>

Hi,

Is there any sure fire way to detect if either a dll or binary compiled
with mono is platform agnostic or platform specific?

There is currently a debate about this on the fedora-packagers list, but
as yet, no one is able to determine a simple way to see where things
need to go (in respects to agnostic going in /usr/share and platform
specific in /usr/lib or /usr/lib64). As FC has only recently taken mono
as part of it's core distro, the packagers (me included) want to get
this right from the outset.

TTFN

Paul
-- 
"Logic, my dear Zoe, is merely the ability to be wrong with authority" -
Dr Who



From marek.sieradzki at gmail.com  Wed Jun 14 05:37:08 2006
From: marek.sieradzki at gmail.com (Marek Sieradzki)
Date: Wed, 14 Jun 2006 11:37:08 +0200
Subject: [Mono-dev] Single thread scheduler for Threading.Timers patch
In-Reply-To: <1150265055.26740.14.camel@stan.ophion.org>
References: <1150265055.26740.14.camel@stan.ophion.org>
Message-ID: <1150277828.14082.0.camel@k5m10marek.cl.wroc.pl>

On Tue, 2006-06-13 at 23:04 -0700, Rafael Ferreira wrote:
> Howdy, 
> 
> The attached patch changes the current Threading.Timer class to use a
> single thread scheduler instead of the current 1 thread per timer logic.
> I also spent a lot of time working on the Timer unit tests so they more
> consistently pass as well as fixing the "NotWorking" tests. 
> 
> Some key features include:
> 
> * A single thread handles firing all timer jobs thus allowing a much
> greater number of Timers to be defined - Fixing bug #65734
> * Timer scheduler is only started after the first System.Threading.Timer
> is created (lazy init)
> * Timer scheduler thread dies if there are no more timer jobs in its Job
> queue (early termination)
> * Scheduler can spit out debug info by exporting the MONO_TIMER_DEBUG
> environment variable
> 
> Of course, I don't expect this patch to be accepted without some degree
> of scrutiny so comments/concerns are appreciated and I can commit the
> code once we're all comfortable with it.  
> 
You are using wrong coding style in some places (f() instead of f ()).
-- 
Marek Sieradzki <marek.sieradzki at gmail.com>



From jonpryor at vt.edu  Wed Jun 14 07:07:16 2006
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Wed, 14 Jun 2006 07:07:16 -0400
Subject: [Mono-dev] Performance of Invoke
In-Reply-To: <BAY104-DAV116FAFC7973EED7F7E5E14A38D0@phx.gbl>
References: <BAY104-DAV116FAFC7973EED7F7E5E14A38D0@phx.gbl>
Message-ID: <1150283237.30777.13.camel@melchior.magi>

I don't think that design is very good, for a number of reasons:

  - Performance will suck (due to reflection)
  - It's highly "magical" (due to reflection)
  - Documentation will likely be problematic (due to "magic")

A cleaner, faster, and more easily documented version would be this
(untested):

        //defined in class library
        class FsmEvent {}
        delegate void FsmEventHandler (object o, FsmEvent e);
        class Fsm
        {
            //events can be posted to the event queue and read from the 
            // dispatch loop from a thread...
            public Queue<fsmEvent>  QueueEvent;
        
            public event FsmEventHandler FsmEvent;
        
            public void dispatchEvent()
            {
                FsmEv e = Queue.Dequeue();
                FsmEvent (this, e);
            }
        }
        
        // defined in user library
        class UserFsmEvent : FsmEvent{}
        class FsmTimerEvent : FsmEvent{}
        
        class FsmUser
        {
            public void MyHandler (object o, FsmEvent e)
            {
                bool handled = false;
                if (!handled) handled = HandleUser (e as UserFsmEvent);
                if (!handled) handled = HandleTimer (e as
        FsmTimerEvent);
                if (!handled) {/* default behavior */}
            }
        
            private bool HandleUser (UserFsmEvent e)
            {
                if (e == null) return false;
                /* ... */
                return true;
            }
        
            private bool HandleTimer (UserFsmEvent e)
            {
                if (e == null) return false;
                /* ... */
                return true;
            }
        }

In short, use an event in Fsm to invoke a FsmEventHandler delegate,
which FsmUser.MyHandler matches.  FsmUser.MyHandler then uses normal
(fast!) type casting with `as' to delegate to the appropriate handler.

Sadly, this requires more work on the User's part, but (1) the work is
highly idiomatic, and (2) gives the user complete control, (3) allows
for saner behavior (less "magic"), and (4) provides excellent
performance.  (The only way to get better performance would be to use a
virtual function, and require that FsmUser inherit from Fsm and override
some virtual/abstract method declared within Fsm.)

If the above still doesn't work for you, you'd have to lookup a delegate
type from the FsmEvent type name, e.g. require that all *FsmEvent types
have a matching *FsmEventHandler delegate within the same assembly, then
use Reflection to lookup this *FsmEventHandler type and create an
appropriate delegate.

This won't help you much, though, unless you cache the delegate lookups
within Fsm; always re-looking up this information won't help performance
at all.

 - Jon

On Tue, 2006-06-13 at 22:06 -0500, Tim Michals wrote:
> I've tested on NET the performance of invoke compared to Delegate,
> Delegate 
> is several orders of magnitude faster.  The problem I'm having is
> creating a 
> delegate with the proper type, Delegate.CreateDelegate requires the
> delegate 
> type to be defined.  But the base library only knows the base type not
> the 
> class defined in the user code
> For example...(This is a very basic pseudo code)   Looking for better 
> perfomance then using Invoke..I read some methods of creating LCG but
> is 
> that the only way?
> 
> //defined in class library
> class fsmEvent{}
> class fsm
> {
>     //events can be posted to the event queue and read from the
> dispatch 
> loop from a thread...
>     public Queue<fsmEvent>  QueueEvent;
> 
>  public void dispatchEvent()
>  {
>   ....
>         fsmEv = Queue.dequeue();
>       Type t= userFsm.GetType();
>       MethodInfo mFsmEvent = t.GetMethod(  ... based on fsmEv type,
> match 
> the parameter list)
>     // invoke proper method
>       mFsmEvent.Invoke(userFsm,new
> object[]{ fsmLoop.fsmEventList[0]});
>    // Want to replace this is some type of Delegate for performance...
> 
>      }
> }
> 
> // define in user library
> class userFsmEvent : fsmEvent{}
> class fsmTimerEvent : fsmEvent{}
> 
> class fsmUser
> {
>     public void hander1(fsmEvent ev){}
>     public void handler2(fsmTimerEvent ev){}
>     public void hander3(userFsmEvent ev){}
> 
> }
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From jonpryor at vt.edu  Wed Jun 14 07:24:31 2006
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Wed, 14 Jun 2006 07:24:31 -0400
Subject: [Mono-dev] Detecting if a dll or binary is platform independant
In-Reply-To: <1150274955.2678.10.camel@mrwibble.mrwobble>
References: <1150274955.2678.10.camel@mrwibble.mrwobble>
Message-ID: <1150284271.30777.31.camel@melchior.magi>

On Wed, 2006-06-14 at 09:49 +0100, PFJ wrote:
> Is there any sure fire way to detect if either a dll or binary compiled
> with mono is platform agnostic or platform specific?

It all depends on what your definition of "platform agnostic" and
"platform specific" is. :-)

The best example of a "platform specific" assembly would be a "mixed
mode" assembly, in which actual x86/AMD64/Itanium/etc. code is placed
into the assembly along with the platform agnostic CIL code.

However, only .NET tools can create such mixed mode assemblies, and Mono
doesn't support their execution on any platform, so they're currently
not a concern (and likely won't ever be, for a variety of reasons).

Consequently, any assembly of consequence executing under Mono will
contain *only* platform agnostic CIL code.

The only thing left to determine whether an assembly is platform
specific is the use of Platform Invoke (P/Invoke), and this is _not_
trivial, as "portable" P/Invoke code can be written, but
platform-specific platform code can also be written.  Classic example:
`struct stat' in C#:

	public struct stat {
		public ulong st_dev, st_ino;
		public uint st_mode;
		private uint _padding_;
		public ulong st_nlink, st_uid, st_gid, st_rdev;
		public long st_size, st_blksize, st_blocks, st_atime,
			st_mtime, st_ctime;
	}

Question: is that structure definition portable for use with fstat(2)?

Answer: Maybe. :-)  It should work on 64-bit ABIs (since long/ulong are
64-bit integer types), but it will fail badly on 32-bit ABIs, and it
will fail on any ABI in which the member ordering differs.
Consequently, such a structure would be platform specific if used with a
DllImport statement, but there is NO EASY WAY for a program to make this
determination. :-/

(Plus, it can get more complicated, particularly if such a structure is
instead used with some native library which will accept that structure,
such as Mono.Posix.dll & libMonoPosixHelper.so, which uses a 64-bit ABI
throughout, and libMonoPosixHelper.so converts this to a 32-bit ABI as
appropriate.)

So it's easiest to assume that all CIL code is platform agnostic.

> There is currently a debate about this on the fedora-packagers list, but
> as yet, no one is able to determine a simple way to see where things
> need to go (in respects to agnostic going in /usr/share and platform
> specific in /usr/lib or /usr/lib64). As FC has only recently taken mono
> as part of it's core distro, the packagers (me included) want to get
> this right from the outset.

I would suggest looking at what SuSE and Debian/Ubuntu have done with
this, as they have all encountered these issues.  Following in their
footsteps would help consistency, and make it easier to repackage
existing programs.

I believe that they currently use /usr/lib for everything.

However, this gets considerably more complicated, as applications may
bundle native libraries with them -- take Blam! and F-Spot as examples:

        $ ls /usr/lib/f-spot
        FlickrNet.dll      libfspoteog.so.0.0.0       libfspot.so.0
        f-spot.exe         libfspotjpegtran.so        libfspot.so.0.0.0
        f-spot.exe.config  libfspotjpegtran.so.0      libgphoto2-sharp.dll
        libfspoteog.so     libfspotjpegtran.so.0.0.0  libgphoto2-sharp.dll.config
        libfspoteog.so.0   libfspot.so                SemWeb.dll

The *.dll and *.exe files may be platform agnostic, but the *.so* files
certainly are NOT.

So the easiest solution may be to check to see if any native libraries
are bundled with the app, and if that's the case stick it under the
appropriate /usr/lib or /usr/lib64 directory.  Otherwise, stick
with /usr/lib.

 - Jon




From kiputnik at gmail.com  Wed Jun 14 07:47:07 2006
From: kiputnik at gmail.com (Jasiu)
Date: Wed, 14 Jun 2006 13:47:07 +0200
Subject: [Mono-dev] [Patch] Stetic crash and invalid code generation.
Message-ID: <f13492b00606140447g12176f14oc18a8ed30d8c36e7@mail.gmail.com>

Hi.

Sorry if this is the wrong page to send a Stetic patch. Anyway, it's
just a tiny bit which fixes one nasty crash which I encountered while
editing my dialogs with SVN Stetic and fixes code generation for
notebook and radio.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stetic.diff
Type: application/octet-stream
Size: 1429 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/21db665f/attachment.obj 

From tcmichals at msn.com  Wed Jun 14 07:53:35 2006
From: tcmichals at msn.com (Tim Michals)
Date: Wed, 14 Jun 2006 06:53:35 -0500
Subject: [Mono-dev] Performance of Invoke
References: <BAY104-DAV116FAFC7973EED7F7E5E14A38D0@phx.gbl>
	<1150283237.30777.13.camel@melchior.magi>
Message-ID: <BAY104-DAV16F0985C93DFE606DFA27DA38D0@phx.gbl>

The goal is to provide a polymorphic functions or delegates based on the 
type of data being past.  Yes, you are correct, this is what I have 
currently but the fsmEvent function has a switch statement decoding the 
type.  In the code I provided, I do have cache of functions, methodInfo etc 
in a tree to assist performance.

----- Original Message ----- 
From: "Jonathan Pryor" <jonpryor at vt.edu>
To: "Tim Michals" <tcmichals at msn.com>
Cc: "mono-devel" <mono-devel-list at lists.ximian.com>
Sent: Wednesday, June 14, 2006 6:07 AM
Subject: Re: [Mono-dev] Performance of Invoke


>I don't think that design is very good, for a number of reasons:
>
>  - Performance will suck (due to reflection)
>  - It's highly "magical" (due to reflection)
>  - Documentation will likely be problematic (due to "magic")
>
> A cleaner, faster, and more easily documented version would be this
> (untested):
>
>        //defined in class library
>        class FsmEvent {}
>        delegate void FsmEventHandler (object o, FsmEvent e);
>        class Fsm
>        {
>            //events can be posted to the event queue and read from the
>            // dispatch loop from a thread...
>            public Queue<fsmEvent>  QueueEvent;
>
>            public event FsmEventHandler FsmEvent;
>
>            public void dispatchEvent()
>            {
>                FsmEv e = Queue.Dequeue();
>                FsmEvent (this, e);
>            }
>        }
>
>        // defined in user library
>        class UserFsmEvent : FsmEvent{}
>        class FsmTimerEvent : FsmEvent{}
>
>        class FsmUser
>        {
>            public void MyHandler (object o, FsmEvent e)
>            {
>                bool handled = false;
>                if (!handled) handled = HandleUser (e as UserFsmEvent);
>                if (!handled) handled = HandleTimer (e as
>        FsmTimerEvent);
>                if (!handled) {/* default behavior */}
>            }
>
>            private bool HandleUser (UserFsmEvent e)
>            {
>                if (e == null) return false;
>                /* ... */
>                return true;
>            }
>
>            private bool HandleTimer (UserFsmEvent e)
>            {
>                if (e == null) return false;
>                /* ... */
>                return true;
>            }
>        }
>
> In short, use an event in Fsm to invoke a FsmEventHandler delegate,
> which FsmUser.MyHandler matches.  FsmUser.MyHandler then uses normal
> (fast!) type casting with `as' to delegate to the appropriate handler.
>
> Sadly, this requires more work on the User's part, but (1) the work is
> highly idiomatic, and (2) gives the user complete control, (3) allows
> for saner behavior (less "magic"), and (4) provides excellent
> performance.  (The only way to get better performance would be to use a
> virtual function, and require that FsmUser inherit from Fsm and override
> some virtual/abstract method declared within Fsm.)
>
> If the above still doesn't work for you, you'd have to lookup a delegate
> type from the FsmEvent type name, e.g. require that all *FsmEvent types
> have a matching *FsmEventHandler delegate within the same assembly, then
> use Reflection to lookup this *FsmEventHandler type and create an
> appropriate delegate.
>
> This won't help you much, though, unless you cache the delegate lookups
> within Fsm; always re-looking up this information won't help performance
> at all.
>
> - Jon
>
> On Tue, 2006-06-13 at 22:06 -0500, Tim Michals wrote:
>> I've tested on NET the performance of invoke compared to Delegate,
>> Delegate
>> is several orders of magnitude faster.  The problem I'm having is
>> creating a
>> delegate with the proper type, Delegate.CreateDelegate requires the
>> delegate
>> type to be defined.  But the base library only knows the base type not
>> the
>> class defined in the user code
>> For example...(This is a very basic pseudo code)   Looking for better
>> perfomance then using Invoke..I read some methods of creating LCG but
>> is
>> that the only way?
>>
>> //defined in class library
>> class fsmEvent{}
>> class fsm
>> {
>>     //events can be posted to the event queue and read from the
>> dispatch
>> loop from a thread...
>>     public Queue<fsmEvent>  QueueEvent;
>>
>>  public void dispatchEvent()
>>  {
>>   ....
>>         fsmEv = Queue.dequeue();
>>       Type t= userFsm.GetType();
>>       MethodInfo mFsmEvent = t.GetMethod(  ... based on fsmEv type,
>> match
>> the parameter list)
>>     // invoke proper method
>>       mFsmEvent.Invoke(userFsm,new
>> object[]{ fsmLoop.fsmEventList[0]});
>>    // Want to replace this is some type of Delegate for performance...
>>
>>      }
>> }
>>
>> // define in user library
>> class userFsmEvent : fsmEvent{}
>> class fsmTimerEvent : fsmEvent{}
>>
>> class fsmUser
>> {
>>     public void hander1(fsmEvent ev){}
>>     public void handler2(fsmTimerEvent ev){}
>>     public void hander3(userFsmEvent ev){}
>>
>> }
>>
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
> 


From atsushi at ximian.com  Wed Jun 14 08:25:15 2006
From: atsushi at ximian.com (Atsushi Eno)
Date: Wed, 14 Jun 2006 21:25:15 +0900
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
In-Reply-To: <008001c68f61$aa299790$0100a8c0@kornelpal.hu>
References: <007a01c68ed3$3e3e45f0$0100a8c0@kornelpal.hu>	<448EC762.2030801@ximian.com>	<01c501c68f2d$3459f9d0$0100a8c0@kornelpal.hu>	<448F6AAF.2060502@ximian.com>
	<008001c68f61$aa299790$0100a8c0@kornelpal.hu>
Message-ID: <4490002B.90808@ximian.com>

I am confused: which is your true opinion?

1)

 > OK, now I understan your problem.

2)

> It may be improper to assume that there is an internal method called 
> InternalAllocateStr even more improper to assume that strings can be 
> modified but I don't think that using reflection to access non-public 
> members is improper. 

Atsushi Eno


From andrews at mainsoft.com  Wed Jun 14 09:37:03 2006
From: andrews at mainsoft.com (Andrew Skiba)
Date: Wed, 14 Jun 2006 06:37:03 -0700
Subject: [Mono-dev] [PATCH] System.Web.Compilation.TemplateControlCompiler
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03136F31@dhost002-45.dex002.intermedia.net>

Hello,

Please review test and patch for TemplateControlCompiler. The bug was
that assignment statement was generated for a read-only property. If no
one objects, I will commit.

Andrew.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TemplateControlCompilerTest.patch
Type: application/octet-stream
Size: 4615 bytes
Desc: TemplateControlCompilerTest.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/1428d678/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TemplateControlCompiler.patch
Type: application/octet-stream
Size: 1366 bytes
Desc: TemplateControlCompiler.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/1428d678/attachment-0001.obj 

From vladimirk at mainsoft.com  Wed Jun 14 10:02:58 2006
From: vladimirk at mainsoft.com (Vladimir Krasnov)
Date: Wed, 14 Jun 2006 07:02:58 -0700
Subject: [Mono-dev] Bug in System.Web.UI.WebControls.BaseDataList
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03136F34@dhost002-45.dex002.intermedia.net>

Sorry, I've forgot the NET_2_0 ifdef, I will recommit.

Vladimir Krasnov

-----Original Message-----
From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Gonzalo
Paniagua Javier
Sent: Tuesday, June 13, 2006 5:58 PM
To: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] Bug in System.Web.UI.WebControls.BaseDataList

On Wed, 2006-05-24 at 06:07 -0700, Vladimir Krasnov wrote:
> Hello,
> 
> There is a bug in BaseDataList, its method OnDataSourceViewChanged is
> not called when data source is changed.
> 
> Look attached sample that reproduces the bug and the patch that fixes
> it.
> I will commit if no one objects.

Your commit broke the 1.1 build and I've reverted it.

-Gonzalo


_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


From js at hotfeet.ch  Wed Jun 14 10:31:46 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Wed, 14 Jun 2006 16:31:46 +0200
Subject: [Mono-dev] Patch for bug #78626
Message-ID: <1150295506.2536.34.camel@leonardo.hotfeet.ch>

Hi,

The attached patch fixes bug
http://bugzilla.ximian.com/show_bug.cgi?id=78626

If think the code for the caching of already compiled
pages/controls/whatever and especially the dependency tracking between
those needs a complete rewrite, but this should do for now.

Is it okay to commit? 

- Juraj



From js at hotfeet.ch  Wed Jun 14 10:33:57 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Wed, 14 Jun 2006 16:33:57 +0200
Subject: [Mono-dev] Patch for bug #78626
Message-ID: <1150295637.2536.36.camel@leonardo.hotfeet.ch>

Hi,

The attached patch fixes bug
http://bugzilla.ximian.com/show_bug.cgi?id=78626

If think the code for the caching of already compiled
pages/controls/whatever and especially the dependency tracking between
those needs a complete rewrite, but this should do for now.

Is it okay to commit? 

- Juraj

(this time _including_ the promised patch)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Caching.patch
Type: text/x-patch
Size: 2406 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/a94dd1bf/attachment.bin 

From tryumk at gmail.com  Mon Jun 12 09:10:21 2006
From: tryumk at gmail.com (Thibault Jochem)
Date: Mon, 12 Jun 2006 15:10:21 +0200
Subject: [Mono-dev] Building steps for Visual Studio 2005 ?
Message-ID: <38f4ed290606120610t24c2b38egb4839a22c14ef52e@mail.gmail.com>

Hi,

I got mono from snv, and I read the README.vsnet, saying that there
was some prerequisite to use mono under VS2005, but no details about
it ( except that it needs monoburg and genmdesc ...).

Before loading the project under VS2005, what do I have to do under
cygwin ? make the whole project to generate some files, or just some
modules ?

Thanks in advance :)
-- 
Try


From mryan at novell.com  Tue Jun 13 10:52:34 2006
From: mryan at novell.com (Matt Ryan)
Date: Tue, 13 Jun 2006 08:52:34 -0600
Subject: [Mono-dev] [Fwd: RE: [cdt-dev] FW: [eclipse-dev] C# plugin for
	Eclipse]
Message-ID: <448E7CD202000046000105A0@victor.provo.novell.com>

There is some discussion going on within the Eclipse CDT project about
C# support.  I'm forwarding some of the information about this
discussion, in case you would be interested.


-- 
Matt Ryan
Senior Software Engineer
Architect - Developer Tools
mryan at novell.com
(801) 861-3518

Novell, Inc.
Software for the Open Enterprise
www.novell.com/open
-------------- next part --------------
An embedded message was scrubbed...
From: Doug Schaefer <DSchaefer at qnx.com>
Subject: RE: [cdt-dev] FW: [eclipse-dev] C# plugin for Eclipse
Date: Tue, 13 Jun 2006 08:34:48 -0400
Size: 22926
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060613/2168e6a3/attachment.mht 

From vojtech.jakubec at strom.cz  Tue Jun 13 12:44:35 2006
From: vojtech.jakubec at strom.cz (Jakubec Vojtech)
Date: Tue, 13 Jun 2006 18:44:35 +0200
Subject: [Mono-dev] System.Timers.Timer bug
Message-ID: <92FFBD2F0464224B88AE6649016CA79749A9A1@exalfa.stromtelecom.cz>

Hi,

I found a multi-threading problem in implementation of System.Timers.Timer class. In our application we are using Timer.Enabled property inside of ElapsedEventHandler method to prevent timer from raising the Elapsed event again while previous handler is still running. In some cases Timer can be disabled and enabled again very fast. 

 

The problem under Mono is with member ManualResetEvent wait. In some cases new thread created by enabling Timer starts and creates instance of wait object before the old thread ends. Then the old thread dispose wait object and new thread throws unhandled NullRefrenceException.

 

I'm attaching modified System.Timers.Timer class from Mono-1.1.15 sources with possible solution.

 

Regards,

Vojtech Jakubec

Telco software development (VAS)

 

STROM telecom, a.s.

 

 

Tel.: +420 211 029 248

BB Cenrum - Beta, Vysko?ilova 1461/2a, 140 00  Praha 4, Czech Republic

www.strom.cz <http://www.strom.cz/> 


DISCLAIMER
This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060613/6f78e491/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Timer.cs
Type: application/octet-stream
Size: 5376 bytes
Desc: Timer.cs
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060613/6f78e491/attachment.obj 

From sebastien.pouliot at gmail.com  Wed Jun 14 11:52:10 2006
From: sebastien.pouliot at gmail.com (Sebastien Pouliot)
Date: Wed, 14 Jun 2006 11:52:10 -0400
Subject: [Mono-dev] Building steps for Visual Studio 2005 ?
In-Reply-To: <38f4ed290606120610t24c2b38egb4839a22c14ef52e@mail.gmail.com>
References: <38f4ed290606120610t24c2b38egb4839a22c14ef52e@mail.gmail.com>
Message-ID: <1150300331.9712.407.camel@poupou.home>

On Mon, 2006-06-12 at 15:10 +0200, Thibault Jochem wrote:
> Hi,
> 
> I got mono from snv, and I read the README.vsnet, saying that there
> was some prerequisite to use mono under VS2005, but no details about
> it ( except that it needs monoburg and genmdesc ...).

"A working cygwin (http://www.cygwin.com/) setup!" implied being able to
build mono under cygwin. I'll update the document to make this clearer.

> Before loading the project under VS2005, what do I have to do under
> cygwin ? make the whole project to generate some files, or just some
> modules ?

You must be able to build mono under cygwin before attempting to compile
it with VS.NET.

You may want to look at the list archive as some people have "reduced"
this requirement. However you'll still need cygwin (and mono building on
it) for other tasks (like building the class libraries, testing the
runtime).
-- 
Sebastien Pouliot  <sebastien at ximian.com>
Blog: http://pages.infinit.net/ctech/



From 2a5gjx302 at sneakemail.com  Wed Jun 14 12:05:51 2006
From: 2a5gjx302 at sneakemail.com (Jonathan Gilbert)
Date: Wed, 14 Jun 2006 11:05:51 -0500
Subject: [Mono-dev] Single thread scheduler for Threading.Timers
  patch
In-Reply-To: <1150265055.26740.14.camel@stan.ophion.org>
Message-ID: <7812-35228@sneakemail.com>

At 11:04 PM 13/06/2006 -0700, Rafael Ferreira wrote:
>Howdy, 
>
>The attached patch changes the current Threading.Timer class to use a
>single thread scheduler instead of the current 1 thread per timer logic.
>I also spent a lot of time working on the Timer unit tests so they more
>consistently pass as well as fixing the "NotWorking" tests. 
>
>Some key features include:
>
>* A single thread handles firing all timer jobs thus allowing a much
>greater number of Timers to be defined - Fixing bug #65734
>* Timer scheduler is only started after the first System.Threading.Timer
>is created (lazy init)
>* Timer scheduler thread dies if there are no more timer jobs in its Job
>queue (early termination)
>* Scheduler can spit out debug info by exporting the MONO_TIMER_DEBUG
>environment variable

One thing that gets me about the design is the way that timer events are
marshalled to a different thread (in the thread pool) in order to be fired.
Obviously, you don't want synchronous callbacks from a single thread for
all timers, but perhaps a timer thread pool, each of which handling a
subset of the timers, would be a viable alternate design. With a limit of,
say, 100 scheduler threads, up to 100 timers could be created without any
chance of interference, and after that point, the threads would be reused
instead of overloading the system with thousands of threads. The threads
could even switch from synchronous callbacks when they are handling only a
single timer to asynchronous thread pool callbacks when their
responsibilities increase.

If we accept the single-thread thread-pool-callback design, though, I have
the following comments on the implementation:

1. A heap structure is very easy to maintain, and would be a significantly
more efficient way to find the next event to be fired. You have comments
that acknowledge the deficiency of looping over the entire set every time,
and I think this would be the logical next step in this.

2. Using Thread.Abort to signal the thread is fundamentally flawed. A user
very quickly adding & removing timers would eventually cause a
ThreadAbortException to fire inside the 'catch' handler, killing off the
scheduler thread and disabling all timers. A better approach would be to
use Monitor.Wait on a synchronization object in the scheduler thread with
the correct time-out, and then Monitor.Pulse to awaken the thread for an
update. The scheduler can use DateTime.Now comparisons to determine, when
Monitor.Wait returns, how long it actually waited and whether it should
actually fire the event at top of the heap, and the return value of
Monitor.Wait will indicate whether it was interrupted and thus should check
the queue of timer additions/deletions before proceeding.

If you'd like, I can try writing an alternate implementation along these
lines, but it will have to wait until after work for me today.

Jonathan Gilbert


From kornelpal at gmail.com  Wed Jun 14 12:51:30 2006
From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=)
Date: Wed, 14 Jun 2006 18:51:30 +0200
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
References: <007a01c68ed3$3e3e45f0$0100a8c0@kornelpal.hu>	<448EC762.2030801@ximian.com>	<01c501c68f2d$3459f9d0$0100a8c0@kornelpal.hu>	<448F6AAF.2060502@ximian.com>
	<008001c68f61$aa299790$0100a8c0@kornelpal.hu>
	<4490002B.90808@ximian.com>
Message-ID: <00a901c68fd2$ca371730$0100a8c0@kornelpal.hu>

>I am confused: which is your true opinion?
>
> 1)
>
> > OK, now I understan your problem.

This is not an opinion. This is only a feedback that I have understood 
Miguel's problem he was speaking of. But I don't means that I have the same 
opinion.

> 2)
>
>> It may be improper to assume that there is an internal method called 
>> InternalAllocateStr even more improper to assume that strings can be 
>> modified but I don't think that using reflection to access non-public 
>> members is improper.

This is my opinion. And another important opinion is that if we assume that 
our class library assemblies have permission to use unsafe code and P/Invoke 
that are higher privileges we can assume that they have reflection 
permissions as well. If they hasn't got these permissions exceptions will be 
raised but this is true for unsafe code and P/Invoke as well. So if our 
opinion is that we should not depend on permissions we should not use either 
unsafe code or P/Invoke. And I think this is somethig we don't want. But if 
our opinion is that it's OK to require full trust or highly privileged 
permissions at least we can use reflection as well.

Korn?l 



From atsushi at ximian.com  Wed Jun 14 13:15:59 2006
From: atsushi at ximian.com (Atsushi Eno)
Date: Thu, 15 Jun 2006 02:15:59 +0900
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
In-Reply-To: <00a901c68fd2$ca371730$0100a8c0@kornelpal.hu>
References: <007a01c68ed3$3e3e45f0$0100a8c0@kornelpal.hu>	<448EC762.2030801@ximian.com>	<01c501c68f2d$3459f9d0$0100a8c0@kornelpal.hu>	<448F6AAF.2060502@ximian.com>
	<008001c68f61$aa299790$0100a8c0@kornelpal.hu>
	<4490002B.90808@ximian.com>
	<00a901c68fd2$ca371730$0100a8c0@kornelpal.hu>
Message-ID: <4490444F.1050706@ximian.com>

Korn?l P?l wrote:
>> I am confused: which is your true opinion?
>>
>> 1)
>>
>> > OK, now I understan your problem.
> 
> This is not an opinion. This is only a feedback that I have understood 
> Miguel's problem he was speaking of. But I don't means that I have the 
> same opinion.
> 
>> 2)
>>
>>> It may be improper to assume that there is an internal method called 
>>> InternalAllocateStr even more improper to assume that strings can be 
>>> modified but I don't think that using reflection to access non-public 
>>> members is improper.
> 
> This is my opinion. And another important opinion is that if we assume 
> that our class library assemblies have permission to use unsafe code and 
> P/Invoke that are higher privileges we can assume that they have 
> reflection permissions as well. If they hasn't got these permissions 
> exceptions will be raised but this is true for unsafe code and P/Invoke 
> as well. So if our opinion is that we should not depend on permissions 
> we should not use either unsafe code or P/Invoke. And I think this is 
> somethig we don't want. But if our opinion is that it's OK to require 
> full trust or highly privileged permissions at least we can use 
> reflection as well.

Then it is very hard to understand why you posted a revised patch
that just removed reflection stuff. No one would think that you
disagree with Miguel when he or she read that reply.

Anyways it matches my understanding. Now we are ready to revert your
changes depending on the future direction without extra discussion
which might happen, as well as the possibility to add extra reflection
dependency. I don't like such extra dependency though, since it makes
code impossible to reuse or to try on other platforms than existing
mono itself.

Atsushi Eno


From mono-devel at fluggo.com  Wed Jun 14 15:12:50 2006
From: mono-devel at fluggo.com (Brian Crowell)
Date: Wed, 14 Jun 2006 14:12:50 -0500
Subject: [Mono-dev] Version-specific binding - resolved, but real bugs
	found
In-Reply-To: <1150242939.2002.4.camel@localhost>
References: <448E0A84.8020707@fluggo.com> <448F4ADE.3080904@fluggo.com>
	<1150242939.2002.4.camel@localhost>
Message-ID: <44905FB2.6080506@fluggo.com>

Gonzalo Paniagua Javier wrote:
> Can you please file bug reports in bugzilla.ximian.com and attach a test
> case for these problems?

Turns out it's a false alarm on the second one. The properties on dynamic 
assemblies in .NET also throw exceptions, though I still think this behavior is 
bad design because it should be treated the same as if the assembly had been 
loaded as a bag-o-bytes.

On the first one, I found that the reason my implicitly-loading assemblies were 
not showing up is because the assemblies loaded into my first domain had 
propogated into the second one. So the bug here is not that the correct assembly 
wasn't being reported, it was that it wasn't even being loaded!

A quick example:

==============================================
using System;
using System.Reflection;

namespace Test {
     class TestClass {
         public static void Main( string[] args ) {
             AppDomain newDomain = AppDomain.CreateDomain( "testDomain" );
			
             foreach( Assembly assem in newDomain.GetAssemblies() ) {
                  Console.WriteLine( assem.FullName );
             }
         }
     }
}
==============================================

Under .NET, this program reports the following assembly in the new AppDomain:

   mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089


Under Mono, these assemblies are reported:

   mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
   test-EmptyAppDomain, Version=0.0.0.0, Culture=neutral


It can be shown that any assembly found in the AppDomain that called 
CreateDomain ends up in the new domain.

This has been filed as bug #78648.

--Brian


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test-EmptyAppDomain.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/e8c43183/attachment.pl 

From Brian.D.Low at hawaii.gov  Wed Jun 14 15:18:07 2006
From: Brian.D.Low at hawaii.gov (Brian.D.Low at hawaii.gov)
Date: Wed, 14 Jun 2006 09:18:07 -1000
Subject: [Mono-dev] (no subject)
Message-ID: <OFF0E0D1D2.84257B9E-ON0A25718D.0069BF83-0A25718D.006A6C4F@hawaii.gov>

Aloha.
  I realy need some help with the install Mono.  I have run into a config 
issue.  When I compile the mod_mono code, the configure works fine (see 
below). However, when I make it craps out complaining about some some code 
that is missing or not compatible.  Do you have any thoughts to this? I am 
running suse 10.1. 
Configuration summary for mod_mono
   * Installation prefix = /usr
   * Apache version = 2.2
   * Apache modules directory = /usr/lib/apache2
   * apxs = /usr/sbin/apxs2
   * apr-config = /usr/bin/apr-1-config
   * Verbose logging (debug) = no
   * mono prefix = /usr/lib/pkgconfig/../..
   * Default MonoApplicationsConfigDir = 
/etc/apache2/mod-mono-applications
Thanks so much,

State of Hawaii
Information Technology Service Office
Brian Low
830 Punchbowl Street Room 216
Honolulu, HI  96813
E-mail: Brian.D.Low at hawaii.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/fdf09aac/attachment.html 

From kornelpal at gmail.com  Wed Jun 14 15:20:49 2006
From: kornelpal at gmail.com (=?iso-8859-2?B?S29ybulsIFDhbA==?=)
Date: Wed, 14 Jun 2006 21:20:49 +0200
Subject: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
References: <007a01c68ed3$3e3e45f0$0100a8c0@kornelpal.hu>	<448EC762.2030801@ximian.com>	<01c501c68f2d$3459f9d0$0100a8c0@kornelpal.hu>	<448F6AAF.2060502@ximian.com>
	<008001c68f61$aa299790$0100a8c0@kornelpal.hu>
	<4490002B.90808@ximian.com>
	<00a901c68fd2$ca371730$0100a8c0@kornelpal.hu>
	<4490444F.1050706@ximian.com>
Message-ID: <008d01c68fe7$a661c340$0100a8c0@kornelpal.hu>

Hi,

> Anyways it matches my understanding. Now we are ready to revert your
> changes depending on the future direction without extra discussion
> which might happen, as well as the possibility to add extra reflection
> dependency. I don't like such extra dependency though, since it makes
> code impossible to reuse or to try on other platforms than existing
> mono itself.

I have the same opinion regarding these things so I'm happy.:) And anyway I 
like to discuss things because I believe that discussing different opinions 
has good results. Note that I didn't committed any reflection related thinks 
so there is nothing to revert.

I don't like late binding either (unless really necessary) but not because 
of CAS rather than because it causes no compilation error so makes the code 
more difficult to maintain and late binging is less efficient than 
compile-time linking.

When I tried "new string ((char) 0, length)" I noticed that altough it's 
slower than InternalAllocateStr, when InternalAllocateStr is called using a 
late binding the performance gain is little so it's better to avoid 
reflection in this case.

Note that I posted this patch but it was out of interest:
http://lists.ximian.com/pipermail/mono-devel-list/2005-December/016253.html

But there allways were different views: for example I was asked to impement 
functionality in corlib and use it from mcs using reflection:
http://lists.ximian.com/pipermail/mono-devel-list/2006-March/017409.html

(BTW I should repost the modified version of this patch at some time in the 
future.:)

All solutions has advantages and drawbacks as well. I was debating about 
reflection becuase there should be some solution to the problem of internal 
interopability of the class library and/or compilers instead following 
different ways.

Microsoft uses public methods then documents that "This type/member supports 
the .NET Framework infrastructure and is not intended to be used directly 
from your code." - I think we should not follow this strategy.

Other solution is to use reflection on non-public types/members that has the 
disadvantages we have discussed.

Or use InternalsVisibleToAttribute that is not available in profile 1.x. - 
By hacking the runtime and mcs to allow this attribute type be declared in 
the assembly privately and serve the same purpose this problem could be 
solved however and this solution provides the best performance.

You mentioned code reusing on other platforms. Regardless of the methods 
used when using non-standard or non-public members or types this is a 
problem. But for example the interaction between System.Windows.Forms and 
System.Drawing or between mono-service and System.ServiceProcess is required 
in order to be possible to implement their functionality so some solution 
should be preferred and used.

Korn?l

----- Original Message ----- 
From: "Atsushi Eno" <atsushi at ximian.com>
To: "Korn?l P?l" <kornelpal at gmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, June 14, 2006 7:15 PM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()


> Korn?l P?l wrote:
>>> I am confused: which is your true opinion?
>>>
>>> 1)
>>>
>>> > OK, now I understan your problem.
>>
>> This is not an opinion. This is only a feedback that I have understood 
>> Miguel's problem he was speaking of. But I don't means that I have the 
>> same opinion.
>>
>>> 2)
>>>
>>>> It may be improper to assume that there is an internal method called 
>>>> InternalAllocateStr even more improper to assume that strings can be 
>>>> modified but I don't think that using reflection to access non-public 
>>>> members is improper.
>>
>> This is my opinion. And another important opinion is that if we assume 
>> that our class library assemblies have permission to use unsafe code and 
>> P/Invoke that are higher privileges we can assume that they have 
>> reflection permissions as well. If they hasn't got these permissions 
>> exceptions will be raised but this is true for unsafe code and P/Invoke 
>> as well. So if our opinion is that we should not depend on permissions we 
>> should not use either unsafe code or P/Invoke. And I think this is 
>> somethig we don't want. But if our opinion is that it's OK to require 
>> full trust or highly privileged permissions at least we can use 
>> reflection as well.
>
> Then it is very hard to understand why you posted a revised patch
> that just removed reflection stuff. No one would think that you
> disagree with Miguel when he or she read that reply.
>
> Anyways it matches my understanding. Now we are ready to revert your
> changes depending on the future direction without extra discussion
> which might happen, as well as the possibility to add extra reflection
> dependency. I don't like such extra dependency though, since it makes
> code impossible to reuse or to try on other platforms than existing
> mono itself.
>
> Atsushi Eno 



From 2a5gjx302 at sneakemail.com  Wed Jun 14 16:19:33 2006
From: 2a5gjx302 at sneakemail.com (Jonathan Gilbert)
Date: Wed, 14 Jun 2006 15:19:33 -0500
Subject: [Mono-dev] Single thread scheduler for Threading.Timers 
  patch
In-Reply-To: <9509.204.17.26.4.1150303035.squirrel@ophion.org>
References: <11728-64231@sneakemail.com>
	<1150265055.26740.14.camel@stan.ophion.org>
	<11728-64231@sneakemail.com>
Message-ID: <3785-35152@sneakemail.com>

At 09:37 AM 14/06/2006 -0700, Rafael Ferreira wrote:
>Hey there, let me start by saying thanks for the feedback.. my commments
>below:

No problem :-) By the way, it may have appeared to be off of the list (I
mention this because I didn't see your reply on the list), but actually my
post was to mono-devel-list and CCed to you. I've done the same with this
reply; I hope that's okay with you :-)

>> At 11:04 PM 13/06/2006 -0700, Rafael Ferreira wrote:
>>>Howdy,
>>>
>>>The attached patch changes the current Threading.Timer class to use a
>>>single thread scheduler instead of the current 1 thread per timer logic.
>>>I also spent a lot of time working on the Timer unit tests so they more
>>>consistently pass as well as fixing the "NotWorking" tests.
>>>
>>>Some key features include:
>>>
>>>* A single thread handles firing all timer jobs thus allowing a much
>>>greater number of Timers to be defined - Fixing bug #65734
>>>* Timer scheduler is only started after the first System.Threading.Timer
>>>is created (lazy init)
>>>* Timer scheduler thread dies if there are no more timer jobs in its Job
>>>queue (early termination)
>>>* Scheduler can spit out debug info by exporting the MONO_TIMER_DEBUG
>>>environment variable
>>
>> One thing that gets me about the design is the way that timer events are
>> marshalled to a different thread (in the thread pool) in order to be
>> fired.
>> Obviously, you don't want synchronous callbacks from a single thread for
>> all timers, but perhaps a timer thread pool, each of which handling a
>> subset of the timers, would be a viable alternate design. With a limit of,
>> say, 100 scheduler threads, up to 100 timers could be created without any
>> chance of interference, and after that point, the threads would be reused
>> instead of overloading the system with thousands of threads. The threads
>> could even switch from synchronous callbacks when they are handling only a
>> single timer to asynchronous thread pool callbacks when their
>> responsibilities increase.
>
>I'm not sure what do you mean by "marshalled to a different thread",
>there's no serialization taking place here and this implementation is not
>any different than what is currently being done by the timer class. The
>only difference is that I chose to call ThreadPool.QueueUserWorkItem
>explicitly instead of using .BeingInvoke(). Also, having n scheduler
>therads would not help you much, actually I the whole point of the
>single-thread scheduler is to minimize idle threads.

The call to ThreadPool.QueueUserWorkItem *is* the marshalling I was
referring to. It isn't data that's being marshalled, but rather the
function call itself. The only concern I had was with the responsiveness of
thread pool threads being awakened when they have possibly been asleep for
a long time; if pages have to be brought into memory when the thread pool
threads unblock, then the timer will have possibly several additional
seconds of delay added to the callback. Obviously, making the callback from
the thread that is driving the timer wouldn't have this problem, but it
would have the different problem that if the callback takes too long the
timer's activity (and that of any other timers on the same thread) will be
negatively affected.

I'm not actually sure how Microsoft's implementation works. I could write a
couple of tests and run them. Specifically, what I'm interested to know is,
if you have only one timer running, and that timer's callback takes longer
than the interval, will the next timer tick cause another, re-entrant call
into the callback on another thread, or does that next tick get delayed
until the callback returns? The MSDN documentation makes it clear that
thread pool threads are involved, but it doesn't indicate whether the
thread pool threads themselves drive the timer, or whether the timer(s) are
driven by a separate thread and only the callbacks are done through the
thread pool.

>> If we accept the single-thread thread-pool-callback design, though, I have
>> the following comments on the implementation:
>>
>> 1. A heap structure is very easy to maintain, and would be a significantly
>> more efficient way to find the next event to be fired. You have comments
>> that acknowledge the deficiency of looping over the entire set every time,
>> and I think this would be the logical next step in this.
>
>I agree that a sorted data structure would speed things up the problem
>there is that SortedList will just not cut it and writing a new data
>structure (or a wrapper class) just didn't sense just to speed up a very
>edge case (how many users are going create 10k timers?)

Sure, but heaps are especially easy to write :-) They fit into an array,
and they require only three helper methods to update the structure: swap,
heapify-up and heapify-down.

When a new timer is added, you simply drop it onto the end of the array,
and then heapify-up. When a timer tick occurs, you move the item at the end
of the array overtop of the one at the front of the array, and then
heapify-down. Following these rules, the first entry in the array will
always be the next event to fire.

The heapifying functions are relatively simple to implement and take only a
dozen lines each.

>> 2. Using Thread.Abort to signal the thread is fundamentally flawed. A user
>> very quickly adding & removing timers would eventually cause a
>> ThreadAbortException to fire inside the 'catch' handler, killing off the
>> scheduler thread and disabling all timers. A better approach would be to
>> use Monitor.Wait on a synchronization object in the scheduler thread with
>> the correct time-out, and then Monitor.Pulse to awaken the thread for an
>> update. The scheduler can use DateTime.Now comparisons to determine, when
>> Monitor.Wait returns, how long it actually waited and whether it should
>> actually fire the event at top of the heap, and the return value of
>> Monitor.Wait will indicate whether it was interrupted and thus should
>> check
>> the queue of timer additions/deletions before proceeding.
>
>I agree that doing a Abort() on the thread is not the most elegant way to
>singal a thread but I do cover the edge cases in send_scheduler_signal so
>a thread is only signaled if it is in the right "state". I also "queue" up
>abort()'s so under heavy "timer" creation only 1 abort call is made. I'm
>not quite sure how your Monitor logic would work but I would be more than
>glad to entertain your solution.

I haven't had the opportunity to apply the patch; I have been reading it
directly from the timer.patch file, in which form it is rather difficult to
make heads or tails of :-) So, I'm not able to evaluate the
send_scheduler_signal code to see if there might be any holes in it.

The monitor approach looks roughly like this:

void send_signal(object signal_object)
{
  lock (sync)
  {
    signal_queue.Enqueue(signal_object);
    Monitor.Pulse(sync);
  }
}

Queue signal_queue = new Queue();
object sync = new object();

struct TickInfo
{
  public DateTime TimeOfNextTick, Interval;
  public WaitCallback CallbackMethod;
  public object CallbackData;
}

void thread_proc()
{
  TickInfo[] heap = new TickInfo[initial size];
  int num_heap_entries = 0;

  lock (sync)
    while (true)
    {
      TimeSpan delay = TimeSpan.FromMilliseconds(Timeout.Infinite);

      if (num_heap_entries > 0)
      {
        DateTime now = DateTime.Now;

        if (heap[0].TimeOfNextTick < now)
        {  
          fire_first_event_from_heap(heap, num_heap_entries);
          continue;
        }

        delay = heap[0].TimeOfNextTick - now;
      }

      Monitor.Wait(sync, delay);

      while (signal_queue.Count > 0)
        update_heap(ref heap,
(SchedulerUpdateSignalObject)signal_queue.Dequeue());
    }
}

void fire_first_event_from_heap(TickInfo[] heap, int num_heap_entries)
{
  ThreadPool.QueueUserWorkItem(heap[0].CallbackMethod, heap[0].CallbackData);

  TickInfo next_tick = heap[0];

  next_tick.TimeOfNextTick = DateTime.Now + next_tick.Interval;

  // remove the old tick
  heap[0] = heap[num_heap_entries - 1];
  heapify_down(heap, num_heap_entries - 1);

  // insert the new one
  heap[num_heap_entries - 1] = next_tick;
  heapify_up(heap, num_heap_entries);
}

>> If you'd like, I can try writing an alternate implementation along these
>> lines, but it will have to wait until after work for me today.
>
>Like I said, go right ahead. There's always more than 1 way to implement
>things

I guess the above counts as a rough pseudocode implementation of what I had
in mind :-) What are your thoughts?

Jonathan Gilbert


From mono-devel at fluggo.com  Wed Jun 14 16:47:39 2006
From: mono-devel at fluggo.com (Brian Crowell)
Date: Wed, 14 Jun 2006 15:47:39 -0500
Subject: [Mono-dev] Version-specific binding - resolved, but real bugs
	found
In-Reply-To: <1150242939.2002.4.camel@localhost>
References: <448E0A84.8020707@fluggo.com> <448F4ADE.3080904@fluggo.com>
	<1150242939.2002.4.camel@localhost>
Message-ID: <449075EB.9000701@fluggo.com>

Gonzalo Paniagua Javier wrote:
> Can you please file bug reports in bugzilla.ximian.com and attach a test
> case for these problems?

mono-devel-list is taking a bizarre amount of time to show my message. 
Regardless, here's one potential solution.

--Brian
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-emptyCreateDomain.diff
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/3a051414/attachment.pl 

From mono-devel at fluggo.com  Wed Jun 14 16:55:17 2006
From: mono-devel at fluggo.com (Brian Crowell)
Date: Wed, 14 Jun 2006 15:55:17 -0500
Subject: [Mono-dev] Version-specific binding - resolved, but real bugs
	found
In-Reply-To: <1150242939.2002.4.camel@localhost>
References: <448E0A84.8020707@fluggo.com> <448F4ADE.3080904@fluggo.com>
	<1150242939.2002.4.camel@localhost>
Message-ID: <449077B5.4050507@fluggo.com>

Gonzalo Paniagua Javier wrote:
> Can you please file bug reports in bugzilla.ximian.com and attach a test
> case for these problems?

Slightly improved patch which removes the now-unnecessary locals.

Sorry for the spam; still very new to this.

--Brian
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: create-empty-appdomain.patch
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/6a8a4073/attachment.pl 

From mono at evain.net  Wed Jun 14 17:26:14 2006
From: mono at evain.net (Jb Evain)
Date: Wed, 14 Jun 2006 23:26:14 +0200
Subject: [Mono-dev] Version-specific binding - resolved,
	but real bugs found
In-Reply-To: <449075EB.9000701@fluggo.com>
References: <448E0A84.8020707@fluggo.com> <448F4ADE.3080904@fluggo.com>
	<1150242939.2002.4.camel@localhost> <449075EB.9000701@fluggo.com>
Message-ID: <980E072B-AEC3-449A-A04F-A7F5378CC396@evain.net>

Hi,

This is discussed here:

http://bugzilla.ximian.com/show_bug.cgi?id=76757

Jb

On Jun 14, 2006, at 10:47 PM, Brian Crowell wrote:

> Gonzalo Paniagua Javier wrote:
>> Can you please file bug reports in bugzilla.ximian.com and attach  
>> a test
>> case for these problems?
>
> mono-devel-list is taking a bizarre amount of time to show my  
> message. Regardless, here's one potential solution.
>
> --Brian
> Index: appdomain.c
> ===================================================================
> --- appdomain.c (revision 61712)
> +++ appdomain.c (working copy)
> @@ -496,12 +496,8 @@
>
>         mono_context_init (data);
>
> -       /* The new appdomain should have all assemblies loaded */
> -       mono_domain_assemblies_lock (domain);
> -       /*g_print ("copy assemblies from domain %p (%s)\n", domain,  
> domain->friendly_name);*/
> -       for (tmp = domain->domain_assemblies; tmp; tmp = tmp->next)
> -               add_assemblies_to_domain (data, tmp->data, NULL);
> -       mono_domain_assemblies_unlock (domain);
> +       /* Load only the corlib into the new domain */
> +       add_assemblies_to_domain (data, mono_defaults.corlib- 
> >assembly, NULL);
>
>         return ad;
>  }_______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From mono-devel at fluggo.com  Wed Jun 14 17:29:55 2006
From: mono-devel at fluggo.com (Brian Crowell)
Date: Wed, 14 Jun 2006 16:29:55 -0500
Subject: [Mono-dev] Version-specific binding - resolved, but real bugs
	found
In-Reply-To: <449075EB.9000701@fluggo.com>
References: <448E0A84.8020707@fluggo.com>
	<448F4ADE.3080904@fluggo.com>	<1150242939.2002.4.camel@localhost>
	<449075EB.9000701@fluggo.com>
Message-ID: <44907FD3.4040408@fluggo.com>

Brian Crowell wrote:
> mono-devel-list is taking a bizarre amount of time to show my message. 
> Regardless, here's one potential solution.

Unfortunately, this solution has splash damage.

Once this bug is fixed, other bad assumptions come into light. For example, a 
CrossAppDomainDelegate does not fire properly in the new domain because the 
assembly associated with its target is not loaded into the new domain before an 
attempt is made to call the target.

I believe the problem can be traced to a combination of the 
CrossAppDomainSink.SyncProcessMessage method (in 
/class/corlib/System.Runtime.Remoting.Channels/CrossAppDomainChannel.cs) and 
AppDomain.InvokeInDomainByID (in /class/corlib/System/AppDomain.cs). It seems to 
be because the cross-appdomain call bypasses the normal remoting channels, and 
therefore bypasses the part that ensures deserialized references can be used in 
the new domain.

I'll keep looking into this.

--Brian


From mono-devel at fluggo.com  Wed Jun 14 17:52:51 2006
From: mono-devel at fluggo.com (Brian Crowell)
Date: Wed, 14 Jun 2006 16:52:51 -0500
Subject: [Mono-dev] Version-specific binding - resolved, but real bugs
	found
In-Reply-To: <980E072B-AEC3-449A-A04F-A7F5378CC396@evain.net>
References: <448E0A84.8020707@fluggo.com> <448F4ADE.3080904@fluggo.com>
	<1150242939.2002.4.camel@localhost> <449075EB.9000701@fluggo.com>
	<980E072B-AEC3-449A-A04F-A7F5378CC396@evain.net>
Message-ID: <44908533.5020009@fluggo.com>

Jb Evain wrote:
> This is discussed here:
> 
> http://bugzilla.ximian.com/show_bug.cgi?id=76757

Ah, good. I thought I was alone here.

So, from that discussion I gather that this is a known bug that no-one wants to 
fix, for fear of having to fix other applications that rely on it.

And yet, from my perspective, this is a known bug that prevents my application 
from running, since my app relies on being able to load two different versions 
of the same assembly in two different AppDomains.

Is that where we stand? Because I would certainly be willing to fix the bug in 
the runtime, and, regardless, it must be fixed, though I would really appreciate 
your input on how to do it.

--Brian


From paul at all-the-johnsons.co.uk  Wed Jun 14 17:54:11 2006
From: paul at all-the-johnsons.co.uk (Paul)
Date: Wed, 14 Jun 2006 22:54:11 +0100
Subject: [Mono-dev] ikvm source tarball
Message-ID: <1150322051.10582.40.camel@T7.Linux>

Hi,

Should there be some source code in the ikvm tarball available from the
go-mono/sources website? It's only got dlls and binaries in there.

TTFN

Paul
-- 
ich liebe Ashleigh, eins zwei drei 
ich liebe Ashleigh, auf meinem Knee zu h?pfen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/d984d0ed/attachment.bin 

From mcastro at mcsoft.com.br  Wed Jun 14 18:14:34 2006
From: mcastro at mcsoft.com.br (=?ISO-8859-1?Q?Marco_Aur=E9lio_Castro?=)
Date: Wed, 14 Jun 2006 19:14:34 -0300
Subject: [Mono-dev] [Fwd: databinder works?]
Message-ID: <44908A4A.7090505@mcsoft.com.br>

Thanks very much by the clue,

   But, can you tell me way a work around to it? text='<%# 
DataBinder.Eval(DataSet,"Tables[Clients].DefaultView.[0].Client") %>'

   Thanks,

   Marco Castro

Martin Hinks escreveu:

If you read the first line of the exception it is fairly clear what
the problem is:

System.NotImplementedException: The requested feature is not implemented.

Unfortunately this portion of Mono has not yet been completed and so
is not implemented... yet.

On 6/13/06, Marco Aur?lio Castro <mcastro at mcsoft.com.br> wrote:

Hello,

    I'm developing a site in Delphi 2006 to run in Mono and I tried to
connect a Dataset with an edit box by DataBinder. The connection is
        text='<%# DataBinder.Eval(DataSet,
"Tables[Clients].DefaultView.[0].Client") %>'

    It works in Windows, what is wrong here?



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 12/6/2006



From joe_audette at yahoo.com  Wed Jun 14 18:34:06 2006
From: joe_audette at yahoo.com (Joe Audette)
Date: Wed, 14 Jun 2006 15:34:06 -0700 (PDT)
Subject: [Mono-dev] (no subject)
In-Reply-To: <OFF0E0D1D2.84257B9E-ON0A25718D.0069BF83-0A25718D.006A6C4F@hawaii.gov>
Message-ID: <20060614223406.5351.qmail@web39102.mail.mud.yahoo.com>

Hi Brian,

Can you post the actual error you get when you run make?

Cheers,

Joe
 
joe_audette [at] yahoo dotcom 
http://www.joeaudette.com 
http://www.mojoportal.com


----- Original Message ----
From: Brian.D.Low at hawaii.gov
To: mono-devel-list at lists.ximian.com
Sent: Wednesday, June 14, 2006 2:18:07 PM
Subject: [Mono-dev] (no subject)


Aloha.   I realy need some help with the install Mono.  I have run into a config issue.  When I compile the mod_mono code, the configure works fine (see below). However, when I make it craps out complaining about some some code that is missing or not compatible.  Do you have any thoughts to this? I am running suse 10.1.   
Configuration summary for mod_mono 
   * Installation prefix = /usr
    * Apache version = 2.2
    * Apache modules directory = /usr/lib/apache2
    * apxs = /usr/sbin/apxs2
    * apr-config = /usr/bin/apr-1-config
    * Verbose logging (debug) = no
    * mono prefix = /usr/lib/pkgconfig/../..
    * Default MonoApplicationsConfigDir = /etc/apache2/mod-mono-applications 
Thanks so much, 

 State of Hawaii
 Information Technology Service Office
 Brian Low
 830 Punchbowl Street Room 216
 Honolulu, HI  96813
 E-mail: Brian.D.Low at hawaii.gov
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/077b12fc/attachment.html 

From gonzalo at novell.com  Wed Jun 14 19:15:05 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Wed, 14 Jun 2006 19:15:05 -0400
Subject: [Mono-dev] [PATCH] System.Web.Compilation.TemplateControlCompiler
In-Reply-To: <DA63C6E8B207E748B20D46DFED7B772D03136F31@dhost002-45.dex002.intermedia.net>
References: <DA63C6E8B207E748B20D46DFED7B772D03136F31@dhost002-45.dex002.intermedia.net>
Message-ID: <1150326905.7507.3.camel@localhost>

On Wed, 2006-06-14 at 06:37 -0700, Andrew Skiba wrote:
> Hello,
> 
> Please review test and patch for TemplateControlCompiler. The bug was
> that assignment statement was generated for a read-only property. If no
> one objects, I will commit.

I don't think this patch is ok. And I'm tired of seeing that 'if no one
objects, I'll commit'. You should wait patiently until the patch is
approved and resubmit if you get no answer, which is what everyone else
does.

AddCodeForPropertyOrField can be called with a FieldInfo, and this will
make:
+                       if (isDataBound && ((PropertyInfo)
member).CanWrite) {

crash.

-Gonzalo




From kornelpal at gmail.com  Wed Jun 14 19:21:00 2006
From: kornelpal at gmail.com (=?ISO-8859-1?B?S29ybulsIFDhbA==?=)
Date: Thu, 15 Jun 2006 01:21:00 +0200
Subject: [Mono-dev] Version-specific binding - resolved, but real bugsfound
References: <448E0A84.8020707@fluggo.com>
	<448F4ADE.3080904@fluggo.com><1150242939.2002.4.camel@localhost>
	<449075EB.9000701@fluggo.com><980E072B-AEC3-449A-A04F-A7F5378CC396@evain.net>
	<44908533.5020009@fluggo.com>
Message-ID: <00aa01c69009$33cd5d40$0100a8c0@kornelpal.hu>

Hi,

Actually it is only XSP (and mod-mono-server) that depends on this. And it 
could be solved by simply installing Mono.WebServer.dll to the GAC but this 
is what Mono team don't want to do because the API of Mono.WebServer.dll is 
not stable and the conception of GAC is to have assemblies with stable API.

Another solution could be to construct the AppDomain inside 
Mono.WebServer.dll (or use a non-public method in System.Web.dll) that uses 
AppDomain.CreateInstanceFrom so Mono.WebServer.dll would be loaded without 
problems if it's not installed to the GAC. But they don't want to do this 
because this could make XSP incompatible with other runtimes. (Altough it 
isn't compatible with other runtimes because it relies on this bug...)

But the of modifying (or keeping) the runtime to behave incorrectly sounds 
to me as a nonsense. And the official point of view of Mono team is to use 
this solution because they consider the other solutions being less 
compatible with MS.NET or being more improper than this one. But the truth 
is that this is the most improper solution and breaking a lot of 
applications just for XSP is not worth...

As I see this situation they take this bug too personally and they don't see 
what is good for Mono.

Korn?l

----- Original Message ----- 
From: "Brian Crowell" <mono-devel at fluggo.com>
To: "Jb Evain" <mono at evain.net>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, June 14, 2006 11:52 PM
Subject: Re: [Mono-dev] Version-specific binding - resolved, but real 
bugsfound


> Jb Evain wrote:
>> This is discussed here:
>>
>> http://bugzilla.ximian.com/show_bug.cgi?id=76757
>
> Ah, good. I thought I was alone here.
>
> So, from that discussion I gather that this is a known bug that no-one 
> wants to fix, for fear of having to fix other applications that rely on 
> it.
>
> And yet, from my perspective, this is a known bug that prevents my 
> application from running, since my app relies on being able to load two 
> different versions of the same assembly in two different AppDomains.
>
> Is that where we stand? Because I would certainly be willing to fix the 
> bug in the runtime, and, regardless, it must be fixed, though I would 
> really appreciate your input on how to do it.
>
> --Brian
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list 



From majkrzak at gmail.com  Wed Jun 14 19:40:25 2006
From: majkrzak at gmail.com (Colt D. Majkrzak)
Date: Wed, 14 Jun 2006 18:40:25 -0500
Subject: [Mono-dev] Mono on the x86 Intel Macs
Message-ID: <01ad01c6900b$e962e3d0$0201a8c0@coltmajk>

Is there any projected time line on when an Intel Mono installer will be
available for the Intel Mac's?  If not, are there any notes some where on
how to properly build mono for the Intel's?  

 

Thanks!

 

----------------------------------------------------- 
"majkrzak at gmail.com" is a NetIBA validated email address. Certificate
#604044E. Protect yourself against Internet fraud by getting the Consumer
Protection Tool at www.netiba.com/?2764.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060614/118bb6c5/attachment.html 

From wberrier at novell.com  Wed Jun 14 19:53:31 2006
From: wberrier at novell.com (Wade Berrier)
Date: Wed, 14 Jun 2006 17:53:31 -0600
Subject: [Mono-dev] Mono on the x86 Intel Macs
In-Reply-To: <01ad01c6900b$e962e3d0$0201a8c0@coltmajk>
References: <01ad01c6900b$e962e3d0$0201a8c0@coltmajk>
Message-ID: <1150329211.12438.10.camel@berrier.site>

The plan is to have one out the next couple of weeks.

Wade

On Wed, 2006-06-14 at 18:40 -0500, Colt D. Majkrzak wrote:
> Is there any projected time line on when an Intel Mono installer will
> be available for the Intel Mac?s?  If not, are there any notes some
> where on how to properly build mono for the Intel?s?  
> 
>  
> 
> Thanks!
> 
>  
> 
> ----------------------------------------------------- 
> "majkrzak at gmail.com" is a NetIBA validated email address. Certificate
> #604044E. Protect yourself against Internet fraud by getting the
> Consumer Protection Tool at www.netiba.com/?2764.
> 
>  
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From aung.sfilter at gmail.com  Thu Jun 15 02:23:27 2006
From: aung.sfilter at gmail.com (Aung)
Date: Thu, 15 Jun 2006 13:23:27 +0700
Subject: [Mono-dev] Can Mono run on IBM-AIX OS?
Message-ID: <006401c69044$39a2bc20$0a00a8c0@aungnewlaptop>

Hi guys,

 

Perhaps, these are newbie questions. 

Can Mono run on IBM-AIX OS?

Is it commercially feasible (performance wise) to run XSP as the server?

Is it possible to change file extension from .aspx or asmx to something
else?

 

Thanks.

 

Aung

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060615/5cdc6b4e/attachment.html 

From adrinael at adrinael.net  Thu Jun 15 02:49:52 2006
From: adrinael at adrinael.net (Petri Latvala)
Date: Thu, 15 Jun 2006 09:49:52 +0300
Subject: [Mono-dev] DataTable.CreateDataReader patch
Message-ID: <20060615064952.GE927@adrinael.net>

Here's a naive implementation of DataTable.CreateDataReader. This is
too simple for me to believe it is correct. Comments, please.




Index: class/System.Data/System.Data/DataTable.cs
===================================================================
--- class/System.Data/System.Data/DataTable.cs	(revision 61743)
+++ class/System.Data/System.Data/DataTable.cs	(working copy)
@@ -1024,9 +1024,9 @@
 
 #if NET_2_0
 		[MonoTODO]
-		public DataTableReader GetDataReader ()
+		public DataTableReader CreateDataReader ()
 		{
-			throw new NotImplementedException ();
+			return new DataTableReader(this);
 		}
 #endif
 







-- 
Petri Latvala
Adrinael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060615/3243a232/attachment.bin 

From =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?=  Thu Jun 15 06:08:26 2006
From: =?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?= (=?ISO-8859-1?Q?=22Andr=E9s_G=2E_Aragoneses_=5B_knocte_=5D?=)
Date: Thu, 15 Jun 2006 12:08:26 +0200
Subject: [Mono-dev] Re: Bug with Serialization of Nullable type
In-Reply-To: <44893F50.1050800@gmail.com>
References: <44893F50.1050800@gmail.com>
Message-ID: <4491319A.8070904@gmail.com>

I wrote:
> I filed a bug about Serialization:
> 
> http://bugzilla.ximian.com/show_bug.cgi?id=78611
> 
> I have made some research and I have proposed a small change to solve 
> it, but I don't have experience or knowledge to determine if it's correct.
> 
> Any help would be appreciated.

I have managed to create a simple testcase for this bug, if anyone is 
interested:

http://bugzilla.ximian.com/showattachment.cgi?attach_id=17190

Regards,

	Andr?s	[ knocte ]

-- 



From alexc at majestic12.co.uk  Thu Jun 15 06:47:09 2006
From: alexc at majestic12.co.uk (Alex Chudnovsky)
Date: Thu, 15 Jun 2006 11:47:09 +0100
Subject: [Mono-dev] State of support for VB.NET
In-Reply-To: <2277.212.36.1.186.1132851944.squirrel@212.36.1.186>
References: <2277.212.36.1.186.1132851944.squirrel@212.36.1.186>
Message-ID: <44913AAD.6080600@majestic12.co.uk>

Hi all,

Has anyone ported VB.NET apps to Mono recently, particularly I am 
wondering if VB.NET is supported in ASP pages?

I've done reasonable amount of C# porting and found Mono is very good 
and I did not even have to recompile, but from what I heard VB.NET 
generates less Mono-compatible code, is that still the case? Say I can 
use C# app compiled in VS 2003 without recompilation in Mono, can same 
be done for VB.NET or it will require recompilation?

I am aware of http://www.mono-project.com/VisualBasic.NET_support page, 
but it has rather short descriptions, I'd really like to see page 
summarising what's not yet supported.

Alex


From tsenganal at novell.com  Thu Jun 15 08:13:58 2006
From: tsenganal at novell.com (T Senganal)
Date: Thu, 15 Jun 2006 06:13:58 -0600
Subject: [Mono-dev] DataTable.CreateDataReader patch
Message-ID: <44919C600200008C0000F8A5@lucius.provo.novell.com>

Hi 

> Here's a naive implementation of DataTable.CreateDataReader. This is
> too simple for me to believe it is correct. Comments, please.

The code for creating the DataTableReader is fine.. But the
DataTableReader has quite a 
few issues to be fixed and hence the delay in comitting the changes
(need more tests)..
I am currently fixing the 2.0 methods and will commit the changes soon..

Regards
Senga


From js at hotfeet.ch  Thu Jun 15 08:25:56 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Thu, 15 Jun 2006 14:25:56 +0200
Subject: [Mono-dev] Patch for AspTokenizer (Bug 78643)
Message-ID: <1150374356.2538.19.camel@leonardo.hotfeet.ch>

Hi,

Could you please review and approve the attached patch?
It fixes bug http://bugzilla.ximian.com/show_bug.cgi?id=78643

I don't know how the tokenizer is supposed to pass errors to the parser.
For the quoting error I've made it throw an exception.

- Juraj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AspTokenizer.patch
Type: text/x-patch
Size: 882 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060615/ae8a07f9/attachment.bin 

From gonzalo at novell.com  Thu Jun 15 10:38:39 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Thu, 15 Jun 2006 10:38:39 -0400
Subject: [Mono-dev] Re: Patch for AspTokenizer (Bug 78643)
In-Reply-To: <1150374356.2538.19.camel@leonardo.hotfeet.ch>
References: <1150374356.2538.19.camel@leonardo.hotfeet.ch>
Message-ID: <1150382319.7507.8.camel@lalo.micasa>

On Thu, 2006-06-15 at 14:25 +0200, Juraj Skripsky wrote:
> Hi,
> 
> Could you please review and approve the attached patch?
> It fixes bug http://bugzilla.ximian.com/show_bug.cgi?id=78643
> 
> I don't know how the tokenizer is supposed to pass errors to the parser.
> For the quoting error I've made it throw an exception.

Try this one and let me know if everything works as it should.
Thanks.

-Gonzalo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 78643.patch
Type: text/x-patch
Size: 1032 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060615/89f3ba39/attachment.bin 

From js at hotfeet.ch  Thu Jun 15 10:48:31 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Thu, 15 Jun 2006 16:48:31 +0200
Subject: [Mono-dev] Re: Patch for AspTokenizer (Bug 78643)
In-Reply-To: <1150382319.7507.8.camel@lalo.micasa>
References: <1150374356.2538.19.camel@leonardo.hotfeet.ch>
	<1150382319.7507.8.camel@lalo.micasa>
Message-ID: <1150382911.2533.8.camel@leonardo.hotfeet.ch>

Hi,

I've applied and tested it. It works just fine.
Will you commit the patch or should I add an changelog entry and do it?

Thanks!

- Juraj


On Thu, 2006-06-15 at 10:38 -0400, Gonzalo Paniagua Javier wrote:
> On Thu, 2006-06-15 at 14:25 +0200, Juraj Skripsky wrote:
> > Hi,
> > 
> > Could you please review and approve the attached patch?
> > It fixes bug http://bugzilla.ximian.com/show_bug.cgi?id=78643
> > 
> > I don't know how the tokenizer is supposed to pass errors to the parser.
> > For the quoting error I've made it throw an exception.
> 
> Try this one and let me know if everything works as it should.
> Thanks.
> 
> -Gonzalo
> 



From monoman at gmail.com  Thu Jun 15 10:53:42 2006
From: monoman at gmail.com (Rafael Teixeira)
Date: Thu, 15 Jun 2006 11:53:42 -0300
Subject: [Mono-dev] Can Mono run on IBM-AIX OS?
In-Reply-To: <006401c69044$39a2bc20$0a00a8c0@aungnewlaptop>
References: <006401c69044$39a2bc20$0a00a8c0@aungnewlaptop>
Message-ID: <dd99b8c80606150753j46e66cb8t8c658c19de79e70e@mail.gmail.com>

AFAIK,

1) AIX isn't supported/mantained
2) XSP performance is good but not outstanding and we have some way to
go in the GC to allow for non-stop operation.
3) Why? But nevertheless you can register other extensions to be dealt
by the same webhandler that processes .aspx or the one that deals with
.asmx and so on...

Hope it helps,

On 6/15/06, Aung <aung.sfilter at gmail.com> wrote:
>
>
>
>
> Hi guys,
>
>
>
> Perhaps, these are newbie questions.
>
> Can Mono run on IBM-AIX OS?
>
> Is it commercially feasible (performance wise) to run XSP as the server?
>
> Is it possible to change file extension from .aspx or asmx to something
> else?
>
>
>
> Thanks.
>
>
>
> Aung
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>


-- 
Rafael "Monoman" Teixeira
---------------------------------------
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man." George Bernard Shaw


From monoman at gmail.com  Thu Jun 15 11:00:51 2006
From: monoman at gmail.com (Rafael Teixeira)
Date: Thu, 15 Jun 2006 12:00:51 -0300
Subject: [Mono-dev] State of support for VB.NET
In-Reply-To: <44913AAD.6080600@majestic12.co.uk>
References: <2277.212.36.1.186.1132851944.squirrel@212.36.1.186>
	<44913AAD.6080600@majestic12.co.uk>
Message-ID: <dd99b8c80606150800s28e939e6t101dfaf9006a7f34@mail.gmail.com>

Hi Alex,

For precompiled usage (VB.NET 1.x (7.x?)) I think our MSVB.dll is good
enough, but currently mbas isn't able to compile any page (Sorry can
get yet to work on the fix).

The newest compiler in the family, vbnc will be able to compile VB.NET
2.0 (8.0?) but it is still in the beginning.

So if you have full codebehind precompiled ASP.NET 1.x pages with
VB.NET you can give Mono a spin, and tell us if you find any bug.

Thank you for your questions and we await your feedback,

:)

On 6/15/06, Alex Chudnovsky <alexc at majestic12.co.uk> wrote:
> Hi all,
>
> Has anyone ported VB.NET apps to Mono recently, particularly I am
> wondering if VB.NET is supported in ASP pages?
>
> I've done reasonable amount of C# porting and found Mono is very good
> and I did not even have to recompile, but from what I heard VB.NET
> generates less Mono-compatible code, is that still the case? Say I can
> use C# app compiled in VS 2003 without recompilation in Mono, can same
> be done for VB.NET or it will require recompilation?
>
> I am aware of http://www.mono-project.com/VisualBasic.NET_support page,
> but it has rather short descriptions, I'd really like to see page
> summarising what's not yet supported.
>
> Alex
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>


-- 
Rafael "Monoman" Teixeira
---------------------------------------
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man." George Bernard Shaw


From alexc at majestic12.co.uk  Thu Jun 15 11:34:00 2006
From: alexc at majestic12.co.uk (Alex Chudnovsky)
Date: Thu, 15 Jun 2006 16:34:00 +0100
Subject: [Mono-dev] State of support for VB.NET
In-Reply-To: <dd99b8c80606150800s28e939e6t101dfaf9006a7f34@mail.gmail.com>
References: <2277.212.36.1.186.1132851944.squirrel@212.36.1.186>	
	<44913AAD.6080600@majestic12.co.uk>
	<dd99b8c80606150800s28e939e6t101dfaf9006a7f34@mail.gmail.com>
Message-ID: <44917DE8.5040503@majestic12.co.uk>


Hi Rafael,

Thanks for this update! I've actually received updated information that 
(thankfully!) the job will need to be done in C#, which I know Mono 
supports very well ;-)

cheers,

Alex

Rafael Teixeira wrote:

> Hi Alex,
>
> For precompiled usage (VB.NET 1.x (7.x?)) I think our MSVB.dll is good
> enough, but currently mbas isn't able to compile any page (Sorry can
> get yet to work on the fix).
>
> The newest compiler in the family, vbnc will be able to compile VB.NET
> 2.0 (8.0?) but it is still in the beginning.
>
> So if you have full codebehind precompiled ASP.NET 1.x pages with
> VB.NET you can give Mono a spin, and tell us if you find any bug.
>
> Thank you for your questions and we await your feedback,
>
> :)
>
> On 6/15/06, Alex Chudnovsky <alexc at majestic12.co.uk> wrote:
>
>> Hi all,
>>
>> Has anyone ported VB.NET apps to Mono recently, particularly I am
>> wondering if VB.NET is supported in ASP pages?
>>
>> I've done reasonable amount of C# porting and found Mono is very good
>> and I did not even have to recompile, but from what I heard VB.NET
>> generates less Mono-compatible code, is that still the case? Say I can
>> use C# app compiled in VS 2003 without recompilation in Mono, can same
>> be done for VB.NET or it will require recompilation?
>>
>> I am aware of http://www.mono-project.com/VisualBasic.NET_support page,
>> but it has rather short descriptions, I'd really like to see page
>> summarising what's not yet supported.
>>
>> Alex
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>



From andrews at mainsoft.com  Thu Jun 15 12:34:27 2006
From: andrews at mainsoft.com (Andrew Skiba)
Date: Thu, 15 Jun 2006 09:34:27 -0700
Subject: [Mono-dev] [PATCH] System.Web.Compilation.TemplateControlCompiler
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D03137125@dhost002-45.dex002.intermedia.net>

Hi Gonzalo,

please review the fixed test and fix.

also please review FormView and UrlProperty patches I sent earlier.

Thank you.
Andrew.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TemplateControlCompilerTest.patch
Type: application/octet-stream
Size: 4424 bytes
Desc: TemplateControlCompilerTest.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060615/1e3d36d7/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TemplateControlCompiler.patch
Type: application/octet-stream
Size: 1901 bytes
Desc: TemplateControlCompiler.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060615/1e3d36d7/attachment-0001.obj 

From robertj at gmx.net  Thu Jun 15 13:18:00 2006
From: robertj at gmx.net (Robert Jordan)
Date: Thu, 15 Jun 2006 19:18:00 +0200
Subject: [Mono-dev] Re: databinder works?
In-Reply-To: <1150227782.14365.2.camel@lalo>
References: <448EE328.7070009@mcsoft.com.br> <1150227782.14365.2.camel@lalo>
Message-ID: <e6s4o9$t88$1@sea.gmane.org>

Gonzalo,

> On Tue, 2006-06-13 at 13:09 -0300, Marco Aur?lio Castro wrote:
>> Hello,
>>    
>>     I'm developing a site in Delphi 2006 to run in Mono and I tried to 
>> connect a Dataset with an edit box by DataBinder. The connection is
>>         text='<%# DataBinder.Eval(DataSet, 
>> "Tables[Clients].DefaultView.[0].Client") %>'
>>
>>     It works in Windows, what is wrong here?
>>
>>     The site returned the screen:
>>  
>>
>> System.NotImplementedException: The requested feature is not implemented.
>> in <0x00021> System.Data.DataSet:get_Site ()
> 
> DataBinder works. If you look at the stacktrace, seems like DataSet.Site
> is not implemented.

This has been fixed a couple of months ago.

Robert



From gonzalo at novell.com  Thu Jun 15 14:42:36 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Thu, 15 Jun 2006 14:42:36 -0400
Subject: [Mono-dev] [PATCH] System.Web.Compilation.TemplateControlCompiler
In-Reply-To: <DA63C6E8B207E748B20D46DFED7B772D03137125@dhost002-45.dex002.intermedia.net>
References: <DA63C6E8B207E748B20D46DFED7B772D03137125@dhost002-45.dex002.intermedia.net>
Message-ID: <1150396956.7507.12.camel@lalo.micasa>

On Thu, 2006-06-15 at 09:34 -0700, Andrew Skiba wrote:
> Hi Gonzalo,
> 
> please review the fixed test and fix.
> 
> also please review FormView and UrlProperty patches I sent earlier.

This is ok to commit.
Thanks.

-Gonzalo




From gonzalo at novell.com  Thu Jun 15 14:47:00 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Thu, 15 Jun 2006 14:47:00 -0400
Subject: [Mono-dev] [PATCH] UrlPropertyAttribute support for
	PageThemeCompiler
In-Reply-To: <DA63C6E8B207E748B20D46DFED7B772D03136BEC@dhost002-45.dex002.intermedia.net>
References: <DA63C6E8B207E748B20D46DFED7B772D03136BEC@dhost002-45.dex002.intermedia.net>
Message-ID: <1150397220.7507.15.camel@lalo.micasa>

On Mon, 2006-06-12 at 05:48 -0700, Andrew Skiba wrote:
> Hello,
> 
> The attached test reveils the missing functionality in PageThemeCompiler
> and the attached patch provides it. In addition to the test here is some
> documentation on the issue (see Theme Graphics and Other Resources) :
> http://msdn2.microsoft.com/en-us/library/ykzx33wh.aspx
> 
> if no one objects, I will commit.

UrlPropertyAttribute is 2.0 only so in TemplateControlCompiler it needs
to be inside #if NET_2_0. After fixing that, feel free to commit.

Thanks.

-Gonzalo




From gonzalo at novell.com  Thu Jun 15 14:47:41 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Thu, 15 Jun 2006 14:47:41 -0400
Subject: [Mono-dev] [PATCH] System.Web.UI.WebControls.FormView test and
	patch
In-Reply-To: <DA63C6E8B207E748B20D46DFED7B772D03136DBF@dhost002-45.dex002.intermedia.net>
References: <DA63C6E8B207E748B20D46DFED7B772D03136DBF@dhost002-45.dex002.intermedia.net>
Message-ID: <1150397261.7507.17.camel@lalo.micasa>

On Tue, 2006-06-13 at 08:36 -0700, Andrew Skiba wrote:
> The previous patch rendered empty cssclass attribute by mistake. This
> test and fix handle this case.
> 
> If no one objects, I will commit.

Please, commit.
Thanks.

-Gonzalo




From g.moskov at gmail.com  Fri Jun 16 03:19:20 2006
From: g.moskov at gmail.com (Georgi Moskov)
Date: Fri, 16 Jun 2006 10:19:20 +0300
Subject: [Mono-dev] User control bug or feature?
Message-ID: <6e837a390606160019l324e67fbv819f4363d83db6c1@mail.gmail.com>

Hi all,

   I am trying to use user controls in the following way - an .aspx
page loads dynamically a user control in Page_Load. After that it puts
the whole object in a static user control object and on every
following postback caused by the click on a submit button in the user
control it takes it from the static user control object and loads it
back on the page. I have a Response.Write in Page_Load of the user
control to check when I pass through there. Now the problem is that
when I run this on a Windows platform I see the Response.Write only
the first time as expected, because the user control object is already
initialised after that. On mono however, not only I see the
Response.Write every time, but the count of messages increases - with
one more on every next postback.

   Can anyone please tell me what I am doing wrong (aside from the
strange use of user controls) and whether this behaviour is intended
or not?

   Attached is a test case, I am using mono 1.1.15 with the standard
rpms for RHEL 4.

Regards,
Georgi Moskov


From janne.rantala at gmail.com  Fri Jun 16 03:53:29 2006
From: janne.rantala at gmail.com (Janne Rantala)
Date: Fri, 16 Jun 2006 10:53:29 +0300
Subject: [Mono-dev] SVN down?
Message-ID: <340e8e120606160053s5d2b130ct62aeab719a55ec5f@mail.gmail.com>

Hi,

Is Mono SVN currently down? I cannot access it from
http://svn.myrealbox.com/ or with Tortoise client. Tortoise just gives error
message "unknown hostname svn.myrealbox.com".

Cheers,

Janne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060616/a92767e9/attachment.html 

From g.moskov at gmail.com  Fri Jun 16 03:57:31 2006
From: g.moskov at gmail.com (Georgi Moskov)
Date: Fri, 16 Jun 2006 10:57:31 +0300
Subject: [Mono-dev] Re: User control bug or feature?
In-Reply-To: <6e837a390606160019l324e67fbv819f4363d83db6c1@mail.gmail.com>
References: <6e837a390606160019l324e67fbv819f4363d83db6c1@mail.gmail.com>
Message-ID: <6e837a390606160057wb11ef89j27ced9bf4addd8cf@mail.gmail.com>

Sorry, I forgot to attach the archive.

On 6/16/06, Georgi Moskov <g.moskov at gmail.com> wrote:
> Hi all,
>
>    I am trying to use user controls in the following way - an .aspx
> page loads dynamically a user control in Page_Load. After that it puts
> the whole object in a static user control object and on every
> following postback caused by the click on a submit button in the user
> control it takes it from the static user control object and loads it
> back on the page. I have a Response.Write in Page_Load of the user
> control to check when I pass through there. Now the problem is that
> when I run this on a Windows platform I see the Response.Write only
> the first time as expected, because the user control object is already
> initialised after that. On mono however, not only I see the
> Response.Write every time, but the count of messages increases - with
> one more on every next postback.
>
>    Can anyone please tell me what I am doing wrong (aside from the
> strange use of user controls) and whether this behaviour is intended
> or not?
>
>    Attached is a test case, I am using mono 1.1.15 with the standard
> rpms for RHEL 4.
>
> Regards,
> Georgi Moskov
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestUC.tar.gz
Type: application/x-gzip
Size: 14009 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060616/bb2b57d1/attachment.gz 

From informatique.internet at fiducial.fr  Fri Jun 16 03:57:20 2006
From: informatique.internet at fiducial.fr (Hubert FONGARNAND)
Date: Fri, 16 Jun 2006 09:57:20 +0200
Subject: [Mono-dev] Dns problem with svn.myrealbox.com
Message-ID: <1150444640.2816.12.camel@hublinux.fidudev.fr>

http://www.dnsstuff.com/tools/lookup.ch?name=svn.myrealbox.com&type=A
_______________________________________________
Ce message et les ?ventuels documents joints peuvent contenir des informations confidentielles.
Au cas o? il ne vous serait pas destin?, nous vous remercions de bien vouloir le supprimer et en aviser imm?diatement l'exp?diteur. Toute utilisation de ce message non conforme ? sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.
Les communications sur internet n'?tant pas s?curis?es, l'int?grit? de ce message n'est pas assur?e et la soci?t? ?mettrice ne peut ?tre tenue pour responsable de son contenu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060616/cd48ecfe/attachment.html 

From lists at ophion.org  Fri Jun 16 04:04:01 2006
From: lists at ophion.org (Rafael Ferreira)
Date: Fri, 16 Jun 2006 01:04:01 -0700
Subject: [Mono-dev] Single thread scheduler for Threading.Timers  patch
In-Reply-To: <3785-35152@sneakemail.com>
References: <11728-64231@sneakemail.com>
	<1150265055.26740.14.camel@stan.ophion.org>
	<11728-64231@sneakemail.com> <3785-35152@sneakemail.com>
Message-ID: <1150445042.2706.22.camel@stan.ophion.org>

sorry for the late response to this email but work has kept me quite
busy lately. 

- raf 

On Wed, 2006-06-14 at 15:19 -0500, Jonathan Gilbert wrote:
> At 09:37 AM 14/06/2006 -0700, Rafael Ferreira wrote:
> >Hey there, let me start by saying thanks for the feedback.. my commments
> >below:
> 
> No problem :-) By the way, it may have appeared to be off of the list (I
> mention this because I didn't see your reply on the list), but actually my
> post was to mono-devel-list and CCed to you. I've done the same with this
> reply; I hope that's okay with you :-)
> 
> >> At 11:04 PM 13/06/2006 -0700, Rafael Ferreira wrote:
> >>>Howdy,
> >>>
> >>>The attached patch changes the current Threading.Timer class to use a
> >>>single thread scheduler instead of the current 1 thread per timer logic.
> >>>I also spent a lot of time working on the Timer unit tests so they more
> >>>consistently pass as well as fixing the "NotWorking" tests.
> >>>
> >>>Some key features include:
> >>>
> >>>* A single thread handles firing all timer jobs thus allowing a much
> >>>greater number of Timers to be defined - Fixing bug #65734
> >>>* Timer scheduler is only started after the first System.Threading.Timer
> >>>is created (lazy init)
> >>>* Timer scheduler thread dies if there are no more timer jobs in its Job
> >>>queue (early termination)
> >>>* Scheduler can spit out debug info by exporting the MONO_TIMER_DEBUG
> >>>environment variable
> >>
> >> One thing that gets me about the design is the way that timer events are
> >> marshalled to a different thread (in the thread pool) in order to be
> >> fired.
> >> Obviously, you don't want synchronous callbacks from a single thread for
> >> all timers, but perhaps a timer thread pool, each of which handling a
> >> subset of the timers, would be a viable alternate design. With a limit of,
> >> say, 100 scheduler threads, up to 100 timers could be created without any
> >> chance of interference, and after that point, the threads would be reused
> >> instead of overloading the system with thousands of threads. The threads
> >> could even switch from synchronous callbacks when they are handling only a
> >> single timer to asynchronous thread pool callbacks when their
> >> responsibilities increase.
> >
> >I'm not sure what do you mean by "marshalled to a different thread",
> >there's no serialization taking place here and this implementation is not
> >any different than what is currently being done by the timer class. The
> >only difference is that I chose to call ThreadPool.QueueUserWorkItem
> >explicitly instead of using .BeingInvoke(). Also, having n scheduler
> >therads would not help you much, actually I the whole point of the
> >single-thread scheduler is to minimize idle threads.
> 
> The call to ThreadPool.QueueUserWorkItem *is* the marshalling I was
> referring to. It isn't data that's being marshalled, but rather the
> function call itself. The only concern I had was with the responsiveness of
> thread pool threads being awakened when they have possibly been asleep for
> a long time; if pages have to be brought into memory when the thread pool
> threads unblock, then the timer will have possibly several additional
> seconds of delay added to the callback. Obviously, making the callback from
> the thread that is driving the timer wouldn't have this problem, but it
> would have the different problem that if the callback takes too long the
> timer's activity (and that of any other timers on the same thread) will be
> negatively affected.
> 
> I'm not actually sure how Microsoft's implementation works. I could write a
> couple of tests and run them. Specifically, what I'm interested to know is,
> if you have only one timer running, and that timer's callback takes longer
> than the interval, will the next timer tick cause another, re-entrant call
> into the callback on another thread, or does that next tick get delayed
> until the callback returns? The MSDN documentation makes it clear that
> thread pool threads are involved, but it doesn't indicate whether the
> thread pool threads themselves drive the timer, or whether the timer(s) are
> driven by a separate thread and only the callbacks are done through the
> thread pool.

According to my tests and the documentation I found here

http://msdn.microsoft.com/msdnmag/issues/04/02/TimersinNET/default.aspx

which describes the re-entrance problem you described above, I believe
that the behavior of my implementation is consistent... but I'm not
claiming to be an expert on Timers. 
It might help you to look over the current Timer implementation so you
can get a sense for how we're currently utilizing the threadpool to
handle timers.

> 
> >> If we accept the single-thread thread-pool-callback design, though, I have
> >> the following comments on the implementation:
> >>
> >> 1. A heap structure is very easy to maintain, and would be a significantly
> >> more efficient way to find the next event to be fired. You have comments
> >> that acknowledge the deficiency of looping over the entire set every time,
> >> and I think this would be the logical next step in this.
> >
> >I agree that a sorted data structure would speed things up the problem
> >there is that SortedList will just not cut it and writing a new data
> >structure (or a wrapper class) just didn't sense just to speed up a very
> >edge case (how many users are going create 10k timers?)
> 
> Sure, but heaps are especially easy to write :-) They fit into an array,
> and they require only three helper methods to update the structure: swap,
> heapify-up and heapify-down.
> 
> When a new timer is added, you simply drop it onto the end of the array,
> and then heapify-up. When a timer tick occurs, you move the item at the end
> of the array overtop of the one at the front of the array, and then
> heapify-down. Following these rules, the first entry in the array will
> always be the next event to fire.
> 
> The heapifying functions are relatively simple to implement and take only a
> dozen lines each.

> >> 2. Using Thread.Abort to signal the thread is fundamentally flawed. A user
> >> very quickly adding & removing timers would eventually cause a
> >> ThreadAbortException to fire inside the 'catch' handler, killing off the
> >> scheduler thread and disabling all timers. A better approach would be to
> >> use Monitor.Wait on a synchronization object in the scheduler thread with
> >> the correct time-out, and then Monitor.Pulse to awaken the thread for an
> >> update. The scheduler can use DateTime.Now comparisons to determine, when
> >> Monitor.Wait returns, how long it actually waited and whether it should
> >> actually fire the event at top of the heap, and the return value of
> >> Monitor.Wait will indicate whether it was interrupted and thus should
> >> check
> >> the queue of timer additions/deletions before proceeding.
> >
> >I agree that doing a Abort() on the thread is not the most elegant way to
> >singal a thread but I do cover the edge cases in send_scheduler_signal so
> >a thread is only signaled if it is in the right "state". I also "queue" up
> >abort()'s so under heavy "timer" creation only 1 abort call is made. I'm
> >not quite sure how your Monitor logic would work but I would be more than
> >glad to entertain your solution.
> 
> I haven't had the opportunity to apply the patch; I have been reading it
> directly from the timer.patch file, in which form it is rather difficult to
> make heads or tails of :-) So, I'm not able to evaluate the
> send_scheduler_signal code to see if there might be any holes in it.
> 
> The monitor approach looks roughly like this:
> 
> void send_signal(object signal_object)
> {
>   lock (sync)
>   {
>     signal_queue.Enqueue(signal_object);
>     Monitor.Pulse(sync);
>   }
> }
> 
> Queue signal_queue = new Queue();
> object sync = new object();
> 
> struct TickInfo
> {
>   public DateTime TimeOfNextTick, Interval;
>   public WaitCallback CallbackMethod;
>   public object CallbackData;
> }
> 
> void thread_proc()
> {
>   TickInfo[] heap = new TickInfo[initial size];
>   int num_heap_entries = 0;
> 
>   lock (sync)
>     while (true)
>     {
>       TimeSpan delay = TimeSpan.FromMilliseconds(Timeout.Infinite);
> 
>       if (num_heap_entries > 0)
>       {
>         DateTime now = DateTime.Now;
> 
>         if (heap[0].TimeOfNextTick < now)
>         {  
>           fire_first_event_from_heap(heap, num_heap_entries);
>           continue;
>         }
> 
>         delay = heap[0].TimeOfNextTick - now;
>       }
> 
>       Monitor.Wait(sync, delay);
> 
>       while (signal_queue.Count > 0)
>         update_heap(ref heap,
> (SchedulerUpdateSignalObject)signal_queue.Dequeue());
>     }
> }
> 
> void fire_first_event_from_heap(TickInfo[] heap, int num_heap_entries)
> {
>   ThreadPool.QueueUserWorkItem(heap[0].CallbackMethod, heap[0].CallbackData);
> 
>   TickInfo next_tick = heap[0];
> 
>   next_tick.TimeOfNextTick = DateTime.Now + next_tick.Interval;
> 
>   // remove the old tick
>   heap[0] = heap[num_heap_entries - 1];
>   heapify_down(heap, num_heap_entries - 1);
> 
>   // insert the new one
>   heap[num_heap_entries - 1] = next_tick;
>   heapify_up(heap, num_heap_entries);
> }

I do like the Monitor Wait/Pulse logic so I'll play with it for a bit
and see how I could use it in the scheduler.

> 
> >> If you'd like, I can try writing an alternate implementation along these
> >> lines, but it will have to wait until after work for me today.
> >
> >Like I said, go right ahead. There's always more than 1 way to implement
> >things
> 
> I guess the above counts as a rough pseudocode implementation of what I had
> in mind :-) What are your thoughts?
> 
> Jonathan Gilbert
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 



From mono-devel at fluggo.com  Fri Jun 16 04:50:04 2006
From: mono-devel at fluggo.com (Brian Crowell)
Date: Fri, 16 Jun 2006 03:50:04 -0500
Subject: [Mono-dev] NullReferenceException on a callvirt... with a non-null
 reference? (please help!)
Message-ID: <449270BC.8000900@fluggo.com>


Okay, while dealing with the whole AppDomains-should-be-empty-bug, I came across 
a strange phenomenon. After making sure that new AppDomains carry only the 
corlib, cross-domain calls to that AppDomain fail with a NullReferenceException.

After careful examination, I've determined that this exception occurs inside the 
xdomain-wrapper method created in metadata/marshal.c. Specifically, it occurs 
during the callvirt instruction that *would* carry out the last step of the 
cross-domain call-- calling the method on the object in the next domain.

Yet, by injecting Console.WriteLine calls into this code, I can show that the 
reference to the target object is, in fact, not null. So, I guess what I need to 
know is-- under what other conditions could a NullReferenceException occur on a 
callvirt (in x86)?

I have a feeling this may have to do with the fact that the called method and 
the calling method come from two instances of the same assembly. Example: I have 
one AppDomain which pulls its assemblies from /foo, and the second which pulls 
it assemblies from /bar. Under the original implementation, these AppDomains 
would carry the same assemblies; that is, the ones that come from the original 
AppDomain. Under the new implementation, the assemblies are separately loaded 
from /foo and /bar, like they should be. So maybe the call-wrapping doesn't take 
this into account?

I'm still working through this, but any help on this particular point would be 
appreciated.

--Brian


From jglenin at o2.pl  Wed Jun 14 16:44:45 2006
From: jglenin at o2.pl (John Lenin)
Date: Wed, 14 Jun 2006 22:44:45 +0200
Subject: [Mono-dev] Fedora Core 5 rpms now available for Monodevelop
Message-ID: <4490753D.7060005@o2.pl>

Thanks a lot, it seems to work now.
Just one note - after installing your rpms, upon first run I got:

$ monodevelop
** (./MonoDevelop.exe:2317): WARNING **: The following assembly 
referenced from /usr/lib/monodevelop/bin/MonoDevelop.Componen ts.dll 
could not be loaded:
     Assembly:   gecko-sharp    (assemblyref_index=10)
     Version:    2.0.0.0
     Public Key: ccf7d78a55e9f021
The assembly was not found in the Global Assembly Cache, a path listed 
in the MONO_PATH environment variable, or in the location of the 
executing assembly (/usr/lib/monodevelop/bin).


** (./MonoDevelop.exe:2317): WARNING **: The class Gecko.WebControl 
could not be loaded, used in gecko-sharp, Version=2.0.0.0, 
Culture=neutral, PublicKeyToken=ccf7d78a55e9f021

** ERROR **: file class.c: line 2505 (mono_class_setup_parent): should 
not be reachedaborting...

Solution is quite easy. Just to install gecko-sharp2. As root:

$ yum install gecko-sharp2

Hope it will help you improving, or someone else running.
Once again,  thank you.
    Tadeusz ?azurski




From vargaz at gmail.com  Fri Jun 16 05:04:03 2006
From: vargaz at gmail.com (Zoltan Varga)
Date: Fri, 16 Jun 2006 11:04:03 +0200
Subject: [Mono-dev] NullReferenceException on a callvirt... with a
	non-null reference? (please help!)
In-Reply-To: <449270BC.8000900@fluggo.com>
References: <449270BC.8000900@fluggo.com>
Message-ID: <295e750a0606160204j75919ff0vc9382c3f9a7890fc@mail.gmail.com>

                                                 Hi,

  The fact that new appdomains have all assemblies loaded is clearly a bug, but
it can't be fixed easily because certain parts of the runtime, most notably the
remoting infrastructure seem to depend on this broken behaviour. Most likely
because the same assembly will be loaded separately into the two appdomains,
confusing the remoting code which expects them to be the same (ie. the same
MonoAssembly structure).

                                                       Zoltan

On 6/16/06, Brian Crowell <mono-devel at fluggo.com> wrote:
>
> Okay, while dealing with the whole AppDomains-should-be-empty-bug, I came across
> a strange phenomenon. After making sure that new AppDomains carry only the
> corlib, cross-domain calls to that AppDomain fail with a NullReferenceException.
>
> After careful examination, I've determined that this exception occurs inside the
> xdomain-wrapper method created in metadata/marshal.c. Specifically, it occurs
> during the callvirt instruction that *would* carry out the last step of the
> cross-domain call-- calling the method on the object in the next domain.
>
> Yet, by injecting Console.WriteLine calls into this code, I can show that the
> reference to the target object is, in fact, not null. So, I guess what I need to
> know is-- under what other conditions could a NullReferenceException occur on a
> callvirt (in x86)?
>
> I have a feeling this may have to do with the fact that the called method and
> the calling method come from two instances of the same assembly. Example: I have
> one AppDomain which pulls its assemblies from /foo, and the second which pulls
> it assemblies from /bar. Under the original implementation, these AppDomains
> would carry the same assemblies; that is, the ones that come from the original
> AppDomain. Under the new implementation, the assemblies are separately loaded
> from /foo and /bar, like they should be. So maybe the call-wrapping doesn't take
> this into account?
>
> I'm still working through this, but any help on this particular point would be
> appreciated.
>
> --Brian
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>


From mono-devel at fluggo.com  Fri Jun 16 05:29:28 2006
From: mono-devel at fluggo.com (Brian Crowell)
Date: Fri, 16 Jun 2006 04:29:28 -0500
Subject: [Mono-dev] NullReferenceException on a callvirt... with a non-null
	reference? (please help!)
In-Reply-To: <295e750a0606160204j75919ff0vc9382c3f9a7890fc@mail.gmail.com>
References: <449270BC.8000900@fluggo.com>
	<295e750a0606160204j75919ff0vc9382c3f9a7890fc@mail.gmail.com>
Message-ID: <449279F8.6070805@fluggo.com>

Zoltan Varga wrote:
>  The fact that new appdomains have all assemblies loaded is clearly a 
> bug, but
> it can't be fixed easily because certain parts of the runtime, most 
> notably the
> remoting infrastructure seem to depend on this broken behaviour.

Yeah, I'm noticing that, too. But, at least in my case, it has to be fixed. :P

Although, I can't really think of anything outside of this particular case that 
might also need to be fixed. Only in-process cross-domain calls would try to 
take advantage of having the same assembly in both AppDomains. If it's in the 
same domain, it *is* the same assembly, and if it's not in the same process, 
then you can't take the shortcut anyways. What other areas can you think of that 
might also need to be fixed?

I find it odd that the author took pains to call the correct method, but failed 
to see that late-loading the method's pointer (the apparent function of 
CEE_MONO_LDPTR) does no good if you assume you're working with the same 
assembly-- you'll just get the same pointer again.

In fact, it may be as simple as introducing a late-binding mechanism into the 
emitted methods.

Thoughts? Suggestions?

--Brian


From robertj at gmx.net  Fri Jun 16 06:30:08 2006
From: robertj at gmx.net (Robert Jordan)
Date: Fri, 16 Jun 2006 11:30:08 +0100
Subject: [Mono-dev] Re: System.Timers.Timer bug
In-Reply-To: <92FFBD2F0464224B88AE6649016CA79749A9A1@exalfa.stromtelecom.cz>
References: <92FFBD2F0464224B88AE6649016CA79749A9A1@exalfa.stromtelecom.cz>
Message-ID: <e6u17g$a4c$1@sea.gmane.org>

Jakubec Vojtech wrote:
> Hi,
> 
> I found a multi-threading problem in implementation of System.Timers.Timer class. In our application we are using Timer.Enabled property inside of ElapsedEventHandler method to prevent timer from raising the Elapsed event again while previous handler is still running. In some cases Timer can be disabled and enabled again very fast. 
> 
>  
> 
> The problem under Mono is with member ManualResetEvent wait. In some cases new thread created by enabling Timer starts and creates instance of wait object before the old thread ends. Then the old thread dispose wait object and new thread throws unhandled NullRefrenceException.
> 
>  
> 
> I'm attaching modified System.Timers.Timer class from Mono-1.1.15 sources with possible solution.

It's similar to this bug & patch:

http://bugzilla.ximian.com/show_bug.cgi?id=77847

Robert



From gonzalo at novell.com  Fri Jun 16 10:09:49 2006
From: gonzalo at novell.com (Gonzalo Paniagua Javier)
Date: Fri, 16 Jun 2006 10:09:49 -0400
Subject: [Mono-dev] SVN down?
In-Reply-To: <340e8e120606160053s5d2b130ct62aeab719a55ec5f@mail.gmail.com>
References: <340e8e120606160053s5d2b130ct62aeab719a55ec5f@mail.gmail.com>
Message-ID: <1150466989.5899.6.camel@lalo.micasa>

On Fri, 2006-06-16 at 10:53 +0300, Janne Rantala wrote:
> Hi,
> 
> Is Mono SVN currently down? I cannot access it from
> http://svn.myrealbox.com/ or with Tortoise client. Tortoise just gives
> error message "unknown hostname svn.myrealbox.com".

There seems to be a network problem.

-Gonzalo




From mono at ims-integer.com  Fri Jun 16 10:16:25 2006
From: mono at ims-integer.com (David Powell)
Date: Fri, 16 Jun 2006 15:16:25 +0100
Subject: [Mono-dev] System.Console echo issue
Message-ID: <4492BD39.6090509@ims-integer.com>

Hi,
	I'm writing a cross-platform console based application and I've come 
across an issue with Mono (V. 1.1.15)

There seems to be a discrepancy with the default status of keyboard echo 
when running Mono on Windows vs. Unix.

On Windows the terminal defaults to 'No Echo' whereas on Linux it 
defaults to 'Echo'. As the Microsoft VM (on Windows) also defaults to 
'No Echo' I'm guessing that this is the correct behavior.

I took a look at the source to see if it was a quick fix, but started 
getting bogged down with 'ioctl' calls in 'console-io.c', so thought I'd 
better ask here first;

Is it a bug, or is it working 'as intended'?

(I have a very small program I can post that shows the issue, if required.)

Thanks.

--
David Powell.



From allan at counterpop.net  Fri Jun 16 20:53:43 2006
From: allan at counterpop.net (Allan Hsu)
Date: Fri, 16 Jun 2006 17:53:43 -0700
Subject: [Mono-dev] patch to fix mach port leaks on OS X/Darwin
Message-ID: <20E54646-83A0-46E4-B702-A1872D519FEF@counterpop.net>

The following patch fixes a threading-related mach port leak in  
Mono's internal libgc (bug #78628) under OS X:
http://bugs.ximian.com/show_bug.cgi?id=78628

This includes a backport (sideport?) of my libgc 6.7 patch for  
darwin_stop_world.c, as well as a Mono-specific patch to  
pthread_support.c. This bug should have affected anybody that uses  
threads under OS X.

Can somebody either look this over and check it in to svn or give me  
the ok to commit?

	-Allan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libgc-internal.patch
Type: application/octet-stream
Size: 4028 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060616/6dcaced1/attachment.obj 
-------------- next part --------------

--
Allan Hsu <allan at counterpop dot net>
1E64 E20F 34D9 CBA7 1300  1457 AC37 CBBB 0E92 C779



From erroneousbollock at gmail.com  Sat Jun 17 05:21:32 2006
From: erroneousbollock at gmail.com (David Toso)
Date: Sat, 17 Jun 2006 19:21:32 +1000
Subject: [Mono-dev] Bug? Inconsistent visibility for delegate type.
Message-ID: <b88da58f0606170221j1dd76769jc855c61c09c6f08c@mail.gmail.com>

Hi folks,

I'm not sure if this has been mentioned before (I could not find it in
the bug database) or wether I'm trying to do something that is
completely wrong... nonetheless:

When compiling the simple program below, I get the following errors:
  bugTest.cs(20,25): error CS0051: Inconsistent accessibility:
parameter type `Foo.Bar.ProtectedBaz' is less accessible than method
Foo.Bar.<#AnonymousMethod>1 (Foo.Bar.ProtectedBaz)'
  bugTest.cs(21,25): error CS0051: Inconsistent accessibility:
parameter type `Foo.Bar.PrivateBaz' is less accessible than method
`Foo.Bar.<#AnonymousMethod>2(Foo.Bar.PrivateBaz)'

It would seem that the visibility assigned to the delegate instances
is 'public', which results in the "Inconsistent accessibility" errors.

That code does compile (and work) in VS2005.

Is this really a bug, or is there some way I can modify the inline
delegate definitions such that they would have the correct visibility
?

I have mono version 1.1.13.6. (Ubuntu package: mono-gmcs 1.1.13.6-0ubuntu3)

Thanks for you time.
-David Toso

------------------------------------------------------------------------------
using System;
using System.Collections.Generic;

namespace Foo
{
  public class Bar
  {
    public    class PublicBaz    { public string id; }
    protected class ProtectedBaz { public string id; }
    private   class PrivateBaz   { public string id; }

    private void Test()
    {
      string nice = "dave";
      List<PublicBaz>    pub = new List<PublicBaz>();
      List<ProtectedBaz> prt = new List<ProtectedBaz>();
      List<PrivateBaz>   prv = new List<PrivateBaz>();

      pub = pub.FindAll(delegate (PublicBaz b)    { return b.id == nice; });
      prt = prt.FindAll(delegate (ProtectedBaz b) { return b.id == nice; });
      prv = prv.FindAll(delegate (PrivateBaz b)   { return b.id == nice; });
    }

    public static void Main(string [] args)
    {
      (new Bar()).Test();
    }
  }
}
------------------------------------------------------------------------------


From tilps.kilm at gmail.com  Sat Jun 17 10:44:47 2006
From: tilps.kilm at gmail.com (Gareth Pearce)
Date: Sun, 18 Jun 2006 00:44:47 +1000
Subject: [Mono-dev] System.Configuration 2.0 ApplicationSettings
	infrastructure.
Message-ID: <4494155F.9040001@gmail.com>

Hi,

In the process of porting my little freeware puzzle game to mono, I've 
found that the .Net 2.0 ApplicationSettings infrastructure is currently 
quite incomplete. I've got one patch in bugzilla so that it at least 
doesn't crash under normal use, but even with that, 
LocalFileSettingsProvider is just a stub, it doesn't actually perform 
any persistence.

I was considering fixing it all up so it worked nicely.  But wanted to 
a) check no one was already working in the area and b) check some design 
questions.

The .Net documentation on the location of the user scoped settings file 
used by local file settings provider appears incorrect.  It states that 
user scoped settings files are found in User directory/Local 
Settings/Application Data/Company Name/Product Name/Version Number
but in reality the product name is replaced with the <executable 
name>_Url_<hash of file location url or something >.
I am wondering whether I should be aiming to match the hash so that the 
same program run under mono vs being run under .net will still find the 
same settings files.  It would seem like a difficult job without having 
access to the actual .net class library disassembly. The hash looks like 
base 32 encoding - 26 lower case letters and 6 digits - 32 characters 
gives 160bits, maybe SHA-1?  But still the question is of what.

And finally, if I get this all done soon would it be likely to go in 
before the 1.2 release?  I'm hoping that Linux and Mac OS-X users can 
start using my puzzle game once mono 1.2 goes out and it would be good 
if their settings actually saved.

--Gareth


From monoman at gmail.com  Sat Jun 17 18:46:35 2006
From: monoman at gmail.com (Rafael Teixeira)
Date: Sat, 17 Jun 2006 19:46:35 -0300
Subject: [Mono-dev] System.Configuration 2.0 ApplicationSettings
	infrastructure.
In-Reply-To: <4494155F.9040001@gmail.com>
References: <4494155F.9040001@gmail.com>
Message-ID: <dd99b8c80606171546p15fd3702h5d1119b313c46906@mail.gmail.com>

I don't think you even have to cook the filename in the same way as
MS, as AppSettings only need to be always retrievable from the same
place for the same exe and not collide with setting files from other
exes, hence the "exe name plus url" piece, but in linux we can for
something simpler, probably just

~/.config/<application-name>/<exename>.settings

Just my two cents,

On 6/17/06, Gareth Pearce <tilps.kilm at gmail.com> wrote:
> Hi,
>
> In the process of porting my little freeware puzzle game to mono, I've
> found that the .Net 2.0 ApplicationSettings infrastructure is currently
> quite incomplete. I've got one patch in bugzilla so that it at least
> doesn't crash under normal use, but even with that,
> LocalFileSettingsProvider is just a stub, it doesn't actually perform
> any persistence.
>
> I was considering fixing it all up so it worked nicely.  But wanted to
> a) check no one was already working in the area and b) check some design
> questions.
>
> The .Net documentation on the location of the user scoped settings file
> used by local file settings provider appears incorrect.  It states that
> user scoped settings files are found in User directory/Local
> Settings/Application Data/Company Name/Product Name/Version Number
> but in reality the product name is replaced with the <executable
> name>_Url_<hash of file location url or something >.
> I am wondering whether I should be aiming to match the hash so that the
> same program run under mono vs being run under .net will still find the
> same settings files.  It would seem like a difficult job without having
> access to the actual .net class library disassembly. The hash looks like
> base 32 encoding - 26 lower case letters and 6 digits - 32 characters
> gives 160bits, maybe SHA-1?  But still the question is of what.
>
> And finally, if I get this all done soon would it be likely to go in
> before the 1.2 release?  I'm hoping that Linux and Mac OS-X users can
> start using my puzzle game once mono 1.2 goes out and it would be good
> if their settings actually saved.
>
> --Gareth
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>


-- 
Rafael "Monoman" Teixeira
---------------------------------------
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man." George Bernard Shaw


From mono-devel at fluggo.com  Sat Jun 17 19:31:22 2006
From: mono-devel at fluggo.com (Brian Crowell)
Date: Sat, 17 Jun 2006 18:31:22 -0500
Subject: [Mono-dev] PATCH: Bug #76757,
	new AppDomains inherit current loaded assemblies
Message-ID: <449490CA.2010709@fluggo.com>


The attached patch (create-empty-appdomain.patch) fixes bug #76757. New domains 
are created with only the corlib loaded, and the cross-domain code now handles 
the type differences correctly.

An important thing to note about this patch is that it disables a lot of code in 
mono/metadata/marshal.c relating to the fast cross-domain wrappers. Much of that 
code made bad assumptions about the availability of types in other domains and 
the ability to make equality comparisons by pointers. The patch forces all 
cross-domain calls to go through the CrossAppDomainChannel, which has also been 
fixed in this regard.

The attached marshal.diff shows another strategy I thought about taking. This 
tries to get the cross-domain wrappers to correctly understand type equality 
across domains. I abandoned it because it was too much effort, but anyone 
interested can look at it and see what I was trying to do. That diff is based on 
version 1.1.13.8.

Please look at this and approve it for inclusion. I can't commit things, nor 
would I in this case without having someone look into #76811:

   http://bugzilla.ximian.com/show_bug.cgi?id=76811

--Brian
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: create-empty-appdomain.patch
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060617/7e93709c/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: marshal.diff
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060617/7e93709c/attachment-0001.pl 

From atsushi at ximian.com  Sat Jun 17 23:28:25 2006
From: atsushi at ximian.com (Atsushi Eno)
Date: Sun, 18 Jun 2006 12:28:25 +0900
Subject: [Mono-dev] System.Configuration 2.0
	ApplicationSettings	infrastructure.
In-Reply-To: <4494155F.9040001@gmail.com>
References: <4494155F.9040001@gmail.com>
Message-ID: <4494C859.8030103@ximian.com>

Hi,

Gareth Pearce wrote:
> Hi,
> 
> In the process of porting my little freeware puzzle game to mono, I've 
> found that the .Net 2.0 ApplicationSettings infrastructure is currently 
> quite incomplete. I've got one patch in bugzilla so that it at least 
> doesn't crash under normal use, but even with that, 
> LocalFileSettingsProvider is just a stub, it doesn't actually perform 
> any persistence.
> 
> I was considering fixing it all up so it worked nicely.  But wanted to 
> a) check no one was already working in the area and b) check some design 
> questions.

It would be awesome if you can contribute those missing bits :-)
Chris worked on System.Configuration stuff as part of ASP.NET 2.0
tasks, and later I implemented more a bit, but it's still incomplete.
And since we are mostly working on WinForms stuff now, no one is
likely working on it.

Usually people should have no problem unless they use new 2.0
configuration classes, since 2.0 machine.config inherits that
of 1.0.

> The .Net documentation on the location of the user scoped settings file 
> used by local file settings provider appears incorrect.  It states that 
> user scoped settings files are found in User directory/Local 
> Settings/Application Data/Company Name/Product Name/Version Number
> but in reality the product name is replaced with the <executable 
> name>_Url_<hash of file location url or something >.
> I am wondering whether I should be aiming to match the hash so that the 
> same program run under mono vs being run under .net will still find the 
> same settings files.  It would seem like a difficult job without having 
> access to the actual .net class library disassembly. The hash looks like 
> base 32 encoding - 26 lower case letters and 6 digits - 32 characters 
> gives 160bits, maybe SHA-1?  But still the question is of what.

We have some special signature identification on our own system
assemblies, so you can just use the same assembly qualified name as
that of .NET and don't have to be afraid that those assemblies
have different assembly qualified names.

> And finally, if I get this all done soon would it be likely to go in 
> before the 1.2 release?  I'm hoping that Linux and Mac OS-X users can 
> start using my puzzle game once mono 1.2 goes out and it would be good 
> if their settings actually saved.

Since 2.0 classes are provided as non-finished works in Mono 1.2,
your changes are possible to be included depending on when it is
checked in. Also, we might not want to change some significant bits
if it changes some core class behaviors (which is pulled
via machine.config) at this state. But anyways please post patches
if you already have.

Thanks,
Atsushi Eno


From tilps.kilm at gmail.com  Sun Jun 18 02:30:04 2006
From: tilps.kilm at gmail.com (Gareth Pearce)
Date: Sun, 18 Jun 2006 16:30:04 +1000
Subject: [Mono-dev] System.Configuration assembly details missing from
 masterinfos on website.
Message-ID: <4494F2EC.2020809@gmail.com>

I noticed that the System.Configuration assembly doesn't show up in the 
web page under 2.0 class status, and maybe its because its missing from 
the masterinfos for 2.0

Attached is a zip of the mono-api-list generated xml file for 
System.Configuration, in case that is useful in fixing the problem.

Regards,
Gareth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: System.Configuration.zip
Type: application/x-zip-compressed
Size: 16830 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060618/7e6d4062/attachment.bin 

From kostat at mainsoft.com  Sun Jun 18 11:16:21 2006
From: kostat at mainsoft.com (Konstantin Triger)
Date: Sun, 18 Jun 2006 08:16:21 -0700
Subject: [Mono-dev] [PATCH] System.Web,
	XmlSiteMapProvider.BuildSiteMapRecursive
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D031372EA@dhost002-45.dex002.intermedia.net>

Hello,

 

The attached patch solves the following issue in XmlSiteMapProvider.BuildSiteMapRecursive():

The site map node url should be relative to the application root and not to the current page.

 

Please review.

 

Regards,

Konstantin Triger

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060618/cbebb14c/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: XmlSiteMapProvider.cs.patch
Type: application/octet-stream
Size: 574 bytes
Desc: XmlSiteMapProvider.cs.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060618/cbebb14c/attachment.obj 

From bmaurer at ximian.com  Sun Jun 18 15:29:07 2006
From: bmaurer at ximian.com (Ben Maurer)
Date: Sun, 18 Jun 2006 12:29:07 -0700
Subject: [Mono-dev] PATCH: Bug #76757, new AppDomains inherit current
	loaded assemblies
In-Reply-To: <449490CA.2010709@fluggo.com>
References: <449490CA.2010709@fluggo.com>
Message-ID: <1150658947.17814.3.camel@localhost>

On Sat, 2006-06-17 at 18:31 -0500, Brian Crowell wrote:
> An important thing to note about this patch is that it disables a lot of code in 
> mono/metadata/marshal.c relating to the fast cross-domain wrappers. Much of that 
> code made bad assumptions about the availability of types in other domains and 
> the ability to make equality comparisons by pointers. The patch forces all 
> cross-domain calls to go through the CrossAppDomainChannel, which has also been 
> fixed in this regard. 

That code had a large impact on xsp performance. It may be worthwhile to
measure this before deciding if the quick fix of disabling that code
path is acceptable.

-- Ben



From mono-devel at fluggo.com  Sun Jun 18 16:00:49 2006
From: mono-devel at fluggo.com (Brian Crowell)
Date: Sun, 18 Jun 2006 15:00:49 -0500
Subject: [Mono-dev] PATCH: Bug #76757, new AppDomains inherit current
	loaded assemblies
In-Reply-To: <1150658947.17814.3.camel@localhost>
References: <449490CA.2010709@fluggo.com> <1150658947.17814.3.camel@localhost>
Message-ID: <4495B0F1.3010402@fluggo.com>

Ben Maurer wrote:
> That code had a large impact on xsp performance. It may be worthwhile to
> measure this before deciding if the quick fix of disabling that code
> path is acceptable.

Unfortunately, any fix will reduce the performance of cross-domain calls, 
because on every call you have to determine whether an acceptable target is 
available or whether a new assembly needs to be loaded. That involves a lot of 
table lookups and string comparisons.

I can think of two ways of reducing the impact of the fix:

* Design the code to perform the target lookup once per domain. For example, if 
one domain makes calls to several others, create one invoke-wrapper for the 
caller, one dispatch-wrapper per target domain, and cache the pointer to the 
dispatch wrapper in the calling domain (per, say, CrossAppDomainChannel).

* Reduce the number of cross-domain calls.

--Brian


From kostat at mainsoft.com  Mon Jun 19 04:17:27 2006
From: kostat at mainsoft.com (Konstantin Triger)
Date: Mon, 19 Jun 2006 01:17:27 -0700
Subject: [Mono-dev] [PATCH] System.Web.Compilation/AspTokenizer.cs
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D0313735C@dhost002-45.dex002.intermedia.net>

Hello,

 

Following the fix 61757: this code started throwing not well formed:

<img src="Handler.ashx?PhotoID=<%# Eval("PhotoID") %>&Size=M" />

 

This is because Eval(?) contains quotes. The attached patch fixes that by ignoring quotes inside server tag.

 

Please review.

 

Regards,

Konstantin Triger

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060619/08bd9137/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AspTokenizer.cs.patch
Type: application/octet-stream
Size: 442 bytes
Desc: AspTokenizer.cs.patch
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060619/08bd9137/attachment.obj 

From js at hotfeet.ch  Mon Jun 19 04:58:59 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Mon, 19 Jun 2006 10:58:59 +0200
Subject: [Mono-dev] [PATCH] System.Web.Compilation/AspTokenizer.cs
In-Reply-To: <DA63C6E8B207E748B20D46DFED7B772D0313735C@dhost002-45.dex002.intermedia.net>
References: <DA63C6E8B207E748B20D46DFED7B772D0313735C@dhost002-45.dex002.intermedia.net>
Message-ID: <1150707539.2516.19.camel@leonardo.hotfeet.ch>

Hi,

The patch you propose is not quite right:

...
               } else if (!inServerTag) {
...
...
               } else if (!inServerTag && quoted && c == quoteChar) {
                     return Token.NOTWELLFORMED;
               }

The case "!inServerTag" is already handled a few lines before, making
"return Token.NOTWELLFORMED" unreachable.

But there is a problem with fix 61757. The quoting rules (or rather the
rules of their nesting) change depending on whether we're inside a
server control or not.

We probably need to tokenize all attributes as if we're not inside a
server control, noting whether the stricter rules were violated or not.
After reading all attributes we check for the presence of runat="server"
and throw in the case of violation.

I'll have a look at it.

- Juraj



On Mon, 2006-06-19 at 01:17 -0700, Konstantin Triger wrote:
> Hello,
> 
>  
> 
> Following the fix 61757: this code started throwing not well formed:
> 
> <img src="Handler.ashx?PhotoID=<%# Eval("PhotoID") %>&Size=M" />
> 
>  
> 
> This is because Eval(?) contains quotes. The attached patch fixes that
> by ignoring quotes inside server tag.
> 
>  
> 
> Please review.
> 
>  
> 
> Regards,
> 
> Konstantin Triger
> 
>  
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From js at hotfeet.ch  Mon Jun 19 05:29:16 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Mon, 19 Jun 2006 11:29:16 +0200
Subject: [Mono-dev] [PATCH] System.Web.Compilation/AspTokenizer.cs
In-Reply-To: <DA63C6E8B207E748B20D46DFED7B772D0313735C@dhost002-45.dex002.intermedia.net>
References: <DA63C6E8B207E748B20D46DFED7B772D0313735C@dhost002-45.dex002.intermedia.net>
Message-ID: <1150709356.2516.21.camel@leonardo.hotfeet.ch>

Hi,

Could you please review and test the attached patch.

- Juraj


On Mon, 2006-06-19 at 01:17 -0700, Konstantin Triger wrote:
> Hello,
> 
>  
> 
> Following the fix 61757: this code started throwing not well formed:
> 
> <img src="Handler.ashx?PhotoID=<%# Eval("PhotoID") %>&Size=M" />
> 
>  
> 
> This is because Eval(?) contains quotes. The attached patch fixes that
> by ignoring quotes inside server tag.
> 
>  
> 
> Please review.
> 
>  
> 
> Regards,
> 
> Konstantin Triger
> 
>  
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Quotes.patch
Type: text/x-patch
Size: 2532 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060619/bed4f10a/attachment.bin 

From martin at ximian.com  Mon Jun 19 06:00:52 2006
From: martin at ximian.com (Martin Baulig)
Date: Mon, 19 Jun 2006 12:00:52 +0200
Subject: [Mono-dev] Line numbers in stack traces and exceptions
Message-ID: <1150711252.6313.1.camel@rohan.trier.ximian.com>

Hi guys,

about two weeks ago, I fixed line numbers in stack traces and
exceptions.

If anyone still has any problems with them, please lemme know.

Martin




From kostat at mainsoft.com  Mon Jun 19 06:51:37 2006
From: kostat at mainsoft.com (Konstantin Triger)
Date: Mon, 19 Jun 2006 03:51:37 -0700
Subject: [Mono-dev] [PATCH] System.Web.Compilation/AspTokenizer.cs
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D0313739A@dhost002-45.dex002.intermedia.net>

Hi Juraj,

You are right, I missed the (!inServerTag) condition above. But I don't think parser/tokenizer should count quotes inside the inline server code (which is regulated by inServerTag flag, to my understanding). This is because parser/tokenizer should be unaware of the language the server side code written with and thus its syntax. If there is an error, the compilation should fail.

I think the 

if (quoted && c == quoteChar) {
   return Token.NOTWELLFORMED;
}

Should be moved to the (!inServerTag) condition scope, and this will do the trick.

Regards,
Konstantin Triger

-----Original Message-----
From: Juraj Skripsky [mailto:js at hotfeet.ch] 
Sent: Monday, June 19, 2006 11:59 AM
To: Konstantin Triger
Cc: mono-devel-list at ximian.com
Subject: Re: [Mono-dev] [PATCH] System.Web.Compilation/AspTokenizer.cs

Hi,

The patch you propose is not quite right:

...
               } else if (!inServerTag) {
...
...
               } else if (!inServerTag && quoted && c == quoteChar) {
                     return Token.NOTWELLFORMED;
               }

The case "!inServerTag" is already handled a few lines before, making
"return Token.NOTWELLFORMED" unreachable.

But there is a problem with fix 61757. The quoting rules (or rather the
rules of their nesting) change depending on whether we're inside a
server control or not.

We probably need to tokenize all attributes as if we're not inside a
server control, noting whether the stricter rules were violated or not.
After reading all attributes we check for the presence of runat="server"
and throw in the case of violation.

I'll have a look at it.

- Juraj



On Mon, 2006-06-19 at 01:17 -0700, Konstantin Triger wrote:
> Hello,
> 
>  
> 
> Following the fix 61757: this code started throwing not well formed:
> 
> <img src="Handler.ashx?PhotoID=<%# Eval("PhotoID") %>&Size=M" />
> 
>  
> 
> This is because Eval(?) contains quotes. The attached patch fixes that
> by ignoring quotes inside server tag.
> 
>  
> 
> Please review.
> 
>  
> 
> Regards,
> 
> Konstantin Triger
> 
>  
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list


From kostat at mainsoft.com  Mon Jun 19 07:23:39 2006
From: kostat at mainsoft.com (Konstantin Triger)
Date: Mon, 19 Jun 2006 04:23:39 -0700
Subject: [Mono-dev] [PATCH] System.Web.Compilation/AspTokenizer.cs
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D031373A6@dhost002-45.dex002.intermedia.net>

Ok,

I rechecked it, your patch is correct.

Regards,
Konstantin Triger

-----Original Message-----
From: Juraj Skripsky [mailto:js at hotfeet.ch] 
Sent: Monday, June 19, 2006 12:29 PM
To: Konstantin Triger
Cc: mono-devel-list at ximian.com
Subject: Re: [Mono-dev] [PATCH] System.Web.Compilation/AspTokenizer.cs

Hi,

Could you please review and test the attached patch.

- Juraj


On Mon, 2006-06-19 at 01:17 -0700, Konstantin Triger wrote:
> Hello,
> 
>  
> 
> Following the fix 61757: this code started throwing not well formed:
> 
> <img src="Handler.ashx?PhotoID=<%# Eval("PhotoID") %>&Size=M" />
> 
>  
> 
> This is because Eval(?) contains quotes. The attached patch fixes that
> by ignoring quotes inside server tag.
> 
>  
> 
> Please review.
> 
>  
> 
> Regards,
> 
> Konstantin Triger
> 
>  
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

From js at hotfeet.ch  Mon Jun 19 07:26:25 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Mon, 19 Jun 2006 13:26:25 +0200
Subject: [Mono-dev] [PATCH] System.Web.Compilation/AspTokenizer.cs
In-Reply-To: <DA63C6E8B207E748B20D46DFED7B772D0313739A@dhost002-45.dex002.intermedia.net>
References: <DA63C6E8B207E748B20D46DFED7B772D0313739A@dhost002-45.dex002.intermedia.net>
Message-ID: <1150716385.2516.43.camel@leonardo.hotfeet.ch>

Hi Konstantin,

I don't think that just moving it into the !inServerTag case will solve
the problem. I'm trying to achieve identical behaviour with MS.NET for
the following cases:

1) <asp:Literal text="<%# "Test" %>" runat="server" />
2) <asp:Literal text='<%# "Test" %>' runat="server" />
3) <img src="blah.aspx?id=<%# "Test" %>" />

On MS.NET, 1 and 3 compile, 2 results in an parser error.
For server controls, MS.NET does not seem to allow the same quoting
characters to be used inside attribute <%...%>-blocks as the ones used
for the attribute value itself - irregardless of the language used for
the server side code.

Browsers treat inline javascript code the same way:
1) <a href="javascript:alert("hello world")">Click me</a>
2) <a href="javascript:alert('hello world')">Click me</a>

Case 2 works while 1 does not. You are not allow to use "s both inside
and outside of the attribute's value.

As far as my tests go, the patch I've posted achieves compatibility with
MS.NET.

- Juraj



On Mon, 2006-06-19 at 03:51 -0700, Konstantin Triger wrote:
> Hi Juraj,
> 
> You are right, I missed the (!inServerTag) condition above. But I don't think parser/tokenizer should count quotes inside the inline server code (which is regulated by inServerTag flag, to my understanding). This is because parser/tokenizer should be unaware of the language the server side code written with and thus its syntax. If there is an error, the compilation should fail.
> 
> I think the 
> 
> if (quoted && c == quoteChar) {
>    return Token.NOTWELLFORMED;
> }
> 
> Should be moved to the (!inServerTag) condition scope, and this will do the trick.
> 
> Regards,
> Konstantin Triger
> 
> -----Original Message-----
> From: Juraj Skripsky [mailto:js at hotfeet.ch] 
> Sent: Monday, June 19, 2006 11:59 AM
> To: Konstantin Triger
> Cc: mono-devel-list at ximian.com
> Subject: Re: [Mono-dev] [PATCH] System.Web.Compilation/AspTokenizer.cs
> 
> Hi,
> 
> The patch you propose is not quite right:
> 
> ...
>                } else if (!inServerTag) {
> ...
> ...
>                } else if (!inServerTag && quoted && c == quoteChar) {
>                      return Token.NOTWELLFORMED;
>                }
> 
> The case "!inServerTag" is already handled a few lines before, making
> "return Token.NOTWELLFORMED" unreachable.
> 
> But there is a problem with fix 61757. The quoting rules (or rather the
> rules of their nesting) change depending on whether we're inside a
> server control or not.
> 
> We probably need to tokenize all attributes as if we're not inside a
> server control, noting whether the stricter rules were violated or not.
> After reading all attributes we check for the presence of runat="server"
> and throw in the case of violation.
> 
> I'll have a look at it.
> 
> - Juraj
> 
> 
> 
> On Mon, 2006-06-19 at 01:17 -0700, Konstantin Triger wrote:
> > Hello,
> > 
> >  
> > 
> > Following the fix 61757: this code started throwing not well formed:
> > 
> > <img src="Handler.ashx?PhotoID=<%# Eval("PhotoID") %>&Size=M" />
> > 
> >  
> > 
> > This is because Eval(?) contains quotes. The attached patch fixes that
> > by ignoring quotes inside server tag.
> > 
> >  
> > 
> > Please review.
> > 
> >  
> > 
> > Regards,
> > 
> > Konstantin Triger
> > 
> >  
> > 
> > 
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From romydmisc at gmail.com  Mon Jun 19 09:49:12 2006
From: romydmisc at gmail.com (romyd misc)
Date: Mon, 19 Jun 2006 09:49:12 -0400
Subject: [Mono-dev] Calling unmanaged dll from C#
Message-ID: <a2bd15780606190649t35f13906ldf4d356b72a0fddb@mail.gmail.com>

Hi All,

I want to use DllImport to call a C function that allocates and
returns an array of strings. I'm not sure if this is the right place
to ask this question, but my sample code works with windows .NET
compiler, so either there is a different way to call unmanaged dlls in
mono or may be i'm not implementing it right?

I've a C function that converts a char * to wchar_t *

DllExport  Func(wchar_t** ipadds)
{
char mbBuf[BUF_SIZE] = "1.1.1.1";
char* s = mbBuf;
size_t len = strlen (mbBuf);
wchar_t *result = malloc ((len + 1) * sizeof (wchar_t));
wchar_t *wcp = result;
wchar_t tmp;
mbstate_t state;
size_t nbytes;

int i = 0;
memset (&state, '\0', sizeof (state));
while ((nbytes = mbrtowc (&tmp, s, len, &state)) > 0)
   {
     if (nbytes >= (size_t) -2)
       /* Invalid input string.  */
       return NULL;

       result[i] = tmp;
       i++;
       len -= nbytes;
       s += nbytes;
   }

   result[i] = '\0';
   *ipadds = result;
}

My C# code looks like this:

     [DllImport("KeyServerUsage.dll", CharSet = CharSet.Auto,
EntryPoint = "Func")]
       private static extern void Func([Out] string[] Names);

            public ArrayList GetIPAdd()
            {
                string[] ipadds = new string[2];
                Func(ipadds);
            }


Now i get a blank array returned in ipadds when i run this program
with mono. But when i run the same program on windows, i get "1.1.1.1"
in ipadds[0]. Any help would be greatly appreciated.

Thanks,
Romy


From martin at ximian.com  Mon Jun 19 10:40:48 2006
From: martin at ximian.com (Martin Baulig)
Date: Mon, 19 Jun 2006 16:40:48 +0200
Subject: [Mono-dev] ChangeType for Nullable
In-Reply-To: <4544655.post@talk.nabble.com>
References: <4543806.post@talk.nabble.com>  <4544655.post@talk.nabble.com>
Message-ID: <1150728048.6313.13.camel@rohan.trier.ximian.com>

On Wed, 2006-05-24 at 09:31 -0700, tut wrote:
> Also i'd like to know if one of next expressions should return true:
> 
> 1) typeof(int?).IsSubclassOf(typeof(Nullable<>))
> 2) typeof(int?).IsSubclassOf(typeof(Nullable))

Hello,

neither of these should return true.

2.) this is `System.Nullable' - ie. the non-generic static class - and
    of course, no type can be a subclass of that.

1.) and again, you're comparing two different things:
    typeof(int?) is an instantiated generic type while
    typeof(Nullable<>) is the corresponding generic type definition; so
    this doesn't work.

3.) typeof(int?).IsSubclassOf(typeof(Nullable<int>))
    would be correct - comparing two instantiated generic types - but
    typeof(int?) is actually an instance of Nullable<int> - and not
    a subclass of it.

4.) typeof(int?) == typeof(Nullable<int>)
    is true.

Martin




From usergroup at cornetdesign.com  Mon Jun 19 12:36:28 2006
From: usergroup at cornetdesign.com (Cory Foy)
Date: Mon, 19 Jun 2006 11:36:28 -0500
Subject: [Mono-dev] Invariant Culture question
Message-ID: <4496D28C.6010000@cornetdesign.com>

Thanks for the replies of why CultureInfo.ToString was empty - because 
it was an invariant culture, which doesn't have a name.

My question now is, why is it Invariant Culture? Is it a Linux specific 
thing? Is there a reason we couldn't determine the culture for the 
platform in Mono?

Any help or pointers would be gladly appreciated. I'm trying to 
determine if we should just limit our CultureInfo tests to the .NET 
platform only, or if there is something that could be done to determine 
the local CultureInfo.

Thanks!

-- 
Cory Foy
http://www.cornetdesign.com


From subscription.sapi at apsystems.it  Mon Jun 19 12:38:21 2006
From: subscription.sapi at apsystems.it (APS)
Date: Mon, 19 Jun 2006 18:38:21 +0200
Subject: [Mono-dev] Ascx and postback
Message-ID: <7.0.0.16.0.20060619183549.01cb6dc0@apsystems.it>

Hi,

I'm making some page that consist in an aspx containing an ascx.
In iis/.net they works fine but when I put them in mono the 
__doPostBack javascript function is not added to the page so buttons 
doesn't work.
I'm missing something?



From subscription.sapi at apsystems.it  Mon Jun 19 13:16:24 2006
From: subscription.sapi at apsystems.it (APS)
Date: Mon, 19 Jun 2006 19:16:24 +0200
Subject: [Mono-dev] Ascx and postback (errata corrige)
Message-ID: <7.0.0.16.0.20060619191240.01e17138@apsystems.it>

Going on with tests I was that probably the problem is not due to 
ascxs but to a custom control I've build.
In this control I render manually the output writing a call to __doPostBack.
I thought that in this case I should instruct mono to write the 
__doPostBack function for my control so I used a 
this.Page.RegisterRequiresPostBack(this); before the rendering 
operation but mono still not write the __doPostBack function.
Someone knows if I've to do something more?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060619/65c57f4e/attachment.html 

From js at hotfeet.ch  Mon Jun 19 14:33:46 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Mon, 19 Jun 2006 20:33:46 +0200
Subject: [Mono-dev] Ascx and postback (errata corrige)
In-Reply-To: <7.0.0.16.0.20060619191240.01e17138@apsystems.it>
References: <7.0.0.16.0.20060619191240.01e17138@apsystems.it>
Message-ID: <1150742026.2816.1.camel@funnyfarm.hotfeet.ch>

Hi,

It's hard to see what's wrong from your description alone. Could you
provide some code or a test case?

- Juraj

On Mon, 2006-06-19 at 19:16 +0200, APS wrote:
> Going on with tests I was that probably the problem is not due to
> ascxs but to a custom control I've build.
> In this control I render manually the output writing a call to
> __doPostBack.
> I thought that in this case I should instruct mono to write the
> __doPostBack function for my control so I used a
> this .Page.RegisterRequiresPostBack( this ); before the rendering
> operation but mono still not write the __doPostBack function.
> Someone knows if I've to do something more?
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From monoman at gmail.com  Mon Jun 19 15:49:03 2006
From: monoman at gmail.com (Rafael Teixeira)
Date: Mon, 19 Jun 2006 16:49:03 -0300
Subject: [Mono-dev] Invariant Culture question
In-Reply-To: <4496D28C.6010000@cornetdesign.com>
References: <4496D28C.6010000@cornetdesign.com>
Message-ID: <dd99b8c80606191249r50a40d34o13cb5d07725f9217@mail.gmail.com>

Hi Cory, I think you have to study things a bit more.

The Invariant Culture is an ECMA CLI (.NET) concept. Mono just has to
implement it to be compatible. It surely isn't Linux specific.

The main thing is: It is not about not knowing what the local culture
is, it is about specifically wanting not to be affected by it. The
Invariant Culture is specially built to be, let me say it again,
invariant, therefore giving predictable results that can be exchanged
between contexts/processes/computers, which may be running under
different cultures.

Regards,

On 6/19/06, Cory Foy <usergroup at cornetdesign.com> wrote:
> Thanks for the replies of why CultureInfo.ToString was empty - because
> it was an invariant culture, which doesn't have a name.
>
> My question now is, why is it Invariant Culture? Is it a Linux specific
> thing? Is there a reason we couldn't determine the culture for the
> platform in Mono?
>
> Any help or pointers would be gladly appreciated. I'm trying to
> determine if we should just limit our CultureInfo tests to the .NET
> platform only, or if there is something that could be done to determine
> the local CultureInfo.
>
> Thanks!
>
> --
> Cory Foy
> http://www.cornetdesign.com
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>


-- 
Rafael "Monoman" Teixeira
---------------------------------------
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man." George Bernard Shaw


From romydmisc at gmail.com  Mon Jun 19 16:41:33 2006
From: romydmisc at gmail.com (romyd misc)
Date: Mon, 19 Jun 2006 16:41:33 -0400
Subject: [Mono-dev] Calling unmanaged dll from C#
In-Reply-To: <dd99b8c80606191310j748d4a12i48e305734c500477@mail.gmail.com>
References: <a2bd15780606190649t35f13906ldf4d356b72a0fddb@mail.gmail.com>
	<dd99b8c80606191310j748d4a12i48e305734c500477@mail.gmail.com>
Message-ID: <a2bd15780606191341k30522dc1xf31a0a4ef7a468e5@mail.gmail.com>

I tried with CharSet = CharSet.Unicode, i again got blank array. I
looked up online and found this link
http://lists.ximian.com/pipermail/mono-bugs/2003-March/004256.html
  which mentions about a bug in mono, but i don't know where to find
if someone closed this bug?

Thanks,
Romy

On 6/19/06, Rafael Teixeira <monoman at gmail.com> wrote:
> Did you try to use CharSet = CharSet.Unicode ? Because the
> CharSet.Auto setting is target OS dependent (Monodoc says "Specifies
> that strings will be automatically marshaled in the character set
> appropriate for the target system (either Unicode or ANSI).")
>
> And AFAIK, that is ANSI (in reality UTF-8) for Linux/Mono, so I think
> you have to be explicit that you are returning wide char strings, as
> that is not the norm on Linux and other non-MS OSes.
>
> Hope it helps,
>
> On 6/19/06, romyd misc <romydmisc at gmail.com> wrote:
> > Hi All,
> >
> > I want to use DllImport to call a C function that allocates and
> > returns an array of strings. I'm not sure if this is the right place
> > to ask this question, but my sample code works with windows .NET
> > compiler, so either there is a different way to call unmanaged dlls in
> > mono or may be i'm not implementing it right?
> >
> > I've a C function that converts a char * to wchar_t *
> >
> > DllExport  Func(wchar_t** ipadds)
> > {
> > char mbBuf[BUF_SIZE] = "1.1.1.1";
> > char* s = mbBuf;
> > size_t len = strlen (mbBuf);
> > wchar_t *result = malloc ((len + 1) * sizeof (wchar_t));
> > wchar_t *wcp = result;
> > wchar_t tmp;
> > mbstate_t state;
> > size_t nbytes;
> >
> > int i = 0;
> > memset (&state, '\0', sizeof (state));
> > while ((nbytes = mbrtowc (&tmp, s, len, &state)) > 0)
> >    {
> >      if (nbytes >= (size_t) -2)
> >        /* Invalid input string.  */
> >        return NULL;
> >
> >        result[i] = tmp;
> >        i++;
> >        len -= nbytes;
> >        s += nbytes;
> >    }
> >
> >    result[i] = '\0';
> >    *ipadds = result;
> > }
> >
> > My C# code looks like this:
> >
> >      [DllImport("KeyServerUsage.dll", CharSet = CharSet.Auto,
> > EntryPoint = "Func")]
> >        private static extern void Func([Out] string[] Names);
> >
> >             public ArrayList GetIPAdd()
> >             {
> >                 string[] ipadds = new string[2];
> >                 Func(ipadds);
> >             }
> >
> >
> > Now i get a blank array returned in ipadds when i run this program
> > with mono. But when i run the same program on windows, i get "1.1.1.1"
> > in ipadds[0]. Any help would be greatly appreciated.
> >
> > Thanks,
> > Romy
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
>
>
> --
> Rafael "Monoman" Teixeira
> ---------------------------------------
> "The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man." George Bernard Shaw
>


From usergroup at cornetdesign.com  Mon Jun 19 17:48:15 2006
From: usergroup at cornetdesign.com (Cory Foy)
Date: Mon, 19 Jun 2006 16:48:15 -0500
Subject: [Mono-dev] Invariant Culture question
In-Reply-To: <dd99b8c80606191249r50a40d34o13cb5d07725f9217@mail.gmail.com>
References: <4496D28C.6010000@cornetdesign.com>
	<dd99b8c80606191249r50a40d34o13cb5d07725f9217@mail.gmail.com>
Message-ID: <44971B9F.6050704@cornetdesign.com>

Hi Rafael,

Thanks for the reply. Comments inline:

Rafael Teixeira wrote:
> Hi Cory, I think you have to study things a bit more.
> 
> The Invariant Culture is an ECMA CLI (.NET) concept. Mono just has to
> implement it to be compatible. It surely isn't Linux specific.

I apologize if I made it sound that way.

What I meant was that, on a 1.1 or 2.0 .NET install on Windows, the 
culture is set, I assume, based on the culture settings of the computer. 
  For example, to change the Culture on a Windows Smartphone, you have 
to change it on the Smartphone itself.

So it seems like CultureInfo is picked up from the underlying system. 
What I was wondering is a) if that was indeed correct and if so b) if 
there is a way to get Mono to automatically pick it up as well.

If not, we'll just platform exclude the tests.

Thanks again!

-- 
Cory Foy
http://www.cornetdesign.com


From monoman at gmail.com  Mon Jun 19 18:15:07 2006
From: monoman at gmail.com (Rafael Teixeira)
Date: Mon, 19 Jun 2006 19:15:07 -0300
Subject: [Mono-dev] Invariant Culture question
In-Reply-To: <44971B9F.6050704@cornetdesign.com>
References: <4496D28C.6010000@cornetdesign.com>
	<dd99b8c80606191249r50a40d34o13cb5d07725f9217@mail.gmail.com>
	<44971B9F.6050704@cornetdesign.com>
Message-ID: <dd99b8c80606191515j78c81a17v98deeae3e3692b2c@mail.gmail.com>

Hi Cory,

AFAIK, that works correctly in Mono also.

But beware that culture is a thread-specific setting, you may be doing
something on a thread spawned and set to another culture. Particularly
you may experience a timing problem, if a thread is created before the
main thread has it's culture set to the local one in the runtime
initialization code, what is a possible scenario when mono is
embedded...

I think some other people may help you more than me at the moment, as
I currently have no time to dig the details by looking at Mono source.

Good luck,

On 6/19/06, Cory Foy <usergroup at cornetdesign.com> wrote:
> Hi Rafael,
>
> Thanks for the reply. Comments inline:
>
> Rafael Teixeira wrote:
> > Hi Cory, I think you have to study things a bit more.
> >
> > The Invariant Culture is an ECMA CLI (.NET) concept. Mono just has to
> > implement it to be compatible. It surely isn't Linux specific.
>
> I apologize if I made it sound that way.
>
> What I meant was that, on a 1.1 or 2.0 .NET install on Windows, the
> culture is set, I assume, based on the culture settings of the computer.
>   For example, to change the Culture on a Windows Smartphone, you have
> to change it on the Smartphone itself.
>
> So it seems like CultureInfo is picked up from the underlying system.
> What I was wondering is a) if that was indeed correct and if so b) if
> there is a way to get Mono to automatically pick it up as well.
>
> If not, we'll just platform exclude the tests.
>
> Thanks again!
>
> --
> Cory Foy
> http://www.cornetdesign.com
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>


-- 
Rafael "Monoman" Teixeira
---------------------------------------
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man." George Bernard Shaw


From lists at ophion.org  Tue Jun 20 01:22:58 2006
From: lists at ophion.org (Rafael Ferreira)
Date: Mon, 19 Jun 2006 22:22:58 -0700
Subject: [Mono-dev] Single thread scheduler for Threading.Timers patch
In-Reply-To: <1150265055.26740.14.camel@stan.ophion.org>
References: <1150265055.26740.14.camel@stan.ophion.org>
Message-ID: <1150780978.2816.0.camel@stan.ophion.org>

Has anyone from the mono team being able to take a look at this patch? 

On Tue, 2006-06-13 at 23:04 -0700, Rafael Ferreira wrote:
> Howdy, 
> 
> The attached patch changes the current Threading.Timer class to use a
> single thread scheduler instead of the current 1 thread per timer logic.
> I also spent a lot of time working on the Timer unit tests so they more
> consistently pass as well as fixing the "NotWorking" tests. 
> 
> Some key features include:
> 
> * A single thread handles firing all timer jobs thus allowing a much
> greater number of Timers to be defined - Fixing bug #65734
> * Timer scheduler is only started after the first System.Threading.Timer
> is created (lazy init)
> * Timer scheduler thread dies if there are no more timer jobs in its Job
> queue (early termination)
> * Scheduler can spit out debug info by exporting the MONO_TIMER_DEBUG
> environment variable
> 
> Of course, I don't expect this patch to be accepted without some degree
> of scrutiny so comments/concerns are appreciated and I can commit the
> code once we're all comfortable with it.  
> 
> Cheers, 
> 
> - raf
> 
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From rusminsusanto at yahoo.com  Tue Jun 20 03:54:49 2006
From: rusminsusanto at yahoo.com (Rusmin Susanto)
Date: Tue, 20 Jun 2006 00:54:49 -0700 (PDT)
Subject: [Mono-dev] C# unsafe code performance
Message-ID: <20060620075449.10368.qmail@web60822.mail.yahoo.com>

Hello.
  I know that unsafe code (especially pointer arithmetic feature) can improve performance. If I have arrays
   
   double[] a1 = new double[100];
 double[] a2 = new double[100];
 double[] a3 = new double[100];
 double[] a4 = new double[100];
 double[] a5 = new double[100];
   
  and do the following:
   
   fixed(double *d1 = a1)
 fixed(double *d2 = a2)
 fixed(double *d3 = a3)
 fixed(double *d4 = a4)
 fixed(double *d5 = a5)
 for(int i = 0; i < 100; i++)
  *(d1 + i) = *(d2 + i) + *(d3 + i) + *(d4 + i) +*(d5 + i);
  
we will get a significant performance gain compared to normal array access using []
   
  However, the performance is still nowhere near gcc. C# + unsafe is a lot slower (around 60-70% slower) than gcc. The gcc code looks like this:
  
 for(int i = 0; i < 100; i++)
  *(d1 + i) = *(d2 + i) + *(d3 + i) + *(d4 + i) +*(d5 + i);
   
  where d1, d2, etc. are arrays of double.
  
I execute each code (the C# version and gcc version) 500,000 times and measure the execution time. gcc just beats C# by miles.
  My question is:
   
  Is there any way we can make the C# performance closer to gcc (eg. 5-10% slower)?
   
  Thanks for your response.
   
  
Rusmin

 		
---------------------------------
Yahoo! Groups gets better. Check out the new email design. Plus there?s much more to come.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060620/8301ad76/attachment.html 

From vargaz at gmail.com  Tue Jun 20 04:18:19 2006
From: vargaz at gmail.com (Zoltan Varga)
Date: Tue, 20 Jun 2006 10:18:19 +0200
Subject: [Mono-dev] C# unsafe code performance
In-Reply-To: <20060620075449.10368.qmail@web60822.mail.yahoo.com>
References: <20060620075449.10368.qmail@web60822.mail.yahoo.com>
Message-ID: <295e750a0606200118k3acfeb85s96c836149fea2903@mail.gmail.com>

                                          Hi,

  gcc is an optimizing compiler with a decade of work behind it, so it
will probably
always be faster than mono on code like this. If you want better perf,
you should
move the given code into a C library and invoke it using p/pinvoke from C#.

                  Zoltan

On 6/20/06, Rusmin Susanto <rusminsusanto at yahoo.com> wrote:
>
> Hello.
> I know that unsafe code (especially pointer arithmetic feature) can improve
> performance. If I have arrays
>
>  double[] a1 = new double[100];
>  double[] a2 = new double[100];
>  double[] a3 = new double[100];
>  double[] a4 = new double[100];
>  double[] a5 = new double[100];
>
> and do the following:
>
>  fixed(double *d1 = a1)
>  fixed(double *d2 = a2)
>  fixed(double *d3 = a3)
>  fixed(double *d4 = a4)
>  fixed(double *d5 = a5)
>  for(int i = 0; i < 100; i++)
>   *(d1 + i) = *(d2 + i) + *(d3 + i) + *(d4 + i) +*(d5 + i);
>
> we will get a significant performance gain compared to normal array access
> using []
>
> However, the performance is still nowhere near gcc. C# + unsafe is a lot
> slower (around 60-70% slower) than gcc. The gcc code looks like this:
>
>  for(int i = 0; i < 100; i++)
>   *(d1 + i) = *(d2 + i) + *(d3 + i) + *(d4 + i) +*(d5 + i);
>
> where d1, d2, etc. are arrays of double.
>
> I execute each code (the C# version and gcc version) 500,000 times and
> measure the execution time. gcc just beats C# by miles.
> My question is:
>
> Is there any way we can make the C# performance closer to gcc (eg. 5-10%
> slower)?
>
> Thanks for your response.
>
>
>
> Rusmin
>
>
>  ________________________________
> Yahoo! Groups gets better. Check out the new email design. Plus there's much
> more to come.
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>


From jonpryor at vt.edu  Tue Jun 20 06:57:38 2006
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Tue, 20 Jun 2006 06:57:38 -0400
Subject: [Mono-dev] Calling unmanaged dll from C#
In-Reply-To: <a2bd15780606191341k30522dc1xf31a0a4ef7a468e5@mail.gmail.com>
References: <a2bd15780606190649t35f13906ldf4d356b72a0fddb@mail.gmail.com>
	<dd99b8c80606191310j748d4a12i48e305734c500477@mail.gmail.com>
	<a2bd15780606191341k30522dc1xf31a0a4ef7a468e5@mail.gmail.com>
Message-ID: <1150801060.15344.1.camel@melchior.magi>

On Mon, 2006-06-19 at 16:41 -0400, romyd misc wrote:
> I tried with CharSet = CharSet.Unicode, i again got blank array. I
> looked up online and found this link
> http://lists.ximian.com/pipermail/mono-bugs/2003-March/004256.html
>   which mentions about a bug in mono, but i don't know where to find
> if someone closed this bug?

At the very top of that link is a URL:

        Changed by lmaloney at bigpond.net.au.
        
        http://bugzilla.ximian.com/show_bug.cgi?id=40149

That URL is the actual bug entry, which says it was fixed in May 2003.

The sample program at the bug continues to work.

 - Jon




From robertj at gmx.net  Tue Jun 20 07:05:34 2006
From: robertj at gmx.net (Robert Jordan)
Date: Tue, 20 Jun 2006 12:05:34 +0100
Subject: [Mono-dev] Invariant Culture question
In-Reply-To: <44971B9F.6050704@cornetdesign.com>
References: <4496D28C.6010000@cornetdesign.com>	<dd99b8c80606191249r50a40d34o13cb5d07725f9217@mail.gmail.com>
	<44971B9F.6050704@cornetdesign.com>
Message-ID: <e78kpr$jr1$1@sea.gmane.org>

Hi Cory,

> Rafael Teixeira wrote:
>> Hi Cory, I think you have to study things a bit more.
>>
>> The Invariant Culture is an ECMA CLI (.NET) concept. Mono just has to
>> implement it to be compatible. It surely isn't Linux specific.
> 
> I apologize if I made it sound that way.
> 
> What I meant was that, on a 1.1 or 2.0 .NET install on Windows, the 
> culture is set, I assume, based on the culture settings of the computer. 
>   For example, to change the Culture on a Windows Smartphone, you have 
> to change it on the Smartphone itself.
> 
> So it seems like CultureInfo is picked up from the underlying system. 
> What I was wondering is a) if that was indeed correct and if so b) if 
> there is a way to get Mono to automatically pick it up as well.

The default CultureInfo is computed from the POSIX locale. Mono
is evaluating the LC_ALL and the LANG env vars (in this order).

Robert



From subscription.sapi at apsystems.it  Tue Jun 20 07:11:48 2006
From: subscription.sapi at apsystems.it (APS)
Date: Tue, 20 Jun 2006 13:11:48 +0200
Subject: [Mono-dev] Postback on Custom Controls
In-Reply-To: <1150742026.2816.1.camel@funnyfarm.hotfeet.ch>
References: <7.0.0.16.0.20060619191240.01e17138@apsystems.it>
	<1150742026.2816.1.camel@funnyfarm.hotfeet.ch>
Message-ID: <7.0.0.16.0.20060620130005.01ddef78@apsystems.it>

I changed the mail subject according to the problem.
I've investigated on my problem and I've found that if I make a new 
custom control inheriting, for example, from a LinkButton and I 
completely rewrite the OnRender without calling the base method .Net 
adds the __doPostBack javascript function, mono doesn't.
I think that is because I didn't wrote any postback calls, in fact if 
I call the Page.GetPostBackClientEvent Mono correctly adds the 
__doPostBack function, .Net instead always adds it cause it looks at 
the LinkButton object.

In some ways this can be correct, if not used is unuseful to add it, 
but if I've to manage in a different way the postback funztionality, 
how can I force mono to write the __doPostBack function?

At 20.33 19/06/2006, Juraj Skripsky wrote:
>Hi,
>
>It's hard to see what's wrong from your description alone. Could you
>provide some code or a test case?
>
>- Juraj
>
>On Mon, 2006-06-19 at 19:16 +0200, APS wrote:
> > Going on with tests I was that probably the problem is not due to
> > ascxs but to a custom control I've build.
> > In this control I render manually the output writing a call to
> > __doPostBack.
> > I thought that in this case I should instruct mono to write the
> > __doPostBack function for my control so I used a
> > this .Page.RegisterRequiresPostBack( this ); before the rendering
> > operation but mono still not write the __doPostBack function.
> > Someone knows if I've to do something more?
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list



From js at hotfeet.ch  Tue Jun 20 07:29:47 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Tue, 20 Jun 2006 13:29:47 +0200
Subject: [Mono-dev] Postback on Custom Controls
In-Reply-To: <7.0.0.16.0.20060620130005.01ddef78@apsystems.it>
References: <7.0.0.16.0.20060619191240.01e17138@apsystems.it>
	<1150742026.2816.1.camel@funnyfarm.hotfeet.ch>
	<7.0.0.16.0.20060620130005.01ddef78@apsystems.it>
Message-ID: <1150802987.2526.31.camel@leonardo.hotfeet.ch>

Hi,

If it works on .Net and fails on Mono, it's probably a bug in Mono.
Could you post the code? We're very interested in making Mono as
compatible to .Net as possible.

- Juraj


On Tue, 2006-06-20 at 13:11 +0200, APS wrote:
> I changed the mail subject according to the problem.
> I've investigated on my problem and I've found that if I make a new 
> custom control inheriting, for example, from a LinkButton and I 
> completely rewrite the OnRender without calling the base method .Net 
> adds the __doPostBack javascript function, mono doesn't.
> I think that is because I didn't wrote any postback calls, in fact if 
> I call the Page.GetPostBackClientEvent Mono correctly adds the 
> __doPostBack function, .Net instead always adds it cause it looks at 
> the LinkButton object.
> 
> In some ways this can be correct, if not used is unuseful to add it, 
> but if I've to manage in a different way the postback funztionality, 
> how can I force mono to write the __doPostBack function?
> 
> At 20.33 19/06/2006, Juraj Skripsky wrote:
> >Hi,
> >
> >It's hard to see what's wrong from your description alone. Could you
> >provide some code or a test case?
> >
> >- Juraj
> >
> >On Mon, 2006-06-19 at 19:16 +0200, APS wrote:
> > > Going on with tests I was that probably the problem is not due to
> > > ascxs but to a custom control I've build.
> > > In this control I render manually the output writing a call to
> > > __doPostBack.
> > > I thought that in this case I should instruct mono to write the
> > > __doPostBack function for my control so I used a
> > > this .Page.RegisterRequiresPostBack( this ); before the rendering
> > > operation but mono still not write the __doPostBack function.
> > > Someone knows if I've to do something more?
> > > _______________________________________________
> > > Mono-devel-list mailing list
> > > Mono-devel-list at lists.ximian.com
> > > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From jonpryor at vt.edu  Tue Jun 20 07:28:21 2006
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Tue, 20 Jun 2006 07:28:21 -0400
Subject: [Mono-dev] Calling unmanaged dll from C#
In-Reply-To: <a2bd15780606190649t35f13906ldf4d356b72a0fddb@mail.gmail.com>
References: <a2bd15780606190649t35f13906ldf4d356b72a0fddb@mail.gmail.com>
Message-ID: <1150802901.15344.20.camel@melchior.magi>

On Mon, 2006-06-19 at 09:49 -0400, romyd misc wrote:
> I want to use DllImport to call a C function that allocates and
> returns an array of strings. I'm not sure if this is the right place
> to ask this question,

mono-list is the appropriate place for this question (yet I'll answer
anyway...)

>  but my sample code works with windows .NET
> compiler, so either there is a different way to call unmanaged dlls in
> mono or may be i'm not implementing it right?

Or it's (C): None of the above. :-)

You're hitting three issues, two of which I wouldn't expect you to know
about, and one of which confuses me (as I don't see why it works
on .NET).

The first issue is this: C's `sizeof(wchar_t)' is NOT equal to C#'s
sizeof(System.Char).  System.String is an array of System.Char structs,
and a System.Char is an unsigned 16-bit value.  `wchar_t' on Unix
platforms, on the other hand, is a signed 32-bit value.  Consequently,
the use of mbrtowc(3) is incorrect.

The second issue is that Mono takes "CharSet.Auto" to be "ANSI" by
default (where for Mono "ANSI" is really UTF-8).  So your DllImport says
Func() should be in the "auto" charset, but your C code is wchar_t,
which wouldn't be right anyway....

The third issue is that your code confuses me. :-)

In particular, Func() is similar to this:

	void Func (wchar_t** ipadds)
	{
		(*ipadds) = malloc (10);
	}

Yet your DllImport says that `ipadds' should be a `string[]'.  That code
looks like it should be a `ref string', not a `string[]', since it would
only be modifying the first element of the array...

I'm surprised this works under .NET, actually.

Regardless, the following code works:

        /*
         * KeyServerUsage.c: Unmanaged Library.
         *
         * Compile as:
         *  gcc -shared -o libKeyServerUsage.so KeyServerUsage.c
         */
        #include <stdio.h>
        #include <stdlib.h>
        #include <string.h>
        
        void Func(char** ipadds)
        {
          char mbBuf[] = "1.1.1.1";
          size_t len = strlen (mbBuf);
        
          *ipadds = malloc (len+1);
          strcpy (*ipadds, mbBuf);
        }
        
        void* Func2 (void)
        {
          char mbBuf[] = "1.1.1.1";
          size_t len = strlen (mbBuf);
        
          char* ipadds = malloc (len+1);
          strcpy (ipadds, mbBuf);
          return ipadds;
        }
        
        
        /*
         * KeyServerUsage.cs
         *
         * Compile as: mcs -r:Mono.Posix.dll KeyServerUsage.cs
         */
        using System;
        using System.Collections;
        using System.Runtime.InteropServices;
        
        using Mono.Unix;
        
        class Test {
          [DllImport("KeyServerUsage.dll")]
          private static extern void Func(out string name);
        
          public static string GetIPAdd ()
          {
            string ipadds;
            Func (out ipadds);
            return ipadds;
          }
        
          [DllImport("KeyServerUsage.dll")]
          private static extern IntPtr Func2 ();
        
          public static string GetIPAdd2 ()
          {
            IntPtr p = Func2 ();
            string s = Marshal.PtrToStringAnsi (p);
            UnixMarshal.FreeHeap (p);
            return s;
          }
        
          public static void Main ()
          {
            string l = GetIPAdd ();
            Console.WriteLine (l);
            l = GetIPAdd2 ();
            Console.WriteLine (l);
          }
        }

Note the addition of the Func2() and GetIPAdd2() methods, which uses a
manually freed return value instead of setting the `out' parameter to
malloc(3)'d memory.  This should probably be preferred in order to avoid
memory leaks (as .NET will _never_ call free(3), using CoTaskMemFree()
instead, and I don't know if .NET will call CoTaskMemFree() on [Out]
parameters...)

 - Jon




From subscription.sapi at apsystems.it  Tue Jun 20 07:42:48 2006
From: subscription.sapi at apsystems.it (APS)
Date: Tue, 20 Jun 2006 13:42:48 +0200
Subject: [Mono-dev] Postback on Custom Controls
In-Reply-To: <1150802987.2526.31.camel@leonardo.hotfeet.ch>
References: <7.0.0.16.0.20060619191240.01e17138@apsystems.it>
	<1150742026.2816.1.camel@funnyfarm.hotfeet.ch>
	<7.0.0.16.0.20060620130005.01ddef78@apsystems.it>
	<1150802987.2526.31.camel@leonardo.hotfeet.ch>
Message-ID: <7.0.0.16.0.20060620133902.01c80da0@apsystems.it>

Ok, I wrote a simple test site, I attach the solution (I develop in 
VS.NET and then deploy to Mono).
I changed my code using GetPostBack... and it works fine, let me know 
if I was doing something wrong or if you retain it a Mono bug.


At 13.29 20/06/2006, you wrote:
>Hi,
>
>If it works on .Net and fails on Mono, it's probably a bug in Mono.
>Could you post the code? We're very interested in making Mono as
>compatible to .Net as possible.
>
>- Juraj
>
>
>On Tue, 2006-06-20 at 13:11 +0200, APS wrote:
> > I changed the mail subject according to the problem.
> > I've investigated on my problem and I've found that if I make a new
> > custom control inheriting, for example, from a LinkButton and I
> > completely rewrite the OnRender without calling the base method .Net
> > adds the __doPostBack javascript function, mono doesn't.
> > I think that is because I didn't wrote any postback calls, in fact if
> > I call the Page.GetPostBackClientEvent Mono correctly adds the
> > __doPostBack function, .Net instead always adds it cause it looks at
> > the LinkButton object.
> >
> > In some ways this can be correct, if not used is unuseful to add it,
> > but if I've to manage in a different way the postback funztionality,
> > how can I force mono to write the __doPostBack function?
> >
> > At 20.33 19/06/2006, Juraj Skripsky wrote:
> > >Hi,
> > >
> > >It's hard to see what's wrong from your description alone. Could you
> > >provide some code or a test case?
> > >
> > >- Juraj
> > >
> > >On Mon, 2006-06-19 at 19:16 +0200, APS wrote:
> > > > Going on with tests I was that probably the problem is not due to
> > > > ascxs but to a custom control I've build.
> > > > In this control I render manually the output writing a call to
> > > > __doPostBack.
> > > > I thought that in this case I should instruct mono to write the
> > > > __doPostBack function for my control so I used a
> > > > this .Page.RegisterRequiresPostBack( this ); before the rendering
> > > > operation but mono still not write the __doPostBack function.
> > > > Someone knows if I've to do something more?
> > > > _______________________________________________
> > > > Mono-devel-list mailing list
> > > > Mono-devel-list at lists.ximian.com
> > > > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestUserControl.zip
Type: application/zip
Size: 29644 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060620/6f9e57d4/attachment.zip 

From mono at evain.net  Tue Jun 20 07:45:10 2006
From: mono at evain.net (Jb Evain)
Date: Tue, 20 Jun 2006 13:45:10 +0200
Subject: [Mono-dev] [PATCH] Math.Truncate
Message-ID: <FB7C42E7-ADB3-45AB-95F0-FB9112B02713@evain.net>

Hello,

This patch implements the new methods Math.Truncate.
Is it ok?

Jb

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Math.diff
Type: application/octet-stream
Size: 458 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060620/7825dcd1/attachment.obj 

From js at hotfeet.ch  Tue Jun 20 07:56:48 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Tue, 20 Jun 2006 13:56:48 +0200
Subject: [Mono-dev] Another patch for AspTokenizer/AspParser
Message-ID: <1150804608.2526.40.camel@leonardo.hotfeet.ch>

Hi Gonzalo,

As Konstantin Triger pointed out, my last patch led to a regression. The
attached patch fixes that. Could you please review and tell me if it's
okay to commit?

- Juraj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Quotes.patch
Type: text/x-patch
Size: 2986 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060620/b0a73b36/attachment.bin 

From sebastien.pouliot at gmail.com  Tue Jun 20 08:10:30 2006
From: sebastien.pouliot at gmail.com (Sebastien Pouliot)
Date: Tue, 20 Jun 2006 08:10:30 -0400
Subject: [Mono-dev] [PATCH] Math.Truncate
In-Reply-To: <FB7C42E7-ADB3-45AB-95F0-FB9112B02713@evain.net>
References: <FB7C42E7-ADB3-45AB-95F0-FB9112B02713@evain.net>
Message-ID: <1150805430.30493.3.camel@poupou.home>

On Tue, 2006-06-20 at 13:45 +0200, Jb Evain wrote:
> Hello,
> 
> This patch implements the new methods Math.Truncate.
> Is it ok?

Looks like, but in the past we had multiple surprise with the rounding
(including some changes between fx 1.0 and 1.1). So I guess you should
include unit tests for both methods. 

You can copy-n-edit existing test cases (e.g. for Round) as it should
cover most corner case we have encountered.

Thanks
Sebastien



From vargaz at gmail.com  Tue Jun 20 08:15:49 2006
From: vargaz at gmail.com (Zoltan Varga)
Date: Tue, 20 Jun 2006 14:15:49 +0200
Subject: [Mono-dev] [PATCH] Math.Truncate
In-Reply-To: <FB7C42E7-ADB3-45AB-95F0-FB9112B02713@evain.net>
References: <FB7C42E7-ADB3-45AB-95F0-FB9112B02713@evain.net>
Message-ID: <295e750a0606200515t1ca90f80rc65f118a9eba8118@mail.gmail.com>

                          Hi,

  I'm no math expert, but truncation is most likely not the same as rounding,
so this patch would probably lead to hard to track down errors later.

             Zoltan

On 6/20/06, Jb Evain <mono at evain.net> wrote:
> Hello,
>
> This patch implements the new methods Math.Truncate.
> Is it ok?
>
> Jb
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>


From js at hotfeet.ch  Tue Jun 20 09:49:59 2006
From: js at hotfeet.ch (Juraj Skripsky)
Date: Tue, 20 Jun 2006 15:49:59 +0200
Subject: [Mono-dev] Postback on Custom Controls
In-Reply-To: <7.0.0.16.0.20060620133902.01c80da0@apsystems.it>
References: <7.0.0.16.0.20060619191240.01e17138@apsystems.it>
	<1150742026.2816.1.camel@funnyfarm.hotfeet.ch>
	<7.0.0.16.0.20060620130005.01ddef78@apsystems.it>
	<1150802987.2526.31.camel@leonardo.hotfeet.ch>
	<7.0.0.16.0.20060620133902.01c80da0@apsystems.it>
Message-ID: <1150811400.2526.52.camel@leonardo.hotfeet.ch>

Thanks for the test case! I'll look into it.

Maybe you should have a look at the source code of WebControl:
http://svn.myrealbox.com/viewcvs/*checkout*/trunk/mcs/class/System.Web/System.Web.UI.WebControls/WebControl.cs?rev=57676

There you can see that Render() calls RenderBeginTag() which in turn
calls AddAttributesToRender(). This method is overridden in LinkButton
and adds the __doPostBack stuff.

- Juraj


On Tue, 2006-06-20 at 13:42 +0200, APS wrote:
> Ok, I wrote a simple test site, I attach the solution (I develop in 
> VS.NET and then deploy to Mono).
> I changed my code using GetPostBack... and it works fine, let me know 
> if I was doing something wrong or if you retain it a Mono bug.
> 
> 
> At 13.29 20/06/2006, you wrote:
> >Hi,
> >
> >If it works on .Net and fails on Mono, it's probably a bug in Mono.
> >Could you post the code? We're very interested in making Mono as
> >compatible to .Net as possible.
> >
> >- Juraj
> >
> >
> >On Tue, 2006-06-20 at 13: