From kostat at mainsoft.com  Sun Sep  2 02:35:03 2007
From: kostat at mainsoft.com (Konstantin Triger)
Date: Sat, 1 Sep 2007 23:35:03 -0700
Subject: [Mono-dev] System.Web.Extension
In-Reply-To: <8a7a2d050708300959w52b17e71t87c3d31ee795270d@mail.gmail.com>
References: <8a7a2d050708250428s12079515n429d52f024cdc1f1@mail.gmail.com>
	<DA63C6E8B207E748B20D46DFED7B772D045E6DFD@dhost002-45.dex002.intermedia.net>
	<8a7a2d050708281059r10d7c945r1cec51542e436811@mail.gmail.com>
	<DA63C6E8B207E748B20D46DFED7B772D045E6EE5@dhost002-45.dex002.intermedia.net>
	<8a7a2d050708291532j69bfb3b6u2971c95a1c9d4a00@mail.gmail.com>
	<DA63C6E8B207E748B20D46DFED7B772D045E7015@dhost002-45.dex002.intermedia.net>
	<8a7a2d050708300233w185ac692v23670b56eee90515@mail.gmail.com>
	<DA63C6E8B207E748B20D46DFED7B772D04669DC5@dhost002-45.dex002.intermedia.net>
	<002b01c7eb13$ac321da0$049658e0$@de>
	<1188490848.4009.75.camel@erandi.dom>
	<8a7a2d050708300959w52b17e71t87c3d31ee795270d@mail.gmail.com>
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D04669ECE@dhost002-45.dex002.intermedia.net>

Hello Onur,

 

> I think these are bugs are  in mono runtime /aspx parser and/or System.Web.Extensions.dll of mainsoft's.

You may really help by identifying the problematic module (Sys.Web or Sys.Web.Extensions ?). To do that you may try to run mono Sys.Web.Extensions in the MS .Net environment. Simply register it to the GAC and change the Version/PublicKeyToken in the web.config.

 

Regards,

Konstantin Triger

________________________________

From: Onur Gumus [mailto:emperon at gmail.com] 
Sent: Thursday, August 30, 2007 8:00 PM
To: Miguel de Icaza
Cc: Jens Wurster; Konstantin Triger; mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] System.Web.Extension

 

Hey Miguel,

I think these are bugs are  in mono runtime /aspx parser and/or System.Web.Extensions.dll of mainsoft's.

The sample is written by Microsoft and works flawlessly on MS.NET platform.

Onur

On 8/30/07, Miguel de Icaza <miguel at novell.com> wrote:

Hello Jens,

> AlwaysVisibleControl, AutoComplete, CascadingDropDown,
> DynamicPopulate, FilteredTextBox, HoverMenu, MaskedEdit,
>
> NumericUpDown, Rating, ReorderList, SlideShow and ValidatorCallout 

Would you mind filing bugs for these on:

        www.mono-project.com/Bugs

Describing the problem?   One for each problem.

Miguel.
>
_______________________________________________ 
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list 




-- 
Warning: If you are reading this then this warning is for you. Every word you read of this useless fine print is another second off your life. Don't you have other things to do? Is your life so empty that you honestly can't think of a better way to spend these moments? Or are you so impressed with authority that you give respect and credence to all that claim it? Do you read everything you're supposed to read? Do you think every thing you're supposed to think? Buy what you're told to want? Get out of your apartment. Meet a member of the opposite sex. Stop the excessive shopping and masturbation.Quit your job. Start a fight. Prove you're alive. If you don't claim your humanity you will become a statistic. You have been warned - Onur 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070901/4b3223d4/attachment.html 

From tyler at monkeypox.org  Sun Sep  2 10:26:02 2007
From: tyler at monkeypox.org (R. Tyler Ballance)
Date: Sun, 2 Sep 2007 07:26:02 -0700
Subject: [Mono-dev] Who broke master pages in trunk :)
In-Reply-To: <20070831160000.30239725@quantum.thanes.org>
References: <0C12DC17-3869-461A-B7BB-3EBE6C6754A7@monkeypox.org>
	<20070831142058.2c93ff30@quantum.thanes.org>
	<D68BFB18-7D1A-42B6-8208-9B6ACEB704CB@monkeypox.org>
	<20070831160000.30239725@quantum.thanes.org>
Message-ID: <368EFB08-CC4B-4B40-AC94-BCF505F89ED6@monkeypox.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Aug 31, 2007, at 7:00 AM, Marek Habersack wrote:


> Your test works perfectly for me - no book (on r85091)

Running with a more recent snapshot (Mono JIT compiler version 1.2.5  
(/trunk/ r85187)) versus a released version (Mono JIT compiler  
version 1.2.3.1) I still get functional ASP.NET master pages in  
1.2.3.1, and errors in 1.2.5 r85187. Grumble.

If anybody has any tips for how I can debug this a bit better than I  
have thus far,


I've run with MONO_LOG_LEVEL=debug to verifiy that it's running  
against the DLLs in my "trunk" GAC, but other than that I'm drawing a  
blank with an error 500 on it ;)


Cheers,
- -R. Tyler Ballance
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFG2sf9A2GmJ0VpG78RAhRFAKCE70gyOARnDhmiDB30xeCXUSqO9ACfarQc
wg0uLM4yY5Wheu61/AWTWhk=
=mjgH
-----END PGP SIGNATURE-----


From brandon at thresholdofthought.com  Sun Sep  2 11:32:34 2007
From: brandon at thresholdofthought.com (Brandon Perry)
Date: Sun, 02 Sep 2007 10:32:34 -0500
Subject: [Mono-dev] Possible bug in System.Windows.Forms
Message-ID: <1188747154.18899.2.camel@radiohead-laptop>

Hi, when I try to run an assembly using the System.Windows.Forms dll, I
get the following error.

radiohead at radiohead-laptop:~/Desktop/MoMA$ mono
'/home/radiohead/Desktop/printinginNet/bin/Debug/PrintingSamples.exe' 

**
(/home/radiohead/Desktop/printinginNet/bin/Debug/PrintingSamples.exe:20402): WARNING **: The following assembly referenced from /home/radiohead/Desktop/printinginNet/bin/Debug/PrintingSamples.exe could not be loaded:
     Assembly:   System.Windows.Forms    (assemblyref_index=1)
     Version:    1.0.3300.0
     Public Key: b77a5c561934e089
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 (/home/radiohead/Desktop/printinginNet/bin/Debug).


**
(/home/radiohead/Desktop/printinginNet/bin/Debug/PrintingSamples.exe:20402): WARNING **: Could not load file or assembly 'System.Windows.Forms, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
The entry point method could not be loaded


I tested it with MoMA and it said all was good. I ran a grep on gacutil
-l to make sure the System.Windows.Forms was installed and it is. Any
thoughts?



From valentin.sawadski at gmx.de  Sun Sep  2 13:09:41 2007
From: valentin.sawadski at gmx.de (Valentin Sawadski)
Date: Sun, 02 Sep 2007 19:09:41 +0200
Subject: [Mono-dev] Possible bug in System.Windows.Forms
In-Reply-To: <1188747154.18899.2.camel@radiohead-laptop>
References: <1188747154.18899.2.camel@radiohead-laptop>
Message-ID: <1188752981.28101.7.camel@pi1536.local>

Hello,

your app seems to target .Net 1.0 which is not supported by Mono.
Recompile it against .Net 1.1 or 2.0 and everything should be fine :-)

Kind Regards,
Valentin S.

On Sun, 2007-09-02 at 10:32 -0500, Brandon Perry wrote:
> Hi, when I try to run an assembly using the System.Windows.Forms dll, I
> get the following error.
> 
> radiohead at radiohead-laptop:~/Desktop/MoMA$ mono
> '/home/radiohead/Desktop/printinginNet/bin/Debug/PrintingSamples.exe' 
> 
> **
> (/home/radiohead/Desktop/printinginNet/bin/Debug/PrintingSamples.exe:20402): WARNING **: The following assembly referenced from /home/radiohead/Desktop/printinginNet/bin/Debug/PrintingSamples.exe could not be loaded:
>      Assembly:   System.Windows.Forms    (assemblyref_index=1)
>      Version:    1.0.3300.0
>      Public Key: b77a5c561934e089
> 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 (/home/radiohead/Desktop/printinginNet/bin/Debug).
> 
> 
> **
> (/home/radiohead/Desktop/printinginNet/bin/Debug/PrintingSamples.exe:20402): WARNING **: Could not load file or assembly 'System.Windows.Forms, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
> The entry point method could not be loaded
> 
> 
> I tested it with MoMA and it said all was good. I ran a grep on gacutil
> -l to make sure the System.Windows.Forms was installed and it is. Any
> thoughts?
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From brandon at thresholdofthought.com  Sun Sep  2 13:27:12 2007
From: brandon at thresholdofthought.com (Brandon Perry)
Date: Sun, 02 Sep 2007 12:27:12 -0500
Subject: [Mono-dev] Possible bug in System.Windows.Forms
In-Reply-To: <1188752981.28101.7.camel@pi1536.local>
References: <1188747154.18899.2.camel@radiohead-laptop>
	<1188752981.28101.7.camel@pi1536.local>
Message-ID: <1188754032.18899.4.camel@radiohead-laptop>

That was it, Thanks.
On Sun, 2007-09-02 at 19:09 +0200, Valentin Sawadski wrote:
> Hello,
> 
> your app seems to target .Net 1.0 which is not supported by Mono.
> Recompile it against .Net 1.1 or 2.0 and everything should be fine :-)
> 
> Kind Regards,
> Valentin S.
> 
> On Sun, 2007-09-02 at 10:32 -0500, Brandon Perry wrote:
> > Hi, when I try to run an assembly using the System.Windows.Forms dll, I
> > get the following error.
> > 
> > radiohead at radiohead-laptop:~/Desktop/MoMA$ mono
> > '/home/radiohead/Desktop/printinginNet/bin/Debug/PrintingSamples.exe' 
> > 
> > **
> > (/home/radiohead/Desktop/printinginNet/bin/Debug/PrintingSamples.exe:20402): WARNING **: The following assembly referenced from /home/radiohead/Desktop/printinginNet/bin/Debug/PrintingSamples.exe could not be loaded:
> >      Assembly:   System.Windows.Forms    (assemblyref_index=1)
> >      Version:    1.0.3300.0
> >      Public Key: b77a5c561934e089
> > 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 (/home/radiohead/Desktop/printinginNet/bin/Debug).
> > 
> > 
> > **
> > (/home/radiohead/Desktop/printinginNet/bin/Debug/PrintingSamples.exe:20402): WARNING **: Could not load file or assembly 'System.Windows.Forms, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies.
> > The entry point method could not be loaded
> > 
> > 
> > I tested it with MoMA and it said all was good. I ran a grep on gacutil
> > -l to make sure the System.Windows.Forms was installed and it is. Any
> > thoughts?
> > 
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 



From charlie at nunit.com  Sun Sep  2 13:56:28 2007
From: charlie at nunit.com (Charlie Poole)
Date: Sun, 2 Sep 2007 10:56:28 -0700
Subject: [Mono-dev] Mono support for .NET 1.0 (was Possible bug in
	System.Windows.Forms)
In-Reply-To: <1188752981.28101.7.camel@pi1536.local>
Message-ID: <003101c7ed8a$96fd7050$6401a8c0@FERRARI>

Hi Valentin,

> your app seems to target .Net 1.0 which is not supported by Mono.
> Recompile it against .Net 1.1 or 2.0 and everything should be fine :-)

Is this documented somewhere? It might explain the hard failure in my
table at http://nunit.org/?p=platformSupport and I'd just as soon not
expend any more effort on 1.0 than I have to.

Charlie





From robertj at gmx.net  Sun Sep  2 14:34:43 2007
From: robertj at gmx.net (Robert Jordan)
Date: Sun, 02 Sep 2007 20:34:43 +0200
Subject: [Mono-dev] Mono support for .NET 1.0 (was Possible bug in
	System.Windows.Forms)
In-Reply-To: <003101c7ed8a$96fd7050$6401a8c0@FERRARI>
References: <1188752981.28101.7.camel@pi1536.local>
	<003101c7ed8a$96fd7050$6401a8c0@FERRARI>
Message-ID: <fbevot$jaj$1@sea.gmane.org>

Hi,

Charlie Poole wrote:
> Hi Valentin,
> 
>> your app seems to target .Net 1.0 which is not supported by Mono.
>> Recompile it against .Net 1.1 or 2.0 and everything should be fine :-)
> 
> Is this documented somewhere? It might explain the hard failure in my
> table at http://nunit.org/?p=platformSupport and I'd just as soon not
> expend any more effort on 1.0 than I have to.

I'm using assemblies compiled against "1.0.3300.0" since ages and
I've never seen this error.

Mono is usually mapping the version of system assemblies:

using System;
using System.Reflection;

class Test
{
	// strong name from OP's  error message
	const string WinForms = "System.Windows.Forms, Version=1.0.3300.0, 
Culture=neutral, PublicKeyToken=b77a5c561934e089";

	static void Main ()
	{
		Console.WriteLine (Assembly.Load (WinForms).FullName);
	}
}

Output:

System.Windows.Forms, Version=1.0.5000.0 ...

or

System.Windows.Forms, Version=2.0.0.0 ...

when compiled with gmcs.


Robert



From tyler at monkeypox.org  Sun Sep  2 22:44:56 2007
From: tyler at monkeypox.org (R. Tyler Ballance)
Date: Sun, 2 Sep 2007 19:44:56 -0700
Subject: [Mono-dev] Proposed Extension to System.Web.Script.Serialization
Message-ID: <24A95FFF-8E72-47C1-A2F0-E0D691C8DB88@monkeypox.org>

Firstly, I'm so glad we have System.Web.Script.Serialization now, woot!

The one major thing missing from JSON serialization (contrasted to  
XML serialization) is the ability to tell the serializer how to  
serialize out your object's attributes, in terms of names. I asked  
James Newton-King about this for Json.NET and he forwarded me a  
modified version of Json.NET that allowed such a beast and I've  
ported it over to our System.Web.Script.Serialization, the only thing  
holding me from committing it is:
	a) Permission from Igor and Konstantin
	b) The fact that .NET doesn't actually define something like this in  
their API

Executing my little test application (attached: JsonTest.cs), my  
"Message" property is serialized out under a different name (insanely  
helpful when dealing with existing JSON APIs and code)


> [mono] \w @ mono JsonTest.exe
> Serializing TestClass out as: {"my_magic_message":"magic!"}


Attached is the cumulative patch for mcs/class/System.Web.Extensions/ 
System.Web.Script.Serialization, I'd like some review and permission  
to go ahead and commit it :D

(patch diffed against rev 85204)

Cheers,
-R. Tyler Ballance

-------------- next part --------------
A non-text attachment was scrubbed...
Name: JsonTest.cs
Type: application/octet-stream
Size: 994 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070902/2359f553/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ScriptElementAttribute.patch
Type: application/octet-stream
Size: 9837 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070902/2359f553/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070902/2359f553/attachment.bin 

From pablosantosluac at terra.es  Mon Sep  3 02:53:31 2007
From: pablosantosluac at terra.es (pablosantosluac)
Date: Mon, 3 Sep 2007 08:53:31 +0200
Subject: [Mono-dev] S390
Message-ID: <176a01c7edf7$59da4410$d501a8c0@beardtongue>

Hi there!


The Mono S390 works on Linux 390, isn't it? Ok, my question is: can a mono 
app running on a 390 virtual machine access resources on other partitions or 
in the "real" host?

We'd considering giving support to "host" users using mono too...


Thanks,

pablo 



From informatique.internet at fiducial.fr  Mon Sep  3 03:08:10 2007
From: informatique.internet at fiducial.fr (Hubert FONGARNAND)
Date: Mon, 03 Sep 2007 09:08:10 +0200
Subject: [Mono-dev] ask for backport on mono 1.2.5 branch
In-Reply-To: <1188572422.4009.159.camel@erandi.dom>
References: <1188572422.4009.159.camel@erandi.dom>
Message-ID: <1188803290.3237.5.camel@hublinux.fidudev.fr>

Le vendredi 31 ao??t 2007 ?? 17:00 +0200, Miguel de Icaza a ??crit :

> Hello,
> 
> > In the actual release, a simple ASP.NET with a ListBox Control
> don't 
> > work, viewstate deserialization problem...
> 
> sigh.    We made tons of preview releases to get people a chance to 
> check stuff against 1.2.5.    
> 
> We have been doing them for more than a month now.   Our largest
> release 
> cycle.
> 
> Miguel.

Hello

I understand, but most of our team was on holydays during this
period... 
(i think you should not choose holydays period for testing period...)

Thanks for the backport, i promise that i'll check preview release next
time!

Hubert

> 
> > This problem as been fixed in the trunk by : 
> > 
> > 2007-08-30 Igor Zelmanovich <igorz at mainsoft.com> 
> > 
> >         * ListControl.cs: fixed selected items state management. 
> > 
> > Could this be backported to the mono 1.2.5 branch? 
> > 
> > 
> > Here's a test case for this problem : 
> > 
> > Default.aspx: 
> > <%@ Page Language="C#" Inherits="TestViewState.Default" %> 
> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
> > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 
> > <html> 
> > <head> 
> > <title>Default</title> 
> > </head> 
> > <body> 
> > <form id="form1" runat="server"> 
> > <asp:Button id="button1" runat="server" /> 
> > <asp:ListBox id="drpSociete" runat="server" CssClass="TextBox200" 
> > Width="200px" Visible="True" 
> >             Rows="1"></asp:ListBox> 
> > </form> 
> > </body> 
> > </html> 
> > 
> > 
> > Default.aspx.cs : 
> > // Default.aspx.cs created with MonoDevelop 
> > // User: hubert at 15:02 31/08/2007 
> > // 
> > // To change standard headers go to 
> > Edit->Preferences->Coding->Standard Headers 
> > // 
> > 
> > using System; 
> > using System.Web; 
> > using System.Web.UI; 
> > using System.Web.UI.WebControls; 
> > using System.Data; 
> > 
> > namespace TestViewState 
> > { 
> > 
> > 
> > public class Default : Page 
> > { 
> > protected ListBox drpSociete; 
> > 
> > 
> > protected override void OnLoad(EventArgs e) 
> > { 
> > if (!IsPostBack){ 
> > drpSociete.Items.Add("bouh"); 
> > drpSociete.Items.Add("bah"); 
> > } 
> > } 
> > 
> > 
> > } 
> > } 
> > 
> > 
> > Click two times on the button and you'll obtain : 
> > Server Error in '/' Application 
> > 
> >
> ______________________________________________________________________ 
> > Index is less than 0 or more than or equal to the list count. 
> > Parameter name: index 0 
> > Description: Error processing request. 
> > 
> > Error Message: HTTP 500. System.ArgumentOutOfRangeException: Index
> is 
> > less than 0 or more than or equal to the list count. Parameter
> name: 
> > index 0 
> > 
> > Stack Trace: 
> > 
> > System.ArgumentOutOfRangeException: Index is less than 0 or more
> than or equal to the list count. 
> > Parameter name: index 
> > 0 
> >   at System.Collections.ArrayList.get_Item (Int32 index) [0x00000] 
> >   at System.Web.UI.WebControls.ListItemCollection.get_Item (Int32
> index) [0x00000] 
> >   at System.Web.UI.WebControls.ListControl.LoadViewState
> (System.Object savedState) [0x00000] 
> >   at System.Web.UI.Control.LoadViewStateRecursive (System.Object
> savedState) [0x00000] 
> >   at System.Web.UI.Control.LoadViewStateRecursive (System.Object
> savedState) [0x00000] 
> >   at System.Web.UI.Control.LoadViewStateRecursive (System.Object
> savedState) [0x00000] 
> >   at System.Web.UI.Page.LoadPageViewState () [0x00000] 
> >   at System.Web.UI.Page.InternalProcessRequest () [0x00000] 
> >   at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext
> context) [0x00000] 
> > 
> > 
> > Thanks in advance! 
> > 
> > _______________________________________________ 
> > 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 immdiatement l'expditeur. 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 scurises, l'intgrit de
> ce 
> > message n'est pas assure et la socit mettrice ne peut tre tenue
> pour 
> > responsable de son contenu. 
> > _______________________________________________ 
> > Mono-devel-list mailing list 
> > Mono-devel-list at lists.ximian.com 
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
_______________________________________________
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/20070903/ff13f097/attachment.html 

From rook at roo.k.pl  Mon Sep  3 03:12:42 2007
From: rook at roo.k.pl (=?ISO-8859-2?Q?Micha=B3_Ziemski?=)
Date: Mon, 03 Sep 2007 09:12:42 +0200
Subject: [Mono-dev] Warnings in mono 1.2.5
Message-ID: <46DBB3EA.50408@roo.k.pl>

Hi!

I am running a vanilla mono 1.2.5 on Suse 10.0.
My app (Amazon S3 backup utility) occasionally (like 1 in 20 runs) 
produces warnings:

WARNING **: _wapi_thread_abandon_mutexes: error looking up thread handle 0x408
WARNING **: _wapi_thread_set_termination_details: error looking up thread handle (nil)

Despite the warnings, app works fine.
My app mostly uses synchronous HttpWebRequests, no threading.

Any ideas what might be the cause?
I considered filing a bug, but I cannot provide any simpe testcase yet,
so I decided to ask here first.

Cheers,
Micha? Ziemski



From pablosantosluac at terra.es  Mon Sep  3 04:00:08 2007
From: pablosantosluac at terra.es (pablosantosluac)
Date: Mon, 3 Sep 2007 10:00:08 +0200
Subject: [Mono-dev] Warnings in mono 1.2.5
References: <46DBB3EA.50408@roo.k.pl>
Message-ID: <17a301c7ee00$72966ca0$d501a8c0@beardtongue>

I've also seen these in previous releases...



----- Original Message ----- 
From: "Micha? Ziemski" <rook at roo.k.pl>
To: <mono-devel-list at lists.ximian.com>
Sent: Monday, September 03, 2007 9:12 AM
Subject: [Mono-dev] Warnings in mono 1.2.5


Hi!

I am running a vanilla mono 1.2.5 on Suse 10.0.
My app (Amazon S3 backup utility) occasionally (like 1 in 20 runs)
produces warnings:

WARNING **: _wapi_thread_abandon_mutexes: error looking up thread handle 
0x408
WARNING **: _wapi_thread_set_termination_details: error looking up thread 
handle (nil)

Despite the warnings, app works fine.
My app mostly uses synchronous HttpWebRequests, no threading.

Any ideas what might be the cause?
I considered filing a bug, but I cannot provide any simpe testcase yet,
so I decided to ask here first.

Cheers,
Micha? Ziemski

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list 



From informatique.internet at fiducial.fr  Mon Sep  3 04:07:28 2007
From: informatique.internet at fiducial.fr (Hubert FONGARNAND)
Date: Mon, 03 Sep 2007 10:07:28 +0200
Subject: [Mono-dev] ask for backport on mono 1.2.5 branch
In-Reply-To: <fb96e3$v50$1@sea.gmane.org>
References: <fb96e3$v50$1@sea.gmane.org>
Message-ID: <1188806848.3237.8.camel@hublinux.fidudev.fr>

Hi,

Ooops after further investigation, it seems that this fix is not enough
to fix this problem... I'm investigating to find out the  revision
number needed

Le vendredi 31 ao??t 2007 ?? 15:51 +0200, Robert Jordan a ??crit :

> Hi,
> 
> Hubert FONGARNAND wrote: 
> > In the actual release, a simple ASP.NET with a ListBox Control
> don't 
> > work, viewstate deserialization problem... 
> > 
> > This problem as been fixed in the trunk by : 
> > 
> > 2007-08-30 Igor Zelmanovich <igorz at mainsoft.com> 
> > 
> >         * ListControl.cs: fixed selected items state management.
> 
> It's r85048:
> 
> http://lists.ximian.com/pipermail/mono-patches/2007-August/099919.html
> 
> Robert
> 
> > 
> > Could this be backported to the mono 1.2.5 branch? 
> > 
> > 
> > Here's a test case for this problem : 
> > 
> > Default.aspx: 
> > <%@ Page Language="C#" Inherits="TestViewState.Default" %> 
> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
> > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 
> > <html> 
> > <head> 
> >       <title>Default</title> 
> > </head> 
> > <body> 
> >       <form id="form1" runat="server"> 
> >               <asp:Button id="button1" runat="server" /> 
> >               <asp:ListBox id="drpSociete" runat="server"
> CssClass="TextBox200" 
> > Width="200px" Visible="True" 
> >             Rows="1"></asp:ListBox> 
> >       </form> 
> > </body> 
> > </html> 
> > 
> > 
> > Default.aspx.cs : 
> > // Default.aspx.cs created with MonoDevelop 
> > // User: hubert at 15:02 31/08/2007 
> > // 
> > // To change standard headers go to
> Edit->Preferences->Coding->Standard 
> > Headers 
> > // 
> > 
> > using System; 
> > using System.Web; 
> > using System.Web.UI; 
> > using System.Web.UI.WebControls; 
> > using System.Data; 
> > 
> > namespace TestViewState 
> > { 
> >       
> >       
> >       public class Default : Page 
> >       { 
> >               protected ListBox drpSociete; 
> >               
> >               
> >               protected override void OnLoad(EventArgs e) 
> >               { 
> >                       if (!IsPostBack){ 
> >                               drpSociete.Items.Add("bouh"); 
> >                               drpSociete.Items.Add("bah"); 
> >                       } 
> >               } 
> >               
> >               
> >       } 
> > } 
> > 
> > 
> > Click two times on the button and you'll obtain : 
> > Server Error in '/' Application 
> > 
> >
> ________________________________________________________________________ 
> > 
> > Index is less than 0 or more than or equal to the list count.
> Parameter 
> > name: index 0 
> > 
> > Description: Error processing request. 
> > 
> > Error Message: HTTP 500. System.ArgumentOutOfRangeException: Index
> is 
> > less than 0 or more than or equal to the list count. Parameter
> name: 
> > index 0 
> > 
> > Stack Trace: 
> > 
> > System.ArgumentOutOfRangeException: Index is less than 0 or more
> than or equal to the list count. 
> > Parameter name: index 
> > 0 
> >   at System.Collections.ArrayList.get_Item (Int32 index) [0x00000] 
> >   at System.Web.UI.WebControls.ListItemCollection.get_Item (Int32
> index) [0x00000] 
> >   at System.Web.UI.WebControls.ListControl.LoadViewState
> (System.Object savedState) [0x00000] 
> >   at System.Web.UI.Control.LoadViewStateRecursive (System.Object
> savedState) [0x00000] 
> >   at System.Web.UI.Control.LoadViewStateRecursive (System.Object
> savedState) [0x00000] 
> >   at System.Web.UI.Control.LoadViewStateRecursive (System.Object
> savedState) [0x00000] 
> >   at System.Web.UI.Page.LoadPageViewState () [0x00000] 
> >   at System.Web.UI.Page.InternalProcessRequest () [0x00000] 
> >   at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext
> context) [0x00000] 
> > 
> > 
> > Thanks in advance! 
> > 
> > _______________________________________________ 
> > 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.
> 
> > 
> > 
> > 
> >
> ------------------------------------------------------------------------ 
> > 
> > _______________________________________________ 
> > 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
> 
_______________________________________________
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/20070903/304f6914/attachment.html 

From informatique.internet at fiducial.fr  Mon Sep  3 04:23:31 2007
From: informatique.internet at fiducial.fr (Hubert FONGARNAND)
Date: Mon, 03 Sep 2007 10:23:31 +0200
Subject: [Mono-dev] ask for backport on mono 1.2.5 branch
In-Reply-To: <1188806848.3237.8.camel@hublinux.fidudev.fr>
References: <1188806848.3237.8.camel@hublinux.fidudev.fr>
Message-ID: <1188807811.3237.11.camel@hublinux.fidudev.fr>

Ok, now i'm sure that the patch that correct the DropDownList viewstate
problem is this one :

http://lists.ximian.com/pipermail/mono-patches/2007-July/097650.html

+2007-07-26  Vladimir Krasnov  <vladimirk at mainsoft.com>

+
+	* ListItemCollection.cs: fixed LoadViewState, items restored from
+	viewstate were not saved, fixes bug #82192
+

it's r82779

Thanks in advance



Le lundi 03 septembre 2007 ?? 10:07 +0200, informatique internet a
??crit :

> Hi,
> 
> Ooops after further investigation, it seems that this fix is not
> enough to fix this problem... I'm investigating to find out the
> revision number needed
> 
> Le vendredi 31 ao??t 2007 ?? 15:51 +0200, Robert Jordan a ??crit :
> 
> > Hi,
> > 
> > Hubert FONGARNAND wrote: 
> > > In the actual release, a simple ASP.NET with a ListBox Control
> > don't 
> > > work, viewstate deserialization problem... 
> > > 
> > > This problem as been fixed in the trunk by : 
> > > 
> > > 2007-08-30 Igor Zelmanovich <igorz at mainsoft.com> 
> > > 
> > >         * ListControl.cs: fixed selected items state management.
> > 
> > It's r85048:
> > 
> > http://lists.ximian.com/pipermail/mono-patches/2007-August/099919.html
> > 
> > Robert
> > 
> > > 
> > > Could this be backported to the mono 1.2.5 branch? 
> > > 
> > > 
> > > Here's a test case for this problem : 
> > > 
> > > Default.aspx: 
> > > <%@ Page Language="C#" Inherits="TestViewState.Default" %> 
> > > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
> > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 
> > > <html> 
> > > <head> 
> > >       <title>Default</title> 
> > > </head> 
> > > <body> 
> > >       <form id="form1" runat="server"> 
> > >               <asp:Button id="button1" runat="server" /> 
> > >               <asp:ListBox id="drpSociete" runat="server"
> > CssClass="TextBox200" 
> > > Width="200px" Visible="True" 
> > >             Rows="1"></asp:ListBox> 
> > >       </form> 
> > > </body> 
> > > </html> 
> > > 
> > > 
> > > Default.aspx.cs : 
> > > // Default.aspx.cs created with MonoDevelop 
> > > // User: hubert at 15:02 31/08/2007 
> > > // 
> > > // To change standard headers go to
> > Edit->Preferences->Coding->Standard 
> > > Headers 
> > > // 
> > > 
> > > using System; 
> > > using System.Web; 
> > > using System.Web.UI; 
> > > using System.Web.UI.WebControls; 
> > > using System.Data; 
> > > 
> > > namespace TestViewState 
> > > { 
> > >       
> > >       
> > >       public class Default : Page 
> > >       { 
> > >               protected ListBox drpSociete; 
> > >               
> > >               
> > >               protected override void OnLoad(EventArgs e) 
> > >               { 
> > >                       if (!IsPostBack){ 
> > >                               drpSociete.Items.Add("bouh"); 
> > >                               drpSociete.Items.Add("bah"); 
> > >                       } 
> > >               } 
> > >               
> > >               
> > >       } 
> > > } 
> > > 
> > > 
> > > Click two times on the button and you'll obtain : 
> > > Server Error in '/' Application 
> > > 
> > >
> > ________________________________________________________________________ 
> > > 
> > > Index is less than 0 or more than or equal to the list count.
> > Parameter 
> > > name: index 0 
> > > 
> > > Description: Error processing request. 
> > > 
> > > Error Message: HTTP 500. System.ArgumentOutOfRangeException: Index
> > is 
> > > less than 0 or more than or equal to the list count. Parameter
> > name: 
> > > index 0 
> > > 
> > > Stack Trace: 
> > > 
> > > System.ArgumentOutOfRangeException: Index is less than 0 or more
> > than or equal to the list count. 
> > > Parameter name: index 
> > > 0 
> > >   at System.Collections.ArrayList.get_Item (Int32 index)
> > [0x00000] 
> > >   at System.Web.UI.WebControls.ListItemCollection.get_Item (Int32
> > index) [0x00000] 
> > >   at System.Web.UI.WebControls.ListControl.LoadViewState
> > (System.Object savedState) [0x00000] 
> > >   at System.Web.UI.Control.LoadViewStateRecursive (System.Object
> > savedState) [0x00000] 
> > >   at System.Web.UI.Control.LoadViewStateRecursive (System.Object
> > savedState) [0x00000] 
> > >   at System.Web.UI.Control.LoadViewStateRecursive (System.Object
> > savedState) [0x00000] 
> > >   at System.Web.UI.Page.LoadPageViewState () [0x00000] 
> > >   at System.Web.UI.Page.InternalProcessRequest () [0x00000] 
> > >   at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext
> > context) [0x00000] 
> > > 
> > > 
> > > Thanks in advance! 
> > > 
> > > _______________________________________________ 
> > > 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.
> > 
> > > 
> > > 
> > > 
> > >
> > ------------------------------------------------------------------------ 
> > > 
> > > _______________________________________________ 
> > > 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
> > 
> 
> _______________________________________________
> 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'expditeur. 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
curises, l'int???grit de
> ce message n'est pas assur
e et la socit??? mettrice ne peut tre tenue
> pour responsable de son contenu.
_______________________________________________
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/20070903/4d11130e/attachment.html 

From mbd at dbc.dk  Mon Sep  3 08:40:57 2007
From: mbd at dbc.dk (Mads Bondo Dydensborg)
Date: Mon, 3 Sep 2007 14:40:57 +0200
Subject: [Mono-dev] More ODBC questions: AutoCommit and BeginTransaction
Message-ID: <200709031440.57355.mbd@dbc.dk>

Hi all

I am not posting a bug, because I have no idea if this is a bug. Perhaps this 
is the intended way:

For ODBC connections, the default mode is "autocommit": Each statement is 
followed by an commit, done by the driver, client side. This can be disabled 
programmatically.

When an ODBC transaction is created in mono, we change the attributes in 
OdbcTransaction.cs:

     51                 internal OdbcTransaction(OdbcConnection conn, 
IsolationLevel isolationlevel)
     52                 {
     53                         // Set Auto-commit (102) to false
     54                         OdbcReturn 
ret=libodbc.SQLSetConnectAttr(conn.hDbc, OdbcConnectionAttribute.AutoCommit, 
IntPtr.Zero, 0);

We have to do that, obviously, but my question is wheter mono should 
reestablish the state of autocommit upon completion of the transaction? 
Currently it does not, but is this to be expected? I think, from my reading 
that it is, but would very much like a confirmation.

Currently I am not able to check out the behavoiur using MS .NET.

Thanks,

Regards

Mads

-- 
Med venlig hilsen/Regards

Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg
Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34



From olivier.duff at gmail.com  Mon Sep  3 10:00:10 2007
From: olivier.duff at gmail.com (olivier dufour)
Date: Mon, 3 Sep 2007 16:00:10 +0200
Subject: [Mono-dev] class status
Message-ID: <d74c39240709030700w312958d9x49bce5cea7dbe168@mail.gmail.com>

Hi all,

Just a small thing to do :
May someone change in the xml of the status for the svn
from
http://svn.myrealbox.com/viewcvs/trunk
to
http://anonsvn.mono-project.com/viewcvs/trunk/

because when we do ctrl+click on the class status page we have error.
There is another issue because the winform adresse is
Managed.winformswhereas must be
System.winforms.
But not sure that it is solvable.

thanks,
bye
Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070903/aadd1e6d/attachment.html 

From xaviblas at gmail.com  Mon Sep  3 11:35:09 2007
From: xaviblas at gmail.com (Xavi de Blas)
Date: Mon, 3 Sep 2007 17:35:09 +0200
Subject: [Mono-dev] [System.IO.Ports] How to configure the serial port?
Message-ID: <256a87490709030835l56699dceh7acb1cf24b72ced7@mail.gmail.com>

Hello all! i just subscribed the list, this post is related to:
http://lists.ximian.com/pipermail/mono-devel-list/2007-August/024670.html

Take a look at chronojump code:
http://gnome.org/projects/chronojump
http://svn.gnome.org/viewcvs/chronojump/trunk/

specially:

chronopic.cs
library that connects to the chronopic (serial port)
http://svn.gnome.org/viewcvs/chronojump/trunk/chronopic.cs

chronojump_mini.cs
little terminal software that gets data from serial port using chronopic.cs
http://svn.gnome.org/viewcvs/chronojump/trunk/src/chronojump_mini.cs

I hope it helps, bye


From miguel at novell.com  Mon Sep  3 12:29:09 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Mon, 03 Sep 2007 12:29:09 -0400
Subject: [Mono-dev] class status
In-Reply-To: <d74c39240709030700w312958d9x49bce5cea7dbe168@mail.gmail.com>
References: <d74c39240709030700w312958d9x49bce5cea7dbe168@mail.gmail.com>
Message-ID: <1188836949.13903.185.camel@erandi.dom>

Hello,

> Just a small thing to do :
> May someone change in the xml of the status for the svn
> from 
> http://svn.myrealbox.com/viewcvs/trunk
> to
> http://anonsvn.mono-project.com/viewcvs/trunk/

This should soon be taken care of.

Miguel.


From LuisOrtiz at Verizon.Net  Mon Sep  3 14:48:22 2007
From: LuisOrtiz at Verizon.Net (Luis F. Ortiz)
Date: Mon, 03 Sep 2007 14:48:22 -0400
Subject: [Mono-dev] Big Arrays, Many Changes --- Request for Advice
In-Reply-To: <1188836949.13903.185.camel@erandi.dom>
References: <d74c39240709030700w312958d9x49bce5cea7dbe168@mail.gmail.com>
	<1188836949.13903.185.camel@erandi.dom>
Message-ID: <23DC1397-F948-467C-BB89-0E1D00665E66@Verizon.Net>

Folks:

I was porting a small test application that was written in C# that  
allocated
an array with a large number of elements (> 2^32).  While it   
compiled and ran
in Visual Studio's C# under WindowsXP-64bit without a hitch, when I  
compiled
and ran it under mcs/mono (1.2.4) on the same hardware, but booted up  
under
Fedora7-x86_64, I ran into a few problems.

Digging into it a bit, I discovered that:

1)  MCS assumed that the arguments to NEWARR were always U4 or I4,  
which does not seem
     to be the case as far as ECMA-335v4.
2)  MONO assumes that array lengths and bounds can always be  
represented as guint32's,
     [ like mono_array_new_specific (MonoVTable *vtable, guint32 n) ]


Would folks object to a series of patches to:

A)  Fix mcs/expression.cs to emit OpCodes.Conv_Ovf_U/I instead of  
OpCodes.Conv_Ovf_U4/I4
     for array size arguments,
B)  Modify mono/metadata/object.h to change the base type for array  
lengths/bounds to
     XXX instead of guint32,
C)  Change mono/metadata/object.c to change the functions that create/ 
access arrays to
     take XXX instead of guint32 length/bounds arguments.  Also  
perhaps update some of
     the lower level object allocation functions to use XXX as needed.
D)  Modify the execution of NEWARR be able to deal with I/U native  
types.  No doubt something
     in the JIT needs tweaking as well.
E)  Double check that array indexing not only takes native int types,  
but uses them right.
F)  Add a few new test cases for large array allocation.
G)  Whatever else needs to be done that I'll bump into after I try  
making the above changes
     and realize what I forgot.  Warnings of known hazards gratefully  
accepted.

My big question is what the right type for the size ought to be?   
I've seen int, size_t, gsize,
and guint32 used in Mono.  I suspect that int and guint32 are wrong  
from a portability perspective,
but would prefer that someone more intimately involved with Mono to  
say if guint or gsize or size_t
were preferred. I'm guessing Bug 81774 is related to this as well.

BTW, is this too big for a newby to tackle?

--Luis F. Ortiz
Follower of the "Selfish Way"


From joncham at gmail.com  Mon Sep  3 17:26:17 2007
From: joncham at gmail.com (Jonathan Chambers)
Date: Mon, 3 Sep 2007 17:26:17 -0400
Subject: [Mono-dev] Big Arrays, Many Changes --- Request for Advice
In-Reply-To: <23DC1397-F948-467C-BB89-0E1D00665E66@Verizon.Net>
References: <d74c39240709030700w312958d9x49bce5cea7dbe168@mail.gmail.com>
	<1188836949.13903.185.camel@erandi.dom>
	<23DC1397-F948-467C-BB89-0E1D00665E66@Verizon.Net>
Message-ID: <17c2d80b0709031426o6c9b2b04n920d2fb17719a2a3@mail.gmail.com>

Hello,

I don't have an answer to your problem, but I did have another question. I
can't find a link to the documentation in msdn, but I thought arrays were
limited to 2 GB in the .Net runtime (even on 64-bit). Do you not see this
behavior?

http://blogs.msdn.com/joshwil/archive/2005/08/10/450202.aspx

Thanks,
Jonathan

On 9/3/07, Luis F. Ortiz <LuisOrtiz at verizon.net> wrote:
>
> Folks:
>
> I was porting a small test application that was written in C# that
> allocated
> an array with a large number of elements (> 2^32).  While it
> compiled and ran
> in Visual Studio's C# under WindowsXP-64bit without a hitch, when I
> compiled
> and ran it under mcs/mono (1.2.4) on the same hardware, but booted up
> under
> Fedora7-x86_64, I ran into a few problems.
>
> Digging into it a bit, I discovered that:
>
> 1)  MCS assumed that the arguments to NEWARR were always U4 or I4,
> which does not seem
>      to be the case as far as ECMA-335v4.
> 2)  MONO assumes that array lengths and bounds can always be
> represented as guint32's,
>      [ like mono_array_new_specific (MonoVTable *vtable, guint32 n) ]
>
>
> Would folks object to a series of patches to:
>
> A)  Fix mcs/expression.cs to emit OpCodes.Conv_Ovf_U/I instead of
> OpCodes.Conv_Ovf_U4/I4
>      for array size arguments,
> B)  Modify mono/metadata/object.h to change the base type for array
> lengths/bounds to
>      XXX instead of guint32,
> C)  Change mono/metadata/object.c to change the functions that create/
> access arrays to
>      take XXX instead of guint32 length/bounds arguments.  Also
> perhaps update some of
>      the lower level object allocation functions to use XXX as needed.
> D)  Modify the execution of NEWARR be able to deal with I/U native
> types.  No doubt something
>      in the JIT needs tweaking as well.
> E)  Double check that array indexing not only takes native int types,
> but uses them right.
> F)  Add a few new test cases for large array allocation.
> G)  Whatever else needs to be done that I'll bump into after I try
> making the above changes
>      and realize what I forgot.  Warnings of known hazards gratefully
> accepted.
>
> My big question is what the right type for the size ought to be?
> I've seen int, size_t, gsize,
> and guint32 used in Mono.  I suspect that int and guint32 are wrong
> from a portability perspective,
> but would prefer that someone more intimately involved with Mono to
> say if guint or gsize or size_t
> were preferred. I'm guessing Bug 81774 is related to this as well.
>
> BTW, is this too big for a newby to tackle?
>
> --Luis F. Ortiz
> Follower of the "Selfish Way"
> _______________________________________________
> 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/20070903/0fe4261f/attachment.html 

From cetin.sert at gmail.com  Mon Sep  3 22:10:42 2007
From: cetin.sert at gmail.com (Cetin Sert)
Date: Tue, 4 Sep 2007 04:10:42 +0200
Subject: [Mono-dev] Mono 1.2.5 for Solaris 10/x86 binaries
Message-ID: <46dcbef7.201f5e0a.14d0.3819@mx.google.com>

Hi,

 

I have made available for download Mono 1.2.5 for Solaris 10/x86 binaries
at:

 

http://tenkatext.sourceforge.net/redist/mono-1.2.5-solaris-10-x86-binary.tar
.gz

http://tenkatext.blogspot.com

 

I would love to collaborate with the Mono team on maintaining similar binary
packages for future versions too.

 

Best Regards,

Cetin Sert

INF 521, 4-6-2

69120 Heidelberg

Germany

 

http://tenkatext.sourceforge.net/contact

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070904/0afaafff/attachment.html 

From ecanuto at novell.com  Tue Sep  4 04:21:19 2007
From: ecanuto at novell.com (Everaldo Canuto)
Date: Tue, 4 Sep 2007 05:21:19 -0300
Subject: [Mono-dev] MWF Status report
Message-ID: <270f2c6b0709040121t2f3e7193kecb8cf7879848b1d@mail.gmail.com>

Hi all,

As promised, attached a OpenOffice Calc spreadsheet with details about
MWF bug status, this week I also implemented a comparison with last
week.

I also would like to propose one "bug hunt week" on winforms, so
instead of implement new functionalities we can use this week to fix
bugs and try to reduce our queue. Maybe start on easy (fast) bugs.

We have a lot of bugs assigned to people that is working now on
Moonlight or assigned to people that is not current working on bug. So
will be nice if we assign this bugs to "mono-bugs at ximian.com" (I
already done it with my owns).

Theres also some bugs marked as "NEEDINFO" if you are creator of one
of this bugs please give us some feedback, maybe it is already
working.


Thanks,
Everaldo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mwf-2007-09-01.ods
Type: application/vnd.oasis.opendocument.spreadsheet
Size: 29911 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070904/5e84b808/attachment.bin 

From everaldo.canuto at gmail.com  Tue Sep  4 04:22:06 2007
From: everaldo.canuto at gmail.com (Everaldo Canuto)
Date: Tue, 4 Sep 2007 05:22:06 -0300
Subject: [Mono-dev] MWF Status report
Message-ID: <270f2c6b0709040122w5e9dc2f2vfc6a6b2edadd9c52@mail.gmail.com>

Hi all,

As promised, attached a OpenOffice Calc spreadsheet with details about
MWF bug status, this week I also implemented a comparison with last
week.

I also would like to propose one "bug hunt week" on winforms, so
instead of implement new functionalities we can use this week to fix
bugs and try to reduce our queue. Maybe start on easy (fast) bugs.

We have a lot of bugs assigned to people that is working now on
Moonlight or assigned to people that is not current working on bug. So
will be nice if we assign this bugs to "mono-bugs at ximian.com" (I
already done it with my owns).

Theres also some bugs marked as "NEEDINFO" if you are creator of one
of this bugs please give us some feedback, maybe it is already
working.


Thanks,
Everaldo.


From everaldo.canuto at gmail.com  Tue Sep  4 04:24:12 2007
From: everaldo.canuto at gmail.com (Everaldo Canuto)
Date: Tue, 4 Sep 2007 05:24:12 -0300
Subject: [Mono-dev] MWF Status report
In-Reply-To: <270f2c6b0709040122w5e9dc2f2vfc6a6b2edadd9c52@mail.gmail.com>
References: <270f2c6b0709040122w5e9dc2f2vfc6a6b2edadd9c52@mail.gmail.com>
Message-ID: <270f2c6b0709040124u7c94cbadxdd69e8fdce4448cd@mail.gmail.com>

Attachment.

On 9/4/07, Everaldo Canuto <everaldo.canuto at gmail.com> wrote:
> Hi all,
>
> As promised, attached a OpenOffice Calc spreadsheet with details about
> MWF bug status, this week I also implemented a comparison with last
> week.
>
> I also would like to propose one "bug hunt week" on winforms, so
> instead of implement new functionalities we can use this week to fix
> bugs and try to reduce our queue. Maybe start on easy (fast) bugs.
>
> We have a lot of bugs assigned to people that is working now on
> Moonlight or assigned to people that is not current working on bug. So
> will be nice if we assign this bugs to "mono-bugs at ximian.com" (I
> already done it with my owns).
>
> Theres also some bugs marked as "NEEDINFO" if you are creator of one
> of this bugs please give us some feedback, maybe it is already
> working.
>
>
> Thanks,
> Everaldo.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mwf-2007-09-01.ods
Type: application/vnd.oasis.opendocument.spreadsheet
Size: 29911 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070904/e824b6a7/attachment.bin 

From olivier.duff at gmail.com  Tue Sep  4 05:12:09 2007
From: olivier.duff at gmail.com (olivier dufour)
Date: Tue, 4 Sep 2007 11:12:09 +0200
Subject: [Mono-dev]  MWF Status report
Message-ID: <d74c39240709040212n7f73b57apf60584e715d085fc@mail.gmail.com>

Hi all,

I have just put the document attachment.bin on google spreadsheet to allow
people to read it easily.
You can see it here :

http://spreadsheets.google.com/ccc?key=pGyiJ8QsIX7CXwDRqEygnYQ&hl=fr
bye,
olivier dufour
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070904/6b8d1320/attachment.html 

From everaldo.canuto at gmail.com  Tue Sep  4 05:38:20 2007
From: everaldo.canuto at gmail.com (Everaldo Canuto)
Date: Tue, 4 Sep 2007 06:38:20 -0300
Subject: [Mono-dev] MWF Status report
In-Reply-To: <d74c39240709040212n7f73b57apf60584e715d085fc@mail.gmail.com>
References: <d74c39240709040212n7f73b57apf60584e715d085fc@mail.gmail.com>
Message-ID: <270f2c6b0709040238l7b405a3fw136fa46906d3dcbc@mail.gmail.com>

Hi,

I just add a flat version since Google docs don't show functions
properly. Next weeks I will make plain version and import on Google
docs.

You can see it here:

   http://spreadsheets0.google.com/ccc?key=pNj_nZBoo-7G0KVgtYrK-IA&hl=pt_BR

Everaldo.

On 9/4/07, olivier dufour <olivier.duff at gmail.com> wrote:
> Hi all,
>
> I have just put the document attachment.bin on google spreadsheet to allow
> people to read it easily.
> You can see it here :
>
>
> http://spreadsheets.google.com/ccc?key=pGyiJ8QsIX7CXwDRqEygnYQ&hl=fr
> bye,
> olivier dufour
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>


From marek.safar at seznam.cz  Tue Sep  4 06:51:02 2007
From: marek.safar at seznam.cz (Marek Safar)
Date: Tue, 04 Sep 2007 11:51:02 +0100
Subject: [Mono-dev] Big Arrays, Many Changes --- Request for Advice
In-Reply-To: <23DC1397-F948-467C-BB89-0E1D00665E66@Verizon.Net>
References: <d74c39240709030700w312958d9x49bce5cea7dbe168@mail.gmail.com>	<1188836949.13903.185.camel@erandi.dom>
	<23DC1397-F948-467C-BB89-0E1D00665E66@Verizon.Net>
Message-ID: <46DD3896.9030106@seznam.cz>

Hi Luis,
> I was porting a small test application that was written in C# that  
> allocated
> an array with a large number of elements (> 2^32).  While it   
> compiled and ran
> in Visual Studio's C# under WindowsXP-64bit without a hitch, when I  
> compiled
> and ran it under mcs/mono (1.2.4) on the same hardware, but booted up  
> under
> Fedora7-x86_64, I ran into a few problems.
>
> Digging into it a bit, I discovered that:
>
> 1)  MCS assumed that the arguments to NEWARR were always U4 or I4,  
> which does not seem
>      to be the case as far as ECMA-335v4.
> 2)  MONO assumes that array lengths and bounds can always be  
> represented as guint32's,
>      [ like mono_array_new_specific (MonoVTable *vtable, guint32 n) ]
>
>
> Would folks object to a series of patches to:
>
> A)  Fix mcs/expression.cs to emit OpCodes.Conv_Ovf_U/I instead of  
> OpCodes.Conv_Ovf_U4/I4
>      for array size arguments,
>   

Any mcs patches with self contained tests are welcome. However,
I think I fix this issue 2-3 weeks ago. Please use SVN version instead.

Thanks
Marek


From valentin.sawadski at gmx.de  Tue Sep  4 10:29:53 2007
From: valentin.sawadski at gmx.de (Valentin Sawadski)
Date: Tue, 04 Sep 2007 16:29:53 +0200
Subject: [Mono-dev] Could this be a bug in gmcs?
In-Reply-To: <46D80361.1090901@seznam.cz>
References: <1188559792.10078.9.camel@pi1536.local>
	<46D80361.1090901@seznam.cz>
Message-ID: <1188916193.28980.1.camel@pi1536.local>

Hello,

I updated Mono from SVN today and tried to compile NClass again, the bug
still exists however the error message has been slightly different so
that I could now extract a location where the Exception seems to come
from.

All this is in bugzilla at no 82690.

Kind Regards,
Valentin S.

On Fri, 2007-08-31 at 13:02 +0100, Marek Safar wrote:
> Hello Valentin,
> > I've tried to port NClass to Mono and ran into a very odd error message:
> >   
> Yes, it looks like gmcs bug. Please fill a bug report into 
> http://bugzilla.ximian.com
> with as small test case as possible.
> 
> Thanks
> Marek



From marek.safar at seznam.cz  Tue Sep  4 10:44:47 2007
From: marek.safar at seznam.cz (Marek Safar)
Date: Tue, 04 Sep 2007 15:44:47 +0100
Subject: [Mono-dev] Could this be a bug in gmcs?
In-Reply-To: <1188916193.28980.1.camel@pi1536.local>
References: <1188559792.10078.9.camel@pi1536.local>	
	<46D80361.1090901@seznam.cz>
	<1188916193.28980.1.camel@pi1536.local>
Message-ID: <46DD6F5F.40907@seznam.cz>

Hi,
> All this is in bugzilla at no 82690.
>   
Thanks !
Marek
> On Fri, 2007-08-31 at 13:02 +0100, Marek Safar wrote:
>   
>> Hello Valentin,
>>     
>>> I've tried to port NClass to Mono and ran into a very odd error message:
>>>   
>>>       
>> Yes, it looks like gmcs bug. Please fill a bug report into 
>> http://bugzilla.ximian.com
>> with as small test case as possible.
>>
>> Thanks
>> Marek
>>     
>
>
>   



From js at hotfeet.ch  Tue Sep  4 13:50:54 2007
From: js at hotfeet.ch (Juraj Skripsky)
Date: Tue, 04 Sep 2007 19:50:54 +0200
Subject: [Mono-dev] Assembly.GetType() leaks with generic types
Message-ID: <1188928254.3290.31.camel@leonardo.hotfeet.ch>

This is bug http://bugzilla.ximian.com/show_bug.cgi?id=82695. I'm
posting it here because it never made it to the list (mono-bugs).
Bugzilla doesn't like me :-(.


Test Case:
==========

using System;
using System.Reflection;

namespace TestApp {
  public class Test<T> {} 

  class Program {
    static void Main(string[] args) {
      Assembly assembly = typeof(Program).Assembly;

      int runs = int.Parse(args[0]);
      for(int i = 0; i < runs; i++) {
        assembly.GetType (
          "TestApp.Test`1[[System.Object, mscorlib, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089]]",
          true
        );
      }
    }
  }
}

Run "mono test.exe 2000000" and watch the mono process grow to over 300MB.
I'm using Mono from SVN.


- Juraj



From kumpera at gmail.com  Tue Sep  4 15:00:00 2007
From: kumpera at gmail.com (Rodrigo Kumpera)
Date: Tue, 4 Sep 2007 16:00:00 -0300
Subject: [Mono-dev] Assembly.GetType() leaks with generic types
In-Reply-To: <1188928254.3290.31.camel@leonardo.hotfeet.ch>
References: <1188928254.3290.31.camel@leonardo.hotfeet.ch>
Message-ID: <8cca42d80709041200t4623443byd43a45b2f0a31199@mail.gmail.com>

Hi Juraj,

I've posted a patch in the bug report.

Cheers,
Rodrigo


On 9/4/07, Juraj Skripsky <js at hotfeet.ch> wrote:
>
> This is bug http://bugzilla.ximian.com/show_bug.cgi?id=82695. I'm
> posting it here because it never made it to the list (mono-bugs).
> Bugzilla doesn't like me :-(.
>
>
> Test Case:
> ==========
>
> using System;
> using System.Reflection;
>
> namespace TestApp {
>   public class Test<T> {}
>
>   class Program {
>     static void Main(string[] args) {
>       Assembly assembly = typeof(Program).Assembly;
>
>       int runs = int.Parse(args[0]);
>       for(int i = 0; i < runs; i++) {
>         assembly.GetType (
>           "TestApp.Test`1[[System.Object, mscorlib, Version=2.0.0.0,
> Culture=neutral, PublicKeyToken=b77a5c561934e089]]",
>           true
>         );
>       }
>     }
>   }
> }
>
> Run "mono test.exe 2000000" and watch the mono process grow to over 300MB.
> I'm using Mono from SVN.
>
>
> - Juraj
>
> _______________________________________________
> 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/20070904/b37756ae/attachment.html 

From js at hotfeet.ch  Tue Sep  4 17:45:00 2007
From: js at hotfeet.ch (Juraj Skripsky)
Date: Tue, 04 Sep 2007 23:45:00 +0200
Subject: [Mono-dev] Assembly.GetType() leaks with generic types
In-Reply-To: <8cca42d80709041200t4623443byd43a45b2f0a31199@mail.gmail.com>
References: <1188928254.3290.31.camel@leonardo.hotfeet.ch>
	<8cca42d80709041200t4623443byd43a45b2f0a31199@mail.gmail.com>
Message-ID: <1188942300.3475.0.camel@funnyfarm.hotfeet.ch>

Hi Rodrigo,

Thanks, I applied the patch, but I'm still seeing a leak.

There must be another leak, which accounts for ~150 bytes lost after
each invocation of Assembly.GetType().

-Juraj


On Tue, 2007-09-04 at 16:00 -0300, Rodrigo Kumpera wrote:
> Hi Juraj,
> 
> I've posted a patch in the bug report.
> 
> Cheers,
> Rodrigo
> 
> 
> On 9/4/07, Juraj Skripsky <js at hotfeet.ch> wrote:
>         This is bug http://bugzilla.ximian.com/show_bug.cgi?id=82695.
>         I'm
>         posting it here because it never made it to the list
>         (mono-bugs).
>         Bugzilla doesn't like me :-(.
>         
>         
>         Test Case:
>         ==========
>         
>         using System; 
>         using System.Reflection;
>         
>         namespace TestApp {
>           public class Test<T> {}
>         
>           class Program {
>             static void Main(string[] args) {
>               Assembly assembly = typeof(Program).Assembly;
>         
>               int runs = int.Parse(args[0]);
>               for(int i = 0; i < runs; i++) {
>                 assembly.GetType (
>                   "TestApp.Test`1[[System.Object, mscorlib,
>         Version=2.0.0.0,
>         Culture=neutral, PublicKeyToken=b77a5c561934e089]]", 
>                   true
>                 );
>               }
>             }
>           }
>         }
>         
>         Run "mono test.exe 2000000" and watch the mono process grow to
>         over 300MB.
>         I'm using Mono from SVN.
>         
>         
>         - Juraj
>         
>         _______________________________________________ 
>         Mono-devel-list mailing list
>         Mono-devel-list at lists.ximian.com
>         http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 



From grendello at gmail.com  Tue Sep  4 19:03:09 2007
From: grendello at gmail.com (Marek Habersack)
Date: Wed, 5 Sep 2007 01:03:09 +0200
Subject: [Mono-dev] [PATCH] AppDomain.AssemblyResolve event differences
 between Mono and MS.NET
Message-ID: <20070905010309.0789937f@quantum.thanes.org>

Hello everybody,

  Running the attached test program on Mono and MS.NET shows that there are
differences in the way we generate the event. MS.NET calls the handler only
with the assembly name passed to the Assembly.Load* methods while Mono takes an
extra step to call the handler with a fake full assembly name. Also,
Assembly.LoadWithPartialName generates the event on MS.NET but not on Mono. The
attached patch makes Mono behave the same way what MS.NET. Please review,

marek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asm_resolve_tests.cs
Type: text/x-csharp
Size: 1862 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070905/a17bfb9c/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: assemblyresolve_event.diff
Type: text/x-patch
Size: 3868 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070905/a17bfb9c/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070905/a17bfb9c/attachment-0002.bin 

From LuisOrtiz at Verizon.Net  Tue Sep  4 19:32:10 2007
From: LuisOrtiz at Verizon.Net (Luis F. Ortiz)
Date: Tue, 04 Sep 2007 19:32:10 -0400
Subject: [Mono-dev] Big Arrays, Many Changes --- Request for Advice
In-Reply-To: <46DD3896.9030106@seznam.cz>
References: <d74c39240709030700w312958d9x49bce5cea7dbe168@mail.gmail.com>
	<1188836949.13903.185.camel@erandi.dom>
	<23DC1397-F948-467C-BB89-0E1D00665E66@Verizon.Net>
	<46DD3896.9030106@seznam.cz>
Message-ID: <845FCC35-0F4B-488C-ACE8-D59157528FAB@Verizon.Net>

On Sep 4, 2007, at 6:51 AM, Marek Safar wrote:
> Hi Luis,
>> 1)  MCS assumed that the arguments to NEWARR were always U4 or I4,
>> which does not seem
>>      to be the case as far as ECMA-335v4.
>> ...
>> A)  Fix mcs/expression.cs to emit OpCodes.Conv_Ovf_U/I instead of
>> OpCodes.Conv_Ovf_U4/I4
>>      for array size arguments,
> Any mcs patches with self contained tests are welcome. However,
> I think I fix this issue 2-3 weeks ago. Please use SVN version  
> instead.

I see you did do serious surgery to the code in question in revision  
84357.
I have a question: ?How literally should ECMA-335 be taken?
If one were to take section 4.20 (newarr ? create a zero-based, one- 
dimensional array)
literally:

     Valid array indexes are 0 <= index < numElems. ...
     Verifiability:  .numElems shall be of type native int or int32.

then I would be inclined to say some work might still be necessary.
The implication would be that unsigned arguments are not proper and that
a 32 bit implementation should be limited to 2^32 - 1 elements.

So perhaps uint32_type's should be converted via Conv_Ovf_I4,
and uint64_type's via Conv_Ovf_I.

But at least now there is only one method to change, though I suspect  
it will take
more than a few minutes for me to get the SVN version to compile from  
scratch.

--Luis F. Ortiz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: EmitArray.diff
Type: application/octet-stream
Size: 606 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070904/5737011f/attachment.obj 

From jeroen at sumatra.nl  Wed Sep  5 01:12:03 2007
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Wed, 5 Sep 2007 07:12:03 +0200
Subject: [Mono-dev] Big Arrays, Many Changes --- Request for Advice
In-Reply-To: <845FCC35-0F4B-488C-ACE8-D59157528FAB@Verizon.Net>
References: <d74c39240709030700w312958d9x49bce5cea7dbe168@mail.gmail.com>
	<1188836949.13903.185.camel@erandi.dom>
	<23DC1397-F948-467C-BB89-0E1D00665E66@Verizon.Net>
	<46DD3896.9030106@seznam.cz>
	<845FCC35-0F4B-488C-ACE8-D59157528FAB@Verizon.Net>
Message-ID: <B866D2B6BBAAAD44B1D109ED50EE131E2AB22CFF64@jambi.sumatrasoftware.com>

Luis F. Ortiz wrote:
> On Sep 4, 2007, at 6:51 AM, Marek Safar wrote:
> > Hi Luis,
> >> 1)  MCS assumed that the arguments to NEWARR were always U4 or I4,
> >> which does not seem
> >>      to be the case as far as ECMA-335v4.
> >> ...
> >> A)  Fix mcs/expression.cs to emit OpCodes.Conv_Ovf_U/I instead of
> >> OpCodes.Conv_Ovf_U4/I4
> >>      for array size arguments,
> > Any mcs patches with self contained tests are welcome. However, I
> > think I fix this issue 2-3 weeks ago. Please use SVN version instead.
>
> I see you did do serious surgery to the code in question in revision
> 84357.
> I have a question: ?How literally should ECMA-335 be taken?
> If one were to take section 4.20 (newarr - create a zero-based, one-
> dimensional array)
> literally:
>
>      Valid array indexes are 0 <= index < numElems. ...
>      Verifiability:  .numElems shall be of type native int or int32.
>
> then I would be inclined to say some work might still be necessary.
> The implication would be that unsigned arguments are not proper and
> that a 32 bit implementation should be limited to 2^32 - 1 elements.

No. The verifier doesn't care about signed vs. unsigned. So the above quote really means "native [u]int or [u]int32". For details see the section "Verification Types" in the ECMA CLI spec.

Regards,
Jeroen



From kostat at mainsoft.com  Wed Sep  5 01:59:07 2007
From: kostat at mainsoft.com (Konstantin Triger)
Date: Tue, 4 Sep 2007 22:59:07 -0700
Subject: [Mono-dev] Proposed Extension to System.Web.Script.Serialization
In-Reply-To: <24A95FFF-8E72-47C1-A2F0-E0D691C8DB88@monkeypox.org>
References: <24A95FFF-8E72-47C1-A2F0-E0D691C8DB88@monkeypox.org>
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D0466A26E@dhost002-45.dex002.intermedia.net>

Hello Tyler,

I'm not sure this extension is required:
1. There is already a mechanism for overriding the default
de/serialization behavior by using TypeConverter (as you say in (b) ).
2. Ability to change names is usually less important for JSON
serialization, since a developer controls both, the server code and the
client side script.

Can you please provide a generic use case for need of this extension?

Regards,
Kosta

> -----Original Message-----
> From: R. Tyler Ballance [mailto:tyler at monkeypox.org]
> Sent: Monday, September 03, 2007 5:45 AM
> To: mono-devel-list at lists.ximian.com
> Cc: Igor Zelmanovich; Konstantin Triger
> Subject: Proposed Extension to System.Web.Script.Serialization
> 
> Firstly, I'm so glad we have System.Web.Script.Serialization now,
woot!
> 
> The one major thing missing from JSON serialization (contrasted to
> XML serialization) is the ability to tell the serializer how to
> serialize out your object's attributes, in terms of names. I asked
> James Newton-King about this for Json.NET and he forwarded me a
> modified version of Json.NET that allowed such a beast and I've
> ported it over to our System.Web.Script.Serialization, the only thing
> holding me from committing it is:
> 	a) Permission from Igor and Konstantin
> 	b) The fact that .NET doesn't actually define something like
this in
> their API
> 
> Executing my little test application (attached: JsonTest.cs), my
> "Message" property is serialized out under a different name (insanely
> helpful when dealing with existing JSON APIs and code)
> 
> 
> > [mono] \w @ mono JsonTest.exe
> > Serializing TestClass out as: {"my_magic_message":"magic!"}
> 
> 
> Attached is the cumulative patch for mcs/class/System.Web.Extensions/
> System.Web.Script.Serialization, I'd like some review and permission
> to go ahead and commit it :D
> 
> (patch diffed against rev 85204)
> 
> Cheers,
> -R. Tyler Ballance



From robertj at gmx.net  Wed Sep  5 05:37:16 2007
From: robertj at gmx.net (Robert Jordan)
Date: Wed, 05 Sep 2007 11:37:16 +0200
Subject: [Mono-dev] Big Arrays, Many Changes --- Request for Advice
In-Reply-To: <845FCC35-0F4B-488C-ACE8-D59157528FAB@Verizon.Net>
References: <d74c39240709030700w312958d9x49bce5cea7dbe168@mail.gmail.com>	<1188836949.13903.185.camel@erandi.dom>	<23DC1397-F948-467C-BB89-0E1D00665E66@Verizon.Net>	<46DD3896.9030106@seznam.cz>
	<845FCC35-0F4B-488C-ACE8-D59157528FAB@Verizon.Net>
Message-ID: <fbltcj$4hk$1@sea.gmane.org>

Luis F. Ortiz wrote:
> But at least now there is only one method to change, though I suspect it 
> will take
> more than a few minutes for me to get the SVN version to compile from 
> scratch.

The big array support leads to an API breakage on 64 systems:

Unlike other API structs, MonoArray's internals are publicly exposed
by macros. Since its "max_length" member has to be extended to 64 bit,
the ABI will change and all applications using libmono have to be
recompiled.

IMO, this cannot be done before Mono 2.0, especially when the benefits
are so tiny, but feel free to provide patches.

Robert



From dban at dako.ro  Wed Sep  5 05:56:24 2007
From: dban at dako.ro (Dumitru Ban)
Date: Wed, 5 Sep 2007 12:56:24 +0300
Subject: [Mono-dev] MailDefinition patch
References: <003201c7a1c9$6cc09f90$f265a8c0@laptopdban><015f01c7b981$b682be90$f265a8c0@laptopdban><DA63C6E8B207E748B20D46DFED7B772D813ABF@dhost002-45.dex002.intermedia.net>
	<007c01c7df1a$7485ad90$f265a8c0@laptopdban>
Message-ID: <004101c7efa3$05986690$f265a8c0@laptopdban>

RE: [Mono-dev] MailDefinition patchHi,

Is anyone reviewing and applying this patch?

Thanks & best regards,
Dumi.
  ----- Original Message ----- 
  From: Dumitru Ban 
  To: Konstantin Triger ; mono-devel-list at lists.ximian.com 
  Sent: Wednesday, August 15, 2007 11:58 AM
  Subject: Re: [Mono-dev] MailDefinition patch


  Hi,

  Attached is a patch for the problem described below. Please review and apply it.

  Thanks & best regards,
  Dumi.
    ----- Original Message ----- 
    From: Konstantin Triger 
    To: Dumitru Ban ; mono-devel-list at lists.ximian.com 
    Sent: Saturday, June 30, 2007 8:07 PM
    Subject: RE: [Mono-dev] MailDefinition patch


    Hey Dumi,

    I would suggest looking into some code in Sys.Web, which has similar issues, i.e. XmlSiteMapProvider. It loads its data from the file and probably solves the problems you face. If appropriate, you may consider refactoring and using same functions for file loading for both cases.

    Regarding permissions (or any other IO problem), I think, the relevant exception should be thrown (nothing special needs to be done, the exception will be thrown when the file will be accessed). As usual, you may verify this by creating similar conditions on MS .net.

    Regards,
    Konstantin Triger



    -----Original Message-----
    From: mono-devel-list-bounces at lists.ximian.com on behalf of Dumitru Ban
    Sent: Thu 6/28/2007 15:41
    To: mono-devel-list at lists.ximian.com
    Subject: Re: [Mono-dev] MailDefinition patch

    Hi again,

    Any thoughts? Any ideas?

    Thanks & best regards,
    Dumi.
      ----- Original Message -----
      From: Dumitru Ban
      To: mono-devel-list at lists.ximian.com
      Sent: Tuesday, May 29, 2007 11:14 AM
      Subject: [Mono-dev] MailDefinition patch


      Hi,

      I'm trying to create a patch for the MailDefinition (System.Web.UI.WebControls) and I'm not sure what's the best way to do it. The problem is in the CreateMailMessage (string recipients, IDictionary replacements, Control owner) method. If the BodyFileName is present and it's rooted everything works fine. If it's not rooted, it is combined with the owner's TemplateSourceDirectory. And this is not working :(

      I'm using the MailDefinition from a CreateUserWizard. Both the aspx containing the CreateUserWizard and the mail file are in the same directory, "users". If I set the BodyFileName for the wizard to "~/users/createaccount.txt", the combined path is something like this: "/myapp/~/users/createaccount.txt". And this is because there's no check for "~/".

      If I set the BodyFileName to "createaccount.txt", the combined path is something like this: "/myapp/users/createaccount.txt". This one looks fine, except that it's a virtual path and the StreamReader in the CreateMailMessage is looking for a physical path.

      How should be the mail file accessed? Using virtual paths or physical paths? Also, what about the permissions of the mail file?

      P.S. Attached is a sample error.

      Thanks & best regards,
      Dumi.




      __________ NOD32 2294 (20070528) Information __________

      This message was checked by NOD32 antivirus system.
      http://www.eset.com



    ------------------------------------------------------------------------------


      _______________________________________________
      Mono-devel-list mailing list
      Mono-devel-list at lists.ximian.com
      http://lists.ximian.com/mailman/listinfo/mono-devel-list



      __________ NOD32 2294 (20070528) Information __________

      This message was checked by NOD32 antivirus system.
      http://www.eset.com





    __________ NOD32 2364 (20070629) Information __________

    This message was checked by NOD32 antivirus system.
    http://www.eset.com



------------------------------------------------------------------------------


  _______________________________________________
  Mono-devel-list mailing list
  Mono-devel-list at lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list



  __________ NOD32 2462 (20070815) Information __________

  This message was checked by NOD32 antivirus system.
  http://www.eset.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070905/cfbf64a6/attachment.html 

From grendello at gmail.com  Wed Sep  5 07:16:31 2007
From: grendello at gmail.com (Marek Habersack)
Date: Wed, 5 Sep 2007 13:16:31 +0200
Subject: [Mono-dev] MailDefinition patch
In-Reply-To: <004101c7efa3$05986690$f265a8c0@laptopdban>
References: <003201c7a1c9$6cc09f90$f265a8c0@laptopdban>
	<015f01c7b981$b682be90$f265a8c0@laptopdban>
	<DA63C6E8B207E748B20D46DFED7B772D813ABF@dhost002-45.dex002.intermedia.net>
	<007c01c7df1a$7485ad90$f265a8c0@laptopdban>
	<004101c7efa3$05986690$f265a8c0@laptopdban>
Message-ID: <20070905131631.20b346b1@quantum.thanes.org>

On Wed, 5 Sep 2007 12:56:24 +0300, "Dumitru Ban" <dban at dako.ro> scribbled:

> RE: [Mono-dev] MailDefinition patchHi,
> 
> Is anyone reviewing and applying this patch?
Hey Dumitru,

   What's the bug number for this problem?

regards,

marek
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070905/7d60e120/attachment.bin 

From dban at dako.ro  Wed Sep  5 08:18:48 2007
From: dban at dako.ro (Dumitru Ban)
Date: Wed, 5 Sep 2007 15:18:48 +0300
Subject: [Mono-dev] MailDefinition patch
References: <003201c7a1c9$6cc09f90$f265a8c0@laptopdban><015f01c7b981$b682be90$f265a8c0@laptopdban><DA63C6E8B207E748B20D46DFED7B772D813ABF@dhost002-45.dex002.intermedia.net><007c01c7df1a$7485ad90$f265a8c0@laptopdban><004101c7efa3$05986690$f265a8c0@laptopdban>
	<20070905131631.20b346b1@quantum.thanes.org>
Message-ID: <015101c7efb6$ec58aff0$f265a8c0@laptopdban>

Hi Marek,

There is no bug added into bugzilla for this problem. I will add one if you 
think is necessary.

Best regards,
Dumi.

----- Original Message ----- 
From: "Marek Habersack" <grendello at gmail.com>
To: "Dumitru Ban" <dban at dako.ro>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, September 05, 2007 2:16 PM
Subject: Re: [Mono-dev] MailDefinition patch




From grendello at gmail.com  Wed Sep  5 08:26:26 2007
From: grendello at gmail.com (Marek Habersack)
Date: Wed, 5 Sep 2007 14:26:26 +0200
Subject: [Mono-dev] MailDefinition patch
In-Reply-To: <015101c7efb6$ec58aff0$f265a8c0@laptopdban>
References: <003201c7a1c9$6cc09f90$f265a8c0@laptopdban>
	<015f01c7b981$b682be90$f265a8c0@laptopdban>
	<DA63C6E8B207E748B20D46DFED7B772D813ABF@dhost002-45.dex002.intermedia.net>
	<007c01c7df1a$7485ad90$f265a8c0@laptopdban>
	<004101c7efa3$05986690$f265a8c0@laptopdban>
	<20070905131631.20b346b1@quantum.thanes.org>
	<015101c7efb6$ec58aff0$f265a8c0@laptopdban>
Message-ID: <20070905142626.2695cd75@quantum.thanes.org>

On Wed, 5 Sep 2007 15:18:48 +0300, "Dumitru Ban" <dban at dako.ro> scribbled:

> Hi Marek,
Hey Dumitru,

> There is no bug added into bugzilla for this problem. I will add one if you 
> think is necessary.
Please do, that way it won't get forgotten - please attach a test case and your
proposed patch, too. Thanks!

best regards,

marek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070905/04fce4e0/attachment.bin 

From jb at nurv.fr  Wed Sep  5 10:20:16 2007
From: jb at nurv.fr (Jb Evain)
Date: Wed, 5 Sep 2007 16:20:16 +0200
Subject: [Mono-dev] cecil optimization design proposal
In-Reply-To: <DA63C6E8B207E748B20D46DFED7B772D0466A340@dhost002-45.dex002.intermedia.net>
References: <DA63C6E8B207E748B20D46DFED7B772D0466A340@dhost002-45.dex002.intermedia.net>
Message-ID: <69f7d8470709050720w3381ce37gaf27643a344b23b@mail.gmail.com>

Hey Roei,

I've received the first mail.

Reviewing the patch is in my stack of things to do this week. But I'm
also in the middle of my move, so I'll complete my review probably
only next week.

Jb

On 9/5/07, Roei Erez <roeie at mainsoft.com> wrote:
>
>
>
>
> Hi all,
>
> I am sending this mail again, because the last one was sent without a
> subject, so ignore it if you have already read it.
>
>
>
> As a continue to the last discussion of cecil memory consumption, I am
> attaching some changes that emphasize the concepts.
>
> In order to remind everyone and to introduce the problem to the 'mono-cecil'
> group here is a summary:
>
>
>
> We have noticed that cecil consume relatively a lot of memory.
>
> This is due to the fact the code builds a full object model on top of the
> assembly basic tables.
>
> Many users are only interested in reading a part of the assembly; therefore
> the full object model is sometimes redundant.
>
>
>
> At the last discussion we were considering some options:
>
> 1.       Get rid of the basic tables after building the object model.
>
> 2.       Make the object model lazy, where the objects are accessing the
> basic tables directly.
>
> 3.       Maybe expose a way to load an assembly in a read-only way, which
> will make the implementation easier.
>
>
>
> I have made some thinking (and coding) regarding the second option, which I
> think is the right way to do it, and you can look at the attached diff as a
> proposed design.
>
> Here are some explanations about the code changes:
>
>
>
> A new class 'LazyReflectionReader' is introduced, which is responsible for
> the lazy assembly reading. This class does not build all the TypeDefinition,
> MethodDefinition, FieldDefinition ? objects at the beginning, but only when
> they are accessed. It also provide some internal helper methods for
> resolving the relations between elements, for example
> 'GetDeclaringType(MetadataToken token)', which is used by the lazy 'object
> model' classes. Currently not all fetching is lazy, but you still can see
> the differences in terms of load time and memory consumption.
> The object model instances that are instantiated by the
> 'LazyReflectionReader' are not populated with their entire dependencies for
> example TypeDefinition is not populated with its Methods, instead they are
> calling the helper methods in the 'LazyReflectionReader' in order to resolve
> the dependencies on request.
> A new class 'MetadataRelations' is introduced which is used as a
> preprocessor of the assembly, and creates the relations to be used by the
> helper methods.
> I have added a method on AssemblyFactory class: 'GetAssembly (string file,
> bool lazy)'.This method loads an assembly in a lazy way, and I have added
> this method only for the purpose of playing with the two implementations and
> see the differences, it is not part of the design.
>
>
>
> Here are some design issues that I have encountered during my work:
>
> 1. Remove the sealed modifier from the object model classes (
> TypeDefinition, FieldDefinition, MethodDefinition?   ) so we can derive from
> them?
>
> 2. Exposing a way to plugin you own ReflectionReader, so the use can
> implement his own object model loading?
>
>
>
> This code is not tested, and is provided for design purpose. Nevertheless
> you are welcome to measure the differences in loading time and memory
> consumption between the lazy and not lazy load.
>
> Any comments, remarks are very welcome.
>
>
>
> Regares,
>
> Roei Erez
>
>
>


-- 
Jb Evain  <jb at nurv.fr>


From xiii29 at free.fr  Wed Sep  5 13:01:06 2007
From: xiii29 at free.fr (xiii29)
Date: Wed, 05 Sep 2007 19:01:06 +0200
Subject: [Mono-dev] Trouble with Build Action
Message-ID: <46DEE0D2.7090407@free.fr>

Hi,
With the last version of MD (0.15), I've trouble with Build Action.

When I set the property to Embed Ressource, the value is not keeped 
between two use of MD ...

Any idea ?

Thanks !



From karim.jouini.ext at parrot.com  Thu Sep  6 03:55:39 2007
From: karim.jouini.ext at parrot.com (Jouini Karim)
Date: Thu, 06 Sep 2007 09:55:39 +0200
Subject: [Mono-dev] BlueZ Sharp
Message-ID: <46DFB27B.6030009@parrot.com>

Hi !
Did any one use the BlueZ Sharp (bluetooth) before ?
http://developer.novell.com/wiki/index.php/BlueZ_Sharp

It seems no longuer maintained ...
If any one has any information please tell ^^

Thanks,
Karim



From elmar at haneke.de  Thu Sep  6 05:25:39 2007
From: elmar at haneke.de (Elmar Haneke)
Date: Thu, 06 Sep 2007 11:25:39 +0200
Subject: [Mono-dev] mkbundle / location of mono-files
Message-ID: <46DFC793.5040502@haneke.de>

How can I tell an mkbundle EXE (on Windows) where to find the mono
runtime files.

Currently the EXE can only be started if it is placed into an subdir of
mono-installation.

Elmar


From robertj at gmx.net  Thu Sep  6 06:16:52 2007
From: robertj at gmx.net (Robert Jordan)
Date: Thu, 06 Sep 2007 12:16:52 +0200
Subject: [Mono-dev] mkbundle / location of mono-files
In-Reply-To: <46DFC793.5040502@haneke.de>
References: <46DFC793.5040502@haneke.de>
Message-ID: <fbok2t$f8l$1@sea.gmane.org>

Elmar Haneke wrote:
> How can I tell an mkbundle EXE (on Windows) where to find the mono
> runtime files.

What do you mean with runtime files? Assemblies, native DLLs,
configuration?

Robert



From LuisOrtiz at Verizon.Net  Thu Sep  6 07:15:34 2007
From: LuisOrtiz at Verizon.Net (Luis F. Ortiz)
Date: Thu, 06 Sep 2007 07:15:34 -0400
Subject: [Mono-dev] Big Arrays, Many Changes --- Request for Advice
In-Reply-To: <B866D2B6BBAAAD44B1D109ED50EE131E2AB22CFF64@jambi.sumatrasoftware.com>
References: <d74c39240709030700w312958d9x49bce5cea7dbe168@mail.gmail.com>
	<1188836949.13903.185.camel@erandi.dom>
	<23DC1397-F948-467C-BB89-0E1D00665E66@Verizon.Net>
	<46DD3896.9030106@seznam.cz>
	<845FCC35-0F4B-488C-ACE8-D59157528FAB@Verizon.Net>
	<B866D2B6BBAAAD44B1D109ED50EE131E2AB22CFF64@jambi.sumatrasoftware.com>
Message-ID: <EBC65723-A8A4-43E0-A707-B0D6500D4682@Verizon.Net>

On Sep 5, 2007, at 1:12 AM, Jeroen Frijters wrote:
> Luis F. Ortiz wrote:
>> On Sep 4, 2007, at 6:51 AM, Marek Safar wrote:
>>> Hi Luis,
>>>> 1)  MCS assumed that the arguments to NEWARR were always U4 or I4,
>>>> which does not seem
>>>>      to be the case as far as ECMA-335v4.
>>>> ...
>>>> A)  Fix mcs/expression.cs to emit OpCodes.Conv_Ovf_U/I instead of
>>>> OpCodes.Conv_Ovf_U4/I4
>>>>      for array size arguments,
>>> Any mcs patches with self contained tests are welcome. However, I
>>> think I fix this issue 2-3 weeks ago. Please use SVN version  
>>> instead.
>>
>> I see you did do serious surgery to the code in question in revision
>> 84357.
>> I have a question: ?How literally should ECMA-335 be taken?
>> If one were to take section 4.20 (newarr - create a zero-based, one-
>> dimensional array)
>> literally:
>>
>>      Valid array indexes are 0 <= index < numElems. ...
>>      Verifiability:  .numElems shall be of type native int or int32.
>>
>> then I would be inclined to say some work might still be necessary.
>> The implication would be that unsigned arguments are not proper and
>> that a 32 bit implementation should be limited to 2^32 - 1 elements.
>
> No. The verifier doesn't care about signed vs. unsigned. So the  
> above quote really means "native [u]int or [u]int32". For details  
> see the section "Verification Types" in the ECMA CLI spec.

Thanks for taking the time to straighten me out, Jeroen.

--Luis

From LuisOrtiz at Verizon.Net  Thu Sep  6 07:36:42 2007
From: LuisOrtiz at Verizon.Net (Luis F. Ortiz)
Date: Thu, 06 Sep 2007 07:36:42 -0400
Subject: [Mono-dev] Big Arrays, Many Changes --- Request for Advice
In-Reply-To: <fbltcj$4hk$1@sea.gmane.org>
References: <d74c39240709030700w312958d9x49bce5cea7dbe168@mail.gmail.com>
	<1188836949.13903.185.camel@erandi.dom>
	<23DC1397-F948-467C-BB89-0E1D00665E66@Verizon.Net>
	<46DD3896.9030106@seznam.cz>
	<845FCC35-0F4B-488C-ACE8-D59157528FAB@Verizon.Net>
	<fbltcj$4hk$1@sea.gmane.org>
Message-ID: <0E0562AE-7D4D-48AC-A67C-D8D9F1F4C8A6@Verizon.Net>

On Sep 5, 2007, at 5:37 AM, Robert Jordan wrote:
> Luis F. Ortiz wrote:
>> But at least now there is only one method to change, though I  
>> suspect it
>> will take
>> more than a few minutes for me to get the SVN version to compile from
>> scratch.
>
> The big array support leads to an API breakage on 64 systems:
>
> Unlike other API structs, MonoArray's internals are publicly exposed
> by macros. Since its "max_length" member has to be extended to 64 bit,
> the ABI will change and all applications using libmono have to be
> recompiled.
>
> IMO, this cannot be done before Mono 2.0, especially when the benefits
> are so tiny, but feel free to provide patches.

You are quire correct, API breakage is to be avoided, thanks for  
pointing out this issue. I'm not sure what release/branching  
structure is used by the mono project, but I suspect it is a live  
trunk with branches used to record releases.  Thus these changes  
could be set up to work off off a ./configure option (say --with- 
large-objects) which could result something like MONO_LARGE_OBJECTS  
being defined and conditional compiles used while the 1.2.X series is  
being worked on.  That way, the API breakage will be restricted to  
those who want to experiment.  Then, when 2.0.0 is in active  
development, the default condition for the configure switch can be  
flipped to ON and then later, once everyone is comfy with the  
changes, the conditional code can be ripped out.

--Luis





From LuisOrtiz at verizon.net  Thu Sep  6 07:47:51 2007
From: LuisOrtiz at verizon.net (Luis F. Ortiz)
Date: Thu, 06 Sep 2007 07:47:51 -0400
Subject: [Mono-dev] Big Arrays, Many Changes --- Request for Advice
In-Reply-To: <17c2d80b0709031426o6c9b2b04n920d2fb17719a2a3@mail.gmail.com>
References: <d74c39240709030700w312958d9x49bce5cea7dbe168@mail.gmail.com>
	<1188836949.13903.185.camel@erandi.dom>
	<23DC1397-F948-467C-BB89-0E1D00665E66@Verizon.Net>
	<17c2d80b0709031426o6c9b2b04n920d2fb17719a2a3@mail.gmail.com>
Message-ID: <9122AE47-E322-4054-B7DB-56551BE021D8@verizon.net>

Jonathan:
      Sorry for the delay in my response; first off, the test  
application I wrote was buggy and lied about how much memory was  
being allocated.   I had to rewrite it.  It now clearly can not  
allocate arrays larger than 2GB, though I have yet to pin down the  
exact amounts, as it seems that my test program gives me numbers that  
are different, depending on which C# compiler I use (csc or mcs) and  
the CLR in use under XP64.

      I'll get down to the bottom of this and reply later.

--Luis

On Sep 3, 2007, at 5:26 PM, Jonathan Chambers wrote:
> Hello,
>
> I don't have an answer to your problem, but I did have another  
> question. I can't find a link to the documentation in msdn, but I  
> thought arrays were limited to 2 GB in the .Net runtime (even on 64- 
> bit). Do you not see this behavior?
>
> http://blogs.msdn.com/joshwil/archive/2005/08/10/450202.aspx
>
> Thanks,
> Jonathan
>
> On 9/3/07, Luis F. Ortiz <LuisOrtiz at verizon.net> wrote:
> Folks:
>
> I was porting a small test application that was written in C# that
> allocated
> an array with a large number of elements (> 2^32).  While it
> compiled and ran
> in Visual Studio's C# under WindowsXP-64bit without a hitch, when I
> compiled
> and ran it under mcs/mono (1.2.4) on the same hardware, but booted up
> under
> Fedora7-x86_64, I ran into a few problems.
>
> Digging into it a bit, I discovered that:
>
> 1)  MCS assumed that the arguments to NEWARR were always U4 or I4,
> which does not seem
>      to be the case as far as ECMA-335v4.
> 2)  MONO assumes that array lengths and bounds can always be
> represented as guint32's,
>      [ like mono_array_new_specific (MonoVTable *vtable, guint32 n) ]
>
>
> Would folks object to a series of patches to:
>
> A)  Fix mcs/expression.cs to emit OpCodes.Conv_Ovf_U/I instead of
> OpCodes.Conv_Ovf_U4/I4
>      for array size arguments,
> B)  Modify mono/metadata/object.h to change the base type for array
> lengths/bounds to
>      XXX instead of guint32,
> C)  Change mono/metadata/object.c to change the functions that create/
> access arrays to
>      take XXX instead of guint32 length/bounds arguments.  Also
> perhaps update some of
>      the lower level object allocation functions to use XXX as needed.
> D)  Modify the execution of NEWARR be able to deal with I/U native
> types.  No doubt something
>      in the JIT needs tweaking as well.
> E)  Double check that array indexing not only takes native int types,
> but uses them right.
> F)  Add a few new test cases for large array allocation.
> G)  Whatever else needs to be done that I'll bump into after I try
> making the above changes
>      and realize what I forgot.  Warnings of known hazards gratefully
> accepted.
>
> My big question is what the right type for the size ought to be?
> I've seen int, size_t, gsize,
> and guint32 used in Mono.  I suspect that int and guint32 are wrong
> from a portability perspective,
> but would prefer that someone more intimately involved with Mono to
> say if guint or gsize or size_t
> were preferred. I'm guessing Bug 81774 is related to this as well.
>
> BTW, is this too big for a newby to tackle?
>
> --Luis F. Ortiz
> Follower of the "Selfish Way"
> _______________________________________________
> 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/20070906/cd60310d/attachment.html 

From elmar at haneke.de  Thu Sep  6 12:00:55 2007
From: elmar at haneke.de (Elmar Haneke)
Date: Thu, 06 Sep 2007 18:00:55 +0200
Subject: [Mono-dev] mkbundle / location of mono-files
In-Reply-To: <fbok2t$f8l$1@sea.gmane.org>
References: <46DFC793.5040502@haneke.de> <fbok2t$f8l$1@sea.gmane.org>
Message-ID: <46E02437.8080401@haneke.de>



Robert Jordan schrieb:
> Elmar Haneke wrote:
>> How can I tell an mkbundle EXE (on Windows) where to find the mono
>> runtime files.
> 
> What do you mean with runtime files? Assemblies, native DLLs,
> configuration?

It fails with message

The assembly mscorlib.dll was not found or could not be loaded.
It should have been installed in the `E:\lib\mono\1.0\mscorlib.dll'
directory.

Mono is in c:\mono, c:\mono\bin is in path.

Elmar





From robertj at gmx.net  Thu Sep  6 12:24:01 2007
From: robertj at gmx.net (Robert Jordan)
Date: Thu, 06 Sep 2007 18:24:01 +0200
Subject: [Mono-dev] mkbundle / location of mono-files
In-Reply-To: <46E02437.8080401@haneke.de>
References: <46DFC793.5040502@haneke.de> <fbok2t$f8l$1@sea.gmane.org>
	<46E02437.8080401@haneke.de>
Message-ID: <fbp9jl$vp4$1@sea.gmane.org>

Elmar Haneke wrote:
> 
> Robert Jordan schrieb:
>> Elmar Haneke wrote:
>>> How can I tell an mkbundle EXE (on Windows) where to find the mono
>>> runtime files.
>> What do you mean with runtime files? Assemblies, native DLLs,
>> configuration?
> 
> It fails with message
> 
> The assembly mscorlib.dll was not found or could not be loaded.
> It should have been installed in the `E:\lib\mono\1.0\mscorlib.dll'
> directory.
> 
> Mono is in c:\mono, c:\mono\bin is in path.

Did you turn dependency embedding on? See the "--deps" switch in the
man page. Which Mono version is this?

Robert



From elmar at haneke.de  Thu Sep  6 13:00:46 2007
From: elmar at haneke.de (Elmar Haneke)
Date: Thu, 06 Sep 2007 19:00:46 +0200
Subject: [Mono-dev] mkbundle / location of mono-files
In-Reply-To: <fbp9jl$vp4$1@sea.gmane.org>
References: <46DFC793.5040502@haneke.de>
	<fbok2t$f8l$1@sea.gmane.org>	<46E02437.8080401@haneke.de>
	<fbp9jl$vp4$1@sea.gmane.org>
Message-ID: <46E0323E.3070505@haneke.de>



Robert Jordan schrieb:
> Elmar Haneke wrote:
>> Robert Jordan schrieb:
>>> Elmar Haneke wrote:
>>>> How can I tell an mkbundle EXE (on Windows) where to find the mono
>>>> runtime files.
>>> What do you mean with runtime files? Assemblies, native DLLs,
>>> configuration?
>> It fails with message
>>
>> The assembly mscorlib.dll was not found or could not be loaded.
>> It should have been installed in the `E:\lib\mono\1.0\mscorlib.dll'
>> directory.
>>
>> Mono is in c:\mono, c:\mono\bin is in path.
> 
> Did you turn dependency embedding on? See the "--deps" switch in the
> man page. Which Mono version is this?

It's version 1.2.5.

Adding --deps does resolve the problem with an significant increase of
EXE-size.

On Linux mbbundled EXE does work without "--deps".

Elmar


From robertj at gmx.net  Thu Sep  6 13:22:34 2007
From: robertj at gmx.net (Robert Jordan)
Date: Thu, 06 Sep 2007 19:22:34 +0200
Subject: [Mono-dev] mkbundle / location of mono-files
In-Reply-To: <46E0323E.3070505@haneke.de>
References: <46DFC793.5040502@haneke.de>	<fbok2t$f8l$1@sea.gmane.org>	<46E02437.8080401@haneke.de>	<fbp9jl$vp4$1@sea.gmane.org>
	<46E0323E.3070505@haneke.de>
Message-ID: <fbpd1g$cmb$1@sea.gmane.org>

Elmar Haneke wrote:
> 
> Robert Jordan schrieb:
>> Elmar Haneke wrote:
>>> Robert Jordan schrieb:
>>>> Elmar Haneke wrote:
>>>>> How can I tell an mkbundle EXE (on Windows) where to find the mono
>>>>> runtime files.
>>>> What do you mean with runtime files? Assemblies, native DLLs,
>>>> configuration?
>>> It fails with message
>>>
>>> The assembly mscorlib.dll was not found or could not be loaded.
>>> It should have been installed in the `E:\lib\mono\1.0\mscorlib.dll'
>>> directory.
>>>
>>> Mono is in c:\mono, c:\mono\bin is in path.
>> Did you turn dependency embedding on? See the "--deps" switch in the
>> man page. Which Mono version is this?
> 
> It's version 1.2.5.
> 
> Adding --deps does resolve the problem with an significant increase of
> EXE-size.

This is expected. The "-z" switch might reduce the size, though.

> On Linux mbbundled EXE does work without "--deps".

Yeah, but only on your machine ;-)

Robert



From tquerci at gmail.com  Fri Sep  7 02:50:53 2007
From: tquerci at gmail.com (Torello Querci)
Date: Fri, 7 Sep 2007 08:50:53 +0200
Subject: [Mono-dev] Problem with sqlite and Win2000
Message-ID: <47337b9c0709062350p32a116acl9025aeec43d5e00e@mail.gmail.com>

Hi to all,

.. I have a real big problem using SQLite on old Win2000 installation
(Win2000 that is not update for several reason) ... If I run several
query (not is necessary a big number, sometimes 10 query is
sufficient) the program crash. I try both 1.2.4 and 1.2.5 version.
I try the same assembly on Linux and WinXP to run 100000 query I have
no problem.

Any suggestion? Is a mono bug or Windows bug that is fixed in some
service pack that is not installed?

If you want I realize a small program to show this behavious.

Thank's in advance (and sorry for my english)

Best Regards
Torello Querci


From glen.a.ford at gmail.com  Fri Sep  7 03:14:04 2007
From: glen.a.ford at gmail.com (Glen Ford)
Date: Fri, 7 Sep 2007 08:14:04 +0100
Subject: [Mono-dev] SOAP Remoting
Message-ID: <39c74bb90709070014t7d71886t60cbc4a3a4fdff03@mail.gmail.com>

Hi,


Just a heads up, I have found that when using SOAP Remoting that the
SoapMethodAttributes are mainly ignored (certainly are for reponse
generation) in both 1.2.4 and 1.2.5.

I have quickly hacked my local copy to get me working and hope to
raise some bugs with test cases and possibly patches soon.



Regards,


Glen


From pablosantosluac at terra.es  Fri Sep  7 04:00:41 2007
From: pablosantosluac at terra.es (pablosantosluac)
Date: Fri, 7 Sep 2007 10:00:41 +0200
Subject: [Mono-dev] Problem with sqlite and Win2000
References: <47337b9c0709062350p32a116acl9025aeec43d5e00e@mail.gmail.com>
Message-ID: <061201c7f125$2ff04d30$0202a8c0@beardtongue>

Hi,

Well, you know SQLite doesn't support concurrency... don't you?

Could it be related?

pablo
----- Original Message ----- 
From: "Torello Querci" <tquerci at gmail.com>
To: <Mono-devel-list at lists.ximian.com>
Sent: Friday, September 07, 2007 8:50 AM
Subject: [Mono-dev] Problem with sqlite and Win2000


> Hi to all,
> 
> .. I have a real big problem using SQLite on old Win2000 installation
> (Win2000 that is not update for several reason) ... If I run several
> query (not is necessary a big number, sometimes 10 query is
> sufficient) the program crash. I try both 1.2.4 and 1.2.5 version.
> I try the same assembly on Linux and WinXP to run 100000 query I have
> no problem.
> 
> Any suggestion? Is a mono bug or Windows bug that is fixed in some
> service pack that is not installed?
> 
> If you want I realize a small program to show this behavious.
> 
> Thank's in advance (and sorry for my english)
> 
> Best Regards
> Torello Querci
> _______________________________________________
> 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  Fri Sep  7 05:36:29 2007
From: pablosantosluac at terra.es (pablosantosluac)
Date: Fri, 7 Sep 2007 11:36:29 +0200
Subject: [Mono-dev] Problem with sqlite and Win2000
References: <47337b9c0709062350p32a116acl9025aeec43d5e00e@mail.gmail.com>
	<061201c7f125$2ff04d30$0202a8c0@beardtongue>
	<47337b9c0709070119v31dcf00fk40ad8059decb45a8@mail.gmail.com>
	<47337b9c0709070125v19172373s6f461e1afe50bda3@mail.gmail.com>
Message-ID: <06bf01c7f132$91cfec10$0202a8c0@beardtongue>

Do you have a callstack?



----- Original Message ----- 
From: "Torello Querci" <tquerci at gmail.com>
To: "pablosantosluac" <pablosantosluac at terra.es>
Sent: Friday, September 07, 2007 10:25 AM
Subject: Re: [Mono-dev] Problem with sqlite and Win2000


> Unfortunally using sqlite2 or sqlite3 I have the same result. The
> application crash :(
>
> 2007/9/7, Torello Querci <tquerci at gmail.com>:
>> Hi, I not use thread, so I wait the end of a select before to do the 
>> next.
>> Under XP work fine.
>>
>> Now I try to use sqlite2 instead.
>>
>> If you want I can attach a simple testing program with related DB.
>>
>> 2007/9/7, pablosantosluac <pablosantosluac at terra.es>:
>> > Hi,
>> >
>> > Well, you know SQLite doesn't support concurrency... don't you?
>> >
>> > Could it be related?
>> >
>> > pablo
>> > ----- Original Message -----
>> > From: "Torello Querci" <tquerci at gmail.com>
>> > To: <Mono-devel-list at lists.ximian.com>
>> > Sent: Friday, September 07, 2007 8:50 AM
>> > Subject: [Mono-dev] Problem with sqlite and Win2000
>> >
>> >
>> > > Hi to all,
>> > >
>> > > .. I have a real big problem using SQLite on old Win2000 installation
>> > > (Win2000 that is not update for several reason) ... If I run several
>> > > query (not is necessary a big number, sometimes 10 query is
>> > > sufficient) the program crash. I try both 1.2.4 and 1.2.5 version.
>> > > I try the same assembly on Linux and WinXP to run 100000 query I have
>> > > no problem.
>> > >
>> > > Any suggestion? Is a mono bug or Windows bug that is fixed in some
>> > > service pack that is not installed?
>> > >
>> > > If you want I realize a small program to show this behavious.
>> > >
>> > > Thank's in advance (and sorry for my english)
>> > >
>> > > Best Regards
>> > > Torello Querci
>> > > _______________________________________________
>> > > Mono-devel-list mailing list
>> > > Mono-devel-list at lists.ximian.com
>> > > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> >
>> 



From skolima at gmail.com  Fri Sep  7 06:55:02 2007
From: skolima at gmail.com (Leszek Ciesielski)
Date: Fri, 7 Sep 2007 12:55:02 +0200
Subject: [Mono-dev] Silverlight test suite
Message-ID: <23a15590709070355m4fc95a8aj2f2d236cba4e6b89@mail.gmail.com>

Hi,

could someone from Novell provide more information on how (and if) the
tests be integrated with mono tests? As Scott Guru writes:

"Silverlight 1.1 will include a cross-platform version of the .NET
Framework, and will enable a rich .NET development experience in the
browser.  It will support a WPF programming model for UI - including
support for an extensible control model, layout management,
data-binding, control skinning, and a rich set of built-in controls.
It will also include a subset of the full .NET Framework base class
library you use today, including support for collections, generics,
IO, threading, globalization, networking (including sockets,
web-services and REST support), HTML DOM, XML, local storage, and
LINQ. "

Will the tests include all those regions? If yes, then this would be
awesome news for mono, even if only Novell employees would have access
to the tests, the whole project would benefit massively.

Intrigued,

Leszek

-- 
MS-DOS user since 5.0
Windows user since 3.11
Linux user since kernel 2.4
Novell Netware user since 2.2
WARCRAFT user since 1.0


From informatique.internet at fiducial.fr  Fri Sep  7 09:35:36 2007
From: informatique.internet at fiducial.fr (Hubert FONGARNAND)
Date: Fri, 07 Sep 2007 15:35:36 +0200
Subject: [Mono-dev] Response.BufferOutput behaviour under apache/mod_mono
Message-ID: <1189172137.11448.14.camel@hublinux.fidudev.fr>

Hello

I've a sample test case which show the correct behaviour of
Response.BufferOutput=false...


	public class pagetest : Page
	{
		protected System.Web.UI.WebControls.TextBox textBox1;
	
		
		protected override void OnLoad(EventArgs e)
		{
			Response.Clear();
			Response.BufferOutput=false;
			for (int i=0;i<100;i++)
			{
				Response.Write(i.ToString());
				Response.Write("<br>");
				System.Threading.Thread.Sleep(100);
			}
			Response.End();
		}
	}

With xsp, my firefox show a number each 100ms...

When using apache/mod_mono, I only received the whole page when it's
done...
So it seems that Response.BufferOutput is ignored...
It's the same if i add Response.Flush(); after Response.Write()...
This behaviour can cause problems if you have to send information in
realtime (some component like progressbar use this feature to run)
Is it a bug or a feature? :) should i open a bugzilla entry for this?

Thanks for help
_______________________________________________
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/20070907/b9643900/attachment.html 

From miguel at novell.com  Fri Sep  7 11:08:37 2007
From: miguel at novell.com (Miguel de Icaza)
Date: Fri, 07 Sep 2007 11:08:37 -0400
Subject: [Mono-dev] Silverlight test suite
In-Reply-To: <23a15590709070355m4fc95a8aj2f2d236cba4e6b89@mail.gmail.com>
References: <23a15590709070355m4fc95a8aj2f2d236cba4e6b89@mail.gmail.com>
Message-ID: <1189177717.4020.21.camel@erandi.dom>

Hello,

> Will the tests include all those regions? If yes, then this would be
> awesome news for mono, even if only Novell employees would have access
> to the tests, the whole project would benefit massively.

Microsoft will give Novell access to the test suites.

The bad news is that the test suites can only be given to Novell and we
do not have rights to redistribute them.

But at least we will be able to get the test suites.

Miguel.



From lupus at ximian.com  Fri Sep  7 13:35:15 2007
From: lupus at ximian.com (Paolo Molaro)
Date: Fri, 7 Sep 2007 19:35:15 +0200
Subject: [Mono-dev] Unhandled exception behavior
In-Reply-To: <1188597093.4148.55.camel@matrix.ximian.com>
References: <1188597093.4148.55.camel@matrix.ximian.com>
Message-ID: <20070907173515.GB1101@debian.org>

On 08/31/07 Massimiliano Mantione wrote:
> Index: mono/metadata/object.h
> ===================================================================
> --- mono/metadata/object.h	(revision 84274)
> +++ mono/metadata/object.h	(working copy)
> @@ -242,6 +242,11 @@
>  mono_runtime_exec_main	    (MonoMethod *method, MonoArray *args,
>  			     MonoObject **exc);
>  
> +void
> +mono_runtime_force_legacy_unhandled_exception_policy (void);
> +gboolean
> +mono_runtime_uses_legacy_unhandled_exception_policy (void);

This should go into object-internals.h and marked MONO_INTERNAL.
It would likely be better to have something like:

enum {
	MONO_UNHANLED_POLICY_LEGACY,
	// need a better name
	MONO_UNHANLED_POLICY_SOME_DESCRIPTIVE_WORD_OF_THE_NEW_BEHAVIOUR
};

and then:

void mono_runtime_unhandled_policy_set (int policy);
int  mono_runtime_unhandled_policy_get (void);

> Index: mono/metadata/mono-config.c
> ===================================================================
> --- mono/metadata/mono-config.c	(revision 84274)
> +++ mono/metadata/mono-config.c	(working copy)
> @@ -289,6 +289,33 @@
>  	dllmap_finish
>  };
>  
> +static void
> +legacyUEP_start (gpointer user_data, 
> +              const gchar         *element_name,
> +              const gchar        **attribute_names,
> +              const gchar        **attribute_values) {
> +	if ((strcmp (element_name, "legacyUnhandledExceptionPolicy") == 0) &&
> +			(attribute_names [0] != NULL) &&
> +			(strcmp (attribute_names [0], "enabled") == 0)) {
> +		if ((strcmp (attribute_values [0], "1") == 0) ||
> +				(strcmp (attribute_values [0], "true") == 0) ||
> +				(strcmp (attribute_values [0], "True") == 0) ||
> +				(strcmp (attribute_values [0], "TRUE") == 0)) {

Why not use a case insensitive compare here?

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better


From lupus at ximian.com  Fri Sep  7 13:12:27 2007
From: lupus at ximian.com (Paolo Molaro)
Date: Fri, 7 Sep 2007 19:12:27 +0200
Subject: [Mono-dev] [PATCH] AppDomain.AssemblyResolve event
	differences	between Mono and MS.NET
In-Reply-To: <20070905010309.0789937f@quantum.thanes.org>
References: <20070905010309.0789937f@quantum.thanes.org>
Message-ID: <20070907171227.GZ1101@debian.org>

On 09/05/07 Marek Habersack wrote:
> Assembly.LoadWithPartialName generates the event on MS.NET but not on Mono. The
> attached patch makes Mono behave the same way what MS.NET. Please review,

Thanks.

Please make the test program into a proper regression test and check it
in in mono/tests (it should exit with a non-zero value if any subtest
fails).

> Index: mono/metadata/appdomain.h
> ===================================================================
> --- mono/metadata/appdomain.h	(revision 85261)
> +++ mono/metadata/appdomain.h	(working copy)
> @@ -88,6 +88,9 @@
>  MonoAssembly *
>  mono_domain_assembly_open  (MonoDomain *domain, const char *name);
>  
> +MonoReflectionAssembly *
> +mono_try_assembly_resolve (MonoDomain *domain, MonoString *fname, gboolean refonly);

Put this into domain-internals.h and mark it as internal.

Thanks!

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better


From lupus at ximian.com  Fri Sep  7 13:22:25 2007
From: lupus at ximian.com (Paolo Molaro)
Date: Fri, 7 Sep 2007 19:22:25 +0200
Subject: [Mono-dev] Big Arrays, Many Changes --- Request for Advice
In-Reply-To: <0E0562AE-7D4D-48AC-A67C-D8D9F1F4C8A6@Verizon.Net>
References: <d74c39240709030700w312958d9x49bce5cea7dbe168@mail.gmail.com>
	<1188836949.13903.185.camel@erandi.dom>
	<23DC1397-F948-467C-BB89-0E1D00665E66@Verizon.Net>
	<46DD3896.9030106@seznam.cz>
	<845FCC35-0F4B-488C-ACE8-D59157528FAB@Verizon.Net>
	<fbltcj$4hk$1@sea.gmane.org>
	<0E0562AE-7D4D-48AC-A67C-D8D9F1F4C8A6@Verizon.Net>
Message-ID: <20070907172225.GA1101@debian.org>

On 09/06/07 Luis F. Ortiz wrote:
> You are quire correct, API breakage is to be avoided, thanks for  
> pointing out this issue. I'm not sure what release/branching  
> structure is used by the mono project, but I suspect it is a live  
> trunk with branches used to record releases.  Thus these changes  
> could be set up to work off off a ./configure option (say --with- 
> large-objects) which could result something like MONO_LARGE_OBJECTS  
> being defined and conditional compiles used while the 1.2.X series is  
> being worked on.  That way, the API breakage will be restricted to  
> those who want to experiment.  Then, when 2.0.0 is in active  
> development, the default condition for the configure switch can be  
> flipped to ON and then later, once everyone is comfy with the  
> changes, the conditional code can be ripped out.

If we have any bug with not supporting arrays with a length up to
Int32.MaxValue we should fix them, at least as far as the code is
concerned, though the GC may not actually be able to allocate them
on 32 bit systems.
If we allow sizes up to Int64.MaxValue on 64 bit system is still very
much up in the air: I haven't seen anybody else request it and my guess
is that this would be very taxing on the GC anyway.
Handling this with a define (but also a libmono soname change) would be
fine I guess. Since this is an incompatible change I would prefer not
having a configure change, though, since apparently some people monitor
our new configure options and enable them even if they don't know what
they mean:)

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better


From roeie at mainsoft.com  Wed Sep  5 10:06:44 2007
From: roeie at mainsoft.com (Roei Erez)
Date: Wed, 5 Sep 2007 07:06:44 -0700
Subject: [Mono-dev] cecil optimization design proposal
Message-ID: <DA63C6E8B207E748B20D46DFED7B772D0466A340@dhost002-45.dex002.intermedia.net>

Hi all,

I am sending this mail again, because the last one was sent without a
subject, so ignore it if you have already read it.

 

As a continue to the last discussion of cecil memory consumption, I am
attaching some changes that emphasize the concepts.

In order to remind everyone and to introduce the problem to the
'mono-cecil' group here is a summary:

 

We have noticed that cecil consume relatively a lot of memory.

This is due to the fact the code builds a full object model on top of
the assembly basic tables.

Many users are only interested in reading a part of the assembly;
therefore the full object model is sometimes redundant.

 

At the last discussion we were considering some options:

1.       Get rid of the basic tables after building the object model.

2.       Make the object model lazy, where the objects are accessing the
basic tables directly.

3.       Maybe expose a way to load an assembly in a read-only way,
which will make the implementation easier.

 

I have made some thinking (and coding) regarding the second option,
which I think is the right way to do it, and you can look at the
attached diff as a proposed design.

Here are some explanations about the code changes:

 

1.	A new class 'LazyReflectionReader' is introduced, which is
responsible for the lazy assembly reading. This class does not build all
the TypeDefinition, MethodDefinition, FieldDefinition ... objects at the
beginning, but only when they are accessed. It also provide some
internal helper methods for resolving the relations between elements,
for example 'GetDeclaringType(MetadataToken token)', which is used by
the lazy 'object model' classes. Currently not all fetching is lazy, but
you still can see the differences in terms of load time and memory
consumption.
2.	The object model instances that are instantiated by the
'LazyReflectionReader' are not populated with their entire dependencies
for example TypeDefinition is not populated with its Methods, instead
they are calling the helper methods in the 'LazyReflectionReader' in
order to resolve the dependencies on request.
3.	A new class 'MetadataRelations' is introduced which is used as a
preprocessor of the assembly, and creates the relations to be used by
the helper methods.
4.	I have added a method on AssemblyFactory class: 'GetAssembly
(string file, bool lazy)'.This method loads an assembly in a lazy way,
and I have added this method only for the purpose of playing with the
two implementations and see the differences, it is not part of the
design. 

 

Here are some design issues that I have encountered during my work:

1. Remove the sealed modifier from the object model classes (
TypeDefinition, FieldDefinition, MethodDefinition...   ) so we can
derive from them?

2. Exposing a way to plugin you own ReflectionReader, so the use can
implement his own object model loading?

 

This code is not tested, and is provided for design purpose.
Nevertheless you are welcome to measure the differences in loading time
and memory consumption between the lazy and not lazy load.

Any comments, remarks are very welcome.

 

Regares, 

Roei Erez

 

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

From azher at hep.caltech.edu  Sun Sep  9 09:51:07 2007
From: azher at hep.caltech.edu (azher at hep.caltech.edu)
Date: Sun, 9 Sep 2007 06:51:07 -0700 (PDT)
Subject: [Mono-dev] Errors: sessionState
Message-ID: <1550.66.215.93.125.1189345867.squirrel@webmail.hep.caltech.edu>

Hi,

I have just installed 1.2.5 and while running my .net application i got 
this error : Code is at the end of email. Can someone plz suggest what 
could be wrong ??

httpd.conf is:

include /etc/httpd/conf/mod_mono.conf
MonoServerPath default /usr/local/1.2.5/bin/mod-mono-server2

Alias /aspx "/usr/local/1.2.5/lib/xsp/test"
MonoApplications "/aspx:/usr/local/1.2.5/lib/xsp/test"

<Location /aspx>
        SetHandler mono
</Location>


Thnx
-Azher

-----
Server Error in '/aspx' Application
The section <sessionState> can't be defined in this configuration file 
(the allowed definition context is 'MachineToApplication'). () ( line 14)

Description: Error processing request.

Error Message: HTTP 500.
System.Configuration.ConfigurationErrorsException: The section
<sessionState> can't be defined in this configuration file (the allowed 
definition context is 'MachineToApplication'). () ( line 14)

Stack Trace:

System.Configuration.ConfigurationErrorsException: The section
<sessionState> can't be defined in this configuration file (the allowed 
definition context is 'MachineToApplication'). () ( line 14)
  at System.Configuration.SectionInfo.ReadData
(System.Configuration.Configuration config, System.Xml.XmlTextReader 
reader, Boolean overrideAllowed) [0x00000]
  at System.Configuration.SectionGroupInfo.ReadContent
(System.Xml.XmlTextReader reader, System.Configuration.Configuration 
config, Boolean overrideAllowed, Boolean root) [0x00000]
  at System.Configuration.SectionGroupInfo.ReadData
(System.Configuration.Configuration config, System.Xml.XmlTextReader 
reader, Boolean overrideAllowed) [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.Web.Configuration.WebConfigurationManager.OpenWebConfiguration 
(System.String path, System.String site, System.String locationSubPath, 
System.String server, System.String userName, System.String password) 
[0x00000]

09/09/2007 13:24:49

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

<?xml version="1.0"?>
<configuration
xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

        <!-- Please Dont Modify this configuration file, unless you know
what you are doing -->

        <configSections>

        </configSections>
        <connectionStrings>
                <add name="TrakkerDBConnectionString1"
connectionString="Server=Axxxxxx;Initial Catalog=xxxxxx;Persist S
ecurity Info=True;User ID=xxxxx;Password=xxxxx;Max Pool Size=20;Connect 
Timeout=1800" providerName="System.Data.SqlClient"/>
        </connectionStrings>
        <system.web>

                <sessionState
           mode="InProc"
     timeout="20"
     >
                </sessionState>

                <customErrors
defaultRedirect="~/WebPages/Client/Error.aspx" />
                <roleManager enabled="true"
defaultProvider="FarazSqlRoleProvider">
                        <providers>
                                <add
connectionStringName="TrakkerDBConnectionString1"
name="FarazSqlRoleProvider" type="Syst
em.Web.Security.SqlRoleProvider"/>
                        </providers>
                </roleManager>








From stapostol at gmail.com  Sun Sep  9 11:37:36 2007
From: stapostol at gmail.com (StApostol)
Date: Sun, 9 Sep 2007 18:37:36 +0300
Subject: [Mono-dev] Possible compiler bug with nested partial classes.
Message-ID: <15aef24e0709090837g3dab9f71qdb507f76b3664544@mail.gmail.com>

Hi,

The following code compiles on csc (.Net 2.0) but fails on gmcs (Mono 1.2.5)
with the message: "error CS0229: Ambiguity between `Bug.GL.Core' and
`Bug.GL.Core'"

using System;

namespace Bug
{
  public static partial class GL
  {
       internal static partial class Core
       {
           internal static bool A() { return true; }
       }
  }

  partial class GL
  {
       public static bool UseCore()
       {
           return Core.A();
       }


       // internal static partial class Core    // <-- Works as it should
       partial class Core    // <-- Throws error CS0229
       {
       }
  }
}

The error goes away if I change the decla"partial class Core" declaration to
"internal static partial class Core".

No such bug exists in the tracker, should I report? Even better, any
pointers on where to start looking to fix this myself?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070909/4bc12bd8/attachment.html 

From marek.safar at seznam.cz  Sun Sep  9 14:11:55 2007
From: marek.safar at seznam.cz (Marek Safar)
Date: Sun, 09 Sep 2007 19:11:55 +0100
Subject: [Mono-dev] Possible compiler bug with nested partial classes.
In-Reply-To: <15aef24e0709090837g3dab9f71qdb507f76b3664544@mail.gmail.com>
References: <15aef24e0709090837g3dab9f71qdb507f76b3664544@mail.gmail.com>
Message-ID: <46E4376B.7020600@seznam.cz>

Hello,

Yes, it is mcs bug. Please fill a bug report into http://bugzilla.ximian.com

If you are interested in fixing the issue TypeContainer::AddPartial is
good starting point.

Thanks
Marek
>
> The following code compiles on csc (.Net 2.0) but fails on gmcs (Mono 
> 1.2.5) with the message: "error CS0229: Ambiguity between 
> `Bug.GL.Core' and `Bug.GL.Core'"
>
> using System;
>
> namespace Bug
> {
>   public static partial class GL
>   {
>        internal static partial class Core
>        {
>            internal static bool A() { return true; }
>        }
>   }
>     
>   partial class GL
>   {
>        public static bool UseCore()
>        {
>            return Core.A();
>        }
>     
>
>        // internal static partial class Core    // <-- Works as it should
>        partial class Core    // <-- Throws error CS0229
>        {
>        }
>   }
> }
>
> The error goes away if I change the decla"partial class Core" 
> declaration to "internal static partial class Core".
>
> No such bug exists in the tracker, should I report? Even better, any 
> pointers on where to start looking to fix this myself?
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>   



From debackerl at gmail.com  Mon Sep 10 03:21:05 2007
From: debackerl at gmail.com (Laurent Debacker)
Date: Mon, 10 Sep 2007 09:21:05 +0200
Subject: [Mono-dev] Ribbon library
Message-ID: <75751ca80709100021w1a69bc8fvc420e3ec9b7c30a8@mail.gmail.com>

Hi,

The ribbon library is now in the official Mono's SVN repository.
You can grab the code in /trunk/gtk-sharp-ribbon

Regards,
Laurent Debacker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070910/d4d7ea61/attachment.html 

From js at hotfeet.ch  Mon Sep 10 09:59:42 2007
From: js at hotfeet.ch (Juraj Skripsky)
Date: Mon, 10 Sep 2007 15:59:42 +0200
Subject: [Mono-dev] Encoding problem with HttpResponse.Redirect
Message-ID: <1189432782.3292.21.camel@leonardo.hotfeet.ch>

(another bug report that made into Bugzilla but never to the
bugs-list...)

- extract the attached test case.
- request index.aspx. 
=> you are redirected to "test???.aspx" instead of "test???.aspx"

This works when using xsp2 (instead of mod_mono).
I'm using Mono from SVN.

- Juraj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: encoding.zip
Type: application/zip
Size: 570 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070910/7801f0b3/attachment.zip 

From david.goddet at gmail.com  Mon Sep 10 11:42:03 2007
From: david.goddet at gmail.com (David Arnaud-Goddet)
Date: Mon, 10 Sep 2007 17:42:03 +0200
Subject: [Mono-dev] [Beginners] Problem to do a simple makefile
Message-ID: <10c19b820709100842u666dd98amb89acd52c1aa6aa@mail.gmail.com>

Hi all,
I use Sharpdevelop to work with mono. It compiles and executes my source
code properly.
But I would like to do my own makefile.
I try this :

mcs -out:test.exe MyFile.cs -r:System.dll -r:atk-sharp.dll
-r:gdk-sharp.dll -r:glib-sharp.dll -r:gtk-sharp.dll -r:pango-sharp.dll

I copy the references from Mono-1.2.4\lib\mono\gac to the current folder.
In my cs file I use System.IO and System.IO.Ports. On Sharpdevelop the
assembly works but when I use my Makefile I obtaint :

Empty2.cs(3,7): error CS0234: The type or namespace name `Ports' does not
exist
in the namespace `System.IO'. Are you missing an assembly reference?
Empty2.cs(3,1): error CS0246: The type or namespace name `IO.Ports' could
not be
 found. Are you missing a using directive or an assembly reference?
Empty2.cs(3,7): error CS0234: The type or namespace name `Ports' does not
exist
in the namespace `System.IO'. Are you missing an assembly reference?
Empty2.cs(3,1): error CS0246: The type or namespace name `IO.Ports' could
not be
 found. Are you missing a using directive or an assembly reference?
Compilation failed: 4 error(s), 0 warnings

I don't understand! The references are the same in the 2 cases...
Thanks in advance.








David ARNAUD-GODDET
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070910/0ba98d2d/attachment.html 

From kamil.skalski at gmail.com  Mon Sep 10 11:48:55 2007
From: kamil.skalski at gmail.com (Kamil Skalski)
Date: Mon, 10 Sep 2007 17:48:55 +0200
Subject: [Mono-dev] [Beginners] Problem to do a simple makefile
In-Reply-To: <10c19b820709100842u666dd98amb89acd52c1aa6aa@mail.gmail.com>
References: <10c19b820709100842u666dd98amb89acd52c1aa6aa@mail.gmail.com>
Message-ID: <711aea6b0709100848u3c0667a1mea8f1b5a28c7a85@mail.gmail.com>

2007/9/10, David Arnaud-Goddet <david.goddet at gmail.com>:
> Hi all,
> I use Sharpdevelop to work with mono. It compiles and executes my source
> code properly.
> But I would like to do my own makefile.
> I try this :
> mcs -out:test.exe
>  MyFile.cs -r:System.dll -r:atk-sharp.dll -r:gdk-sharp.dll -r:glib-sharp.dll
> -r:gtk-sharp.dll -r:pango-sharp.dll
> I copy the references from Mono-1.2.4\lib\mono\gac to the current folder.
> In my cs file I use System.IO and System.IO.Ports. On Sharpdevelop the

First of all you should use gmcs to compile code for .NET 2.0 version.
System.IO.Ports is AFAIR only available in 2.0.

> assembly works but when I use my Makefile I obtaint :
>
> Empty2.cs(3,7): error CS0234: The type or namespace name `Ports' does not
> exist
> in the namespace `System.IO'. Are you missing an assembly reference?
> Empty2.cs(3,1): error CS0246: The type or namespace name `IO.Ports' could
> not be
>  found. Are you missing a using directive or an assembly reference?
> Empty2.cs(3,7): error CS0234: The type or namespace name `Ports' does not
> exist
> in the namespace `System.IO'. Are you missing an assembly reference?
> Empty2.cs(3,1): error CS0246: The type or namespace name `IO.Ports' could
> not be
>  found. Are you missing a using directive or an assembly reference?
> Compilation failed: 4 error(s), 0 warnings
>
> I don't understand! The references are the same in the 2 cases...
> Thanks in advance.
>
>
>
>
>
>
>
>
>  David ARNAUD-GODDET
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>


-- 
Kamil Skalski
http://nazgul.omega.pl


From rook at roo.k.pl  Mon Sep 10 11:49:22 2007
From: rook at roo.k.pl (=?UTF-8?B?TWljaGHFgiBaaWVtc2tp?=)
Date: Mon, 10 Sep 2007 17:49:22 +0200
Subject: [Mono-dev] [Beginners] Problem to do a simple makefile
In-Reply-To: <10c19b820709100842u666dd98amb89acd52c1aa6aa@mail.gmail.com>
References: <10c19b820709100842u666dd98amb89acd52c1aa6aa@mail.gmail.com>
Message-ID: <46E56782.2090803@roo.k.pl>

Hi!

Try using gmcs rather than mcs.
AFAIR System.IO.Ports doesn't exist in NET 1.1

Cheers!
Micha? Ziemski

David Arnaud-Goddet pisze:
> Hi all,
> I use Sharpdevelop to work with mono. It compiles and executes my 
> source code properly.
> But I would like to do my own makefile.
> I try this :
> mcs -out:test.exe
>  MyFile.cs -r:System.dll -r:atk-sharp.dll -r:gdk-sharp.dll -r:glib-sharp.dll -r:gtk-sharp.dll -r:pango-sharp.dll
> I copy the references from Mono-1.2.4\lib\mono\gac to the current folder.
> In my cs file I use System.IO and System.IO.Ports. On Sharpdevelop the 
> assembly works but when I use my Makefile I obtaint :
>
> Empty2.cs(3,7): error CS0234: The type or namespace name `Ports' does 
> not exist
> in the namespace `System.IO'. Are you missing an assembly referenc