From dave-monolist at earth.li  Sun Feb  1 06:25:42 2004
From: dave-monolist at earth.li (David Sheldon)
Date: Sun, 1 Feb 2004 11:25:42 +0000
Subject: [Mono-devel-list] AppDomainSetupTest.cs
In-Reply-To: <E1AldrB-00031l-Ha@smtp02.fields.gol.com>
References: <20040127184608.GG16885@ox.compsoc.net> <E1AldrB-00031l-Ha@smtp02.fields.gol.com>
Message-ID: <20040201112542.GE30479@ox.compsoc.net>

On Wed, Jan 28, 2004 at 09:47:09AM +0900, Nick Drochak wrote:
> OK, it's what I thought then.  If I make a simple test like you did, then I
> get the same results.  If I use the nunit test runner (i.e. 'make run-test')
> then I get the other kind of result, namely a path from Path.GetTempPath().

If I compile the test with 

csc /r:"C:\Program Files\NUnit V2.1\bin\nunit.framework.dll" /t:library AppDomainSetupTest.cs

Then run it with the nunit gui, then my version with "curDir" always
passes. I haven't yet got enough of a working environment on windows to
by able to do "make run-test".

David
-- 
     To understand recursion, we must first understand recursion.


From martin at ximian.com  Sun Feb  1 10:07:29 2004
From: martin at ximian.com (Martin Baulig)
Date: Sun, 01 Feb 2004 16:07:29 +0100
Subject: [Mono-devel-list] Problem with P/Invoke
In-Reply-To: <1075588042.25957.87.camel@melchior.magi>
References: <1075490214.2438.7.camel@localhost.localdomain>
	 <1075588042.25957.87.camel@melchior.magi>
Message-ID: <1075648049.1661.1.camel@gondor.martin.baulig>

On Sat, 2004-01-31 at 23:27, Jonathan Pryor wrote:
> Thus, your DllImport should be:
> 
> 	[DllImport ("libc.so")]
> 	private static extern IntPtr strncpy (StringBuilder dest,
> 		string src, uint len);
> 
> Now, the bad news begins.  When I try this under Mono 0.29, the code
> doesn't work correctly.  Nothing appears to be copied.

You forgot a more serious issue:

The first argument or strncpy is a `char *' and you can't just overwrite
the managed `StringBuilder' instance.

--
Martin Baulig <martin at ximian.com>
Now blogging !  http://primates.ximian.com/~martin/blog



From jonpryor at vt.edu  Sun Feb  1 11:58:02 2004
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Sun, 01 Feb 2004 11:58:02 -0500
Subject: [Mono-devel-list] Problem with P/Invoke
In-Reply-To: <1075648049.1661.1.camel@gondor.martin.baulig>
References: <1075490214.2438.7.camel@localhost.localdomain>
	 <1075588042.25957.87.camel@melchior.magi>
	 <1075648049.1661.1.camel@gondor.martin.baulig>
Message-ID: <1075654681.25957.1019.camel@melchior.magi>

Below...

On Sun, 2004-02-01 at 10:07, Martin Baulig wrote:
> On Sat, 2004-01-31 at 23:27, Jonathan Pryor wrote:
> > Thus, your DllImport should be:
> > 
> > 	[DllImport ("libc.so")]
> > 	private static extern IntPtr strncpy (StringBuilder dest,
> > 		string src, uint len);
> > 
> > Now, the bad news begins.  When I try this under Mono 0.29, the code
> > doesn't work correctly.  Nothing appears to be copied.
> 
> You forgot a more serious issue:
> 
> The first argument or strncpy is a `char *' and you can't just overwrite
> the managed `StringBuilder' instance.

The runtime is supposed to handle this transparently, so that
StringBuilder can be used with fixed-with buffers.

See (beware line wraps):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpcondefaultmarshalingforstrings.asp?frame=true&hidetoc=true

 - Jon




From jonpryor at vt.edu  Sun Feb  1 12:56:21 2004
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Sun, 01 Feb 2004 12:56:21 -0500
Subject: [Mono-devel-list] I want to help! (and learn)
In-Reply-To: <000001c3e6ab$233de1c0$6402a8c0@cyphosbox>
References: <000001c3e6ab$233de1c0$6402a8c0@cyphosbox>
Message-ID: <1075658179.25957.1079.camel@melchior.magi>

Q: Is there anything small that I can do to contribute to Mono?

A: Maybe.  In the fashion of all things that "should be simple, but I
just spent hours working on this @#$% thing!", Yes, there should be
small things you can do to contribute, but only because they *look*
small.  That doesn't mean that they *will be*. :-)

Bugs in bugzilla are always something that can be looked at.  Resolving
them might not even be required; just running CVS-current and checking
to see if the bugs still apply (cleaning up bugzilla) would likely be
useful.  At least, this is useful for the Gnome bugzilla site, judging
by mailing list messages...

Fixing sugzilla bugs would also be good.  As well as running the
regression tests, and fixing any bugs that they show.

Some of these will be easy; some of these will be hard.

Writing test cases would also be useful, so that we can keep our class
libraries in good shape.  This should be simple to do, and will be very
helpful in the long run, though test cases aren't always the most
interesting things to be writing...

On the VB front, if you're into compilers I'm sure the mbas compiler
could use some additional help; talk with Nick Drochak
<nickd at mono-cvs.ximian.com> and Rafael Teixeira
<rafael at mono-cvs.ximian.com>.

The Microsoft.VisualBasic assembly could also use some help, IIRC.  I
know that Rafael Teixeira has been working on this (judging from
mono-cvs-list), so talking with him might be good, too.

 - Jon

On Thu, 2004-01-29 at 16:01, Michael Weichert wrote:
> Hi,
> 
>  
> 
> First of all, I just wanted to say that this is the greatest project
> to ever come to Linux, IMO. I?ve been watching this project since it
> was first established. Anyhow, I love .net technology. I?m currently
> attending a private college called TriOS College studying the
> ?Enterprise Application Developer? program, currently learning VB.net
> and C#, but later pursuing the other .net technologies. Anyhow, I want
> to gain a better understanding of the framework and the languages
> themselves, and therefore thought it would be really great if I could
> help the Mono project. My programming skills are mostly intermediate
> at this point, but I?m very eager to learn and willing to do so. So,
> is there anything small that I contribute to the project? Even if it?s
> just adding those odd missing methods that have been put off because
> they?re so easy to implement or boring to code, I?ll take them! I?d
> love to see VB.net come to Linux, so if there?s anything I can do to
> help there that would be great. I?ve never really coded anything
> outside of school, so I?ll have to ask for your patience at first, but
> I definitely want to contribute to this wonderful project somehow.
> Thanks.
> 
>  
> 
>  
> 
> Regards,
> 
> Mike.
> 
>  
> 
>  
> 
> 



From duncan at ximian.com  Sun Feb  1 16:12:46 2004
From: duncan at ximian.com (Duncan Mak)
Date: Sun, 01 Feb 2004 16:12:46 -0500
Subject: [Mono-devel-list] Problem with P/Invoke
In-Reply-To: <1075654681.25957.1019.camel@melchior.magi>
References: <1075490214.2438.7.camel@localhost.localdomain>
	 <1075588042.25957.87.camel@melchior.magi>
	 <1075648049.1661.1.camel@gondor.martin.baulig>
	 <1075654681.25957.1019.camel@melchior.magi>
Message-ID: <1075669965.19281.3.camel@diphthong>

Hello,

On Sun, 2004-02-01 at 11:58, Jonathan Pryor wrote:
> The runtime is supposed to handle this transparently, so that
> StringBuilder can be used with fixed-with buffers.

I just confirmed this with Jon online,  this bug is not in CVS (0.30)
anymore. Here's the program we used to test:

using System;
using System.Runtime.InteropServices;
using System.Text;

class Test { 
        [DllImport ("libc")]
        static extern IntPtr strncpy (
                StringBuilder dest, string src, uint len);

        static void Main ()
        {
                string src = "test"; 
                uint len = (uint) src.Length;
                StringBuilder dest = new StringBuilder (src.Length);

                for (int i = 0; i < 10; i++) {
                        strncpy (dest, src, len);
                        Console.WriteLine (dest.ToString ());
                }
        }
}

The output is 10x "test".

I don't have time to check whether or not we have this in the test suite
somewhere now, but if we don't, we ought to.

Duncan.


From jonpryor at vt.edu  Sun Feb  1 16:14:40 2004
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Sun, 01 Feb 2004 16:14:40 -0500
Subject: [Mono-devel-list] Problem with P/Invoke
In-Reply-To: <1075588042.25957.87.camel@melchior.magi>
References: <1075490214.2438.7.camel@localhost.localdomain>
	 <1075588042.25957.87.camel@melchior.magi>
Message-ID: <1075670078.25957.1112.camel@melchior.magi>

On Sat, 2004-01-31 at 17:27, Jonathan Pryor wrote:
> Could someone running CVS try this example, with the above DllImport
> statement (and appropriate casts to uint), and see if this works?

Many thanks to duncan, who tried this on IRC today.  This is working
properly in CVS right now, and there is even a mono test case for it in
<cvs root="mono"/>/mono/tests/libtest.c:mono_test_marshal_stringbuilder.

 - Jon




From carlos at unixmexico.org  Sun Feb  1 19:23:44 2004
From: carlos at unixmexico.org (Carlos Alberto Cortez Guevara)
Date: Sun, 01 Feb 2004 18:23:44 -0600
Subject: [Mono-devel-list] Problem with P/Invoke
In-Reply-To: <1075588042.25957.87.camel@melchior.magi>
References: <1075490214.2438.7.camel@localhost.localdomain>
	 <1075588042.25957.87.camel@melchior.magi>
Message-ID: <1075681423.18560.7.camel@localhost.localdomain>

Hi,

I didn't know the problem about the function returns, but will take care
of them then (I had seen that IntPtr return in gtk-sharp, but thought it
wasn't neccessary at all ...)

I've seen duncan looked at a test. However, I'm seeing that if you try
to modify a string n-times, it will continue failing. 

If you have a code like:

<code>

[DllImport ("libc")]
private static extern IntPtr strncpy (StringBuilder dest, string src,
uint length);

string a = "Message to be printed";
StringBuilder s = new StringBuilder (a.Length);

for (int i = 1;i <= a.Length; i++) {
	strncpy (dest, src, i);
	Console.WriteLine (dest);
}

</code>

It will print ten "M". I've updated my mono modules from cvs, and I'm
still getting this error. Let me know if my tree is wrong ..

Thanks in advance,
Carlos.

El s?b, 31-01-2004 a las 16:27, Jonathan Pryor escribi?:
> There are a couple of problems with your DllImport statement.  First of
> all, strncpy(3) is documented as taking a "size_t n" argument, so your
> third argument should be uint, not int, though this really won't matter
> unless you try passing in negative values.
> 
> The second problem is more serious: you have a "string" return type. 
> .NET (and Mono), when marshaling functions with class return types (not
> structures), will attempt to free the memory of the of the returned
> object.  It is assumed that the runtime is supposed to take ownership of
> the memory in the return value.
> 
> Since strncpy(3) returns it's first argument, you *really* don't want
> the runtime to be freeing this memory, so you have two alternatives: use
> a "void" return type, or use System.IntPtr (which can then be converted
> to a string -- without freeing the memory -- using
> System.Runtime.InteropServices.Marshal.PtrToStringAnsi).
> 
> Thus, your DllImport should be:
> 
> 	[DllImport ("libc.so")]
> 	private static extern IntPtr strncpy (StringBuilder dest,
> 		string src, uint len);
> 
> Now, the bad news begins.  When I try this under Mono 0.29, the code
> doesn't work correctly.  Nothing appears to be copied.
> 
> Could someone running CVS try this example, with the above DllImport
> statement (and appropriate casts to uint), and see if this works?
> 
> Thanks,
>  - Jon
> 
> 
> On Fri, 2004-01-30 at 14:16, Carlos Alberto Cortez Guevara wrote:
> > Hi,
> > 
> > I was playing with some P/Invoke samples, and I found that the next code
> > doesn't work perfect.
> > 
> > I'm loading the strncpy function from the standard library (libc), and
> > the first call works perfect. However, in the second call (and third,
> > ..) it doesn't work.
> > 
> > Is this a bug?
> > 
> > Regards,
> > Carlos.
-- 
--------------------------------------------------
/* The definition of myself */
using Cortez;
using GeniusIntelligence;

public class Carlos : Human, IGenius, ILinuxUser {

	static void Main () {
		Me.Think();
	}

}

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


From miguel at novell.com  Mon Feb  2 00:45:40 2004
From: miguel at novell.com (Miguel de Icaza)
Date: Mon, 02 Feb 2004 00:45:40 -0500
Subject: [Mono-devel-list] The CVS tree is open.
Message-ID: <1075700739.5086.209.camel@erandi.boston.ximian.com>



From fa385084 at skynet.be  Sun Feb  1 12:04:41 2004
From: fa385084 at skynet.be (tropico)
Date: Sun, 01 Feb 2004 18:04:41 +0100
Subject: [Mono-devel-list] Small fix in README
Message-ID: <1075655081.2782.4.camel@localhost>

Hi

Small fix in mono README:

in the Upgrading to CVS section, there is an small error in the test:

Replace 

echo 'class X { static void Main () { System.Console.Write("OK");}'}' >
x.cs

with 

echo 'class X { static void Main () { System.Console.Write("OK");}}' >
x.cs

See you

Vincent



From jon at jellybob.co.uk  Sun Feb  1 15:02:13 2004
From: jon at jellybob.co.uk (Jon Wood)
Date: Sun, 01 Feb 2004 20:02:13 +0000
Subject: [Mono-devel-list] Mono on Windows, and associations
Message-ID: <1075665733.4604.61.camel@bertha>

Having just tried to get a 25 line C# application to run on a Windows
machine with Mono installed, I've come to the conclusion that it's too
much work at the moment, unless the person using it knows about
programming already (I just explained the concept of source to this
person).

As a stop gap measure, my thought is that we could associate .mexe with
Mono.

Jon



From martin at parvat.com  Sun Feb  1 23:07:11 2004
From: martin at parvat.com (Martin C.Atkins)
Date: Mon, 2 Feb 2004 09:37:11 +0530
Subject: [Mono-devel-list] Can one "hook" API functions?
In-Reply-To: <20040131123335.5ee92824.martin@parvat.com>
References: <20040128172409.7633a1f8.martin@parvat.com>
	<20040131123335.5ee92824.martin@parvat.com>
Message-ID: <20040202093711.6977c6e2.martin@parvat.com>

Sorry folks,

On Sat, 31 Jan 2004 12:33:35 +0530 Martin C.Atkins <martin at parvat.com> wrote:
>...
> OK. given the deafening silence, I guess there isn't a nice way. I'll
> just have to hack corelib/etc. :-(

I guess I was just too impatient! Many thanks to Jonathan and Miguel
for their responses. (Although the conclusion isn't changed! :-)

Martin

-- 
Martin C. Atkins			martin at parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}


From jackson at ximian.com  Mon Feb  2 05:30:04 2004
From: jackson at ximian.com (Jackson Harper)
Date: Mon, 02 Feb 2004 02:30:04 -0800
Subject: [Mono-devel-list] Small fix in README
In-Reply-To: <1075655081.2782.4.camel@localhost>
References: <1075655081.2782.4.camel@localhost>
Message-ID: <1075717803.28314.11.camel@localhost.localdomain>

fixed, thank you.

Jackson

On Sun, 2004-02-01 at 09:04, tropico wrote:
> Hi
> 
> Small fix in mono README:
> 
> in the Upgrading to CVS section, there is an small error in the test:
> 
> Replace 
> 
> echo 'class X { static void Main () { System.Console.Write("OK");}'}' >
> x.cs
> 
> with 
> 
> echo 'class X { static void Main () { System.Console.Write("OK");}}' >
> x.cs
> 
> See you
> 
> Vincent
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From spouliot at videotron.ca  Mon Feb  2 12:03:30 2004
From: spouliot at videotron.ca (=?iso-8859-1?Q?S=E9bastien_Pouliot?=)
Date: Mon, 02 Feb 2004 12:03:30 -0500
Subject: [Mono-devel-list] [PATCH] Principal support for AppDomain and Thread
Message-ID: <LNEAJLBKIAFKOPHEICIDGEFMDGAA.spouliot@videotron.ca>

Hello Mono,

Here's a patch to add support principals to AppDomain and Thread (with unit
tests). This should enable role-based access control using imperative
permissions.

Some tests requiring unloading appdomains are [Ignore]d for the moment
because they freeze nunit-console.
IIRC unloading support is incomplte or maybe I did something wrong ?

S?bastien

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PrincipalSupport.diff
Type: application/octet-stream
Size: 11911 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040202/8b331dde/attachment.obj 
-------------- next part --------------
//
// AppDomainTest.cs - NUnit Test Cases for AppDomain
//
// Author:
//	Sebastien Pouliot (sebastien at ximian.com)
//
// (C) 2004 Novell (http://www.novell.com)
//

using NUnit.Framework;
using System;
using System.Collections;
using System.IO;
using System.Reflection;
using System.Reflection.Emit;
using System.Security;
using System.Security.Policy;
using System.Security.Principal;

namespace MonoTests.System {

	[TestFixture]
	public class AppDomainTest : Assertion {

		private AppDomain ad;
		private ArrayList files = new ArrayList ();

		[TearDown]
		public void Unload () 
		{
			if (ad != null) {
				try {
// Mono has a problem unloading AppDomain
//					AppDomain.Unload (ad);
					ad = null;
				}
				catch {} // do not affect unit test results in TearDown
			}
			foreach (string fname in files) {
				File.Delete (fname);
			}
			files.Clear ();
		}

		[Test]
		public void SetThreadPrincipal () 
		{
			IIdentity i = new GenericIdentity ("sebastien at ximian.com", "rfc822");
			IPrincipal p = new GenericPrincipal (i, null);
			ad = AppDomain.CreateDomain ("SetThreadPrincipal");
			ad.SetThreadPrincipal (p);
		}

		[Test]
		[ExpectedException (typeof (ArgumentNullException))]
		public void SetThreadPrincipalNull ()
		{
			AppDomain.CurrentDomain.SetThreadPrincipal (null);
		}

		[Test]
		[ExpectedException (typeof (PolicyException))]
		public void SetThreadPrincipalTwice () 
		{
			IIdentity i = new GenericIdentity ("sebastien at ximian.com", "rfc822");
			IPrincipal p = new GenericPrincipal (i, null);
			ad = AppDomain.CreateDomain ("SetThreadPrincipalTwice");
			ad.SetThreadPrincipal (p);
			// you only live twice (or so James told me ;-)
			ad.SetThreadPrincipal (p);
		}

		[Test]
		[ExpectedException (typeof (AppDomainUnloadedException))]
		[Ignore ("Unloading cause a failure in Mono - stopping the unit tests")]
		public void SetThreadPrincipalUnloaded () 
		{
			ad = AppDomain.CreateDomain ("Ximian");
			AppDomain.Unload (ad);
			IIdentity i = new GenericIdentity ("sebastien at ximian.com", "rfc822");
			IPrincipal p = new GenericPrincipal (i, null);
			ad.SetThreadPrincipal (p);
		}

		[Test]
		public void SetPrincipalPolicy_NoPrincipal () 
		{
			AppDomain.CurrentDomain.SetPrincipalPolicy (PrincipalPolicy.NoPrincipal);
		}

		[Test]
		public void SetPrincipalPolicy_UnauthenticatedPrincipal () 
		{
			AppDomain.CurrentDomain.SetPrincipalPolicy (PrincipalPolicy.UnauthenticatedPrincipal);
		}

		[Test]
		public void SetPrincipalPolicy_WindowsPrincipal () 
		{
			AppDomain.CurrentDomain.SetPrincipalPolicy (PrincipalPolicy.WindowsPrincipal);
		}

		[Test]
		[ExpectedException (typeof (AppDomainUnloadedException))]
		[Ignore ("Unloading cause a failure in Mono - stopping the unit tests")]
		public void SetPrincipalPolicyUnloaded () 
		{
			AppDomain ad = AppDomain.CreateDomain ("Ximian");
			AppDomain.Unload (ad);
			ad.SetPrincipalPolicy (PrincipalPolicy.NoPrincipal);
		}
	}
}

From rafaelteixeirabr at hotmail.com  Mon Feb  2 13:19:24 2004
From: rafaelteixeirabr at hotmail.com (A Rafael D Teixeira)
Date: Mon, 02 Feb 2004 16:19:24 -0200
Subject: [Mono-devel-list] [PATCH] Principal support for AppDomain and Thread
Message-ID: <SEA2-F32hdbRMy6wGbf0003b3c9@hotmail.com>

>From: S?bastien Pouliot <spouliot at videotron.ca>
>
>Here's a patch to add support principals to AppDomain and Thread (with unit
>tests). This should enable role-based access control using imperative
>permissions.

Wonderful!!!

>Some tests requiring unloading appdomains are [Ignore]d for the moment
>because they freeze nunit-console.
>IIRC unloading support is incomplte or maybe I did something wrong ?

Well that's happenning for my tests too, I just Ctrl-C after the warning, 
but surely something is wrong...

Fun,

Rafael Teixeira
Brazilian Polymath
Mono Hacker since 16 Jul 2001
MonoBrasil Founding Member - Membro Fundador do MonoBrasil
English Blog: http://monoblog.blogspot.com/
Brazilian Portuguese Blog: http://monoblog.weblogger.terra.com.br/

>
>S?bastien
>
><< PrincipalSupport.diff >>
><< AppDomainTest.cs >>

_________________________________________________________________
MSN Messenger: instale gr?tis e converse com seus amigos. 
http://messenger.msn.com.br



From gonzalo at ximian.com  Mon Feb  2 17:27:15 2004
From: gonzalo at ximian.com (Gonzalo Paniagua Javier)
Date: Mon, 02 Feb 2004 23:27:15 +0100
Subject: [Mono-devel-list] Authentication and SoapHttpClientProtocol
In-Reply-To: <23BE0C16E0C22F48B3FB5B0BD6B5307B0A0F4A@visdd003.devdd.vi.lan>
References: <23BE0C16E0C22F48B3FB5B0BD6B5307B0A0F4A@visdd003.devdd.vi.lan>
Message-ID: <1075760835.1340.178.camel@localhost>

El vie, 30-01-2004 a las 10:18, J?rg Rosenkranz escribi?:
> Hello all,
>  
> We're accessing a PHP webservice using a generated web service client class 
> (Child class of SoapHttpClientProtocol). This works very well. 
>  
> Now we've activated Authentication on the web server using a .htaccess file 
> with Basic authentication. We're using following code to authenticate the
> web service client:
>  
>   _service.PreAuthenticate = true;
> 
>   _service.Credentials = new NetworkCredential("Username", "Password");
> 
> This works under MS.NET. It throws  System.Net.WebException
> "Request error. Return code was: Unauthorized" under Mono. Is this a
> known problem and are there any workarounds?

There's a bug report for this, afair. We'll get to it soon.

Thanks.

-Gonzalo




From miguel at novell.com  Mon Feb  2 19:18:43 2004
From: miguel at novell.com (Miguel de Icaza)
Date: Mon, 02 Feb 2004 19:18:43 -0500
Subject: [Mono-devel-list] Mono 0.30 has been released.
Message-ID: <1075767523.5086.444.camel@erandi.boston.ximian.com>

Hello,

    Mono 0.30 has been released, the release notes with details are
here:

	http://www.go-mono.com/archive/mono-0.30.html

Enjoy,
Miguel.



From danielmorgan at verizon.net  Mon Feb  2 21:13:18 2004
From: danielmorgan at verizon.net (Daniel Morgan)
Date: Mon, 2 Feb 2004 21:13:18 -0500
Subject: [Mono-devel-list] Windows Installers for Mono 0.30 and GTK# 0.15
Message-ID: <OEEFLJJACNOBNHOAAKNJGEEECCAA.danielmorgan@verizon.net>

If you want only Mono, you can get the
Mono 0.30 Windows Installer here:

http://www.go-mono.com/archive/0.30/windows/mono-0.30-win32-2.exe


If you want only GTK#, you can get the
GTK# 0.15 Windows Installer here:

http://prdownloads.sourceforge.net/gtk-sharp/gtk-sharp-0.15-win32-setup.exe?
download


If you want both Mono and gtk#, you can get the
Mono 0.30 and gtk# 0.15 (gtk+ 2.2) Windows Installer here:

http://www.go-mono.com/archive/0.30/windows/mono-0.30-gtksharp-0.15-win32-1.
exe



From mstanley at cauldronsolutions.com  Mon Feb  2 11:14:21 2004
From: mstanley at cauldronsolutions.com (Mike Stanley)
Date: Mon, 2 Feb 2004 11:14:21 -0500
Subject: [Mono-devel-list] Hardware Requirements (Porting)
Message-ID: <E1AngiM-0005Jl-UP@visor.electric.net>

Hi All.  
 
I'm new to the list, fairly new to mono, and definitely a newbie when it
comes to porting.  I'm an expert J2EE developer, intermediate .NET
developer, and rusty C developer.  Lately, I've been working primarily in
the embedded C arena, and would love to be able to port mono to a target
platform.   I'm not necessarily interested in a JIT runtime compiler, but
rather just interested in having the ability to compile c# to a native
application.   
 
Before I head down this path, I just wanted to know whether or not it would
be possible.  What is the minimum system requirements for porting mono?  I'm
looking for a recommendation (yeah or nah) given the following specs (and
given your experiences):
 
- 166 MHz (MIPS) 32 bit RISC Processor
- 16 Mb DRAM
- 4 Mb Graphic Dram
- 4 Mb Flash EPROM
 
If possible can someone give me an idea about the level of difficulty and
time estimate (minus the reading - which I know is substantial.  btw. I have
a comp. eng. background, with hardware, assembly lang, os dev, experience)
 
Thanks in advance for any advice...
- Mike Stanley
 
P.S.  Out of curiosity has anyone attempted to port mono to the new TI
and/or ARM based Palm OS devices?  
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040202/e9c80343/attachment.html 

From erand at mainsoft.com  Tue Feb  3 07:58:45 2004
From: erand at mainsoft.com (Eran Domb)
Date: Tue, 03 Feb 2004 14:58:45 +0200
Subject: [Mono-devel-list] [PATCH] System.Data.DataSet.cs compatebility with ms.net
Message-ID: <401F9B05.8030608@mainsoft.com>

Hello,

I found that in MS.Net the method GetSchemaSerializable return null 
(This is an undocumented method).
Also I found that when VisualStudio.Net generates TypedDataSet they 
override this method and in the implementation
they call WriteXmlSchema. This thing is causing an infinite loop in MONO 
implementation : WriteXmlSchema calls DoWriteXmlSchema which calls 
GetSchemaSerializable that calls again to WriteXmlSchema. This ends with 
stack overflow.
The patch solves this problem.

If no one objects I will commit.

Index: DataSet.cs
===================================================================
RCS file: /cvs/public/mcs/class/System.Data/System.Data/DataSet.cs,v
retrieving revision 1.61
diff -u -r1.61 DataSet.cs
--- DataSet.cs    2 Feb 2004 09:01:23 -0000    1.61
+++ DataSet.cs    3 Feb 2004 12:29:10 -0000
@@ -926,7 +926,7 @@
        
         protected virtual System.Xml.Schema.XmlSchema 
GetSchemaSerializable ()
         {
-            return BuildSchema ();
+            return null;
         }
        
         protected virtual void ReadXmlSerializable (XmlReader reader)
@@ -1473,7 +1473,7 @@
 
         private void DoWriteXmlSchema (XmlWriter writer)
         {
-            GetSchemaSerializable ().Write (writer);
+            BuildSchema ().Write (writer);
         }
        
         ///<summary>



From sourcejedi at phonecoop.coop  Tue Feb  3 05:55:45 2004
From: sourcejedi at phonecoop.coop (Alan Jenkins)
Date: 03 Feb 2004 10:55:45 +0000
Subject: [Mono-devel-list] Building mcs with generics profile
In-Reply-To: <20040120102245.GB4888@ox.compsoc.net>
References: <20040117234127.GW4888@ox.compsoc.net>
	<LNEAJLBKIAFKOPHEICIDOEPNDEAA.spouliot@videotron.ca> 
	<20040120102245.GB4888@ox.compsoc.net>
Message-ID: <1075805745.15390.8.camel@nova>

I have just downloaded mono/mcs 0.30.  I followed the instructions in
the mono docs to build mcs using the generics profile (after building &
installing mono).  It fails because it tries to compile the source for
gmcs.exe using gmcs.exe:

src at nova:~/mcs-0.30> ./configure --profile=generics

MCS module configured

     Profile selected: generics
     Prefix:           /usr/local

src at nova:~/mcs-0.30> make
make[1]: Entering directory `/home/src/mcs-0.30/build'
make[1]: Leaving directory `/home/src/mcs-0.30/build'
make[1]: Entering directory `/home/src/mcs-0.30/jay'
make[1]: Leaving directory `/home/src/mcs-0.30/jay'
make[1]: Entering directory `/home/src/mcs-0.30/mcs'
MONO_PATH="../class/lib:$MONO_PATH" mono  --debug ../gmcs/gmcs.exe  
-d:NET_1_1 -d:NET_1_2 -d:GENERICS -2 -g /target:exe /out:mcs.exe
AssemblyInfo.cs anonymous.cs assign.cs attribute.cs driver.cs
cs-tokenizer.cs cfold.cs class.cs codegen.cs const.cs constant.cs
convert.cs decl.cs delegate.cs enum.cs ecore.cs expression.cs
flowanalysis.cs genericparser.cs interface.cs iterators.cs literal.cs
location.cs modifiers.cs namespace.cs parameter.cs pending.cs report.cs
rootcontext.cs statement.cs support.cs typemanager.cs symbolwriter.cs
tree.cs cs-parser.cs
cannot open assembly ../gmcs/gmcs.exe
make[1]: *** [mcs.exe] Error 2
make[1]: Leaving directory `/home/src/mcs-0.30/mcs'
make: *** [all-recursive] Error 1

Is this my problem, is the makefile at fault, or should gmcs.exe be
provided (like mcs.exe is, from the mono package)?


From danielmorgan at verizon.net  Tue Feb  3 21:49:24 2004
From: danielmorgan at verizon.net (Daniel Morgan)
Date: Tue, 3 Feb 2004 21:49:24 -0500
Subject: [Mono-devel-list] Test Integrated Security in System.Data.SqlClient
Message-ID: <OEEFLJJACNOBNHOAAKNJKEFCCCAA.danielmorgan@verizon.net>

Can developers test Integrated Security in System.Data.SqlClient for me
please?

Integrated Security aka NTLM Authentication aka Domain Login aka Windows
Authentication
was added to Mono around versions 0.29/0.30.

With the release of Mono 0.30, can people test connecting to Microsoft SQL
Server 2000 via Windows Authentication?

Please note: in Mono's version of SqlClient, you need to give your Windows
User ID and Password for it to work.

If you are on a Windows domain, you can use this connection string:
"Server=SERVER_HOSTNAME;" +
"Database=DATABASE_NAME;" +
"User ID=DOMAIN_NAME\user_name;" +
"Password=your_password;"

If you are not, and you have SQL Server installed locally, you can use this
connection string:
"Server=localhost;" +
"Database=DATABASE_NAME;" +
"User ID=windows_user;" +
"Password=your_password;"
"Integrated Security=SSPI;"

I really would like to get feedback on this whether or not it works for you.
If you are able to debug the problem or isolate a test case -- even the
better!

Thanks,
Daniel



From danielmorgan at verizon.net  Tue Feb  3 23:26:57 2004
From: danielmorgan at verizon.net (Daniel Morgan)
Date: Tue, 3 Feb 2004 23:26:57 -0500
Subject: [Mono-devel-list] Windows Installers for Mono 0.30 and GTK# 0.15
In-Reply-To: <OEEFLJJACNOBNHOAAKNJGEEECCAA.danielmorgan@verizon.net>
Message-ID: <OEEFLJJACNOBNHOAAKNJMEFDCCAA.danielmorgan@verizon.net>

Oh, I forgot to mention.  Included in the Mono 0.30/gtk# 0.15 installer is a
Bonus.  SQL# For GTK#.  It isn't great, but it works out-of-the-box on
Windows 2000 and XP Pro!  I'm sure it has many bug begging for some
attention.  By the way, SQL# was inpsired by GNOME-DB.

1. download it
2. install it
3. open a DOS prompt
4. type sqlsharpgtk and press Enter

You can't get any easier than that!

I'm not promising anything spectacular, but its a great start for Mono and
GTK#!

Note: this does not exist in the Mono 0.30 only nor gtk# 0.15 only
installers.

-----Original Message-----
From: mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com]On Behalf Of Daniel
Morgan
Sent: Monday, February 02, 2004 9:13 PM
To: Mono-Devel-List; Mono-Hackers-List; Mono-List
Subject: [Mono-devel-list] Windows Installers for Mono 0.30 and GTK#
0.15


If you want only Mono, you can get the
Mono 0.30 Windows Installer here:

http://www.go-mono.com/archive/0.30/windows/mono-0.30-win32-2.exe


If you want only GTK#, you can get the
GTK# 0.15 Windows Installer here:

http://prdownloads.sourceforge.net/gtk-sharp/gtk-sharp-0.15-win32-setup.exe?
download


If you want both Mono and gtk#, you can get the
Mono 0.30 and gtk# 0.15 (gtk+ 2.2) Windows Installer here:

http://www.go-mono.com/archive/0.30/windows/mono-0.30-gtksharp-0.15-win32-1.
exe

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



From leadershipopensource at katamail.com  Wed Feb  4 09:13:39 2004
From: leadershipopensource at katamail.com (Gianluca Bosco)
Date: Wed, 04 Feb 2004 14:13:39 +0000
Subject: [Mono-devel-list] [leadership/opensource] invitation to online survey
Message-ID: <130.226.213.116+06rHLIXa18tuJ01a@hal-2.inet.it>

Dear all,

      I have just put online a survey addressing the topic of "leadership
in the open-source environment". Basically, my objective is to
identify the personal conceptions of good leadership that reside in
the minds of the contributors, in terms of leaders' _behaviors_ and
_characteristics_.

What is a good open-source project leader, from the
contributor's point of view? To what extent, those personal believes are
shared among developers? Can the contributor's national cultural belonging
and level of experience in contributing to open-source projects explain such
differences in their idea of what a good leader is?

I would really appreciate your participation to the survey! Contribution
(*completely* anonymous) consists in rating a list of statements that may be
used to describe the behaviors of an open-source leader. It will take around
ten minutes - there aren't any "time-consuming" open ended questions;)

Following, the link to the survey:

http://freeonlinesurveys.com/rendersurvey.asp?id=52191

If you are interested, I will not miss to email you a link to the
final report, when ready ;) (approx, a couple of months from now)

Thank you in advance, and don't hesitate to contact me if you have
any questions or comments :)

Gianluca Bosco
g.bosco at GETRIDOFTHISinwind.it
Denmark Technical University
Department of manufacturing engineering and management


From mikkel at linet.dk  Wed Feb  4 10:15:02 2004
From: mikkel at linet.dk (Mikkel Kruse Johnsen)
Date: Wed, 04 Feb 2004 16:15:02 +0100
Subject: [Mono-devel-list] Embedding C# in C, domains
Message-ID: <1075907701.6905.12.camel@mikkel.orholm.dk>

Hi All

Im working on embedding C# in my C program. What I wanna do is being
able to load a Bonobo Object into my C program by having the activated
shlib embed C#, parsing the pointer to the BonoboObject on to C#, which
wraps Bonobo, just like Gtk# wraps Gtk+, setting the pointer to the
"IntPtr Raw".

I can then access the pointer with this.Handle (this.Raw). All of this
is working, but the problem is domains, Im a bit confused about domain.

I now create one domain (mono_jit_init) and I can load a lot of bonobo
objects, but when closing one of them, the others don't work.

---

1: Should I create a new domain for each Bonobo Object I create ?

2: Should I create one global domain, with "mono_jit_init" ?

2.1: The def. is mono_jit_init (const gchar *filename), is it the
filename or is it the name of the domain.

3: Is there one global domain, and then you create sub domain, with
"mono_domain_create", my program fails when domain
mono_domain_assembly_open using a domain created like this.

4: What is "mono_runtime_init", "mono_runtime_cleanup",
"mono_runtime_quit", etc.

---

If someone could just explain a little about the ideas behind domains, I
you be so happy, or point me to some doc (that google hasn't picked up
yet :)

/Mikkel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040204/b4653f8b/attachment.bin 

From jason.king at profox.co.uk  Wed Feb  4 11:12:00 2004
From: jason.king at profox.co.uk (Jason King)
Date: Wed, 4 Feb 2004 16:12:00 -0000
Subject: [Mono-devel-list] Isolated Storage and Code Access Security
Message-ID: <JDEEKAHPEBFHCCNMGFFKKEMGCGAA.jason.king@profox.co.uk>

Hello everyone,

Try as I might, I can't seem to find any information about Mono's plans for
Code Access Security or Isolated Storage.

Is anybody working on these items, or is there a strategy in place for
meeting these items in the future?

Jase

Regards,
Jason King
Profox Systems Ltd 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 1668 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040204/10c5d354/attachment.bin 

From jason.king at profox.co.uk  Wed Feb  4 10:50:45 2004
From: jason.king at profox.co.uk (Jason King)
Date: Wed, 4 Feb 2004 15:50:45 -0000
Subject: [Mono-devel-list] GAC, Shared Assemblies and Assembly Versioning
Message-ID: <JDEEKAHPEBFHCCNMGFFKCEMGCGAA.jason.king@profox.co.uk>

Hello

Given that Mono users have the freedom to install Mono and supporting
libraries pretty much wherever they like, where does this leave the Mono
implementation of the global assembly cache?  For example, say I want to add
a shared assembly so that all apps on my machine can use it...?

Are there any plans for assembly versioning in Mono?

Thanks for any advice, plans or help with this issue.

Jase

Regards,
Jason King
Profox Systems Ltd 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 1796 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040204/3be1ecc4/attachment.bin 

From spouliot at videotron.ca  Wed Feb  4 13:03:56 2004
From: spouliot at videotron.ca (=?iso-8859-1?Q?S=E9bastien_Pouliot?=)
Date: Wed, 04 Feb 2004 13:03:56 -0500
Subject: [Mono-devel-list] Isolated Storage and Code Access Security
In-Reply-To: <JDEEKAHPEBFHCCNMGFFKKEMGCGAA.jason.king@profox.co.uk>
Message-ID: <LNEAJLBKIAFKOPHEICIDOEJADGAA.spouliot@videotron.ca>

Jason,

Here some info. Please have a look in the mailing-list archives
(http://www.go-mono.com/mailing-lists.html) for more informations.


Code Access Security

*Roadmap
 	http://www.go-mono.com/mono-roadmap.html
	See: Unscheduled activities

* Definition
 	http://www.go-mono.com/mono-todo.html

* Task
	http://bugzilla.ximian.com/show_bug.cgi?id=52606

* Conclusion
	Someone is working on it but it won't be part of Mono 1.0.


Isolated Storage

* Class status
	http://www.go-mono.com/class-status-corlib.html

* Conclusion
	Incomplete. IIRC no one has worked in the classes for quite some time.


Help for both tasks is welcome!

S?bastien
http://pages.infinit.net/ctech/poupou.html


>  -----Original Message-----
> From: 	mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com]
> Sent:	4 f?vrier 2004 11:12
> To:	Mono List
> Subject:	[Mono-devel-list] Isolated Storage and Code Access Security
>
> Hello everyone,
>
> Try as I might, I can't seem to find any information about Mono's plans
for Code Access Security or Isolated Storage.
>
> Is anybody working on these items, or is there a strategy in place for
meeting these items in the future?
>
> Jase
>
> Regards,
> Jason King
> Profox Systems Ltd
>



From spouliot at videotron.ca  Wed Feb  4 13:07:16 2004
From: spouliot at videotron.ca (=?iso-8859-1?Q?S=E9bastien_Pouliot?=)
Date: Wed, 04 Feb 2004 13:07:16 -0500
Subject: [Mono-devel-list] GAC, Shared Assemblies and Assembly Versioning
In-Reply-To: <JDEEKAHPEBFHCCNMGFFKCEMGCGAA.jason.king@profox.co.uk>
Message-ID: <LNEAJLBKIAFKOPHEICIDGEJBDGAA.spouliot@videotron.ca>

Jason,

Strongnames are working and a gacutil tool has been created. There are still
some issues (like strongnaming mono assemblies in a way that is compatible
with MS keys) but nothing major. So (hopefully) soon ;-)

S?bastien Pouliot
http://pages.infinit.net/ctech/poupou.html


>  -----Original Message-----
> From: 	mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com]
> Sent:	4 f?vrier 2004 10:51
> To:	Mono List
> Subject:	[Mono-devel-list] GAC, Shared Assemblies and Assembly Versioning
>
> Hello
>
> Given that Mono users have the freedom to install Mono and supporting
libraries pretty much wherever they like, where does this leave the Mono
implementation of the global assembly cache?  For example, say I want to add
a shared assembly so that all apps on my machine can use it...?
>
> Are there any plans for assembly versioning in Mono?
>
> Thanks for any advice, plans or help with this issue.
>
> Jase
>
> Regards,
> Jason King
> Profox Systems Ltd
>



From wingman at techmonkeys.org  Wed Feb  4 13:21:44 2004
From: wingman at techmonkeys.org (Christian Birkl)
Date: Wed, 4 Feb 2004 19:21:44 +0100
Subject: [Mono-devel-list] ICodeParser && Mono
Message-ID: <001601c3eb4b$c2626a10$0200a8c0@winghome>

Hi all,

Is there something equivalent to Microsoft.CSharp namespace in Mono? I
can't find any in the current class/ directory in recent cvs. I'm
specifically interested in Microsoft.CSharp.CSharpProvider. I'd like to
do some code analysing stuff via ICodeProvider, which can create a
CodeCompileUnit via .CreateParser().Parse(). This would be a much nicer
way than doing the parsing on my own. But unfortuntly .CreateParser() is
defined to *always* return null. It would be nice if Mono would break
this MS behaviour (or somehow provide a second .CreateParser() method.).


My second question is wether mcs (mono c# compiler) internally actually
uses System.CodeDom for its code creation or not. And if yes, how can i
access the CodeDom created by the parser?

Regards,

	Christian



From miguel at ximian.com  Wed Feb  4 14:04:53 2004
From: miguel at ximian.com (Miguel de Icaza)
Date: Wed, 04 Feb 2004 14:04:53 -0500
Subject: [Mono-devel-list] Hardware Requirements (Porting)
In-Reply-To: <E1AngiM-0005Jl-UP@visor.electric.net>
References: <E1AngiM-0005Jl-UP@visor.electric.net>
Message-ID: <1075921492.4700.655.camel@erandi.boston.ximian.com>

Hello,

 
> I'm new to the list, fairly new to mono, and definitely a newbie when
> it comes to porting.  I'm an expert J2EE developer, intermediate .NET
> developer, and rusty C developer.  Lately, I've been working primarily
> in the embedded C arena, and would love to be able to port mono to a
> target platform.   I'm not necessarily interested in a JIT runtime
> compiler, but rather just interested in having the ability to compile
> c# to a native application.   

Mono today does not support generating a standalone executable.  But
we can pre-compile the code to avoid any JITing if that is what you
want.

You still need the original image, and the precompiled image though.


>  not it would be possible.  What is the minimum system requirements
> for porting mono?  I'm looking for a recommendation (yeah or nah)
> given the following specs (and given your experiences):
>  
> - 166 MHz (MIPS) 32 bit RISC Processor
> - 16 Mb DRAM
> - 4 Mb Graphic Dram
> - 4 Mb Flash EPROM
>  
> If possible can someone give me an idea about the level of difficulty
> and time estimate (minus the reading - which I know is substantial. 
> btw. I have a comp. eng. background, with hardware, assembly lang, os
> dev, experience)

You might want to read the porting document:

	http://www.go-mono.com/porting.html


From miguel at ximian.com  Wed Feb  4 14:05:49 2004
From: miguel at ximian.com (Miguel de Icaza)
Date: Wed, 04 Feb 2004 14:05:49 -0500
Subject: [Mono-devel-list] Building mcs with generics profile
In-Reply-To: <1075805745.15390.8.camel@nova>
References: <20040117234127.GW4888@ox.compsoc.net>
	 <LNEAJLBKIAFKOPHEICIDOEPNDEAA.spouliot@videotron.ca>
	 <20040120102245.GB4888@ox.compsoc.net>  <1075805745.15390.8.camel@nova>
Message-ID: <1075921548.4700.657.camel@erandi.boston.ximian.com>

Hello!

> Is this my problem, is the makefile at fault, or should gmcs.exe be
> provided (like mcs.exe is, from the mono package)?

This is a small buglet.

Please type:

	cd mcs-0.30/gmcs
	make

And then resume the build.

Basically, the profile did not compile the MCS with Generics compiler.


From jackson at ximian.com  Wed Feb  4 14:47:18 2004
From: jackson at ximian.com (Jackson Harper)
Date: Wed, 04 Feb 2004 11:47:18 -0800
Subject: [Mono-devel-list] tool for converting from csproj2make
Message-ID: <1075924038.5700.21.camel@localhost.localdomain>

Hello,

	While doing some porting last week I wrote a little tool for converting
csproj files to basic makefiles. Its really simple and just does what
*I* needed it to do, but it may be of some help to other people. As soon
as I get some time I will make it more bad ass so please send me
suggestions.

http://primates.ximian.com/~jackson/csproj2make-0.0.1.tar.gz

Jackson





From wingman at techmonkeys.org  Wed Feb  4 14:41:50 2004
From: wingman at techmonkeys.org (Christian Birkl)
Date: Wed, 4 Feb 2004 20:41:50 +0100
Subject: [Mono-devel-list] (Il)legal code check-ins
Message-ID: <001701c3eb56$f17e58d0$0200a8c0@winghome>

Hi all,

when is it "illegal" (sorry, can't find any better word) to check-in
code to mono? I'm sure about some points, like if i decompile Microsoft
assemblies and use the generated code as base of the new code, but what
about using MSDN documentation and such stuff? Or how about testing what
a method returns and how it behavious with different parameters? When
will (exactly) i'm not be allowed to contribute code?

Regards,

	Christian



From rafaelteixeirabr at hotmail.com  Wed Feb  4 15:11:47 2004
From: rafaelteixeirabr at hotmail.com (A Rafael D Teixeira)
Date: Wed, 04 Feb 2004 18:11:47 -0200
Subject: [Mono-devel-list] ICodeParser && Mono
Message-ID: <SEA2-F33RkRm502R39H00084012@hotmail.com>

>From: "Christian Birkl" <wingman at techmonkeys.org>
>
>Hi all,
>
>Is there something equivalent to Microsoft.CSharp namespace in Mono?

Sure, that namespace is in the System Assembly (System.dll) [pay attention 
to msdn documentation, please]

>I can't find any in the current class/ directory in recent cvs.

It's in mcs/class/System/Microsoft.CSharp/   [that is our convention to 
place source files]

>I'm specifically interested in Microsoft.CSharp.CSharpProvider. I'd like to
>do some code analysing stuff via ICodeProvider, which can create a
>CodeCompileUnit via .CreateParser().Parse(). This would be a much nicer
>way than doing the parsing on my own. But unfortuntly .CreateParser() is
>defined to *always* return null.

If so, Mono implementation will do the same...

>It would be nice if Mono would break
>this MS behaviour (or somehow provide a second .CreateParser() method.).

If needed we can expose a class/method in another namespace AND assembly.

>My second question is wether mcs (mono c# compiler) internally actually
>uses System.CodeDom for its code creation or not.

Well, you are confusing things, mcs is a compiler it just compiles C# code.

C# code generation is done by the Microsoft.CSharp.CSharpCodeProvider, and 
is used, for example, in System.Web to generate classes from aspx pages.

>And if yes, how can i access the CodeDom created by the parser?

No, you instantiate de CodeDom classes to create code not the reverse. More 
a parser would generate a lot more information than what is possible to 
represent in the CodeDom format...

>Regards,
>
>	Christian

Regards,

Rafael Teixeira
Brazilian Polymath
Mono Hacker since 16 Jul 2001
MonoBrasil Founding Member - Membro Fundador do MonoBrasil
English Blog: http://monoblog.blogspot.com/
Brazilian Portuguese Blog: http://monoblog.weblogger.terra.com.br/

_________________________________________________________________
MSN Messenger: instale gr?tis e converse com seus amigos. 
http://messenger.msn.com.br



From sourcejedi at phonecoop.coop  Wed Feb  4 15:37:39 2004
From: sourcejedi at phonecoop.coop (Alan Jenkins)
Date: 04 Feb 2004 20:37:39 +0000
Subject: [Mono-devel-list] Building mcs with generics profile
In-Reply-To: <1075921548.4700.657.camel@erandi.boston.ximian.com>
References: <20040117234127.GW4888@ox.compsoc.net>
	<LNEAJLBKIAFKOPHEICIDOEPNDEAA.spouliot@videotron.ca>
	<20040120102245.GB4888@ox.compsoc.net>  <1075805745.15390.8.camel@nova> 
	<1075921548.4700.657.camel@erandi.boston.ximian.com>
Message-ID: <1075927060.2519.24.camel@nova>

On Wed, 2004-02-04 at 19:05, Miguel de Icaza wrote:
> Hello!
> 
> > Is this my problem, is the makefile at fault, or should gmcs.exe be
> > provided (like mcs.exe is, from the mono package)?
> 
> This is a small buglet.
> 
> Please type:
> 
> 	cd mcs-0.30/gmcs
> 	make
> 
> And then resume the build.

Oops!
I did actually try doing that, but I left that out of my original
email.  I had pretty much the same error:

src at nova:~/mcs-0.30> cd gmcs/
src at nova:~/mcs-0.30/gmcs> make
MONO_PATH="../class/lib:$MONO_PATH" mono  --debug ../gmcs/gmcs.exe  
-d:NET_1_1 -d:NET_1_2 -d:GENERICS -2 -g /target:exe /out:gmcs.exe
AssemblyInfo.cs anonymous.cs assign.cs attribute.cs driver.cs
cs-tokenizer.cs cfold.cs class.cs codegen.cs const.cs constant.cs
convert.cs decl.cs delegate.cs enum.cs ecore.cs expression.cs
flowanalysis.cs generic.cs interface.cs iterators.cs literal.cs
location.cs modifiers.cs namespace.cs parameter.cs pending.cs report.cs
rootcontext.cs statement.cs support.cs typemanager.cs symbolwriter.cs
tree.cs cs-parser.cs
cannot open assembly ../gmcs/gmcs.exe
make: *** [gmcs.exe] Error 2
src at nova:~/mcs-0.30/gmcs> 

Thats why I said it fails because it tries to compile the source for
gmcs.exe using gmcs.exe.  I guess I should read my emails more
carefully.

I can't use the default profile to compile gmcs either - the default
corlib is missing all the generic stuff:

src at nova:~/mcs-0.30/gmcs> make
mcs   -d:NET_1_1 -d:ONLY_1_1 -g /target:exe /out:gmcs.exe
AssemblyInfo.cs anonymous.cs assign.cs attribute.cs driver.cs
cs-tokenizer.cs cfold.cs class.cs codegen.cs const.cs constant.cs
convert.cs decl.cs delegate.cs enum.cs ecore.cs expression.cs
flowanalysis.cs generic.cs interface.cs iterators.cs literal.cs
location.cs modifiers.cs namespace.cs parameter.cs pending.cs report.cs
rootcontext.cs statement.cs support.cs typemanager.cs symbolwriter.cs
tree.cs cs-parser.cs
decl.cs(403) error CS0117: `System.Type' does not contain a definition
for `IsGenericParameter'

....

typemanager.cs(1472) error CS0117: `System.Type' does not contain a
definition for `IsGenericInstance'
Compilation failed: 28 error(s), 3 warnings
make: *** [gmcs.exe] Error 1

I think there's a circular dependancy here - and unlike that of mcs, it
is not resolved by installing the mono package first.

Thanks
	Alan


From bmaurer at users.sourceforge.net  Wed Feb  4 16:49:07 2004
From: bmaurer at users.sourceforge.net (Ben Maurer)
Date: Wed, 04 Feb 2004 16:49:07 -0500
Subject: [Mono-devel-list] (Il)legal code check-ins
In-Reply-To: <001701c3eb56$f17e58d0$0200a8c0@winghome>
References: <001701c3eb56$f17e58d0$0200a8c0@winghome>
Message-ID: <1075931347.2457.35.camel@Ben>

Under this goes looking at the MS documentation and creating an
implementation compliant with theirs. The only information that is
copyrighted in the documentation is the words themselves. So, it is *ok*
to take the *facts* out of a document, but not ok to take the *words*

A real life example of the above is using a newspaper article for a
paper. There are three things you could do:

1) Make a reference to a fact in the article ("50 people were killed by
a bomer attack in Russia on July 15th"). Legally, you do not need to do
anything else. Obviously, good academic standards require that you cite
your source.

2) Take a small quote from the article ("`Officials said that 50 people
were killed in today's attack," said the July 15th edition of the New
York Times). Again, you need to nothing else. This falls under Fair Use.
(google that term).

3) Quoting a large portion of the article. This is not allowed. The text
of the article is likely copyrighted, and you cannot copy it word for
word.

The line between 1 and 2 is pretty clear, but 2 and 3 is fuzzy.

So, some Mono connections. The following would be ok:

// (This comment is OK because of 1 above)
// According to the MS documentation, this foos
void Foo () {
    // `Foo throws an exception if Bar is ture' (although
    // this is a direct quote, it falls under fair use).

    if (bar) throw new Exception ();
}

However, it would *not* be ok, to copy lots of documentation word for
word. For example, copying the entire `remarks' section for a method
would not be ok.

Testing how a progam works in different conditions is OK. The code in
the MS.net implementation is copyrighted. So, the only restriction is
that you may not copy the *TEXT* of the code (or disassembled code).
Legally, it is ok to look at disassembled code, however we stay away
from it for two reasons: first, it restricts the creativity in our
implementation, secondly by not looking at the code we prevent the
argument that we are infact copying code.

However, testing what a method returns is absolutely OK.

I hope this clears things up.

-- Ben 

On Wed, 2004-02-04 at 14:41, Christian Birkl wrote:
> Hi all,
> 
> when is it "illegal" (sorry, can't find any better word) to check-in
> code to mono? I'm sure about some points, like if i decompile Microsoft
> assemblies and use the generated code as base of the new code, but what
> about using MSDN documentation and such stuff? Or how about testing what
> a method returns and how it behavious with different parameters? When
> will (exactly) i'm not be allowed to contribute code?
> 
> Regards,
> 
> 	Christian
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From wingman at techmonkeys.org  Wed Feb  4 17:07:58 2004
From: wingman at techmonkeys.org (Christian Birkl)
Date: Wed, 4 Feb 2004 23:07:58 +0100
Subject: [Mono-devel-list] Path.Combine, Directory.DirectorySeperatorChar, String.Format...?
Message-ID: <001e01c3eb6b$5abc1710$0200a8c0@winghome>

Hi all,

now that .Net becomes platform independend it raises the question of how
handling filenames. After reading some of mono sources i found three
major versions of dealing with the "/" or "\" issues, but which should
now be used?

1. Path.Combine

	Usage:
		string path = Path.Combine("home", "username");

	Advantage(s):
		No need to mess around with Path.DirectorySeparatorChar.
	Disadvantage(s)
		Looks (and performes?) somewhat ugly when combining
		a depth directory structure like:
			/usr/local/some/foo/doc

		string path = Path.Combine("usr", "local");
		path = Path.Combine(path, "some");
		path = Path.Combine(path, "foo");
		path = Path.Combine(path, "doc");
		/* ... */

2. String Concat

	Usage:
		string path = "home" + Path.DirectorySeparatorChar +
"username";

	Disadvantage(s):
		A lot of usage of Path.DirectorySeperatorChar which
makes the code
		more unreadable:

		string path = "usr"
				+ Path.DirectorySeperaterChar
				+ "local"
				+ Path.DirectorySeperaterChar
				+ "some"
				+ Path.DirectorySeperaterChar
				+ "foo"
				+ Path.DirectorySeperaterChar
				+ "doc"
				+ /* ... */;
3. String Format:

	Usage:
		string path = String.Format("home{0}username");

	Advantage:
		Makes the code smaller than using
Path.DirectorySeperatorChar all over
	Disadvantages:
		Less slower than Concat (i guess)

		string path =
String.Format("usr{0}local{0}some{0}foo{0}doc{0}...",
Path.DirectorySeperaterChar);

4. Use *only* "/"

	Usage:

		string path = "home/username";

	Disadvantages:

		Works (not?) on all platforms (does Win95 understand
'/'? I know NT+ do.)


To sum up, is there any conventation in mono or which version (i bet the
one i didn't mention ;-)) is the best to be most portable?

Greets,

	Christian



From simon at redhillconsulting.com.au  Wed Feb  4 17:19:28 2004
From: simon at redhillconsulting.com.au (Simon Harris)
Date: Thu, 05 Feb 2004 09:19:28 +1100
Subject: [Mono-devel-list] Obfuscation packages that run under mono
Message-ID: <1075933168.2080.36.camel@localhost>

I'm trying, without much success I might add, to find any IL obfuscation
packages that will run under mono (on linux). 
 
Does anyone know of any?
 
Cheers, 
 Obfuscation packages that run under mono
Simon
-- 
http://www.redhillconsulting.com.au
RedHill Consulting, Pty. Ltd.
12/55-67 Batman Street
West Melbourne VIC 3003
+61 417 505 611



From bmaurer at users.sourceforge.net  Wed Feb  4 17:27:48 2004
From: bmaurer at users.sourceforge.net (Ben Maurer)
Date: Wed, 04 Feb 2004 17:27:48 -0500
Subject: [Mono-devel-list] Path.Combine,
	Directory.DirectorySeperatorChar, String.Format...?
In-Reply-To: <001e01c3eb6b$5abc1710$0200a8c0@winghome>
References: <001e01c3eb6b$5abc1710$0200a8c0@winghome>
Message-ID: <1075933667.2457.47.camel@Ben>

On Wed, 2004-02-04 at 17:07, Christian Birkl wrote:
> Hi all,
> 
> now that .Net becomes platform independend it raises the question of how
> handling filenames. After reading some of mono sources i found three
> major versions of dealing with the "/" or "\" issues, but which should
> now be used?
> 
> 1. Path.Combine
IMHO, this is the best for two directories, by far. With multiple
directories, it is a performance problem, because you end up creating
multiple string just to throw them away.

> 
> 2. String Concat
The performance here is going to be pretty bad. What is happening is:

String.Concat ("a", Path.DSC.ToString () ...)

However, it is actually worse because before that, you put the DSCs into
an Object [], so you have to box the chars. Also, you have to do a
virtual call on everything, it is a mess.

> 3. String Format:
The performance here is bad because you end up doing a stringbuilder,
and you dont know the exact length.
> 
> 4. Use *only* "/"
Not portable.

What I would do (and I wish MS had done) is to make your own helper
method:

Combine (params string [] args)
{
    string dsc = Path.DSC.ToString ();
    string [] items = new string [1 + (args.Length - 1) * 2];
    int pos = 0;
    foreach (string s in args) {
        if (pos != 0) items [pos++] = dsc;
	items [pos++] = s;
    }
    return String.Concat (items);
}

So you can call:

PathHelper.Combine (foo, bar, baz, do, re, me);

And get the items combined.





From jaak at zd.com.pl  Wed Feb  4 18:21:15 2004
From: jaak at zd.com.pl (Jaroslaw Kowalski)
Date: Thu, 5 Feb 2004 00:21:15 +0100
Subject: [Mono-devel-list] Path.Combine,Directory.DirectorySeperatorChar, String.Format...?
References: <001e01c3eb6b$5abc1710$0200a8c0@winghome> <1075933667.2457.47.camel@Ben>
Message-ID: <005401c3eb75$96086760$2000a8c0@jarekxp>

> > 4. Use *only* "/"
> Not portable.

I'm pretty sure that this works on all Windows versions. AFAIR it even used
to work with DOS 3.30.

There's been some discussion on python list which seems to confirm it.

http://mail.python.org/pipermail/python-list/2003-September/185202.html

Jarek



From miguel at ximian.com  Wed Feb  4 18:34:32 2004
From: miguel at ximian.com (Miguel de Icaza)
Date: Wed, 04 Feb 2004 18:34:32 -0500
Subject: [Mono-devel-list] Re: [Mono-list] Obfuscation packages that run under mono
In-Reply-To: <1075933168.2080.36.camel@localhost>
References: <1075933168.2080.36.camel@localhost>
Message-ID: <1075937672.32556.15.camel@erandi.boston.ximian.com>

Hey,

> I'm trying, without much success I might add, to find any IL obfuscation
> packages that will run under mono (on linux). 
>  
> Does anyone know of any?

Dont know of one, but there are a few things someone could do:

	* Use the bundle functionality in Mono.

	  This would bundle your binary inside a Mono instance,
	  so you distribute a single executable.  Not impossible
	  to break, but would work around simple attempts.

	* You could precompile with --aot, then disassemble the
	  original .exe, remove all the code, then re-assemble
  	  and ship both.

That being said, value these days does not lie in particular tiny
routines, but lies in the large body of work, and if someone steals
your code, you are likely going to find out anyways.

Miguel.


From miguel at ximian.com  Wed Feb  4 18:35:33 2004
From: miguel at ximian.com (Miguel de Icaza)
Date: Wed, 04 Feb 2004 18:35:33 -0500
Subject: [Mono-devel-list] GAC, Shared Assemblies and Assembly
	Versioning
In-Reply-To: <JDEEKAHPEBFHCCNMGFFKCEMGCGAA.jason.king@profox.co.uk>
References: <JDEEKAHPEBFHCCNMGFFKCEMGCGAA.jason.king@profox.co.uk>
Message-ID: <1075937733.32556.17.camel@erandi.boston.ximian.com>

Hello,

> Given that Mono users have the freedom to install Mono and supporting
> libraries pretty much wherever they like, where does this leave the Mono
> implementation of the global assembly cache?  For example, say I want to add
> a shared assembly so that all apps on my machine can use it...?
> 
> Are there any plans for assembly versioning in Mono?

There are plans, yes.  But not implemented yet.



From miguel at ximian.com  Wed Feb  4 18:35:58 2004
From: miguel at ximian.com (Miguel de Icaza)
Date: Wed, 04 Feb 2004 18:35:58 -0500
Subject: [Mono-devel-list] GAC, Shared Assemblies and Assembly
	Versioning
In-Reply-To: <JDEEKAHPEBFHCCNMGFFKCEMGCGAA.jason.king@profox.co.uk>
References: <JDEEKAHPEBFHCCNMGFFKCEMGCGAA.jason.king@profox.co.uk>
Message-ID: <1075937758.32556.19.camel@erandi.boston.ximian.com>

Hello,

Answering your second question: the assemblies installed in the system
are effectively shared between all apps today.

> Given that Mono users have the freedom to install Mono and supporting
> libraries pretty much wherever they like, where does this leave the Mono
> implementation of the global assembly cache?  For example, say I want to add
> a shared assembly so that all apps on my machine can use it...?
> 
> Are there any plans for assembly versioning in Mono?
> 
> Thanks for any advice, plans or help with this issue.



From miguel at ximian.com  Wed Feb  4 18:38:38 2004
From: miguel at ximian.com (Miguel de Icaza)
Date: Wed, 04 Feb 2004 18:38:38 -0500
Subject: [Mono-devel-list] Building mcs with generics profile
In-Reply-To: <1075927060.2519.24.camel@nova>
References: <20040117234127.GW4888@ox.compsoc.net>
	 <LNEAJLBKIAFKOPHEICIDOEPNDEAA.spouliot@videotron.ca>
	 <20040120102245.GB4888@ox.compsoc.net>  <1075805745.15390.8.camel@nova>
	 <1075921548.4700.657.camel@erandi.boston.ximian.com>
	 <1075927060.2519.24.camel@nova>
Message-ID: <1075937917.32556.23.camel@erandi.boston.ximian.com>

Hello,

   I think you will have to:

	* Compile the corlib next, but using mcs with the generics profile.

	* Manually fix the Makefile to have gmcs be built with mcs first.

	* Restart the process at that point.

    You are right that building the generics profile will get tricky. 
It is currently only being used by those working on the generics support.


From jonpryor at vt.edu  Wed Feb  4 20:41:09 2004
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Wed, 04 Feb 2004 20:41:09 -0500
Subject: [Mono-devel-list] Isolated Storage and Code Access Security
In-Reply-To: <LNEAJLBKIAFKOPHEICIDOEJADGAA.spouliot@videotron.ca>
References: <LNEAJLBKIAFKOPHEICIDOEJADGAA.spouliot@videotron.ca>
Message-ID: <1075945269.5063.40.camel@melchior.magi>

On Wed, 2004-02-04 at 13:03, S?bastien Pouliot wrote:
<snip/>
> Isolated Storage
> 
> * Class status
> 	http://www.go-mono.com/class-status-corlib.html
> 
> * Conclusion
> 	Incomplete. IIRC no one has worked in the classes for quite some time.
<snip/>

Just to elaborate, I worked on IsolatedStorage as a weekend project to
get it to run an example I found in "Programming C#".

Which means:
  + You can actually create files with it
  + It really works!

  - No effort was paid to security
  - or disk space concerns
  - or anything else that would be needed for a actual completeness.

It's a simple way to create files for the individual user that aren't
visible by the user (they're stored ~/.mono/isolated-storage).  It
should work quite well for this, and should suffice for storing program
preferences and other related things.

Aside from permission support and implementing a fixed-size data store
(and how should that be configured?), it's pretty much feature
complete.  Or mostly complete, anyway.

 - Jon




From jonpryor at vt.edu  Wed Feb  4 20:59:55 2004
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Wed, 04 Feb 2004 20:59:55 -0500
Subject: [Mono-devel-list] ICodeParser && Mono
In-Reply-To: <001601c3eb4b$c2626a10$0200a8c0@winghome>
References: <001601c3eb4b$c2626a10$0200a8c0@winghome>
Message-ID: <1075946393.5063.59.camel@melchior.magi>

Below...

On Wed, 2004-02-04 at 13:21, Christian Birkl wrote:
> Hi all,
> 
> Is there something equivalent to Microsoft.CSharp namespace in Mono? I
> can't find any in the current class/ directory in recent cvs. I'm
> specifically interested in Microsoft.CSharp.CSharpProvider. I'd like to
> do some code analysing stuff via ICodeProvider, which can create a
> CodeCompileUnit via .CreateParser().Parse(). This would be a much nicer
> way than doing the parsing on my own. But unfortuntly .CreateParser() is
> defined to *always* return null. It would be nice if Mono would break
> this MS behaviour (or somehow provide a second .CreateParser() method.).

Are you sure it's not CSharpCodeProvider?  There's one in 
<cvs root="mcs"/>/class/System/Microsoft.CSharp/CSharpCodeProvider.cs.

There's also a Microsoft.CSharp namespace in class/Cscompgd.

I don't know if Mono would be willing to break compatibility, but I
suspect not.

> My second question is wether mcs (mono c# compiler) internally actually
> uses System.CodeDom for its code creation or not. And if yes, how can i
> access the CodeDom created by the parser?

I believe this is a misunderstanding of what CodeDom is for.  CodeDom
isn't for *parsing* code.  It's for *generating* code.  Not CIL code. 
Source code.

CodeDom would be used by e.g. VisualStudio for generating templates: you
would describe, via CodeDom, that you want a class (MyClass), with a
method (Main), and some comments ("Do something here").  This CodeDom
description could then be used to generate the template code in VB.NET,
C#, JavaScript...  Anything that has a CodeDom provider.  It's to
generate *human readable* source code.

This was discussed -- in excruciating depth because of perceived GPL
"backdoor" -- in May 2002, when miguel noted:

	The System.CodeDOM API is a mechanism to "build" source code 
	through an API.  It is just an abstraction so that ASP.NET can
	"create" pages built on a number of languages.

	Once you have constructed your "CodeDOM", it is written into a
	file, and an external compiler is invoked.  So there are no
	licensing problems.

See:	http://lists.ximian.com/archives/public/mono-list/2002-May/005929.html

To generate IL, System.Reflection.Emit is used.  This is what mcs does. 
You can also use PEAPI (in mcs CVS), or just directly emit the opcodes
(if you're writing in a non-managed environment).

I think PEAPI can also be used to parse existing IL code, but I'm not
entirely sure.

 - Jon




From rshade at dvsconsulting.com  Thu Feb  5 00:04:42 2004
From: rshade at dvsconsulting.com (Robert Shade)
Date: Thu, 5 Feb 2004 00:04:42 -0500
Subject: [Mono-devel-list] [Patch] Nunit-gtk
Message-ID: <200402050004.56574.rshade@dvsconsulting.com>

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

This is a quick patch to fix the Nunit-gtk compile.

rob
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAIc702aTuCyd+7ZYRApRhAKDMiVRwqmkT415SSEhQFkIeiJ/vDQCePOUH
tevJRn2rSYn9jj1783O4Imc=
=Tnlw
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nunit-gtk.diff
Type: text/x-diff
Size: 861 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040205/d88005c8/attachment.bin 

From gonzalo at ximian.com  Thu Feb  5 04:41:22 2004
From: gonzalo at ximian.com (Gonzalo Paniagua Javier)
Date: Thu, 05 Feb 2004 10:41:22 +0100
Subject: [Mono-devel-list] [Patch] Nunit-gtk
In-Reply-To: <200402050004.56574.rshade@dvsconsulting.com>
References: <200402050004.56574.rshade@dvsconsulting.com>
Message-ID: <1075974081.22297.393.camel@localhost>

El jue, 05-02-2004 a las 06:04, Robert Shade escribi?:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> This is a quick patch to fix the Nunit-gtk compile.

I fixed that locally, but it used to work. There's a:

        using Thread = System.Threading.Thread;

line at the top of that file.

May be a mcs bug, but didn't have time to check for sure.

-Gonzalo





From spouliot at videotron.ca  Thu Feb  5 08:11:20 2004
From: spouliot at videotron.ca (=?UTF-8?Q?S=C3=A9bastien_Pouliot?=)
Date: Thu, 05 Feb 2004 08:11:20 -0500
Subject: [Mono-devel-list] Isolated Storage and Code Access Security
In-Reply-To: <1075945269.5063.40.camel@melchior.magi>
Message-ID: <LNEAJLBKIAFKOPHEICIDCEKJDGAA.spouliot@videotron.ca>

Hello Jon,

> Just to elaborate, I worked on IsolatedStorage as a weekend project to
> get it to run an example I found in "Programming C#".
>
> Which means:
>   + You can actually create files with it
>   + It really works!

Thanks for the additional informations. Corlib status just doesn't render justice ;-).

>   - No effort was paid to security
>   - or disk space concerns
>   - or anything else that would be needed for a actual completeness.


From rshade at dvsconsulting.com  Thu Feb  5 08:46:13 2004
From: rshade at dvsconsulting.com (Robert Shade)
Date: Thu, 5 Feb 2004 08:46:13 -0500
Subject: [Mono-devel-list] [Patch] Nunit-gtk
In-Reply-To: <1075974081.22297.393.camel@localhost>
References: <200402050004.56574.rshade@dvsconsulting.com> <1075974081.22297.393.camel@localhost>
Message-ID: <200402050846.13469.rshade@dvsconsulting.com>

Yes, it looks like it is.  From mcs's behavior, it looks like that using alias 
directive should override the GLib.Thread that is also in the scope.

I'll file a bug for it.

rob

On Thursday 05 February 2004 04:41 am, Gonzalo Paniagua Javier wrote:
> El jue, 05-02-2004 a las 06:04, Robert Shade escribi?:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > This is a quick patch to fix the Nunit-gtk compile.
>
> I fixed that locally, but it used to work. There's a:
>
>         using Thread = System.Threading.Thread;
>
> line at the top of that file.
>
> May be a mcs bug, but didn't have time to check for sure.
>
> -Gonzalo
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list


From rshade at dvsconsulting.com  Thu Feb  5 08:53:57 2004
From: rshade at dvsconsulting.com (Robert Shade)
Date: Thu, 5 Feb 2004 08:53:57 -0500
Subject: [Mono-devel-list] [Patch] Nunit-gtk
In-Reply-To: <200402050846.13469.rshade@dvsconsulting.com>
References: <200402050004.56574.rshade@dvsconsulting.com> <1075974081.22297.393.camel@localhost> <200402050846.13469.rshade@dvsconsulting.com>
Message-ID: <200402050853.57952.rshade@dvsconsulting.com>

I mean csc's behavior.  Sorry.

rob

On Thursday 05 February 2004 08:46 am, Robert Shade wrote:
> Yes, it looks like it is.  From mcs's behavior, it looks like that using
> alias directive should override the GLib.Thread that is also in the scope.
>
> I'll file a bug for it.
>
> rob
>
> On Thursday 05 February 2004 04:41 am, Gonzalo Paniagua Javier wrote:
> > El jue, 05-02-2004 a las 06:04, Robert Shade escribi?:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > This is a quick patch to fix the Nunit-gtk compile.
> >
> > I fixed that locally, but it used to work. There's a:
> >
> >         using Thread = System.Threading.Thread;
> >
> > line at the top of that file.
> >
> > May be a mcs bug, but didn't have time to check for sure.
> >
> > -Gonzalo
> >
> >
> >
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list


From lupus at ximian.com  Thu Feb  5 09:01:10 2004
From: lupus at ximian.com (Paolo Molaro)
Date: Thu, 5 Feb 2004 15:01:10 +0100
Subject: [Mono-devel-list] Re: [Mono-list] Obfuscation packages that run under mono
In-Reply-To: <1075937672.32556.15.camel@erandi.boston.ximian.com>
References: <1075933168.2080.36.camel@localhost> <1075937672.32556.15.camel@erandi.boston.ximian.com>
Message-ID: <20040205140109.GH28812@debian.org>

On 02/04/04 Miguel de Icaza wrote:
> > I'm trying, without much success I might add, to find any IL obfuscation
> > packages that will run under mono (on linux). 
> >  
> > Does anyone know of any?
> 
> Dont know of one, but there are a few things someone could do:
> 
> 	* Use the bundle functionality in Mono.
> 
> 	  This would bundle your binary inside a Mono instance,
> 	  so you distribute a single executable.  Not impossible
> 	  to break, but would work around simple attempts.

Note that in this case the app needs to comply with the LGPL, the
license of the mono runtime: in practice, the individual assemblies need
to be provided. Alternatively, a separate license needs to be issued
that allows the linking: I guess Miguel and/or the ximian/Novell sales
teams can fill in the details if people are interested (note, I'm not a 
lawyer, the above is my reading of the license, blah, blah, blah).

> 	* You could precompile with --aot, then disassemble the
> 	  original .exe, remove all the code, then re-assemble
>   	  and ship both.

	* Get the companies that build the obfuscation packages to read
	the ECMA spec and fix the bugs in their products that generate	
	non-standard binaries (or, if they expose a bug in mono, please
	file a report in our bugzilla).

	* Pay Ximian/Novell to spend the development time needed to get
	mono to support the broken binaries that some of the obfuscation
	packages generate (or contribute that support).
	
> That being said, value these days does not lie in particular tiny
> routines, but lies in the large body of work, and if someone steals
> your code, you are likely going to find out anyways.

People disassembling the code is a legal problem and should
be solved with legal means: trying to solve legal problems with
technical solutions is doomed to fail (though of course people are happy
to take your money if that makes you feel better:-).

lupus

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


From rafaelteixeirabr at hotmail.com  Thu Feb  5 09:08:25 2004
From: rafaelteixeirabr at hotmail.com (A Rafael D Teixeira)
Date: Thu, 05 Feb 2004 12:08:25 -0200
Subject: Bundling WAS RE: [Mono-devel-list] Obfuscation pkgs that run under mono
Message-ID: <Sea2-F40QFM83UV8wAd0002338d@hotmail.com>

>From: Miguel de Icaza <miguel at ximian.com>
>
>Hey,
>
> > I'm trying, without much success I might add, to find any IL obfuscation
> > packages that will run under mono (on linux).
> >
> > Does anyone know of any?
>
>Dont know of one, but there are a few things someone could do:
>
>	* Use the bundle functionality in Mono.
>
>	  This would bundle your binary inside a Mono instance,
>	  so you distribute a single executable.  Not impossible
>	  to break, but would work around simple attempts.

Does we have some way of smartly link only used pieces of code, like what 
the following product does?

http://www.remotesoft.com/linker/

I see it as having negative aspects when dealing with programs that revolve 
around the plugin pattern (pieces glued by configuration files at run-time).

But as pointed out by some people (mainly developers for 
download-and-try-before-you-buy software), forcing people to first install a 
(big) runtime to be able to run some software they are interested to try 
sometimes makes those people lose the interest.

Does we have plans to do some tool like that?

Regards,

Rafael Teixeira
Brazilian Polymath
Mono Hacker since 16 Jul 2001
MonoBrasil Founding Member - Membro Fundador do MonoBrasil
English Blog: http://monoblog.blogspot.com/
Brazilian Portuguese Blog: http://monoblog.weblogger.terra.com.br/

_________________________________________________________________
MSN Messenger: instale gr?tis e converse com seus amigos. 
http://messenger.msn.com.br



From lupus at ximian.com  Thu Feb  5 09:13:42 2004
From: lupus at ximian.com (Paolo Molaro)
Date: Thu, 5 Feb 2004 15:13:42 +0100
Subject: [Mono-devel-list] GAC, Shared Assemblies and Assembly Versioning
In-Reply-To: <JDEEKAHPEBFHCCNMGFFKCEMGCGAA.jason.king@profox.co.uk>
References: <JDEEKAHPEBFHCCNMGFFKCEMGCGAA.jason.king@profox.co.uk>
Message-ID: <20040205141342.GI28812@debian.org>

On 02/04/04 Jason King wrote:
> Given that Mono users have the freedom to install Mono and supporting
> libraries pretty much wherever they like, where does this leave the Mono
> implementation of the global assembly cache?  For example, say I want to add
> a shared assembly so that all apps on my machine can use it...?

Versioned and strongnamed assemblies may be installed (using a specific
gacutil program) into a per-user or per-system GAC-like directory
structure. Additionally, the loader will also look at the MONO_PATH
environment variable (list of directories) and in a default location.
Only the default location and MONO_PATH support is implemented right
now. The loader side of the GAC will be implemented as soon as we figure
out a way to cheat about versions and strongnames.

lupus

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


From lupus at ximian.com  Thu Feb  5 09:35:34 2004
From: lupus at ximian.com (Paolo Molaro)
Date: Thu, 5 Feb 2004 15:35:34 +0100
Subject: [Mono-devel-list] (Il)legal code check-ins
In-Reply-To: <1075931347.2457.35.camel@Ben>
References: <001701c3eb56$f17e58d0$0200a8c0@winghome> <1075931347.2457.35.camel@Ben>
Message-ID: <20040205143534.GJ28812@debian.org>

On 02/04/04 Ben Maurer wrote:
[...]
> Testing how a progam works in different conditions is OK. The code in
> the MS.net implementation is copyrighted. So, the only restriction is
> that you may not copy the *TEXT* of the code (or disassembled code).
> Legally, it is ok to look at disassembled code, however we stay away

It is definitely NOT OK to look at the disassembly of code you didn't
write yourself, unless you have the explicit permission to do so.
For example, you didn't write mcs, but the mcs license allows you to
look at the generated code: that is not the case for the microsoft
assemblies. If you looked at the disassmbled code you most likely should
stay away from contributing to mono (though note is some countries
disassembling for interoperability reasons is allowed, it's better if
the person who does it doesn't directly write the code: he could write
a specification and publish that instead, unless other laws prohibit
that as well). There are a lot of gray and not so gray areas in the
legal issues and we should avoid all the situations which could bring
legal problems: one of these is looking at the disassembly of code from
the MS assemblies.

You can safely use the info you read in the documentation (provided you
don't copy the actual expression). You can look at the public interface
of an assembly and you can write tests to check the output from the
public interfaces.
You should definitely not look at the disassembly of code you're not
supposed to, unless you have consulted a lawyer and in any case, don't
contribute code to mono based on that: if it's allowed in your countrry,
write a specificauiion and let someone else implement the code.
You should also not contribute code you didn't write or code you took
from someone else if it's license is not compatible with the mono module
where it's being integrated.

lupus

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


From miguel at ximian.com  Thu Feb  5 09:41:37 2004
From: miguel at ximian.com (Miguel de Icaza)
Date: Thu, 05 Feb 2004 09:41:37 -0500
Subject: [Mono-devel-list] (Il)legal code check-ins
In-Reply-To: <1075931347.2457.35.camel@Ben>
References: <001701c3eb56$f17e58d0$0200a8c0@winghome>
	 <1075931347.2457.35.camel@Ben>
Message-ID: <1075992097.32556.62.camel@erandi.boston.ximian.com>

Hello,

> Testing how a progam works in different conditions is OK. The code in
> the MS.net implementation is copyrighted. So, the only restriction is
> that you may not copy the *TEXT* of the code (or disassembled code).
> Legally, it is ok to look at disassembled code, however we stay away
> from it for two reasons: first, it restricts the creativity in our
> implementation, secondly by not looking at the code we prevent the
> argument that we are infact copying code.

In Mono it is *never* OK to look at disassembled code.

If you want to get your code into Mono, you should not disassemble a
third-party chunk of code.

Miguel.


From jason.king at profox.co.uk  Thu Feb  5 10:20:47 2004
From: jason.king at profox.co.uk (Jason King)
Date: Thu, 5 Feb 2004 15:20:47 -0000
Subject: [Mono-devel-list] List of namespaces
Message-ID: <JDEEKAHPEBFHCCNMGFFKKENCCGAA.jason.king@profox.co.uk>

Hello,

does anyone have a list of namespaces within Mono that do not exist with in
the Microsoft framework?  If not, can anyone tell me the best place to start
looking - that is, is it better to look through the installed directories,
or trawl through the status pages (don't they only contain unfinished
namespaces?).

Jase

Regards,
Jason King
Profox Systems Ltd 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 1704 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040205/08b9c7de/attachment.bin 

From rafaelteixeirabr at hotmail.com  Thu Feb  5 11:47:08 2004
From: rafaelteixeirabr at hotmail.com (A Rafael D Teixeira)
Date: Thu, 05 Feb 2004 14:47:08 -0200
Subject: [Mono-devel-list] List of namespaces
Message-ID: <Sea2-F40nNtIBDr8YhP00025340@hotmail.com>

Look at mcs/class. Any *public* namespace not present in MS' implementation 
will reside in different assemblies thus different subdirectories under 
mcs/class. Look for all subs that doesn't start with System or Microsoft...

Fun,


Rafael Teixeira
Brazilian Polymath
Mono Hacker since 16 Jul 2001
MonoBrasil Founding Member - Membro Fundador do MonoBrasil
English Blog: http://monoblog.blogspot.com/
Brazilian Portuguese Blog: http://monoblog.weblogger.terra.com.br/

_________________________________________________________________
MSN Messenger: instale gr?tis e converse com seus amigos. 
http://messenger.msn.com.br



From spamfrommailing at freax.org  Thu Feb  5 11:52:33 2004
From: spamfrommailing at freax.org (Philip Van Hoof)
Date: Thu, 05 Feb 2004 17:52:33 +0100
Subject: [Mono-devel-list] Problems wth ds.ReadXml () (DataSet)
Message-ID: <1075999953.7928.25.camel@localhost>

Hi there,

When I want to read a DataSet from an XML-file from both a
ManifestResource or a file I always get this Exception:

"A null value was found where an object instance was required"

I am running mono-0.30 on a Fedora Core 1

This is the code I am trying:

DataSet conf = new DataSet();
Assembly a = c.GetType().Assembly;
System.IO.Stream ConfigFile =
a.GetManifestResourceStream("Cronos.Xnet.XnetDotBe.DAL.DALConfig.xml"); 
-> Exception point <-
conf.ReadXml (ConfigFile);
-> Exception point <-

When I loop the resource-names I do get the resource
"Cronos.Xnet.XnetDotBe.DAL.DALConfig.xml" in the string-array (so the
resource actually does exist). Note that it has been compiled using VS
2003 .NET (not using Mono).

I can also try something like :

conf.ReadXml ("/home/freax/cvs/XnetDotBe/XnetDotBe/bin/DALConfig.xml");

And read the XML from a file on my filesystem (and indeed, that file
'does' exist, of course -I am not VERY stupid, you know-)

'The line' (so not my code) will throw the same exception


I am indeed running this code using xsp (it's a ASP.NET website, yes)


This is how my xml-file looks  (nothing THAT strange about it huh):

On Microsoft .NET it will load the DataSet with a table Config and
columns like "ConnectionString" and "DatabaseType". This code works
1000% perfectly on the Microsoft .NET framework (and it's not very very
platform specific, imho)

<?xml version="1.0" encoding="utf-8" ?>
<Config>

<!-- Database connectivity settings //-->
        <ConnectionString>server=localhost;User
ID=xnet;Password=xnet;database=XnetDotBe</ConnectionString>
        <DatabaseType>SqlServer</DatabaseType>

<!-- Other possibilities //-->
<!--    <ConnectionString>server=W2SK-MSSQL;User
ID=sa;Password=;database=Default</ConnectionString> //-->
<!--    <DatabaseType>Oracle</DatabaseType> //-->
<!--    <DatabaseType>MySQL</DatabaseType> //-->
<!--    <DatabaseType>PostgreSQL</DatabaseType> //-->
<!--    <DatabaseType>Odbc</DatabaseType> //-->
<!--    <DatabaseType>SqlServer</DatabaseType> //-->

<!-- The Implementations for each Interface //-->
       
<IProject>Cronos.Xnet.XnetDotBe.DAL.Implementations.SqlServer.Project</IProject>
        <IProject.Assembly>DAL</IProject.Assembly>
       
<IEmployee>Cronos.Xnet.XnetDotBe.DAL.Implementations.SqlServer.Employee</IEmployee>
        <IEmployee.Assembly>DAL</IEmployee.Assembly>
        <ICustomer>Cronos.Xnet.XnetDotBe.DAL.Customer</ICustomer>
        <ICustomer.Assembly>DAL</ICustomer.Assembly>
        <ITechDomain>Cronos.Xnet.XnetDotBe.DAL.TechDomain</ITechDomain>
        <ITechDomain.Assembly>DAL</ITechDomain.Assembly>
        <ITechnology>Cronos.Xnet.XnetDotBe.DAL.Technology</ITechnology>
        <ITechnology.Assembly>DAL</ITechnology.Assembly>

</Config>





From lupus at ximian.com  Thu Feb  5 11:58:46 2004
From: lupus at ximian.com (Paolo Molaro)
Date: Thu, 5 Feb 2004 17:58:46 +0100
Subject: [Mono-devel-list] Hardware Requirements (Porting)
In-Reply-To: <E1AngiM-0005Jl-UP@visor.electric.net>
References: <E1AngiM-0005Jl-UP@visor.electric.net>
Message-ID: <20040205165846.GL28812@debian.org>

On 02/02/04 Mike Stanley wrote:
> I'm new to the list, fairly new to mono, and definitely a newbie when it
> comes to porting.  I'm an expert J2EE developer, intermediate .NET
> developer, and rusty C developer.  Lately, I've been working primarily in
> the embedded C arena, and would love to be able to port mono to a target
> platform.   I'm not necessarily interested in a JIT runtime compiler, but
> rather just interested in having the ability to compile c# to a native
> application.   

C# need the runtime to run, so you basically always need the jit anyway.

> Before I head down this path, I just wanted to know whether or not it would
> be possible.  What is the minimum system requirements for porting mono?  I'm
> looking for a recommendation (yeah or nah) given the following specs (and
> given your experiences):
>  
> - 166 MHz (MIPS) 32 bit RISC Processor
> - 16 Mb DRAM
> - 4 Mb Graphic Dram
> - 4 Mb Flash EPROM

The current minimum sizes for the runtime is roughly 1 MB for the
runtime and 1 MB for corlib. Of course both contain a lot of code that
may not be needed for the applications that will run on the device and
runtime memory usage could be shrinked a lot, too: we just haven't spent
the cycles to optimize for size, yet.
In the end, it depends on what kind of applications you need to run: you
can run them on mono/x86 and measure memory usage: it would be a fairly 
close estimate of how much it would take on mips. You could also use the
profiling tools to see how memory use and speed could be improved to see
if it would be ok on the embedded platform.

> If possible can someone give me an idea about the level of difficulty and
> time estimate (minus the reading - which I know is substantial.  btw. I have
> a comp. eng. background, with hardware, assembly lang, os dev, experience)

Since mips is very close to ppc, you can probably do a basic port in a
couple of weeks. Supporting exceptions and some of the other advanced
features will take a month or two (of course you need to double or
triple the estimates for unscheduled late night debugging sessions...).
I have already written the low-level code to emit mips native code, so a
chunk of the work is already done:-) Your background is very good for
this sort of porting work, too.
Please also take a look at the porting document as suggested by Miguel
and feel free to ask me (or on the list) any jit and runtime porting 
question you may have.

> P.S.  Out of curiosity has anyone attempted to port mono to the new TI
> and/or ARM based Palm OS devices?  

Malte/Serge started a port of the JIT to ARM, but I don't know what is
the status and it hasn't been submitted for inclusion in cvs. The port
was for Linux: handling the PalmOS weirdnesses would undoubtly increase
the complexity of the port.

lupus

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


From mstanley at cauldronsolutions.com  Thu Feb  5 12:51:24 2004
From: mstanley at cauldronsolutions.com (Mike Stanley)
Date: Thu, 5 Feb 2004 12:51:24 -0500
Subject: [Mono-devel-list] Hardware Requirements (Porting)
In-Reply-To: <20040205165846.GL28812@debian.org>
Message-ID: <E1Aoneu-0003BD-Vr@sarge.electric.net>

Thanks!  

Miguel/Paolo... You've been very helpful and have given me enough to make
the argument to those who have ultimate control over my available time for
such an effort.  I will keep the list posted on any status.  In the
meantime, I've started to begin reading :-)  *cough* luckily *cough* I have
a 2 hour a day train commute so there is some time for reading.

You'll definitely here from me again (its just a question of how soon and
how much)...

Keep up the good work guys.  The (continued) success of Mono will have a
tremendous impact.  (and it has been one of my favorite projects to watch
since its inception)

- Mike

> -----Original Message-----
> From: Paolo Molaro [mailto:lupus at ximian.com] 
> Sent: Thursday, February 05, 2004 11:59 AM
> To: Mike Stanley
> Cc: mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-devel-list] Hardware Requirements (Porting)
> 
> On 02/02/04 Mike Stanley wrote:
> > I'm new to the list, fairly new to mono, and definitely a 
> newbie when 
> > it comes to porting.  I'm an expert J2EE developer, 
> intermediate .NET 
> > developer, and rusty C developer.  Lately, I've been 
> working primarily 
> > in the embedded C arena, and would love to be able to port 
> mono to a target
> > platform.   I'm not necessarily interested in a JIT runtime 
> compiler, but
> > rather just interested in having the ability to compile c# 
> to a native
> > application.   
> 
> C# need the runtime to run, so you basically always need the 
> jit anyway.
> 
> > Before I head down this path, I just wanted to know whether 
> or not it 
> > would be possible.  What is the minimum system requirements for 
> > porting mono?  I'm looking for a recommendation (yeah or nah) given 
> > the following specs (and given your experiences):
> >  
> > - 166 MHz (MIPS) 32 bit RISC Processor
> > - 16 Mb DRAM
> > - 4 Mb Graphic Dram
> > - 4 Mb Flash EPROM
> 
> The current minimum sizes for the runtime is roughly 1 MB for 
> the runtime and 1 MB for corlib. Of course both contain a lot 
> of code that may not be needed for the applications that will 
> run on the device and runtime memory usage could be shrinked 
> a lot, too: we just haven't spent the cycles to optimize for 
> size, yet.
> In the end, it depends on what kind of applications you need 
> to run: you can run them on mono/x86 and measure memory 
> usage: it would be a fairly close estimate of how much it 
> would take on mips. You could also use the profiling tools to 
> see how memory use and speed could be improved to see if it 
> would be ok on the embedded platform.
> 
> > If possible can someone give me an idea about the level of 
> difficulty 
> > and time estimate (minus the reading - which I know is 
> substantial.  
> > btw. I have a comp. eng. background, with hardware, 
> assembly lang, os 
> > dev, experience)
> 
> Since mips is very close to ppc, you can probably do a basic 
> port in a couple of weeks. Supporting exceptions and some of 
> the other advanced features will take a month or two (of 
> course you need to double or triple the estimates for 
> unscheduled late night debugging sessions...).
> I have already written the low-level code to emit mips native 
> code, so a chunk of the work is already done:-) Your 
> background is very good for this sort of porting work, too.
> Please also take a look at the porting document as suggested 
> by Miguel and feel free to ask me (or on the list) any jit 
> and runtime porting question you may have.
> 
> > P.S.  Out of curiosity has anyone attempted to port mono to 
> the new TI 
> > and/or ARM based Palm OS devices?
> 
> Malte/Serge started a port of the JIT to ARM, but I don't 
> know what is the status and it hasn't been submitted for 
> inclusion in cvs. The port was for Linux: handling the PalmOS 
> weirdnesses would undoubtly increase the complexity of the port.
> 
> lupus
> 
> --
> -----------------------------------------------------------------
> lupus at debian.org                                     debian/rules
> lupus at ximian.com                             Monkeys do it better
> 



From benjaminwootton at hotpop.com  Thu Feb  5 15:02:15 2004
From: benjaminwootton at hotpop.com (Benjamin Wootton)
Date: Thu, 5 Feb 2004 20:02:15 -0000
Subject: [Mono-devel-list] Isolated Storage and Code Access Security
In-Reply-To: <JDEEKAHPEBFHCCNMGFFKKEMGCGAA.jason.king@profox.co.uk>
Message-ID: <20040205200226.29486124181@lists.ximian.com>

I'm working on Code Access Security at the moment.  I can give you more
information if you need it.

If you are looking for a project, take a look at the two tasks and if you
decide to help with CAS I will be able to get you up to speed.  Isolated
Storage might be better for an independent project though.  

Ben

_____________________________________________
From: mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Jason King
Sent: Wednesday, February 04, 2004 4:12 PM
To: Mono List
Subject: [Mono-devel-list] Isolated Storage and Code Access Security

Hello everyone,

Try as I might, I can't seem to find any information about Mono's plans for
Code Access Security or Isolated Storage.

Is anybody working on these items, or is there a strategy in place for
meeting these items in the future?

Jase

Regards,
Jason King
Profox Systems Ltd 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 3658 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040205/dfb30b4f/attachment.bin 

From jaak at zd.com.pl  Thu Feb  5 16:01:09 2004
From: jaak at zd.com.pl (Jaroslaw Kowalski)
Date: Thu, 5 Feb 2004 22:01:09 +0100
Subject: [Mono-devel-list] Virtual hosts with mod_mono_server
Message-ID: <006e01c3ec2b$2e332b00$2000a8c0@jarekxp>

Is it possible to run multiple ASP.NET applications with mod_mono when
apache is configured for name-based virtual hosts? The applications are to
be located the vhost root.

http://sitea.net/index.aspx
http://siteb.net/index.aspx

Do I need multiple mod_mono_server.exe's?

Jarek



From jamesl at appliedminds.com  Thu Feb  5 16:02:21 2004
From: jamesl at appliedminds.com (James Lamanna)
Date: Thu, 05 Feb 2004 13:02:21 -0800
Subject: [Mono-devel-list] Calling object constructor from C
Message-ID: <opr2w0p7oh331ubk@mail.appliedminds.com>

So I figured out the array problem I posted about earlier, but here's another problem I'd like some help with.

I'm trying to call a constructor for an object from C using the following:

     MonoDomain *domain = mono_domain_get();
     MonoAssembly *assembly = (MonoAssembly *)mono_assembly_get_main();
     MonoClass *na_class = mono_class_from_name(assembly->image,
             "DOL", "NetworkAdapter");
     MonoObject *na_this = mono_object_new(domain, na_class);
     MonoMethod *na_ctor = NULL;
     MonoString *test_string = mono_string_new(domain, "Test String");
     MonoString *test_string2 = mono_string_new(domain, "Test String");
     MonoString *test_string3 = mono_string_new(domain, "Test String");
     MonoString *test_string4 = mono_string_new(domain, "Test String");
     MonoString *test_string5 = mono_string_new(domain, "Test String");
     MonoArray *ip_array, *subnet_array;
     MonoObject *na;
     const char *na_ctor_name = "DOL.NetworkAdapter:.ctor (string,string[],string[],string,string)";
     int i,;
     void **args = g_new( void *, 5);

     for (i = 0; i < na_class->method.count; i++) {
         if (strncmp((char *)mono_method_full_name(na_class->methods[i]),
                    na_ctor_name, strlen(na_ctor_name)) == 0) {
             na_ctor = na_class->methods[i];
             break;
         }
     }

     ip_array = mono_array_new(domain, mono_defaults.string_class, 1);
     mono_array_set(ip_array, gpointer, 0, test_string);
     subnet_array = mono_array_new(domain, mono_defaults.string_class, 1);
     mono_array_set(subnet_array, gpointer, 0, test_string2);

     args[0] = test_string3;
     args[1] = ip_array;
     args[2] = subnet_array;
     args[3] = test_string4;
     args[4] = test_string5;

     na = mono_runtime_invoke(na_ctor, na_this, args, NULL);

The ctor is found ok, the arrays get set up ok, but mono_runtime_invoke always returns null.
Any help?
Thanks.

-- 
James Lamanna
Applied Minds, Inc.
1209 Grand Central Ave.
Glendale, CA 91201
(818) 332-5214


From jaak at zd.com.pl  Thu Feb  5 18:00:02 2004
From: jaak at zd.com.pl (Jaroslaw Kowalski)
Date: Fri, 6 Feb 2004 00:00:02 +0100
Subject: [Mono-devel-list] [PATCH] Virtual hosts with mod_mono_server
References: <006e01c3ec2b$2e332b00$2000a8c0@jarekxp>
Message-ID: <00cc01c3ec3b$c97e0250$2000a8c0@jarekxp>

Answering to myself: I've made some research and looks like virtual hosts
can be implemented entirely on the "mod_mono_server" level. I've attached a
patch that does this.

Basically it extends the application specification so that you can include
your vhost parameters.

"hostname:port:vpath:directory"

I've completely rewritten "GetApplicationForPath()" method:

1. I've replaced the hashtable lookup with a linear scan of an array (in
most cases you have only a small number of applications and the performance
of hashtable is poor in this case). For larger installations (e.g. hosting
providers) it may be useful to do something more advanced (hashing or binary
search) so that the method scales better, but I'm not sure if it's worth it.

2. I've eliminated all allocations from this method (there were actually a
lot of them in String.Join() and String.Split()). Instead of splitting and
re-joining strings I'm simply looking for an entry with the longest matching
prefix. This is easily done with StartsWith() which afaik doesn't allocate
anything.

3. My patch allows two "vpaths" to point to a single physical directory and
run two different applicationhosts there.

4. There are some TODOs - basically related to retrieving information from
the HTTP headers (port and host) but I don't have time and knowledge to dig
into it as it looks to be apache-dependent.

Can someone verify the patch, fix the TODOs and commit if it's ok? I've got
only anoncvs access and this patch was made against today's fresh copy.

Jarek

----- Original Message ----- 
From: "Jaroslaw Kowalski" <jaak at zd.com.pl>
To: "mono-devel mailing list" <mono-devel-list at lists.ximian.com>
Sent: Thursday, February 05, 2004 10:01 PM
Subject: [Mono-devel-list] Virtual hosts with mod_mono_server


> Is it possible to run multiple ASP.NET applications with mod_mono when
> apache is configured for name-based virtual hosts? The applications are to
> be located the vhost root.
>
> http://sitea.net/index.aspx
> http://siteb.net/index.aspx
>
> Do I need multiple mod_mono_server.exe's?
>
> Jarek
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vhosts.patch
Type: application/octet-stream
Size: 8180 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040206/3dbbfb79/attachment.obj 

From jonpryor at vt.edu  Thu Feb  5 18:06:54 2004
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Thu, 05 Feb 2004 18:06:54 -0500
Subject: [Mono-devel-list] Isolated Storage and Code Access Security
In-Reply-To: <LNEAJLBKIAFKOPHEICIDCEKJDGAA.spouliot@videotron.ca>
References: <LNEAJLBKIAFKOPHEICIDCEKJDGAA.spouliot@videotron.ca>
Message-ID: <1076022413.5063.62.camel@melchior.magi>

On Thu, 2004-02-05 at 08:11, S?bastien Pouliot wrote:
<snip/>
> Do you plan to complete the classes ?
> or to add some unit tests for them ?

I don't plan on it.  I have little enough time as it is just responding
to email, work, and life-in-general.

 - Jon




From umuff at quark.com  Thu Feb  5 18:49:46 2004
From: umuff at quark.com (Urs C Muff)
Date: Thu, 5 Feb 2004 16:49:46 -0700
Subject: [Mono-devel-list] bug in mcs: error CS8003: Constant type is not valid
Message-ID: <FA41DBC6-5835-11D8-88A5-0003938D4EE2@quark.com>

public sealed class Test
{
         public const string A = "A";
         public const string B = "B";

         public const string[] ALL = new string[]
         {
                 A,
                 B,
         };

         private Test() {}
}

Compiles fine with csc, but mcs fails with:
~Test.cs(10) error CS8003: Constant type is not valid (only system 
types are allowed)
Compilation failed: 1 error(s), 0 warnings

BTW: do you want me to file a bug in bugzilla?

- Urs



From duncan at ximian.com  Thu Feb  5 18:57:17 2004
From: duncan at ximian.com (Duncan Mak)
Date: Thu, 05 Feb 2004 18:57:17 -0500
Subject: [Mono-devel-list] Status to Exception handling in GDI+
Message-ID: <1076025437.11755.42.camel@diphthong>

Hey Ravindra!

I see that you implemented Status code checking in the System.Drawing
code base. I noticed that you've been using the following pattern:

void someFunction ()
{
    Status s = GdipDoSomething ();

    if (s != Status.Ok)
        throw GetException (s);
    else 
        return aValue;
}

Exception GetException (Status s)
{
    // a case switch here.
}

I don't think this is necessary and it's a round-about way of doing the
check. I would much prefer to see:

void f ()
{
    Status s = GdipDooSmoething ();
    CheckStatus (s);
}

void CheckStatus (Status s)
{
    if (s == Status.Ok) return;
    else {
       // put case switch here and throw the Exception immediately.
    }
}

I also noticed that, in your current GetException implementation, you
have:

String message;

switch (status) {
    // TODO: Test and add more status code mappings here
    case Status.GenericError:
        message = String.Format ("Generic Error.");
        return new Exception (message);

    case ....:
        message = ....;
}

there's no need for that, instead say:

switch (status) {
    case Status.GenericError:
        throw new Exception ("Generic Error.");

    case FooBar:
        throw new FooBarException ("Foo Bar error");

    ....
}

I think it is excellent that we now have checking of error codes in C#
from our GDI+ implementation, but I think doing this way is more
manageable and efficient than the current implementation.

We should also move the CheckStatus / GetException method out of the
abstract Brush class (gdipFunction.cs is not a bad location), as
managing the mapping from GDI+ Status codes to .NET Exceptions is not an
operation that is relevant to the Brush class.

Duncan.


From duncan at ximian.com  Thu Feb  5 18:59:24 2004
From: duncan at ximian.com (Duncan Mak)
Date: Thu, 05 Feb 2004 18:59:24 -0500
Subject: [Mono-devel-list] Marking the GDIPlus class as internal (as opposed to public)
Message-ID: <1076025564.11559.46.camel@diphthong>

Hola,

Right now, the GDIPlus class in gdipFunction.cs is marked as public. Is
there a reason for that? Do we need to expose anything public that is in
that class? It seems like its main use is a storage container for
internal static wrapper methods to hook onto P/Invoke. If there is a
need for some method in that class, would it make sense to keep GDIPlus
only for the P/Invoke functions and create a new class to house those
other methods?

Duncan.


From duncan at ximian.com  Thu Feb  5 19:27:31 2004
From: duncan at ximian.com (Duncan Mak)
Date: Thu, 05 Feb 2004 19:27:31 -0500
Subject: [Mono-devel-list] Re: Texture Brush
In-Reply-To: <1075800432.22789.13.camel@ravi>
References: <1075800432.22789.13.camel@ravi>
Message-ID: <1076027243.11755.68.camel@diphthong>

Hello Ravindra,

On Tue, 2004-02-03 at 04:27, Ravindra wrote:
> Please find attached the Cairo side implementation of TextureBrush. I've
> not debugged this code yet, it has some problems that I'm looking into.

What are these problems?

> I would like to change this code to OO-C style, once I get it working.

It might make sense to go this route from the beginning. The differences
are significant enough that having this other implementation working
does not mean that the transition to an OO layout will be seamless.

About texturebrush.c:

In general, I think it's pretty good! Two things:

* GDI+ uses floats primarily and the -I family of functions is just
there for convenience. For example, for GdipCreateTexture2, it should
not delegate to GdipCreateTexture2I. The opposite should happen instead.
Incidentally, all of Cairo uses doubles for their data storage.

* For all the Matrix operations (Translate, Rotate, Scale, etc), I think
we are required to set the texture's matrix after performing the
operation, for an example see the equivalent functions in graphics.c
(i.e. GdipMultiplyWorldTransform)

As for the diffs in gdip.h, I would prefer that we start a new
texturebrush.h and put all the function prototypes there instead. I've
regretted merging all of the old headers into one single gdip.h; even
though it is a lot more convenient, it is a monster to maintain. Bit by
bit, we should move towards having gdip.h only including other smaller
header files, and I guess that should be true for gdipFunction.cs as
well, as it's getting pretty long and scary.

Duncan.


From ct at cs.clemson.edu  Thu Feb  5 20:15:58 2004
From: ct at cs.clemson.edu (Taylor Christopher P)
Date: Thu, 5 Feb 2004 20:15:58 -0500 (EST)
Subject: [Mono-devel-list] Strangeness with lib versions
Message-ID: <Pine.GSO.4.51.0402052011220.16513@yoda.cs.clemson.edu>

I've been trying to build gtk# on my ppc machine and when i tried
debugging the build (it craps out in the pango directory), I'm getting
this message:

ct at winnabego pango $ mono --debug ../parser/gapi-fixup.exe
--api=pango-api.xml --metadata=Pango.metadata

** (../parser/gapi-fixup.exe:3477): WARNING **: Symbol file
/usr/local/lib/mscorlib.dll has is not a mono symbol file

** (../parser/gapi-fixup.exe:3477): WARNING **: Symbol file
/usr/local/lib/System.dll has is not a mono symbol file

** (../parser/gapi-fixup.exe:3477): WARNING **: Symbol file
/usr/local/lib/System.Xml.dll has is not a mono symbol file

Unhandled Exception: System.ExecutionEngineException: SIGILL

So, I tried running this:

ct at winnabego parser $ mono --debug gapi-fixup.exe

** (gapi-fixup.exe:3543): WARNING **: Symbol file
/usr/local/lib/mscorlib.dll has is not a mono symbol file

** (gapi-fixup.exe:3543): WARNING **: Symbol file
/usr/local/lib/System.dll has is not a mono symbol file

** (gapi-fixup.exe:3543): WARNING **: Symbol file
/usr/local/lib/System.Xml.dll has is not a mono symbol file
Killed

with similar results.

So, I've greped the mono sources and this is the location where the bug is
occuring (well maybe not the bug but the message mono is giving me)

metadata/debug-mono-symfile.c:61:               g_warning ("Symbol file %s
has is not a mono symbol file", handle->image_file);

I've been using the latest mono stable (0.30) if that's any help. I've
installed to /usr/local and I have tried this with and without GC support
enabled.

when GC is running, it dumps this message:

ct at winnabego pango $  mono --debug ../parser/gapi-fixup.exe
--api=pango-api.xml --metadata=Pango.metadata

** (../parser/gapi-fixup.exe:3615): WARNING **: Symbol file
/usr/local/lib/mscorlib.dll has is not a mono symbol file

** (../parser/gapi-fixup.exe:3615): WARNING **: Symbol file
/usr/local/lib/System.dll has is not a mono symbol file

** (../parser/gapi-fixup.exe:3615): WARNING **: Symbol file
/usr/local/lib/System.Xml.dll has is not a mono symbol file

Unhandled Exception: System.ExecutionEngineException: SIGILL

Any suggestions, tips are appreciated!

Christopher Paul Taylor, Clemson University Computer Science Dept.


From ravi at ximian.com  Thu Feb  5 21:12:19 2004
From: ravi at ximian.com (Ravi Pratap M)
Date: Thu, 05 Feb 2004 20:12:19 -0600
Subject: [Mono-devel-list] bug in mcs: error CS8003: Constant type is
	not valid
In-Reply-To: <FA41DBC6-5835-11D8-88A5-0003938D4EE2@quark.com>
References: <FA41DBC6-5835-11D8-88A5-0003938D4EE2@quark.com>
Message-ID: <1076033539.1883.868.camel@raj.cse.wustl.edu>

Hi Urs,

On Thu, 2004-02-05 at 17:49, Urs C Muff wrote:
> Compiles fine with csc, but mcs fails with:
> ~Test.cs(10) error CS8003: Constant type is not valid (only system 
> types are allowed)
> Compilation failed: 1 error(s), 0 warnings
> 
> BTW: do you want me to file a bug in bugzilla?


        Please file a bug on bugzilla :-)


        Ravi.




From jordi at ximian.com  Fri Feb  6 01:19:51 2004
From: jordi at ximian.com (Jordi Mas)
Date: Fri, 06 Feb 2004 07:19:51 +0100
Subject: [Mono-devel-list] Marking the GDIPlus class as internal (as opposed
 to public)
In-Reply-To: <1076025564.11559.46.camel@diphthong>
References: <1076025564.11559.46.camel@diphthong>
Message-ID: <40233207.1000300@ximian.com>

En/na Duncan Mak ha escrit:

>  Hola,
>
>  Right now, the GDIPlus class in gdipFunction.cs is marked as public.
>  Is there a reason for that? Do we need to expose anything public that
>  is in that class? It seems like its main use is a storage container
>  for internal static wrapper methods to hook onto P/Invoke. If there
>  is a need for some method in that class, would it make sense to keep
>  GDIPlus only for the P/Invoke functions and create a new class to
>  house those other methods?

Hola Duncan,

They should be internal. Also, System.Windows.Forms.Win32_WineLess and
System.Windows.Forms.Win32 and any other class that encapsulates
internal implementations should be internal also.

I do not see any reason to keep them public.

Jordi,





From rkumar at novell.com  Fri Feb  6 02:31:17 2004
From: rkumar at novell.com (Ravindra)
Date: Fri, 06 Feb 2004 13:01:17 +0530
Subject: [Mono-devel-list] Re: Status to Exception handling in GDI+
In-Reply-To: <1076025437.11755.42.camel@diphthong>
References: <1076025437.11755.42.camel@diphthong>
Message-ID: <1076052676.22789.266.camel@ravi>

Hello Duncan,
Thanks for your time. I have incorporated all of your comments.

Regards
Ravindra

PS: Read below my minor reasons.

On Fri, 2004-02-06 at 05:27, Duncan Mak wrote:
> I see that you implemented Status code checking in the System.Drawing
> code base. I noticed that you've been using the following pattern:
> 
> void someFunction ()
> {
>     Status s = GdipDoSomething ();
> 
>     if (s != Status.Ok)
>         throw GetException (s);
>     else 
>         return aValue;
> }
> 
> Exception GetException (Status s)
> {
>     // a case switch here.
> }
> 
> I don't think this is necessary and it's a round-about way of doing the
> check. I would much prefer to see:
> 
> void f ()
> {
>     Status s = GdipDooSmoething ();
>     CheckStatus (s);
> }
> 
> void CheckStatus (Status s)
> {
>     if (s == Status.Ok) return;
>     else {
>        // put case switch here and throw the Exception immediately.
>     }
> }
Here we have an extra function call always, even if we have a status of
OK. Current implementation does not do that.

> I also noticed that, in your current GetException implementation, you
> have:
> 
> String message;
> 
> switch (status) {
>     // TODO: Test and add more status code mappings here
>     case Status.GenericError:
>         message = String.Format ("Generic Error.");
>         return new Exception (message);
> 
>     case ....:
>         message = ....;
> }
> 
> there's no need for that, instead say:
> 
> switch (status) {
>     case Status.GenericError:
>         throw new Exception ("Generic Error.");
> 
>     case FooBar:
>         throw new FooBarException ("Foo Bar error");
> 
>     ....
> }
I took this idea from System.IO/MonoIO.cs.GetException (String, error).
I thought we might need the message, in future, if we want to insert
e.g. fileName or propertyName in FileNotFoundException or
PropertyNotSupportedException messages.

> We should also move the CheckStatus / GetException method out of the
> abstract Brush class (gdipFunction.cs is not a bad location), as
> managing the mapping from GDI+ Status codes to .NET Exceptions is not an
> operation that is relevant to the Brush class.
This is absolutely right. I was wrong.



From achester at bigpond.com  Fri Feb  6 04:14:52 2004
From: achester at bigpond.com (Adam Chester)
Date: Fri, 6 Feb 2004 19:14:52 +1000
Subject: [Mono-devel-list] [PATCH] Virtual hosts with mod_mono_server
In-Reply-To: <00cc01c3ec3b$c97e0250$2000a8c0@jarekxp>
Message-ID: <20040206091458.7ADB9124407@lists.ximian.com>

RE: 1

Try HybridDictionary

As MSDN states:
"Implements IDictionary by using a ListDictionary while the collection is
small, and then switching to a Hashtable when the collection gets large."

 		 

-----Original Message-----
From: mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Jaroslaw
Kowalski
Sent: Friday, 6 February 2004 9:00 AM
To: Jaroslaw Kowalski; mono-devel mailing list
Cc: gonzalo at ximian.com
Subject: [Mono-devel-list] [PATCH] Virtual hosts with mod_mono_server

Answering to myself: I've made some research and looks like virtual hosts
can be implemented entirely on the "mod_mono_server" level. I've attached a
patch that does this.

Basically it extends the application specification so that you can include
your vhost parameters.

"hostname:port:vpath:directory"

I've completely rewritten "GetApplicationForPath()" method:

1. I've replaced the hashtable lookup with a linear scan of an array (in
most cases you have only a small number of applications and the performance
of hashtable is poor in this case). For larger installations (e.g. hosting
providers) it may be useful to do something more advanced (hashing or binary
search) so that the method scales better, but I'm not sure if it's worth it.

2. I've eliminated all allocations from this method (there were actually a
lot of them in String.Join() and String.Split()). Instead of splitting and
re-joining strings I'm simply looking for an entry with the longest matching
prefix. This is easily done with StartsWith() which afaik doesn't allocate
anything.

3. My patch allows two "vpaths" to point to a single physical directory and
run two different applicationhosts there.

4. There are some TODOs - basically related to retrieving information from
the HTTP headers (port and host) but I don't have time and knowledge to dig
into it as it looks to be apache-dependent.

Can someone verify the patch, fix the TODOs and commit if it's ok? I've got
only anoncvs access and this patch was made against today's fresh copy.

Jarek

----- Original Message -----
From: "Jaroslaw Kowalski" <jaak at zd.com.pl>
To: "mono-devel mailing list" <mono-devel-list at lists.ximian.com>
Sent: Thursday, February 05, 2004 10:01 PM
Subject: [Mono-devel-list] Virtual hosts with mod_mono_server


> Is it possible to run multiple ASP.NET applications with mod_mono when
> apache is configured for name-based virtual hosts? The applications are to
> be located the vhost root.
>
> http://sitea.net/index.aspx
> http://siteb.net/index.aspx
>
> Do I need multiple mod_mono_server.exe's?
>
> Jarek
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>



From micke at imendio.com  Thu Feb  5 09:00:55 2004
From: micke at imendio.com (Mikael Hallendal)
Date: Thu, 05 Feb 2004 15:00:55 +0100
Subject: [Mono-devel-list] Spam/Virus to mono-cvs list
Message-ID: <1075989655.3552.29.camel@chili.home.hallendal.net>

Hi!

I was just wondering whether someone could turn off posts from
unsubscribed (or probably even better posts from other than the cvs
on-commit script) to the mono-cvs list.

There are a lot of zip files getting sent there.

Thanks,
  Mikael Hallendal

-- 
Mikael Hallendal               micke at imendio.com
Imendio HB                     http://www.imendio.com
Phone: +46 (0)709 718 918




From jamesl at appliedminds.com  Thu Feb  5 12:53:20 2004
From: jamesl at appliedminds.com (James Lamanna)
Date: Thu, 05 Feb 2004 09:53:20 -0800
Subject: [Mono-devel-list] Creating a string[] from C
Message-ID: <opr2wry6lm331ubk@mail.appliedminds.com>

Hello.
I'm trying to embed the mono runtime and I'm writing a function that 
returns a string[] from C.
However I have had no luck so far:
My C# code will hang with the following:

string[] s_array = generateArrayFromC();
Console.WriteLine(a[0]);

The C code that I'm using to generate the array looks something like this:
static MonoArray *generateArrayFromC()
{
     MonoString *test_string = mono_string_new(domain, "Test String");
     MonoArray *ip_array;
     int elem_size;

     ip_array = mono_array_new(domain, mono_defaults.string_class, 1);
     elem_size = mono_array_element_size(ip_array->obj.vtable->klass);
     memcpy(mono_array_addr_with_size(ip_array, elem_size, 0), test_string, 
elem_size);

     return ip_array;
}

Please CC me for I'm not subscribed.

Thanks.

-- 
James Lamanna
Applied Minds, Inc.
1209 Grand Central Ave.
Glendale, CA 91201
(818) 332-5214


From jaak at zd.com.pl  Fri Feb  6 05:14:29 2004
From: jaak at zd.com.pl (Jaroslaw Kowalski)
Date: Fri, 6 Feb 2004 11:14:29 +0100
Subject: [Mono-devel-list] [PATCH] Virtual hosts with mod_mono_server
References: <20040206091504.4CD96BA@frodo.zd.com.pl>
Message-ID: <005c01c3ec9a$02290fb0$2000a8c0@jarekxp>

> RE: 1
>
> Try HybridDictionary
>
> As MSDN states:
> "Implements IDictionary by using a ListDictionary while the collection is
> small, and then switching to a Hashtable when the collection gets large."
>

Yes, but I need to have a rather complex hashtable key (3 elements, some of
them used) + this creates a temporary object.
I'm actually quite interested in using hybrid dictionary here in
"GetApplicationForPath()". Can you suggest - how to do it?

Jarek



From achester at bigpond.com  Fri Feb  6 06:56:30 2004
From: achester at bigpond.com (Adam Chester)
Date: Fri, 6 Feb 2004 21:56:30 +1000
Subject: [Mono-devel-list] [PATCH] Virtual hosts with mod_mono_server
In-Reply-To: <005c01c3ec9a$02290fb0$2000a8c0@jarekxp>
Message-ID: <20040206115636.CEB6D1242C1@lists.ximian.com>

I can only guess you need a good GetHashCode() impl, and encapsulate your
hash keys into a single object (which then overrides Object.GetHashCode())

if this method is called every request, and you think it's likely somebody
would run >10 vhosts in a single mod_mono_server, you probabaly want to do
this, but it depends on usage scenarios.

Go here for an intro:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfsystemobjectclassgethashcodetopic.asp

- adam

-----Original Message-----
From: mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Jaroslaw
Kowalski
Sent: Friday, 6 February 2004 8:14 PM
To: Adam Chester; 'mono-devel mailing list'
Cc: gonzalo at ximian.com
Subject: Re: [Mono-devel-list] [PATCH] Virtual hosts with mod_mono_server

> RE: 1
>
> Try HybridDictionary
>
> As MSDN states:
> "Implements IDictionary by using a ListDictionary while the collection 
> is small, and then switching to a Hashtable when the collection gets
large."
>

Yes, but I need to have a rather complex hashtable key (3 elements, some of
them used) + this creates a temporary object.
I'm actually quite interested in using hybrid dictionary here in
"GetApplicationForPath()". Can you suggest - how to do it?

Jarek

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



From rkumar at novell.com  Fri Feb  6 08:17:35 2004
From: rkumar at novell.com (Ravindra)
Date: Fri, 06 Feb 2004 18:47:35 +0530
Subject: [Mono-devel-list] Marking the GDIPlus class as internal (as
	opposed to public)
In-Reply-To: <1076025564.11559.46.camel@diphthong>
References: <1076025564.11559.46.camel@diphthong>
Message-ID: <1076073454.22789.278.camel@ravi>

Hi Duncan,
On Fri, 2004-02-06 at 05:29, Duncan Mak wrote:
> Right now, the GDIPlus class in gdipFunction.cs is marked as public. Is
> there a reason for that? Do we need to expose anything public that is in
> that class? It seems like its main use is a storage container for
> internal static wrapper methods to hook onto P/Invoke. If there is a
> need for some method in that class, would it make sense to keep GDIPlus
> only for the P/Invoke functions and create a new class to house those
> other methods?
I agree with your thoughts. I think it is good idea to mark GDIPlus as
internal class. Also, I'm concerned about the size of gdipFunctions.cs
(pointed out by you in other mail). We need to do something about it. In
my opinion, this class can be used to house the commonly used functions
and we should have separate internal classes to house internal static
wrapper methods used by each and every class of S.D. However, I'm OK to
house static wrapper methods used by abstract classes in there.

Regards,
Ravindra



From martin at ximian.com  Fri Feb  6 08:33:40 2004
From: martin at ximian.com (Martin Baulig)
Date: Fri, 06 Feb 2004 14:33:40 +0100
Subject: [Mono-devel-list] Creating a string[] from C
In-Reply-To: <opr2wry6lm331ubk@mail.appliedminds.com>
References: <opr2wry6lm331ubk@mail.appliedminds.com>
Message-ID: <1076074419.1662.3.camel@gondor.martin.baulig>

On Thu, 2004-02-05 at 18:53, James Lamanna wrote:
> The C code that I'm using to generate the array looks something like this:
> static MonoArray *generateArrayFromC()
> {
>      MonoString *test_string = mono_string_new(domain, "Test String");
>      MonoArray *ip_array;
>      int elem_size;
> 
>      ip_array = mono_array_new(domain, mono_defaults.string_class, 1);
>      elem_size = mono_array_element_size(ip_array->obj.vtable->klass);
>      memcpy(mono_array_addr_with_size(ip_array, elem_size, 0), test_string, 
> elem_size);
> 
>      return ip_array;
> }

Hello,

this code is wrong; string is a reference type, not a value type.  This
means that your array just holds pointers to the string, ie. you do
something like

   test_string = mono_string_new (domain, "Test String");
   ip_array = mono_array_new (domain, mono_defaults.string_class, 1);
   mono_array_set (ip_array, gpointer, 0, test_string);

--
Martin Baulig <martin at ximian.com>
Now blogging !  http://primates.ximian.com/~martin/blog



From rkumar at novell.com  Fri Feb  6 08:41:02 2004
From: rkumar at novell.com (Ravindra)
Date: Fri, 06 Feb 2004 19:11:02 +0530
Subject: [Mono-devel-list] Re: Texture Brush
In-Reply-To: <1076027243.11755.68.camel@diphthong>
References: <1075800432.22789.13.camel@ravi>
	 <1076027243.11755.68.camel@diphthong>
Message-ID: <1076074861.22789.302.camel@ravi>

Hello Duncan,
Thanks for your time. Please see my comments below.

Regards,
Ravindra

On Fri, 2004-02-06 at 05:57, Duncan Mak wrote:
> Hello Ravindra,
> 
> On Tue, 2004-02-03 at 04:27, Ravindra wrote:
> > Please find attached the Cairo side implementation of TextureBrush. I've
> > not debugged this code yet, it has some problems that I'm looking into.
> 
> What are these problems?
I was facing null pointer problem mainly. Anyway, now I have stopped my 
testing. First, I'll do little rework to convert my code in OO-C style and 
then I'll test it again. But, again I'm not very clear as to what argument
types must be used in case of inherited methods. e.g. consider init ()
or setup () inherited from Brush to Texture. Now, I'm not sure what
argument (Brush or Texture) will these methods take when being
implemented in Texture.

> > I would like to change this code to OO-C style, once I get it working.
> 
> It might make sense to go this route from the beginning. The differences
> are significant enough that having this other implementation working
> does not mean that the transition to an OO layout will be seamless.
I'll take care in implementing other brushes.

> About texturebrush.c:
> 
> In general, I think it's pretty good! Two things:
> 
> * GDI+ uses floats primarily and the -I family of functions is just
> there for convenience. For example, for GdipCreateTexture2, it should
> not delegate to GdipCreateTexture2I. The opposite should happen instead.
> Incidentally, all of Cairo uses doubles for their data storage.
Actually, I have used following API there,
cairo_status_t
cairo_surface_clip_rectangle (cairo_surface_t *surface,
			      int x, int y,
			      int width, int height);
It takes int, so I did not have the other option that you are referring
to. FYI, this API is not implemented. There is an "NYI" comment around
it in cairo.h.

> * For all the Matrix operations (Translate, Rotate, Scale, etc), I think
> we are required to set the texture's matrix after performing the
> operation, for an example see the equivalent functions in graphics.c
> (i.e. GdipMultiplyWorldTransform)
OK fine. I'll do that.

> As for the diffs in gdip.h, I would prefer that we start a new
> texturebrush.h and put all the function prototypes there instead. I've
> regretted merging all of the old headers into one single gdip.h; even
> though it is a lot more convenient, it is a monster to maintain. Bit by
> bit, we should move towards having gdip.h only including other smaller
> header files, and I guess that should be true for gdipFunction.cs as
> well, as it's getting pretty long and scary.
I agree with you.



From sourcejedi at phonecoop.coop  Thu Feb  5 15:44:34 2004
From: sourcejedi at phonecoop.coop (Alan Jenkins)
Date: 05 Feb 2004 20:44:34 +0000
Subject: [Mono-devel-list] Building mcs with generics profile
In-Reply-To: <1075937917.32556.23.camel@erandi.boston.ximian.com>
References: <20040117234127.GW4888@ox.compsoc.net>
	<LNEAJLBKIAFKOPHEICIDOEPNDEAA.spouliot@videotron.ca>
	<20040120102245.GB4888@ox.compsoc.net>  <1075805745.15390.8.camel@nova>
	<1075921548.4700.657.camel@erandi.boston.ximian.com>
	<1075927060.2519.24.camel@nova> 
	<1075937917.32556.23.camel@erandi.boston.ximian.com>
Message-ID: <1076013869.4071.16.camel@nova>

On Wed, 2004-02-04 at 23:38, Miguel de Icaza wrote:
> Hello,
> 
>    I think you will have to:
> 
> 	* Compile the corlib next, but using mcs with the generics profile.
> 
> 	* Manually fix the Makefile to have gmcs be built with mcs first.
> 
> 	* Restart the process at that point.
> 
>     You are right that building the generics profile will get tricky. 
> It is currently only being used by those working on the generics support.

Ok.  Please be frank; if my feedback is not welcome at this point then I
am happy to wait until gmcs is reintegrated into mcs.

I've had some success, but when I come to resume the build process I hit
problems.  gmcs doesnt like implicit implementation of indexers - here
is one such error:

System.CodeDom/CodeNamespaceImportCollection.cs(87) error CS8025:
Parsing error
syntax error, expecting IDENTIFIER
Mono.CSharp.yyParser.yyException: irrecoverable syntax error
in [0x00313] (at /home/src/mcs-0.30/gmcs/cs-parser.cs:991)
Mono.CSharp.CSharpParser:yyparse (Mono.CSharp.yyParser.yyInput)
in [0x00029] (at /home/src/mcs-0.30/gmcs/cs-parser.jay:4434)
Mono.CSharp.CSharpParser:parse ()

All the errors so far have the same methods and line numbers inside gmcs


From lupus at ximian.com  Fri Feb  6 11:03:40 2004
From: lupus at ximian.com (Paolo Molaro)
Date: Fri, 6 Feb 2004 17:03:40 +0100
Subject: [Mono-devel-list] Strangeness with lib versions
In-Reply-To: <Pine.GSO.4.51.0402052011220.16513@yoda.cs.clemson.edu>
References: <Pine.GSO.4.51.0402052011220.16513@yoda.cs.clemson.edu>
Message-ID: <20040206160340.GS28812@debian.org>

On 02/05/04 Taylor Christopher P wrote:
> I've been trying to build gtk# on my ppc machine and when i tried
> debugging the build (it craps out in the pango directory), I'm getting
> this message:
> 
> ct at winnabego pango $ mono --debug ../parser/gapi-fixup.exe
> --api=pango-api.xml --metadata=Pango.metadata
> 
> ** (../parser/gapi-fixup.exe:3477): WARNING **: Symbol file
> /usr/local/lib/mscorlib.dll has is not a mono symbol file
[...]
> Any suggestions, tips are appreciated!

Most likely the debug symbol data code wasn't written with
portability in mind and it's full of endianess issues: from
metadata/debug-mono-symfile.c:

        magic = *((guint64 *) ptr);
        ptr += sizeof(guint64);
        if (magic != MONO_SYMBOL_FILE_MAGIC) {
                g_warning ("Symbol file %s has is not a mono symbol file", handle->image_file);
                return FALSE;
        }

ptr is a pointer to the data loaded from disk: since it was probably
written from a little endian box it won't work on ppc. Code like that
should be changed to use mono_read64() as in the rest of mono.
Similarly, the code that writes out the data should be changed to emit
it always in little endian format. I filed the following bug to track
it: http://bugzilla.ximian.com/show_bug.cgi?id=53975

lupus

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


From Matt.Davey at finetix.com  Fri Feb  6 14:56:54 2004
From: Matt.Davey at finetix.com (Matt Davey)
Date: Fri, 6 Feb 2004 19:56:54 -0000
Subject: [Mono-devel-list] Calling unmanaged code from C#
Message-ID: <03cd01c3eceb$5f188ce0$0200a8c0@fast20>

Hi,

I have an app that runs on MIcrosoft .NET that is build with C# calling a Visual C++ Managed wrapper around the TIBCO RV libraries (http://www.tibco.com/software/enterprise_backbone/rendezvous.jsp).  

I want to move the app to Mono on RedHat. Am I correct is thinking that instead of using the managed/unmanaged Visual C++ component on Mono, I should build a C# component that wrappers the tibco .so file, and invokes methd via DllImport ?

Later
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040206/e1f722bc/attachment.html 

From mathpup at mylinuxisp.com  Fri Feb  6 17:38:18 2004
From: mathpup at mylinuxisp.com (Marcus)
Date: Fri, 6 Feb 2004 17:38:18 -0500
Subject: [Mono-devel-list] Calling unmanaged code from C#
In-Reply-To: <03cd01c3eceb$5f188ce0$0200a8c0@fast20>
References: <03cd01c3eceb$5f188ce0$0200a8c0@fast20>
Message-ID: <200402061738.19001.mathpup@mylinuxisp.com>

I believe so. Unfortunately, GCC does not have the equivalent of Visual C++'s 
ability to mix unmanaged and managed code. I see that TIBCO's RV libraries 
are available with both C and C++ APIs. You will probably want to use the C 
API with DllImport. Calling C++ from C# directly with GCC as the C++ compiler 
is difficult-and-non-portable or impossible, without an intermediate C 
support library.

Brief list of problems:

First, there is no way to create a new instance of a C++ object from outside 
C++ unless the C++ library provides an appropriate function. There is no 
obvious way to determine how much memory to allocate for a given C++ object, 
so even if it were possible to call a C++ constructor directly to initialize 
the object, allocating the memory for the object in the first place seems 
impossible. 

Second, C++ compilers use name-mangling to avoid duplication of symbols when 
several classes define the same method and when overloaded methods are used. 
This mangling is platform dependent. It is possible to use system-specific 
utilities to produce a list of mangled and unmanagled names and then match 
them up to create a conversion table. So this is more of an annoyance than an 
an outright dead-end. 

Third, when optimization is specified, C++ compilers frequently inline any 
methods those bodies are defined within the class scope (and possibly other 
methods as well). Moreover, if every invocation of a method is inlined, some 
compilers do not by default emit an out-of-line copy for the method. This is 
the default for GCC when optimization is selected.



On Friday 06 February 2004 2:56 pm, Matt Davey wrote:
> Hi,
>
> I have an app that runs on MIcrosoft .NET that is build with C# calling a
> Visual C++ Managed wrapper around the TIBCO RV libraries
> (http://www.tibco.com/software/enterprise_backbone/rendezvous.jsp).
>
> I want to move the app to Mono on RedHat. Am I correct is thinking that
> instead of using the managed/unmanaged Visual C++ component on Mono, I
> should build a C# component that wrappers the tibco .so file, and invokes
> methd via DllImport ?



From Matt.Davey at finetix.com  Fri Feb  6 18:54:16 2004
From: Matt.Davey at finetix.com (Matt Davey)
Date: Fri, 6 Feb 2004 23:54:16 -0000
Subject: [Mono-devel-list] Calling unmanaged code from C#
References: <03cd01c3eceb$5f188ce0$0200a8c0@fast20> <200402061738.19001.mathpup@mylinuxisp.com>
Message-ID: <042c01c3ed0c$881e8d80$0200a8c0@fast20>

Thanks for the reply, I appreciate the help

Later
----- Original Message ----- 
From: "Marcus" <mathpup at mylinuxisp.com>
To: <mono-devel-list at lists.ximian.com>
Cc: "Matt Davey" <Matt.Davey at finetix.com>
Sent: Friday, February 06, 2004 10:38 PM
Subject: Re: [Mono-devel-list] Calling unmanaged code from C#


> I believe so. Unfortunately, GCC does not have the equivalent of Visual
C++'s
> ability to mix unmanaged and managed code. I see that TIBCO's RV libraries
> are available with both C and C++ APIs. You will probably want to use the
C
> API with DllImport. Calling C++ from C# directly with GCC as the C++
compiler
> is difficult-and-non-portable or impossible, without an intermediate C
> support library.
>
> Brief list of problems:
>
> First, there is no way to create a new instance of a C++ object from
outside
> C++ unless the C++ library provides an appropriate function. There is no
> obvious way to determine how much memory to allocate for a given C++
object,
> so even if it were possible to call a C++ constructor directly to
initialize
> the object, allocating the memory for the object in the first place seems
> impossible.
>
> Second, C++ compilers use name-mangling to avoid duplication of symbols
when
> several classes define the same method and when overloaded methods are
used.
> This mangling is platform dependent. It is possible to use system-specific
> utilities to produce a list of mangled and unmanagled names and then match
> them up to create a conversion table. So this is more of an annoyance than
an
> an outright dead-end.
>
> Third, when optimization is specified, C++ compilers frequently inline any
> methods those bodies are defined within the class scope (and possibly
other
> methods as well). Moreover, if every invocation of a method is inlined,
some
> compilers do not by default emit an out-of-line copy for the method. This
is
> the default for GCC when optimization is selected.
>
>
>
> On Friday 06 February 2004 2:56 pm, Matt Davey wrote:
> > Hi,
> >
> > I have an app that runs on MIcrosoft .NET that is build with C# calling
a
> > Visual C++ Managed wrapper around the TIBCO RV libraries
> > (http://www.tibco.com/software/enterprise_backbone/rendezvous.jsp).
> >
> > I want to move the app to Mono on RedHat. Am I correct is thinking that
> > instead of using the managed/unmanaged Visual C++ component on Mono, I
> > should build a C# component that wrappers the tibco .so file, and
invokes
> > methd via DllImport ?
>
>



From mathpup at mylinuxisp.com  Sat Feb  7 01:19:35 2004
From: mathpup at mylinuxisp.com (Marcus)
Date: Sat, 7 Feb 2004 01:19:35 -0500
Subject: [Mono-devel-list] Building Mono with GCC and aggressive optimizations
Message-ID: <200402070119.35995.mathpup@mylinuxisp.com>

I realize that there is probably little point in trying to improve execution 
speed of a JIT with aggressive C optimizations. However, many people 
(possibly on the advice of various articles floating around) do set CFLAGS 
for aggressive optimization, such as

-O3 -march=athlon-tbird -fomit-frame-pointer -mpreferred-stack-boundary=2

Tonight I discovered that the mono runtime segfaults when it tries to throw an 
exception when compiled with flags like those above. I do not recall this 
happening before, but I wanted to mention it in case anyone else notices 
aberrant behavior.

Is it possible to include a note about this in the docs for mono? Or maybe 
even a warning at ./configure time? Some packages like MPlayer display a 
warning along the lines of "You specified some C-compiler flags using CFLAGS, 
and I'll go ahead and build with those compiler flags, but if you have 
problems, don't complain to us."

Point of interest: I'm using GCC 3.2.2:

-fomit-frame-pointer WORKS
-O2 -march=athlon-tbird WORKS
-O3 -march=athlon-tbird -fomit-frame-pointer -mpreferred-stack-boundary=2 
FAILS
-O3 -march=athlon-tbird -fomit-frame-pointer FAILS
-O3 -fomit-frame-pointer -mpreferred-stack-boundary=2 FAILS
-O2 -march=athlon-tbird -fomit-frame-pointer -mpreferred-stack-boundary=2 
FAILS


From phil at noggle.biz  Sat Feb  7 18:43:28 2004
From: phil at noggle.biz (Philip Tricca)
Date: Sat, 07 Feb 2004 18:43:28 -0500
Subject: [Mono-devel-list] NUnit && AssertEquals
Message-ID: <1076197408.29277.13.camel@dhcppc5>

I'm currently playing around with the NUnit system testing some code
with AssertEquals as was recommended on go-mono. NUnit is working great
and AssertEquals catches my test cases when they are not as expected ie.

(I'm generating SQL)
AssertEquals("DeletePk", sql, "DELETE FROM member WHERE id = 0101010");

When the generated string (sql) matches everything works fine. When the
assert fails, I get the expected Failures message but also some debug
stuff (see bottom). Should this be expected? I just upgraded all my
mcs/mono/gtk# to the latest versions. Any one who could shed some light
on this, I'd really appreciate it.

Thanks
 - flip

output:
============================
in [0x00042] (at
/home/flip/ccw-dotnet/Umbrella/class/Umbrella.PMS/Test/Umbrella.PMS.Query.Sql/SqlGeneratorTest.cs:64) Umbrella.Test.SqlGeneratorTest:DeletePk ()
in (unmanaged) /usr/local//lib/libmono.so.0 [0x76db4b]
in (unmanaged) /usr/local//lib/libmono.so.0(mono_runtime_invoke+0x23)
[0x7a87cb]in (unmanaged)
/usr/local//lib/libmono.so.0(mono_runtime_invoke_array+0x115) [0x7a94e1]
in (unmanaged) /usr/local//lib/libmono.so.0 [0x7aeca4]
in [0x00033] (at
/cvs/mcs/class/corlib/System.Reflection/MonoMethod.cs:98)
System.Reflection.MonoMethod:Invoke
(object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo)



From umuff at QUARK.com  Fri Feb  6 18:21:05 2004
From: umuff at QUARK.com (Urs Muff)
Date: Fri, 6 Feb 2004 16:21:05 -0700 
Subject: [Mono-devel-list] IChannelReceiver.Parse
Message-ID: <A70185F8290B6E4B92F848A60D21481D18E865@usmxsrv1.quark.com>

Hi Lluis,

I have some issues with the TcpChannel: the following function works fine on
.Net:
		public static string GetChannelUri(RemotingProtocol
protocol)
		{
			IChannelReceiver channel = GetChannel(protocol);
			string objectUri;
			return channel != null ?
channel.Parse(ToUrl(protocol,new System.IO.MemoryStream()),out objectUri) :
null;
		}

The GetChannel function will return the right channel object depending on
protocol (like Tcp, Iiop, Http, ...) and I would like to return the channel
Uri so that I can build a complete Uri to use in Activator.GetObject.
It seems to return null instead of the channel Uri.

How am I supposed to get the channel Uri in mono?

Kindest regards,

- Urs C. Muff
Software Architect		- Research Lab, Quark
<http://umuff-nt/FlexWiki/default.aspx/Quark.Projects.QuarkEIF.QuarkEIF>
EIF
Quark Inc.
UMuff at Quark.Com    	- X6360
+1 (303) 894 3360
CONFIDENTIALITY NOTICE
This e-mail transmission and any documents, files, or previous e-mail
messages appended or attached to it, may contain information that is
confidential or legally privileged. If you are not the intended recipient,
or a person responsible for delivering it to the intended recipient, you are
hereby notified that you must not read this transmission and that any
disclosure, copying, printing, distribution, or use of the information
contained or attached to this transmission is STRICTLY PROHIBITED. If you
have received this transmission in error, please immediately notify the
sender by telephone +1 (303) 894-3360 or return e-mail message
umuff at quark.com <mailto:umuff at quark.com>  and delete the original
transmission, its attachments, and any copies without reading or saving in
any manner. Thank you.


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

From erand at mainsoft.com  Sun Feb  8 07:19:13 2004
From: erand at mainsoft.com (Eran Domb)
Date: Sun, 08 Feb 2004 14:19:13 +0200
Subject: [Mono-devel-list] Problems wth ds.ReadXml () (DataSet)
In-Reply-To: <1075999953.7928.25.camel@localhost>
References: <1075999953.7928.25.camel@localhost>
Message-ID: <40262941.3030904@mainsoft.com>

Philip Van Hoof wrote:

>Hi there,
>
>When I want to read a DataSet from an XML-file from both a
>ManifestResource or a file I always get this Exception:
>
>"A null value was found where an object instance was required"
>
>I am running mono-0.30 on a Fedora Core 1
>
>This is the code I am trying:
>
>DataSet conf = new DataSet();
>Assembly a = c.GetType().Assembly;
>System.IO.Stream ConfigFile =
>a.GetManifestResourceStream("Cronos.Xnet.XnetDotBe.DAL.DALConfig.xml"); 
>-> Exception point <-
>conf.ReadXml (ConfigFile);
>-> Exception point <-
>
>When I loop the resource-names I do get the resource
>"Cronos.Xnet.XnetDotBe.DAL.DALConfig.xml" in the string-array (so the
>resource actually does exist). Note that it has been compiled using VS
>2003 .NET (not using Mono).
>
>I can also try something like :
>
>conf.ReadXml ("/home/freax/cvs/XnetDotBe/XnetDotBe/bin/DALConfig.xml");
>
>And read the XML from a file on my filesystem (and indeed, that file
>'does' exist, of course -I am not VERY stupid, you know-)
>
>'The line' (so not my code) will throw the same exception
>
>
>I am indeed running this code using xsp (it's a ASP.NET website, yes)
>
>
>This is how my xml-file looks  (nothing THAT strange about it huh):
>
>On Microsoft .NET it will load the DataSet with a table Config and
>columns like "ConnectionString" and "DatabaseType". This code works
>1000% perfectly on the Microsoft .NET framework (and it's not very very
>platform specific, imho)
>
><?xml version="1.0" encoding="utf-8" ?>
><Config>
>
><!-- Database connectivity settings //-->
>        <ConnectionString>server=localhost;User
>ID=xnet;Password=xnet;database=XnetDotBe</ConnectionString>
>        <DatabaseType>SqlServer</DatabaseType>
>
><!-- Other possibilities //-->
><!--    <ConnectionString>server=W2SK-MSSQL;User
>ID=sa;Password=;database=Default</ConnectionString> //-->
><!--    <DatabaseType>Oracle</DatabaseType> //-->
><!--    <DatabaseType>MySQL</DatabaseType> //-->
><!--    <DatabaseType>PostgreSQL</DatabaseType> //-->
><!--    <DatabaseType>Odbc</DatabaseType> //-->
><!--    <DatabaseType>SqlServer</DatabaseType> //-->
>
><!-- The Implementations for each Interface //-->
>       
><IProject>Cronos.Xnet.XnetDotBe.DAL.Implementations.SqlServer.Project</IProject>
>        <IProject.Assembly>DAL</IProject.Assembly>
>       
><IEmployee>Cronos.Xnet.XnetDotBe.DAL.Implementations.SqlServer.Employee</IEmployee>
>        <IEmployee.Assembly>DAL</IEmployee.Assembly>
>        <ICustomer>Cronos.Xnet.XnetDotBe.DAL.Customer</ICustomer>
>        <ICustomer.Assembly>DAL</ICustomer.Assembly>
>        <ITechDomain>Cronos.Xnet.XnetDotBe.DAL.TechDomain</ITechDomain>
>        <ITechDomain.Assembly>DAL</ITechDomain.Assembly>
>        <ITechnology>Cronos.Xnet.XnetDotBe.DAL.Technology</ITechnology>
>        <ITechnology.Assembly>DAL</ITechnology.Assembly>
>
></Config>
>
>
>
>_______________________________________________
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>  
>
Hello,
There is a problem reading xml file that does not have a DataSet element 
as a root.
I can suggest a workaround - just add to the xml a DataSet element, exp:

<?xml version="1.0" encoding="utf-8" ?>
<MyDataSet>
<Config>

<!-- Database connectivity settings //-->
        <ConnectionString>server=localhost;User
ID=xnet;Password=xnet;database=XnetDotBe</ConnectionString>
        <DatabaseType>SqlServer</DatabaseType>

<!-- Other possibilities //-->
<!--    <ConnectionString>server=W2SK-MSSQL;User
ID=sa;Password=;database=Default</ConnectionString> //-->
<!--    <DatabaseType>Oracle</DatabaseType> //-->
<!--    <DatabaseType>MySQL</DatabaseType> //-->
<!--    <DatabaseType>PostgreSQL</DatabaseType> //-->
<!--    <DatabaseType>Odbc</DatabaseType> //-->
<!--    <DatabaseType>SqlServer</DatabaseType> //-->

<!-- The Implementations for each Interface //-->
       
<IProject>Cronos.Xnet.XnetDotBe.DAL.Implementations.SqlServer.Project</IProject>
        <IProject.Assembly>DAL</IProject.Assembly>
       
<IEmployee>Cronos.Xnet.XnetDotBe.DAL.Implementations.SqlServer.Employee</IEmployee>
        <IEmployee.Assembly>DAL</IEmployee.Assembly>
        <ICustomer>Cronos.Xnet.XnetDotBe.DAL.Customer</ICustomer>
        <ICustomer.Assembly>DAL</ICustomer.Assembly>
        <ITechDomain>Cronos.Xnet.XnetDotBe.DAL.TechDomain</ITechDomain>
        <ITechDomain.Assembly>DAL</ITechDomain.Assembly>
        <ITechnology>Cronos.Xnet.XnetDotBe.DAL.Technology</ITechnology>
        <ITechnology.Assembly>DAL</ITechnology.Assembly>

</Config>
</MyDataSet>




From S0302298 at newi.ac.uk  Sat Feb  7 09:17:30 2004
From: S0302298 at newi.ac.uk (Sergio Rubio)
Date: Sat, 07 Feb 2004 15:17:30 +0100
Subject: [Mono-devel-list] MCS bug?
Message-ID: <1076163450.8350.9.camel@bigdad>

Hi,
I haven't found anything about this on ximian's bugzilla.

TestProperty.cs makes mono crash when executed.
The file is attached.

mono --version:
Mono JIT compiler version 0.30.99.20040207

Cheers,
Rubio.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestProperty.cs
Type: text/x-csharp
Size: 232 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040207/295665d4/attachment.bin 

From iain at mccoy.id.au  Sun Feb  8 09:31:53 2004
From: iain at mccoy.id.au (Iain McCoy)
Date: Mon, 09 Feb 2004 01:31:53 +1100
Subject: [Mono-devel-list] MCS bug?
In-Reply-To: <1076163450.8350.9.camel@bigdad>
References: <1076163450.8350.9.camel@bigdad>
Message-ID: <1076250713.859.2.camel@artefact>

On Sun, 2004-02-08 at 01:17, Sergio Rubio wrote:
> Hi,
> TestProperty.cs makes mono crash when executed.

I'm curious. This is equivalent to writing something like this:
void Foo() { return Foo(); }

and calling it. It's going to cause an infinite loop - what do you think
mono should do in this situation?
-- 
Iain McCoy <iain at mccoy.id.au>



From martin at ximian.com  Sun Feb  8 10:13:03 2004
From: martin at ximian.com (Martin Baulig)
Date: Sun, 08 Feb 2004 16:13:03 +0100
Subject: [Mono-devel-list] MCS bug?
In-Reply-To: <1076250713.859.2.camel@artefact>
References: <1076163450.8350.9.camel@bigdad>
	 <1076250713.859.2.camel@artefact>
Message-ID: <1076253183.2007.8.camel@gondor.martin.baulig>

On Sun, 2004-02-08 at 15:31, Iain McCoy wrote:
> On Sun, 2004-02-08 at 01:17, Sergio Rubio wrote:
> > Hi,
> > TestProperty.cs makes mono crash when executed.
> 
> I'm curious. This is equivalent to writing something like this:
> void Foo() { return Foo(); }
> 
> and calling it. It's going to cause an infinite loop - what do you think
> mono should do in this situation?

Actually, it's causing a stack overflow because the method is being
invoked recursively.

--
Martin Baulig <martin at ximian.com>
Now blogging !  http://primates.ximian.com/~martin/blog



From met at uberstats.com  Sun Feb  8 12:03:13 2004
From: met at uberstats.com (Met @ Uber)
Date: Sun, 08 Feb 2004 12:03:13 -0500
Subject: [Mono-devel-list] Xsp DumpExtension Error
Message-ID: <1076259793.3963.3.camel@rasmus>

No matter what I do, I am unable to get .asmx pages to load correctly. 
I keep getting an error saying that it cannot load type 'DumpExtension,
extensions'.

Any ideas?

~ Matthew



From lluis at ximian.com  Sun Feb  8 15:03:41 2004
From: lluis at ximian.com (Lluis Sanchez)
Date: Sun, 08 Feb 2004 21:03:41 +0100
Subject: [Mono-devel-list] Xsp DumpExtension Error
In-Reply-To: <1076259793.3963.3.camel@rasmus>
References: <1076259793.3963.3.camel@rasmus>
Message-ID: <1076261610.4281.3.camel@portatil.aticatacs>

Hi,

If you want to use the DumpExtension XSP sample, make sure you have the
assembly extensions.dll in the bin directory. If you don't want to use
it, just remove the following line from the web.config file:

 <add type="DumpExtension, extensions" priority="0" group="0" />

Lluis.

On dg, 2004-02-08 at 18:03, Met @ Uber wrote:
> No matter what I do, I am unable to get .asmx pages to load correctly. 
> I keep getting an error saying that it cannot load type 'DumpExtension,
> extensions'.
> 
> Any ideas?
> 
> ~ Matthew
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From jackson at ximian.com  Sun Feb  8 15:08:45 2004
From: jackson at ximian.com (Jackson Harper)
Date: Sun, 08 Feb 2004 12:08:45 -0800
Subject: [Mono-devel-list] MCS bug?
In-Reply-To: <1076163450.8350.9.camel@bigdad>
References: <1076163450.8350.9.camel@bigdad>
Message-ID: <1076270924.22633.3.camel@localhost.localdomain>

That code recurses forever of course mono is going to crash. Fixed code
below.

Jackson


using System;
using System.Runtime.InteropServices;
public class TestProperty 
{
        int prop;

        public int Prop
        {
                get {
                        return prop;
                }
        }

        public static void Main()
        {
                TestProperty prop = new TestProperty();
                int i = prop.Prop;
        }
}


On Sat, 2004-02-07 at 06:17, Sergio Rubio wrote:
> Hi,
> I haven't found anything about this on ximian's bugzilla.
> 
> TestProperty.cs makes mono crash when executed.
> The file is attached.
> 
> mono --version:
> Mono JIT compiler version 0.30.99.20040207
> 
> Cheers,
> Rubio.



From malekith at pld-linux.org  Sun Feb  8 18:02:51 2004
From: malekith at pld-linux.org (Michal Moskal)
Date: Mon, 9 Feb 2004 00:02:51 +0100
Subject: [Mono-devel-list] adding new language to xsp
Message-ID: <20040208230251.GA16550@roke.freak>

Hello,

How do I add new language, so it is supported in .aspx pages? Does it
require writing CodeDom parser and/or generator? I couldn't find any
documentation regarding this subject, but I probably missed something,
and would be very interested in some links, or just a one sentence
explanation.

I would like to add support for Nemerle (http://nemerle.org/).

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?


From rafaelteixeirabr at hotmail.com  Sun Feb  8 19:36:51 2004
From: rafaelteixeirabr at hotmail.com (A Rafael D Teixeira)
Date: Sun, 08 Feb 2004 22:36:51 -0200
Subject: [Mono-devel-list] adding new language to xsp
Message-ID: <Sea2-F63CllPF6p0V7n00015cb6@hotmail.com>

>From: Michal Moskal <malekith at pld-linux.org>
>
>How do I add new language, so it is supported in .aspx pages?

Currently you need to change some code in our processing of the language 
directive, so that the CodeDom Generator for your language is used.

>Does it require writing CodeDom parser and/or generator?

A CodeDom generator is needed, and also a working compiler for the language 
called via a CodeCompiler (ours for C# and VB.NET do as MS' spawing a 
process that calls the command line compiler).

>I couldn't find any documentation regarding this subject, but I probably 
>missed something,
>and would be very interested in some links, or just a one sentence 
>explanation.

Sorry, just now I'm without to time to give you better directions, Gonzalo 
surely will help you a lot better and sooner.

>I would like to add support for Nemerle (http://nemerle.org/).

Very interesting language!!! I just hated the defs and mutables (just my bad 
taste). But I wish you success with this project.

>: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++

See You, Michal

Regards,

Rafael Teixeira
Brazilian Polymath
Mono Hacker since 16 Jul 2001
MonoBrasil Founding Member - Membro Fundador do MonoBrasil
English Blog: http://monoblog.blogspot.com/
Brazilian Portuguese Blog: http://monoblog.weblogger.terra.com.br/

_________________________________________________________________
MSN Messenger: instale gr?tis e converse com seus amigos. 
http://messenger.msn.com.br



From malekith at pld-linux.org  Mon Feb  9 05:11:20 2004
From: malekith at pld-linux.org (Michal Moskal)
Date: Mon, 9 Feb 2004 11:11:20 +0100
Subject: [Mono-devel-list] adding new language to xsp
In-Reply-To: <Sea2-F63CllPF6p0V7n00015cb6@hotmail.com>
References: <Sea2-F63CllPF6p0V7n00015cb6@hotmail.com>
Message-ID: <20040209101120.GA8722@roke.freak>

On Sun, Feb 08, 2004 at 10:36:51PM -0200, A Rafael D Teixeira wrote:
> >From: Michal Moskal <malekith at pld-linux.org>
> >
> >How do I add new language, so it is supported in .aspx pages?
> 
> Currently you need to change some code in our processing of the language 
> directive, so that the CodeDom Generator for your language is used.
> 
> >Does it require writing CodeDom parser and/or generator?
> 
> A CodeDom generator is needed, and also a working compiler for the language 
> called via a CodeCompiler (ours for C# and VB.NET do as MS' spawing a 
> process that calls the command line compiler).

Do I need *entire* codedom? That is for example CodeGotoExpression would
be quite hard to implement for me. Thanks anyway. I'll look into sources.

> >I would like to add support for Nemerle (http://nemerle.org/).
> 
> Very interesting language!!! I just hated the defs and mutables (just my 
> bad taste). But I wish you success with this project.

Thanks!

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?


From joergr at voelcker.com  Mon Feb  9 09:13:37 2004
From: joergr at voelcker.com (=?iso-8859-1?Q?J=F6rg_Rosenkranz?=)
Date: Mon, 9 Feb 2004 15:13:37 +0100
Subject: [Mono-devel-list] [PATCH] Calling OracleLob.Erase with zero based index
Message-ID: <23BE0C16E0C22F48B3FB5B0BD6B5307B27963F@visdd003.devdd.vi.lan>

Hello,

The attached patch fixes a minor problem with OracleLob.Erase.
The implementation of Erase without parameters called the other
implementation using an offset of 1. This leads to an
ArgumentOutOfRangeException for all calls.

Could you please commit this patch?

Thanks,
Joerg.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OracleLob_Erase.diff
Type: application/octet-stream
Size: 1141 bytes
Desc: OracleLob_Erase.diff
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040209/7f161d17/attachment.obj 

From jason.king at profox.co.uk  Mon Feb  9 10:15:06 2004
From: jason.king at profox.co.uk (Jason King)
Date: Mon, 9 Feb 2004 15:15:06 -0000
Subject: [Mono-devel-list] Mono tools
Message-ID: <JDEEKAHPEBFHCCNMGFFKCEOCCGAA.jason.king@profox.co.uk>

Hello everybody.

Does anyone have a list of the tools that ship with Mono, and a brief
description of what they do and where they can be found?

Thanks
Jase

Regards,
Jason King
Profox Systems Ltd 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 1560 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040209/510a6c65/attachment.bin 

From tim at timcoleman.com  Mon Feb  9 13:28:10 2004
From: tim at timcoleman.com (tim at timcoleman.com)
Date: Mon, 09 Feb 2004 13:28:10 -0500
Subject: [Mono-devel-list] Re: [PATCH] Calling OracleLob.Erase with zero based index
In-Reply-To: Message from =?iso-8859-1?Q?J=F6rg_Rosenkranz?= <joergr@voelcker.com> 
   of "Mon, 09 Feb 2004 15:13:37 +0100." <23BE0C16E0C22F48B3FB5B0BD6B5307B27963F@visdd003.devdd.vi.lan> 
References: <23BE0C16E0C22F48B3FB5B0BD6B5307B27963F@visdd003.devdd.vi.lan> 
Message-ID: <200402091828.i19ISAtq027960@tux.epenguin.org>

> This is a multi-part message in MIME format.
> 
> ------_=_NextPart_001_01C3EF16.E912284B
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> Hello,
> 
> The attached patch fixes a minor problem with OracleLob.Erase.
> The implementation of Erase without parameters called the other
> implementation using an offset of 1. This leads to an
> ArgumentOutOfRangeException for all calls.
> 
> Could you please commit this patch?
> 
> Thanks,
> Joerg.

I have applied this patch, thanks.
-- 
Tim Coleman       <tim at timcoleman.com>                  [43.43 N 80.45 W]
BMath, Honours Combinatorics and Optimization, University of Waterloo
Software Developer * RDBMS Specialist * Linux Zealot
"I never let my schooling get in the way of my education." -- Mark Twain


From umuff at QUARK.com  Mon Feb  9 14:41:54 2004
From: umuff at QUARK.com (Urs Muff)
Date: Mon, 9 Feb 2004 12:41:54 -0700 
Subject: [Mono-devel-list] ** ERROR **: file appdomain.c: line 898 (ves_icall_System_AppDoma
 in_LoadAssembly): assetion failed: (assRef != NULL), aborting...
Message-ID: <A70185F8290B6E4B92F848A60D21481D18E86C@usmxsrv1.quark.com>

I tried AppDomain.CurrentDomain.Load, Assembly.Load, Assembly.LoadFile, and
Assembly.LoadWithPartialName.  I always get the same error.

I don't know which reference cannot be loaded, but all references are either
in the same directory as the assembly to be loaded, or system assemblies.

I'm also adding a AssemblyResolve handler (which is not called).

Please advice: what parts are supported on mono?  [BTW: this code is running
fine on .Net 1.1].
This is a showstopper for me: I can't get further without a workaround or
fix...

- Urs C. Muff
Software Architect		- Research Lab
Quark Inc.
UMuff at Quark.Com    	- X6360
+1 (303) 894 3360
CONFIDENTIALITY NOTICE
This e-mail transmission and any documents, files, or previous e-mail
messages appended or attached to it, may contain information that is
confidential or legally privileged. If you are not the intended recipient,
or a person responsible for delivering it to the intended recipient, you are
hereby notified that you must not read this transmission and that any
disclosure, copying, printing, distribution, or use of the information
contained or attached to this transmission is STRICTLY PROHIBITED. If you
have received this transmission in error, please immediately notify the
sender by telephone +1 (303) 894-3360 or return e-mail message
umuff at quark.com <mailto:umuff at quark.com>  and delete the original
transmission, its attachments, and any copies without reading or saving in
any manner. Thank you.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040209/82f0b2bd/attachment.html 

From RUBIOJR at terra.es  Mon Feb  9 15:03:49 2004
From: RUBIOJR at terra.es (RUBIOJR)
Date: Mon, 09 Feb 2004 20:03:49 GMT
Subject: [Mono-devel-list] MCS bug?
Message-ID: <7f6d17e170.7e1707f6d1@teleline.es>

Sorry, I thought it should be checked by the compiler.

A stupid thought I supose.

Cheers,
Rubio

----- Mensaje Original -----
De: Jackson Harper <jackson at ximian.com>
Fecha: Domingo, Febrero 8, 2004 8:08 pm
Asunto: Re: [Mono-devel-list] MCS bug?

> That code recurses forever of course mono is going to crash. Fixed 
> codebelow.
> 
> Jackson
> 
> 
> using System;
> using System.Runtime.InteropServices;
> public class TestProperty 
> {
>        int prop;
> 
>        public int Prop
>        {
>                get {
>                        return prop;
>                }
>        }
> 
>        public static void Main()
>        {
>                TestProperty prop = new TestProperty();
>                int i = prop.Prop;
>        }
> }
> 
> 
> On Sat, 2004-02-07 at 06:17, Sergio Rubio wrote:
> > Hi,
> > I haven't found anything about this on ximian's bugzilla.
> > 
> > TestProperty.cs makes mono crash when executed.
> > The file is attached.
> > 
> > mono --version:
> > Mono JIT compiler version 0.30.99.20040207
> > 
> > Cheers,
> > Rubio.
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 




From dave-monolist at earth.li  Mon Feb  9 15:59:06 2004
From: dave-monolist at earth.li (David Sheldon)
Date: Mon, 9 Feb 2004 20:59:06 +0000
Subject: [Mono-devel-list] MCS bug?
In-Reply-To: <7f6d17e170.7e1707f6d1@teleline.es>
References: <7f6d17e170.7e1707f6d1@teleline.es>
Message-ID: <20040209205906.GD20501@ox.compsoc.net>

The fact that it is recursive is not something that the compiler should
check, however csc does give the warning 
   
   "test.cs(5,13): warning CS0169: The private field
   'TestProperty.prop' is never used"

Which mono does not. Should this be reported as a bug in mcs in its own
right?

David

On Mon, Feb 09, 2004 at 08:03:49PM +0000, RUBIOJR wrote:
> Sorry, I thought it should be checked by the compiler.
> 
> A stupid thought I supose.

-- 
             Of course when you're making an erotic movie
                  it's very easy to muff your lines.
                      -- Channel 5 Voiceover Guy


From martin at ximian.com  Mon Feb  9 16:12:26 2004
From: martin at ximian.com (Martin Baulig)
Date: Mon, 09 Feb 2004 22:12:26 +0100
Subject: [Mono-devel-list] MCS bug?
In-Reply-To: <20040209205906.GD20501@ox.compsoc.net>
References: <7f6d17e170.7e1707f6d1@teleline.es>
	 <20040209205906.GD20501@ox.compsoc.net>
Message-ID: <1076361146.2007.20.camel@gondor.martin.baulig>

On Mon, 2004-02-09 at 21:59, David Sheldon wrote:
> The fact that it is recursive is not something that the compiler should
> check, however csc does give the warning 
>    
>    "test.cs(5,13): warning CS0169: The private field
>    'TestProperty.prop' is never used"
> 
> Which mono does not. Should this be reported as a bug in mcs in its own
> right?

Have you tried this with a higher warning level in mcs ?  If I remember
correctly, csc and mcs have different default warning levels and you
only get this warning in level 3 or 4.

--
Martin Baulig <martin at ximian.com>
Now blogging !  http://primates.ximian.com/~martin/blog



From dave-monolist at earth.li  Mon Feb  9 17:35:38 2004
From: dave-monolist at earth.li (David Sheldon)
Date: Mon, 9 Feb 2004 22:35:38 +0000
Subject: [Mono-devel-list] MCS bug?
In-Reply-To: <1076361146.2007.20.camel@gondor.martin.baulig>
References: <7f6d17e170.7e1707f6d1@teleline.es> <20040209205906.GD20501@ox.compsoc.net> <1076361146.2007.20.camel@gondor.martin.baulig>
Message-ID: <20040209223538.GE20501@ox.compsoc.net>

On Mon, Feb 09, 2004 at 10:12:26PM +0100, Martin Baulig wrote:
> On Mon, 2004-02-09 at 21:59, David Sheldon wrote:
> > The fact that it is recursive is not something that the compiler should
> > check, however csc does give the warning 
> >    
> >    "test.cs(5,13): warning CS0169: The private field
> >    'TestProperty.prop' is never used"
> > 
> > Which mono does not. Should this be reported as a bug in mcs in its own
> > right?
> 
> Have you tried this with a higher warning level in mcs ?  If I remember
> correctly, csc and mcs have different default warning levels and you
> only get this warning in level 3 or 4.

Oh, nice. I hadn't seen that before. Yes, with warning on 3 or 4, mcs
reports two warnings. 

The other is:
 warning CS0219: The variable `i' is assigned but its value is never
 used

David
-- 
I wish my keyboard had a SMITE key
    -- J-P Stacey


From peter at newton.cx  Mon Feb  9 21:12:42 2004
From: peter at newton.cx (Peter Williams)
Date: Mon, 09 Feb 2004 21:12:42 -0500
Subject: [Mono-devel-list] MBuild preview release 0.0.2
Message-ID: <1076379161.18547.6.camel@beta.newton.cx>

Hi everyone,

I've posted an updated preview of MBuild, my fancy slicey-dicey build
tool at:

	http://www.newton.cx/~peter/software/mbuild-0.0.2.tar.gz

As before, see doc/Manifesto.txt in the tarball for an explanation of
what I'm trying to accomplish with MBuild.

There's been a lot of work under the hood: there's now a nice system for
executing tools, with classes for filtering their output a la grep and
sed; the beginnings of the configury mechanism are in place; the logging
and error reporting infrastructure is working now; and I have target
'tags' working although there isn't much fancy going on so far.

As in the first release, there's a walkthrough in the file TUTORIAL.
It's been updated to demonstrate the new features in this release.

I'd be glad to answer any questions or comments that come up. MBuild
still has a user base of exactly 0, but the infrastructure is coming
along nicely. Still, on the whole, MBuild won't change your life ...
*yet*.

Peter

-- 
Peter Williams                          peter at newton.cx

"[Ninjas] are cool; and by cool, I mean totally sweet."
                              -- REAL Ultimate Power



From met at uberstats.com  Mon Feb  9 21:47:44 2004
From: met at uberstats.com (Met @ Uber)
Date: Mon, 09 Feb 2004 21:47:44 -0500
Subject: [Mono-devel-list] Possible problems with Npgsql
Message-ID: <1076381264.9330.12.camel@rasmus>

I really have no idea how to continue debugging the following errors,
but all the arrows keep pointing towards Npgsql.

The following is a snippet printed to my screen if I turn on logging
within Npgsql.  Does this look familiar to anyone?  I'm not using any
lists of any sort that I am directly aware of.  Any help, any at all
would be extremely appreciated.

Suggestions?

===
Entering NpgsqlState.ChangeState()
Index is less than 0 or more than or equal to the list count.
Parameter name: index
0
===

~ Matthew

P.S. The full log file is attached.

-------------- next part --------------
2/9/04 9:40:39 a	12833	Normal	Set NpgsqlEventLog.EchoMessages = True
2/9/04 9:40:40 a	12833	Debug	Entering NpgsqlConnection.NpgsqlConnection(Server=localhost;Database=dotGrr;User ID=chinwag;Password=chinwag;)
2/9/04 9:40:40 a	12833	Debug	Get NpgsqlClosedState.Instance
2/9/04 9:40:40 a	12833	Debug	Entering NpgsqlConnection.ParseConnectionString()
2/9/04 9:40:40 a	12833	Debug	Connection string option: SERVER = localhost
2/9/04 9:40:40 a	12833	Debug	Connection string option: DATABASE = dotGrr
2/9/04 9:40:40 a	12833	Debug	Connection string option: USER ID = chinwag
2/9/04 9:40:40 a	12833	Debug	Connection string option: PASSWORD = chinwag
2/9/04 9:40:40 a	12833	Debug	Entering NpgsqlConnection.Open()
2/9/04 9:40:40 a	12833	Debug	Get NpgsqlClosedState.Instance
2/9/04 9:40:40 a	12833	Debug	Entering NpgsqlClosedState.Open()
2/9/04 9:40:40 a	12833	Normal	Connected to: localhost:5432.
2/9/04 9:40:40 a	12833	Debug	Entering NpgsqlState.ChangeState()
2/9/04 9:40:40 a	12833	Debug	Entering NpgsqlStartupPacket.NpgsqlStartupPacket()
2/9/04 9:40:40 a	12833	Debug	Entering NpgsqlStartupPacket.WriteToStream()
2/9/04 9:40:40 a	12833	Debug	Entering PGUtil.WriteString()
2/9/04 9:40:40 a	12833	Debug	Entering PGUtil.WriteString()
2/9/04 9:40:40 a	12833	Debug	Entering PGUtil.WriteString()
2/9/04 9:40:40 a	12833	Debug	Entering PGUtil.WriteString()
2/9/04 9:40:40 a	12833	Debug	Entering NpgsqlState.ProcessBackendResponses()
2/9/04 9:40:40 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:40 a	12833	Debug	String read: L:  unsupported frontend protocol
.
2/9/04 9:40:40 a	12833	Debug	ErrorResponse message from Server: FATAL:  unsupported frontend protocol
.
2/9/04 9:40:40 a	12833	Debug	Get NpgsqlClosedState.Instance
2/9/04 9:40:40 a	12833	Debug	Entering NpgsqlClosedState.Open()
2/9/04 9:40:40 a	12833	Normal	Connected to: localhost:5432.
2/9/04 9:40:40 a	12833	Debug	Entering NpgsqlState.ChangeState()
2/9/04 9:40:40 a	12833	Debug	Entering NpgsqlStartupPacket.NpgsqlStartupPacket()
2/9/04 9:40:40 a	12833	Debug	Entering NpgsqlStartupPacket.WriteToStream()
2/9/04 9:40:41 a	12833	Debug	Entering PGUtil.WriteLimString()
2/9/04 9:40:41 a	12833	Debug	Entering PGUtil.WriteLimString()
2/9/04 9:40:41 a	12833	Debug	Entering PGUtil.WriteLimString()
2/9/04 9:40:41 a	12833	Debug	Entering PGUtil.WriteLimString()
2/9/04 9:40:41 a	12833	Debug	Entering PGUtil.WriteLimString()
2/9/04 9:40:41 a	12833	Debug	Entering NpgsqlState.ProcessBackendResponses()
2/9/04 9:40:41 a	12833	Debug	AuthenticationRequest message received from server.
2/9/04 9:40:41 a	12833	Debug	AuthenticationOK received.
2/9/04 9:40:41 a	12833	Debug	BackendKeyData message received from server.
2/9/04 9:40:41 a	12833	Debug	Entering NpgsqlBackEndKeyData.NpgsqlBackEndKeyData()
2/9/04 9:40:41 a	12833	Debug	ReadyForQuery message received from server.
2/9/04 9:40:41 a	12833	Debug	Entering NpgsqlState.ChangeState()
2/9/04 9:40:41 a	12833	Debug	Entering NpgsqlCommand.NpgsqlCommand()
2/9/04 9:40:41 a	12833	Debug	Entering NpgsqlParameterCollection.NpgsqlParameterCollection()
2/9/04 9:40:41 a	12833	Debug	Set NpgsqlCommand.Transaction = 
2/9/04 9:40:41 a	12833	Debug	Entering NpgsqlCommand.ExecuteScalar()
2/9/04 9:40:41 a	12833	Debug	Entering NpgsqlCommand.CheckConnectionState()
2/9/04 9:40:41 a	12833	Debug	Entering NpgsqlReadyState.Query()
2/9/04 9:40:41 a	12833	Debug	Entering NpgsqlCommand.GetCommandText()
2/9/04 9:40:41 a	12833	Debug	Entering NpgsqlCommand.GetClearCommandText()
2/9/04 9:40:41 a	12833	Debug	Get NpgsqlParameterCollection.Count
2/9/04 9:40:41 a	12833	Debug	Query sent: select version();set DATESTYLE TO ISO;.
2/9/04 9:40:41 a	12833	Debug	Entering PGUtil.WriteString()
2/9/04 9:40:41 a	12833	Debug	Entering NpgsqlState.ProcessBackendResponses()
2/9/04 9:40:41 a	12833	Debug	CursorResponse message received from server.
2/9/04 9:40:41 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:41 a	12833	Debug	String read: blank.
2/9/04 9:40:41 a	12833	Debug	RowDescription message received from server.
2/9/04 9:40:41 a	12833	Debug	Entering NpgsqlRowDescription.ReadFromStream()
2/9/04 9:40:41 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:42 a	12833	Debug	String read: version.
2/9/04 9:40:42 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:42 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:42 a	12833	Debug	String read: SELECT.
2/9/04 9:40:42 a	12833	Debug	CompletedResponse message from Server: SELECT.
2/9/04 9:40:42 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:42 a	12833	Debug	String read: SET.
2/9/04 9:40:42 a	12833	Debug	CompletedResponse message from Server: SET.
2/9/04 9:40:42 a	12833	Debug	ReadyForQuery message received from server.
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlState.ChangeState()
2/9/04 9:40:42 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlConnection.ProcessServerVersion()
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlDataReader.LoadTypesMapping()
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlCommand.NpgsqlCommand()
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlParameterCollection.NpgsqlParameterCollection()
2/9/04 9:40:42 a	12833	Debug	Set NpgsqlCommand.Transaction = 
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlCommand.ExecuteReader()
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlCommand.ExecuteReader(Default)
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlCommand.CheckConnectionState()
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlReadyState.Query()
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlCommand.GetCommandText()
2/9/04 9:40:42 a	12833	Debug	Entering NpgsqlCommand.GetClearCommandText()
2/9/04 9:40:42 a	12833	Debug	Get NpgsqlParameterCollection.Count
2/9/04 9:40:42 a	12833	Debug	Query sent: select oid, typname from pg_type where typname in ('bool', 'bytea', 'date', 'float4', 'float8', 'int2', 'int4', 'int8', 'numeric', 'text', 'time', 'timestamp');.
2/9/04 9:40:42 a	12833	Debug	Entering PGUtil.WriteString()
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlState.ProcessBackendResponses()
2/9/04 9:40:43 a	12833	Debug	CursorResponse message received from server.
2/9/04 9:40:43 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:43 a	12833	Debug	String read: blank.
2/9/04 9:40:43 a	12833	Debug	RowDescription message received from server.
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlRowDescription.ReadFromStream()
2/9/04 9:40:43 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:43 a	12833	Debug	String read: oid.
2/9/04 9:40:43 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:43 a	12833	Debug	String read: typname.
2/9/04 9:40:43 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(1)
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:43 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(1)
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:43 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:43 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(1)
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:44 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(1)
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:44 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(1)
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:44 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(1)
2/9/04 9:40:44 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:44 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(1)
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:45 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(1)
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:45 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(1)
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:45 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:45 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(1)
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:46 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(1)
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:46 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(1)
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:46 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:46 a	12833	Debug	String read: SELECT.
2/9/04 9:40:46 a	12833	Debug	CompletedResponse message from Server: SELECT.
2/9/04 9:40:46 a	12833	Debug	ReadyForQuery message received from server.
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlState.ChangeState()
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlDataReader.Read()
2/9/04 9:40:46 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:47 a	12833	Debug	Get NpgsqlDataReader.this[1]
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:47 a	12833	Debug	Get NpgsqlAsciiRow.this[1]
2/9/04 9:40:47 a	12833	Debug	Get NpgsqlDataReader.this[0]
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:47 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.Read()
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:47 a	12833	Debug	Get NpgsqlDataReader.this[1]
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:47 a	12833	Debug	Get NpgsqlAsciiRow.this[1]
2/9/04 9:40:47 a	12833	Debug	Get NpgsqlDataReader.this[0]
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:47 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.Read()
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:47 a	12833	Debug	Get NpgsqlDataReader.this[1]
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:47 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:47 a	12833	Debug	Get NpgsqlAsciiRow.this[1]
2/9/04 9:40:48 a	12833	Debug	Get NpgsqlDataReader.this[0]
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:48 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.Read()
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:48 a	12833	Debug	Get NpgsqlDataReader.this[1]
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:48 a	12833	Debug	Get NpgsqlAsciiRow.this[1]
2/9/04 9:40:48 a	12833	Debug	Get NpgsqlDataReader.this[0]
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:48 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.Read()
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:48 a	12833	Debug	Get NpgsqlDataReader.this[1]
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:48 a	12833	Debug	Get NpgsqlAsciiRow.this[1]
2/9/04 9:40:48 a	12833	Debug	Get NpgsqlDataReader.this[0]
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:48 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.Read()
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:48 a	12833	Debug	Get NpgsqlDataReader.this[1]
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:48 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:49 a	12833	Debug	Get NpgsqlAsciiRow.this[1]
2/9/04 9:40:49 a	12833	Debug	Get NpgsqlDataReader.this[0]
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:49 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.Read()
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:49 a	12833	Debug	Get NpgsqlDataReader.this[1]
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:49 a	12833	Debug	Get NpgsqlAsciiRow.this[1]
2/9/04 9:40:49 a	12833	Debug	Get NpgsqlDataReader.this[0]
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:49 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.Read()
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:49 a	12833	Debug	Get NpgsqlDataReader.this[1]
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:49 a	12833	Debug	Get NpgsqlAsciiRow.this[1]
2/9/04 9:40:49 a	12833	Debug	Get NpgsqlDataReader.this[0]
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:49 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.Read()
2/9/04 9:40:49 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:49 a	12833	Debug	Get NpgsqlDataReader.this[1]
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:50 a	12833	Debug	Get NpgsqlAsciiRow.this[1]
2/9/04 9:40:50 a	12833	Debug	Get NpgsqlDataReader.this[0]
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:50 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.Read()
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:50 a	12833	Debug	Get NpgsqlDataReader.this[1]
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:50 a	12833	Debug	Get NpgsqlAsciiRow.this[1]
2/9/04 9:40:50 a	12833	Debug	Get NpgsqlDataReader.this[0]
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:50 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.Read()
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:50 a	12833	Debug	Get NpgsqlDataReader.this[1]
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:50 a	12833	Debug	Get NpgsqlAsciiRow.this[1]
2/9/04 9:40:50 a	12833	Debug	Get NpgsqlDataReader.this[0]
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:50 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.Read()
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:50 a	12833	Debug	Get NpgsqlDataReader.this[1]
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:50 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:50 a	12833	Debug	Get NpgsqlAsciiRow.this[1]
2/9/04 9:40:51 a	12833	Debug	Get NpgsqlDataReader.this[0]
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlDataReader.GetValue()
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:51 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlDataReader.Read()
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlDataReader.CanRead()
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlConnection.NpgsqlConnection(Server=localhost;Database=dotGrr;User ID=chinwag;Password=chinwag;)
2/9/04 9:40:51 a	12833	Debug	Get NpgsqlClosedState.Instance
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlConnection.ParseConnectionString()
2/9/04 9:40:51 a	12833	Debug	Connection string option: SERVER = localhost
2/9/04 9:40:51 a	12833	Debug	Connection string option: DATABASE = dotGrr
2/9/04 9:40:51 a	12833	Debug	Connection string option: USER ID = chinwag
2/9/04 9:40:51 a	12833	Debug	Connection string option: PASSWORD = chinwag
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlConnection.Open()
2/9/04 9:40:51 a	12833	Debug	Get NpgsqlClosedState.Instance
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlClosedState.Open()
2/9/04 9:40:51 a	12833	Normal	Connected to: localhost:5432.
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlState.ChangeState()
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlStartupPacket.NpgsqlStartupPacket()
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlStartupPacket.WriteToStream()
2/9/04 9:40:51 a	12833	Debug	Entering PGUtil.WriteString()
2/9/04 9:40:51 a	12833	Debug	Entering PGUtil.WriteString()
2/9/04 9:40:51 a	12833	Debug	Entering PGUtil.WriteString()
2/9/04 9:40:51 a	12833	Debug	Entering PGUtil.WriteString()
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlState.ProcessBackendResponses()
2/9/04 9:40:51 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:51 a	12833	Debug	String read: L:  unsupported frontend protocol
.
2/9/04 9:40:51 a	12833	Debug	ErrorResponse message from Server: FATAL:  unsupported frontend protocol
.
2/9/04 9:40:51 a	12833	Debug	Get NpgsqlClosedState.Instance
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlClosedState.Open()
2/9/04 9:40:51 a	12833	Normal	Connected to: localhost:5432.
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlState.ChangeState()
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlStartupPacket.NpgsqlStartupPacket()
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlStartupPacket.WriteToStream()
2/9/04 9:40:51 a	12833	Debug	Entering PGUtil.WriteLimString()
2/9/04 9:40:51 a	12833	Debug	Entering PGUtil.WriteLimString()
2/9/04 9:40:51 a	12833	Debug	Entering PGUtil.WriteLimString()
2/9/04 9:40:51 a	12833	Debug	Entering PGUtil.WriteLimString()
2/9/04 9:40:51 a	12833	Debug	Entering PGUtil.WriteLimString()
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlState.ProcessBackendResponses()
2/9/04 9:40:51 a	12833	Debug	AuthenticationRequest message received from server.
2/9/04 9:40:51 a	12833	Debug	AuthenticationOK received.
2/9/04 9:40:51 a	12833	Debug	BackendKeyData message received from server.
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlBackEndKeyData.NpgsqlBackEndKeyData()
2/9/04 9:40:51 a	12833	Debug	ReadyForQuery message received from server.
2/9/04 9:40:51 a	12833	Debug	Entering NpgsqlState.ChangeState()
2/9/04 9:40:52 a	12833	Debug	Entering NpgsqlCommand.NpgsqlCommand()
2/9/04 9:40:52 a	12833	Debug	Entering NpgsqlParameterCollection.NpgsqlParameterCollection()
2/9/04 9:40:52 a	12833	Debug	Set NpgsqlCommand.Transaction = 
2/9/04 9:40:52 a	12833	Debug	Entering NpgsqlCommand.ExecuteScalar()
2/9/04 9:40:52 a	12833	Debug	Entering NpgsqlCommand.CheckConnectionState()
2/9/04 9:40:52 a	12833	Debug	Entering NpgsqlReadyState.Query()
2/9/04 9:40:52 a	12833	Debug	Entering NpgsqlCommand.GetCommandText()
2/9/04 9:40:52 a	12833	Debug	Entering NpgsqlCommand.GetClearCommandText()
2/9/04 9:40:52 a	12833	Debug	Get NpgsqlParameterCollection.Count
2/9/04 9:40:52 a	12833	Debug	Query sent: select version();set DATESTYLE TO ISO;.
2/9/04 9:40:52 a	12833	Debug	Entering PGUtil.WriteString()
2/9/04 9:40:52 a	12833	Debug	Entering NpgsqlState.ProcessBackendResponses()
2/9/04 9:40:52 a	12833	Debug	CursorResponse message received from server.
2/9/04 9:40:52 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:52 a	12833	Debug	String read: blank.
2/9/04 9:40:52 a	12833	Debug	RowDescription message received from server.
2/9/04 9:40:52 a	12833	Debug	Entering NpgsqlRowDescription.ReadFromStream()
2/9/04 9:40:52 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:52 a	12833	Debug	String read: version.
2/9/04 9:40:52 a	12833	Debug	AsciiRow message received from server.
2/9/04 9:40:52 a	12833	Debug	Entering NpgsqlAsciiRow.NpgsqlAsciiRow()
2/9/04 9:40:52 a	12833	Debug	Entering NpgsqlAsciiRow.ReadFromStream()()
2/9/04 9:40:52 a	12833	Debug	Entering NpgsqlAsciiRow.IsNull(0)
2/9/04 9:40:52 a	12833	Debug	Entering NpgsqlDataReader.ConvertBackendStringToSystemType()
2/9/04 9:40:53 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:53 a	12833	Debug	String read: SELECT.
2/9/04 9:40:53 a	12833	Debug	CompletedResponse message from Server: SELECT.
2/9/04 9:40:53 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:53 a	12833	Debug	String read: SET.
2/9/04 9:40:53 a	12833	Debug	CompletedResponse message from Server: SET.
2/9/04 9:40:53 a	12833	Debug	ReadyForQuery message received from server.
2/9/04 9:40:53 a	12833	Debug	Entering NpgsqlState.ChangeState()
2/9/04 9:40:53 a	12833	Debug	Get NpgsqlAsciiRow.this[0]
2/9/04 9:40:53 a	12833	Debug	Entering NpgsqlConnection.ProcessServerVersion()
2/9/04 9:40:53 a	12833	Debug	Entering NpgsqlDataReader.LoadTypesMapping()
2/9/04 9:40:53 a	12833	Debug	Entering NpgsqlConnection.IDbConnection.CreateCommand()
2/9/04 9:40:53 a	12833	Debug	Entering NpgsqlConnection.CreateCommand()
2/9/04 9:40:53 a	12833	Debug	Entering NpgsqlCommand.NpgsqlCommand()
2/9/04 9:40:53 a	12833	Debug	Entering NpgsqlParameterCollection.NpgsqlParameterCollection()
2/9/04 9:40:53 a	12833	Debug	Set NpgsqlCommand.Transaction = 
2/9/04 9:40:53 a	12833	Debug	Set NpgsqlCommand.CommandText = DELETE FROM member WHERE id = '01010101'
2/9/04 9:40:53 a	12833	Debug	Entering NpgsqlCommand.ExecuteNonQuery()
2/9/04 9:40:53 a	12833	Debug	Entering NpgsqlCommand.CheckConnectionState()
2/9/04 9:40:53 a	12833	Debug	Entering NpgsqlReadyState.Query()
2/9/04 9:40:53 a	12833	Debug	Entering NpgsqlCommand.GetCommandText()
2/9/04 9:40:53 a	12833	Debug	Entering NpgsqlCommand.GetClearCommandText()
2/9/04 9:40:53 a	12833	Debug	Get NpgsqlParameterCollection.Count
2/9/04 9:40:53 a	12833	Debug	Query sent: DELETE FROM member WHERE id = '01010101'.
2/9/04 9:40:54 a	12833	Debug	Entering PGUtil.WriteString()
2/9/04 9:40:54 a	12833	Debug	Entering NpgsqlState.ProcessBackendResponses()
2/9/04 9:40:54 a	12833	Debug	CursorResponse message received from server.
2/9/04 9:40:54 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:54 a	12833	Debug	String read: blank.
2/9/04 9:40:54 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:54 a	12833	Debug	String read: DELETE 0.
2/9/04 9:40:54 a	12833	Debug	CompletedResponse message from Server: DELETE 0.
2/9/04 9:40:54 a	12833	Debug	ReadyForQuery message received from server.
2/9/04 9:40:54 a	12833	Debug	Entering NpgsqlState.ChangeState()
2/9/04 9:40:54 a	12833	Debug	Entering NpgsqlConnection.IDbConnection.CreateCommand()
2/9/04 9:40:54 a	12833	Debug	Entering NpgsqlConnection.CreateCommand()
2/9/04 9:40:54 a	12833	Debug	Entering NpgsqlCommand.NpgsqlCommand()
2/9/04 9:40:54 a	12833	Debug	Entering NpgsqlParameterCollection.NpgsqlParameterCollection()
2/9/04 9:40:54 a	12833	Debug	Set NpgsqlCommand.Transaction = 
2/9/04 9:40:54 a	12833	Debug	Set NpgsqlCommand.CommandText = SELECT * FROM member WHERE id = '01010101'
2/9/04 9:40:54 a	12833	Debug	Entering NpgsqlCommand.ExecuteScalar()
2/9/04 9:40:54 a	12833	Debug	Entering NpgsqlCommand.CheckConnectionState()
2/9/04 9:40:54 a	12833	Debug	Entering NpgsqlReadyState.Query()
2/9/04 9:40:54 a	12833	Debug	Entering NpgsqlCommand.GetCommandText()
2/9/04 9:40:54 a	12833	Debug	Entering NpgsqlCommand.GetClearCommandText()
2/9/04 9:40:54 a	12833	Debug	Get NpgsqlParameterCollection.Count
2/9/04 9:40:55 a	12833	Debug	Query sent: SELECT * FROM member WHERE id = '01010101'.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.WriteString()
2/9/04 9:40:55 a	12833	Debug	Entering NpgsqlState.ProcessBackendResponses()
2/9/04 9:40:55 a	12833	Debug	CursorResponse message received from server.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: blank.
2/9/04 9:40:55 a	12833	Debug	RowDescription message received from server.
2/9/04 9:40:55 a	12833	Debug	Entering NpgsqlRowDescription.ReadFromStream()
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: id.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: password.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: first_name.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: last_name.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: email.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: home_phone.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: work_phone.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: description.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: image.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: inactive.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: id_number.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: organization_id.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: last_login.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: old_login.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: username.
2/9/04 9:40:55 a	12833	Debug	Entering PGUtil.ReadString()
2/9/04 9:40:55 a	12833	Debug	String read: SELECT.
2/9/04 9:40:55 a	12833	Debug	CompletedResponse message from Server: SELECT.
2/9/04 9:40:55 a	12833	Debug	ReadyForQuery message received from server.
2/9/04 9:40:55 a	12833	Debug	Entering NpgsqlState.ChangeState()
2/9/04 9:40:55 a	12833	Debug	Entering NpgsqlConnection.Dispose(True)
2/9/04 9:40:55 a	12833	Debug	Entering NpgsqlConnection.Dispose(True)

From phil at noggle.biz  Mon Feb  9 22:10:00 2004
From: phil at noggle.biz (Philip Tricca)
Date: Mon, 09 Feb 2004 22:10:00 -0500
Subject: [Mono-devel-list] Possible problems with Npgsql
In-Reply-To: <1076381264.9330.12.camel@rasmus>
References: <1076381264.9330.12.camel@rasmus>
Message-ID: <1076382600.6031.5.camel@dhcppc5>

Matt,

On Mon, 2004-02-09 at 21:47, Met @ Uber wrote:
> I really have no idea how to continue debugging the following errors,
> but all the arrows keep pointing towards Npgsql.
> 
> The following is a snippet printed to my screen if I turn on logging
> within Npgsql.  Does this look familiar to anyone?  I'm not using any
> lists of any sort that I am directly aware of.  Any help, any at all
> would be extremely appreciated.
> 
> Suggestions?
> 
> ===
> Entering NpgsqlState.ChangeState()
> Index is less than 0 or more than or equal to the list count.
> Parameter name: index
> 0
> ===
> 
> ~ Matthew
> 
> P.S. The full log file is attached.
> 

This is far from a fix but your problem sounds a lot like the
OracleLob.Erase bug that was patched and sent to the list earlier today.

Might ring a bell with someone who knows more.

 - Phil



From ianm at ActiveState.com  Tue Feb 10 01:28:17 2004
From: ianm at ActiveState.com (Ian MacLean)
Date: Tue, 10 Feb 2004 15:28:17 +0900
Subject: [Mono-devel-list] MBuild preview release 0.0.2
In-Reply-To: <1076379161.18547.6.camel@beta.newton.cx>
References: <1076379161.18547.6.camel@beta.newton.cx>
Message-ID: <40287A01.7090707@activestate.com>

Peter,

you should be aware that constructs like the following :

using System;
...
Text.StringBuilder sb = new Text.StringBuilder ();

do not compile under ms.net ( csc.exe ). You need to explicitly import 
the whole namespace like:

using System.Text;
...
StringBuilder sb = new StringBuilder ();

the fact that it compiles with mcs is really a bug. I logged this a 
while ago http://bugs.ximian.com/show_bug.cgi?id=52622 but forgot to 
notify you as well.

Ian


Peter Williams wrote:

>Hi everyone,
>
>I've posted an updated preview of MBuild, my fancy slicey-dicey build
>tool at:
>
>	http://www.newton.cx/~peter/software/mbuild-0.0.2.tar.gz
>
>As before, see doc/Manifesto.txt in the tarball for an explanation of
>what I'm trying to accomplish with MBuild.
>
>There's been a lot of work under the hood: there's now a nice system for
>executing tools, with classes for filtering their output a la grep and
>sed; the beginnings of the configury mechanism are in place; the logging
>and error reporting infrastructure is working now; and I have target
>'tags' working although there isn't much fancy going on so far.
>
>As in the first release, there's a walkthrough in the file TUTORIAL.
>It's been updated to demonstrate the new features in this release.
>
>I'd be glad to answer any questions or comments that come up. MBuild
>still has a user base of exactly 0, but the infrastructure is coming
>along nicely. Still, on the whole, MBuild won't change your life ...
>*yet*.
>
>Peter
>
>  
>


-- 
Ian MacLean, Developer, 
ActiveState, a division of Sophos
http://www.ActiveState.com



From peter at newton.cx  Tue Feb 10 01:41:18 2004
From: peter at newton.cx (Peter Williams)
Date: Tue, 10 Feb 2004 01:41:18 -0500
Subject: [Mono-devel-list] MBuild preview release 0.0.2
In-Reply-To: <40287A01.7090707@activestate.com>
References: <1076379161.18547.6.camel@beta.newton.cx>
	 <40287A01.7090707@activestate.com>
Message-ID: <1076395275.18547.13.camel@beta.newton.cx>

On Tue, 2004-02-10 at 01:28, Ian MacLean wrote:
> Peter,
> 
> you should be aware that constructs like the following :
> 
> using System;
> ...
> Text.StringBuilder sb = new Text.StringBuilder ();
> 
> do not compile under ms.net ( csc.exe ). You need to explicitly import 
> the whole namespace like:

Oh, thanks. I've been fuzzy on these rules; MCS does *sometimes* report
the error. I'll try and fix those up.

Peter
 
-- 
Peter Williams                          peter at newton.cx

"[Ninjas] are cool; and by cool, I mean totally sweet."
                              -- REAL Ultimate Power



From fxjrlists at yahoo.com.br  Tue Feb 10 10:36:10 2004
From: fxjrlists at yahoo.com.br (Francisco Figueiredo Jr.)
Date: Tue, 10 Feb 2004 10:36:10 -0500
Subject: [Mono-devel-list] Possible problems with Npgsql
In-Reply-To: <1076381264.9330.12.camel@rasmus>
References: <1076381264.9330.12.camel@rasmus>
Message-ID: <4028FA6A.9040408@yahoo.com.br>

Met @ Uber wrote:
> I really have no idea how to continue debugging the following errors,
> but all the arrows keep pointing towards Npgsql.

:)

> 
> The following is a snippet printed to my screen if I turn on logging
> within Npgsql.  Does this look familiar to anyone?  I'm not using any
> lists of any sort that I am directly aware of.  Any help, any at all
> would be extremely appreciated.
> 

Nope. This looks very strange. But indeed, Npgsql uses some lists 
internally and for sure maybe the cause of the problem... ;)

What are you doing when you get that??
Could you provide a simple test case?

Thanks.

Regards,

Francisco Figueiredo Jr.



From vguzev at yandex.ru  Tue Feb 10 08:16:34 2004
From: vguzev at yandex.ru (Vadim B. Guzev)
Date: Tue, 10 Feb 2004 16:16:34 +0300
Subject: [Mono-devel-list] ** ERROR **: file appdomain.c: line 898 (ves_icall_System_AppDoma in_LoadAssembly): assetion failed: (assRef != NULL), aborting...
References: <A70185F8290B6E4B92F848A60D21481D18E86C@usmxsrv1.quark.com>
Message-ID: <003d01c3efd8$1c2c5e30$1117010a@HOME>

** ERROR **: file appdomain.c: line 898 (ves_icall_System_AppDomain_LoadAssembly): assetion failed: (assRef != NULL), aborting...I've got the same problem in Mono 0.30, however, everything was fine in Mono 0.29.
This's a blocking problem why I can't migrate to new versions of Mono :-(
Assemblies can't be loaded from the specified path - full or partial (I used AppDomainSetup.PrivateBinPath 
to specify assemblies location or AppDomainSetup.PrivateBinPath - the result is the same).


Best regards,
Vadim B. Guzev
  ----- Original Message ----- 
  From: Urs Muff 
  To: mono-devel-list at lists.ximian.com 
  Sent: Monday, February 09, 2004 10:41 PM
  Subject: [Mono-devel-list] ** ERROR **: file appdomain.c: line 898 (ves_icall_System_AppDoma in_LoadAssembly): assetion failed: (assRef != NULL), aborting...


  I tried AppDomain.CurrentDomain.Load, Assembly.Load, Assembly.LoadFile, and Assembly.LoadWithPartialName.  I always get the same error.

  I don't know which reference cannot be loaded, but all references are either in the same directory as the assembly to be loaded, or system assemblies.

  I'm also adding a AssemblyResolve handler (which is not called).

  Please advice: what parts are supported on mono?  [BTW: this code is running fine on .Net 1.1].

  This is a showstopper for me: I can't get further without a workaround or fix...

  - Urs C. Muff
  Software Architect              - Research Lab
  Quark Inc.

  UMuff at Quark.Com         - X6360
  +1 (303) 894 3360

  CONFIDENTIALITY NOTICE

  This e-mail transmission and any documents, files, or previous e-mail messages appended or attached to it, may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution, or use of the information contained or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone +1 (303) 894-3360 or return e-mail message umuff at quark.com and delete the original transmission, its attachments, and any copies without reading or saving in any manner. Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040210/8a781c51/attachment.html 

From spouliot at videotron.ca  Tue Feb 10 08:53:39 2004
From: spouliot at videotron.ca (=?iso-8859-1?Q?S=E9bastien_Pouliot?=)
Date: Tue, 10 Feb 2004 08:53:39 -0500
Subject: [Mono-devel-list] Key Pair Persistence
Message-ID: <LNEAJLBKIAFKOPHEICIDIEBJDHAA.spouliot@videotron.ca>

Hello all,

Key pair persistance is a service that CryptoAPI offers (under Windows) that
is exposed in the .NET framework. The exact location of the key pairs varies
between Windows OS releases and their format is undocumented (both offers
integrity and confidentiality - maybe too much of the later ;-). Normally
key pairs can be (optional) password protected - but this functionality
isn't (yet) exposed in the .NET framework (as this causes UI issues).

Note: Only key pairs created with a CspParameters parameter in the
constructor are persisted. Code that do not use CspParameters or
PersistKeyInCsp won't get their key pair persisted.

For compatibility, similar support for key pair persistence has been added
to Mono (this applies to DSACryptoServiceProvider and
RSACryptoServiceProvider classes). The key pairs are stored as XML files
(without any more protection) under

	Environment.SpecialFolder.ApplicationData + "/.mono/keypairs" (using
Path.Combine ;-).

This resolves into "~/.mono/keypairs/" under Linux. Note that this won't
work (right now), in most case, under Windows (mono's corlib) because of
issue #50532 (%HOME% used but not defined). Useing MS runtime the path would
resolve to "%USERPROFILE%\Application Data\.mono\keypairs".

This is similar to how the SSH keys are stored (except they can't be used
unless the private key access is limited to it's owner).

The only thing not currently implemented is the "machine" keys storage
(shared between all users).
Any ideas where such keys should be stored on Linux ?

Comments welcomed!

Sebastien
http://pages.infinit.net/ctech/poupou.html



From Alain.ROUGE at enac.fr  Tue Feb 10 09:17:39 2004
From: Alain.ROUGE at enac.fr (ROUGE Alain)
Date: Tue, 10 Feb 2004 15:17:39 +0100
Subject: [Mono-devel-list] testing gdi+ without SWF
Message-ID: <OFD47E7BFF.6C1DD394-ONC1256E36.004D153A@enac.fr>

hi,

I want to use cairo/libgdiplus/System.Drawing for my new C# application.

System.Drawing is in a good shape in cvs and seems usable.

I don't want to use mono SWF because it is a bit broken and certainly not 
usable.
I've tried many many ways to activate SWF with fresh cvs, with wine, with 
patches etc etc
and it never works.

Is it possible to implement a hack to render System.Drawing to the screen 
without SWF?
just to test and debug gdi+ API.

Thanks for your help.

ar.




From jordi at ximian.com  Tue Feb 10 10:57:39 2004
From: jordi at ximian.com (Jordi Mas)
Date: Tue, 10 Feb 2004 16:57:39 +0100
Subject: [Mono-devel-list] testing gdi+ without SWF
In-Reply-To: <OFD47E7BFF.6C1DD394-ONC1256E36.004D153A@enac.fr>
References: <OFD47E7BFF.6C1DD394-ONC1256E36.004D153A@enac.fr>
Message-ID: <4028FF73.5080902@ximian.com>

Hello,

>Is it possible to implement a hack to render System.Drawing to the screen 
>without SWF?
>just to test and debug gdi+ API.
>
You can render  System.Drawing into a bitmap. Instead of using SWF, have
a look into GTK#.

Jordi,




From joergr at voelcker.com  Tue Feb 10 10:58:23 2004
From: joergr at voelcker.com (=?iso-8859-1?Q?J=F6rg_Rosenkranz?=)
Date: Tue, 10 Feb 2004 16:58:23 +0100
Subject: [Mono-devel-list] Problems with Webservice client
Message-ID: <23BE0C16E0C22F48B3FB5B0BD6B5307B279655@visdd003.devdd.vi.lan>

Hello,

We're having problems accessing a webservice written in PHP. When we're
doing many requests to this web service we're getting a number of 
different exceptions:

1)
WebException:	The request timed out
Status:		Timeout    	
Stack Trace: 
    in <0x001b6> System.Net.HttpWebRequest:EndGetResponse (System.IAsyncResult)
    in <0x00092> System.Net.HttpWebRequest:GetResponse ()
    in <0x00078> System.Web.Services.Protocols.WebClientProtocol:GetWebResponse (System.Net.WebRequest)
    in <0x000ab> System.Web.Services.Protocols.WebClientProtocol:GetWebResponse (System.Net.WebRequest)
    in <0x0001d> System.Web.Services.Protocols.HttpWebClientProtocol:GetWebResponse (System.Net.WebRequest)
    in <0x00195> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
    in <0x0021c> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
    ...    
		
2)
WebException:	The request timed out
Status:		Timeout
Stack Trace: 
    in <0x000bb> System.Net.HttpWebRequest:GetRequestStream ()
    in <0x00168> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
    in <0x0021c> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
    ...
    
3)    	
WebException:	Request error. Return code was: 0
Status:		RequestCanceled
Stack Trace: 
    in <0x0013a> System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveResponse (System.Net.WebResponse,System.Web.Services.Protocols.SoapClientMessage,System.Web.Services.Protocols.SoapExtension[])
    in <0x0007d> (wrapper remoting-invoke-with-check) System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveResponse (System.Net.WebResponse,System.Web.Services.Protocols.SoapClientMessage,System.Web.Services.Protocols.SoapExtension[])
    in <0x00249> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
    ...
    
4)	
WebException:	Error getting response stream
Status:		ReceiveFailure
Stack Trace: 
    in <0x00076> System.Net.HttpWebRequest:CheckFinalStatus (System.Net.WebAsyncResult)
    in <0x00065> (wrapper remoting-invoke-with-check) System.Net.HttpWebRequest:CheckFinalStatus (System.Net.WebAsyncResult)
    in <0x001c3> System.Net.HttpWebRequest:EndGetResponse (System.IAsyncResult)
    in <0x00092> System.Net.HttpWebRequest:GetResponse ()
    in <0x00078> System.Web.Services.Protocols.WebClientProtocol:GetWebResponse (System.Net.WebRequest)
    in <0x000ab> System.Web.Services.Protocols.WebClientProtocol:GetWebResponse (System.Net.WebRequest)
    in <0x0001d> System.Web.Services.Protocols.HttpWebClientProtocol:GetWebResponse (System.Net.WebRequest)
    in <0x00195> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
    in <0x0021c> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
    ...    


Our problem is: It's not possible to reproduce this behaviour in a 
simple test case.

Are there any ideas how to track this down? It would already be very 
helpfull to exclude one of the involved components (PHP web service,
Apache, Mono web service client). Are there any tracing facilities?

Any help is highly appreciated because this is a major problem for us.

Thanks,
Joerg.


From joergr at voelcker.com  Tue Feb 10 11:55:32 2004
From: joergr at voelcker.com (=?iso-8859-1?Q?J=F6rg_Rosenkranz?=)
Date: Tue, 10 Feb 2004 17:55:32 +0100
Subject: [Mono-devel-list] Problems with Webservice client
Message-ID: <23BE0C16E0C22F48B3FB5B0BD6B5307B279656@visdd003.devdd.vi.lan>

Addendum:

I have tested the application under MS.NET against the same 
PHP webservice now: There are no timeouts at all. So the problem
seems to lie in the Mono web service client implementation.

But I don't know how to track this one down.

Joerg.

> -----Original Message-----
> From: mono-devel-list-admin at lists.ximian.com 
> [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of 
> J?rg Rosenkranz
> Sent: Tuesday, February 10, 2004 4:58 PM
> To: mono-devel-list at ximian.com
> Subject: [Mono-devel-list] Problems with Webservice client
> 
> 
> Hello,
> 
> We're having problems accessing a webservice written in PHP. 
> When we're
> doing many requests to this web service we're getting a number of 
> different exceptions:
> 
> 1)
> WebException:	The request timed out
> Status:		Timeout    	
> Stack Trace: 
>     in <0x001b6> System.Net.HttpWebRequest:EndGetResponse 
> (System.IAsyncResult)
>     in <0x00092> System.Net.HttpWebRequest:GetResponse ()
>     in <0x00078> 
> System.Web.Services.Protocols.WebClientProtocol:GetWebResponse
>  (System.Net.WebRequest)
>     in <0x000ab> 
> System.Web.Services.Protocols.WebClientProtocol:GetWebResponse
>  (System.Net.WebRequest)
>     in <0x0001d> 
> System.Web.Services.Protocols.HttpWebClientProtocol:GetWebResp
> onse (System.Net.WebRequest)
>     in <0x00195> 
> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke 
> (string,object[])
>     in <0x0021c> 
> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke 
> (string,object[])
>     ...    
> 		
> 2)
> WebException:	The request timed out
> Status:		Timeout
> Stack Trace: 
>     in <0x000bb> System.Net.HttpWebRequest:GetRequestStream ()
>     in <0x00168> 
> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke 
> (string,object[])
>     in <0x0021c> 
> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke 
> (string,object[])
>     ...
>     
> 3)    	
> WebException:	Request error. Return code was: 0
> Status:		RequestCanceled
> Stack Trace: 
>     in <0x0013a> 
> System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveRe
> sponse 
> (System.Net.WebResponse,System.Web.Services.Protocols.SoapClie
> ntMessage,System.Web.Services.Protocols.SoapExtension[])
>     in <0x0007d> (wrapper remoting-invoke-with-check) 
> System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveRe
> sponse 
> (System.Net.WebResponse,System.Web.Services.Protocols.SoapClie
> ntMessage,System.Web.Services.Protocols.SoapExtension[])
>     in <0x00249> 
> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke 
> (string,object[])
>     ...
>     
> 4)	
> WebException:	Error getting response stream
> Status:		ReceiveFailure
> Stack Trace: 
>     in <0x00076> System.Net.HttpWebRequest:CheckFinalStatus 
> (System.Net.WebAsyncResult)
>     in <0x00065> (wrapper remoting-invoke-with-check) 
> System.Net.HttpWebRequest:CheckFinalStatus (System.Net.WebAsyncResult)
>     in <0x001c3> System.Net.HttpWebRequest:EndGetResponse 
> (System.IAsyncResult)
>     in <0x00092> System.Net.HttpWebRequest:GetResponse ()
>     in <0x00078> 
> System.Web.Services.Protocols.WebClientProtocol:GetWebResponse
>  (System.Net.WebRequest)
>     in <0x000ab> 
> System.Web.Services.Protocols.WebClientProtocol:GetWebResponse
>  (System.Net.WebRequest)
>     in <0x0001d> 
> System.Web.Services.Protocols.HttpWebClientProtocol:GetWebResp
> onse (System.Net.WebRequest)
>     in <0x00195> 
> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke 
> (string,object[])
>     in <0x0021c> 
> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke 
> (string,object[])
>     ...    
> 
> 
> Our problem is: It's not possible to reproduce this behaviour in a 
> simple test case.
> 
> Are there any ideas how to track this down? It would already be very 
> helpfull to exclude one of the involved components (PHP web service,
> Apache, Mono web service client). Are there any tracing facilities?
> 
> Any help is highly appreciated because this is a major problem for us.
> 
> Thanks,
> Joerg.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


From lluis at ximian.com  Tue Feb 10 12:17:11 2004
From: lluis at ximian.com (Lluis Sanchez)
Date: Tue, 10 Feb 2004 18:17:11 +0100
Subject: [Mono-devel-list] Problems with Webservice client
In-Reply-To: <23BE0C16E0C22F48B3FB5B0BD6B5307B279655@visdd003.devdd.vi.lan>
References: <23BE0C16E0C22F48B3FB5B0BD6B5307B279655@visdd003.devdd.vi.lan>
Message-ID: <1076433430.4455.0.camel@portatil.aticatacs>

Are you trying with current CVS?

On dt, 2004-02-10 at 16:58, J?rg Rosenkranz wrote:
> Hello,
> 
> We're having problems accessing a webservice written in PHP. When we're
> doing many requests to this web service we're getting a number of 
> different exceptions:
> 
> 1)
> WebException:	The request timed out
> Status:		Timeout    	
> Stack Trace: 
>     in <0x001b6> System.Net.HttpWebRequest:EndGetResponse (System.IAsyncResult)
>     in <0x00092> System.Net.HttpWebRequest:GetResponse ()
>     in <0x00078> System.Web.Services.Protocols.WebClientProtocol:GetWebResponse (System.Net.WebRequest)
>     in <0x000ab> System.Web.Services.Protocols.WebClientProtocol:GetWebResponse (System.Net.WebRequest)
>     in <0x0001d> System.Web.Services.Protocols.HttpWebClientProtocol:GetWebResponse (System.Net.WebRequest)
>     in <0x00195> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
>     in <0x0021c> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
>     ...    
> 		
> 2)
> WebException:	The request timed out
> Status:		Timeout
> Stack Trace: 
>     in <0x000bb> System.Net.HttpWebRequest:GetRequestStream ()
>     in <0x00168> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
>     in <0x0021c> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
>     ...
>     
> 3)    	
> WebException:	Request error. Return code was: 0
> Status:		RequestCanceled
> Stack Trace: 
>     in <0x0013a> System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveResponse (System.Net.WebResponse,System.Web.Services.Protocols.SoapClientMessage,System.Web.Services.Protocols.SoapExtension[])
>     in <0x0007d> (wrapper remoting-invoke-with-check) System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveResponse (System.Net.WebResponse,System.Web.Services.Protocols.SoapClientMessage,System.Web.Services.Protocols.SoapExtension[])
>     in <0x00249> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
>     ...
>     
> 4)	
> WebException:	Error getting response stream
> Status:		ReceiveFailure
> Stack Trace: 
>     in <0x00076> System.Net.HttpWebRequest:CheckFinalStatus (System.Net.WebAsyncResult)
>     in <0x00065> (wrapper remoting-invoke-with-check) System.Net.HttpWebRequest:CheckFinalStatus (System.Net.WebAsyncResult)
>     in <0x001c3> System.Net.HttpWebRequest:EndGetResponse (System.IAsyncResult)
>     in <0x00092> System.Net.HttpWebRequest:GetResponse ()
>     in <0x00078> System.Web.Services.Protocols.WebClientProtocol:GetWebResponse (System.Net.WebRequest)
>     in <0x000ab> System.Web.Services.Protocols.WebClientProtocol:GetWebResponse (System.Net.WebRequest)
>     in <0x0001d> System.Web.Services.Protocols.HttpWebClientProtocol:GetWebResponse (System.Net.WebRequest)
>     in <0x00195> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
>     in <0x0021c> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
>     ...    
> 
> 
> Our problem is: It's not possible to reproduce this behaviour in a 
> simple test case.
> 
> Are there any ideas how to track this down? It would already be very 
> helpfull to exclude one of the involved components (PHP web service,
> Apache, Mono web service client). Are there any tracing facilities?
> 
> Any help is highly appreciated because this is a major problem for us.
> 
> Thanks,
> Joerg.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From joergr at voelcker.com  Tue Feb 10 13:14:50 2004
From: joergr at voelcker.com (=?iso-8859-1?Q?J=F6rg_Rosenkranz?=)
Date: Tue, 10 Feb 2004 19:14:50 +0100
Subject: [Mono-devel-list] Problems with Webservice client
Message-ID: <23BE0C16E0C22F48B3FB5B0BD6B5307B279658@visdd003.devdd.vi.lan>

Hello Lluis,

> -----Original Message-----
> From: Lluis Sanchez [mailto:lluis at ximian.com] 
> Sent: Tuesday, February 10, 2004 6:17 PM
> 
> Are you trying with current CVS?
> 

I have tried this using a version from end of January.
Now I've upgraded the server using a CVS version of
today and am still getting some timeouts but none of
the other exceptions. 

I will try this on other machines too because it's 
not always reproducible.

Thanks,
Joerg.


From umuff at quark.com  Tue Feb 10 15:51:09 2004
From: umuff at quark.com (Urs C Muff)
Date: Tue, 10 Feb 2004 13:51:09 -0700
Subject: [Mono-devel-list] GC alpha 3, libgc, and PPC
Message-ID: <DAA99E72-5C0A-11D8-B645-0003938D4EE2@quark.com>

Hi,

Is there a reason why libgc under mono is not the latest alpha 3?  Are 
there any issues with that version on any system?  I'm just asking, 
because that version is required for PPC, and I'm not sure if I can 
guarantee when I rebuild mono from CVS that it will take the alpha 3 
version that I installed vs. libgc.

- Urs



From martin at ximian.com  Tue Feb 10 16:08:36 2004
From: martin at ximian.com (Martin Baulig)
Date: Tue, 10 Feb 2004 22:08:36 +0100
Subject: [Mono-devel-list] GC alpha 3, libgc, and PPC
In-Reply-To: <DAA99E72-5C0A-11D8-B645-0003938D4EE2@quark.com>
References: <DAA99E72-5C0A-11D8-B645-0003938D4EE2@quark.com>
Message-ID: <1076447316.1657.6.camel@gondor.martin.baulig>

On Tue, 2004-02-10 at 21:51, Urs C Muff wrote:

> Is there a reason why libgc under mono is not the latest alpha 3?  Are 
> there any issues with that version on any system?  I'm just asking, 
> because that version is required for PPC, and I'm not sure if I can 
> guarantee when I rebuild mono from CVS that it will take the alpha 3 
> version that I installed vs. libgc.

Hi,

normally, I'm upgrading the libgc in mono each time a new release comes
out.  Unless there's a good reason for it, I don't really want to import
alpha version because - as the name already sais - they're most likely
unstable.

If you want another libgc, you should be able to give configure the
--with-gc=boehm argument, this should make it use the installed one
(--with-gc=included is the default).  If it does not, then this is a
bug.

--
Martin Baulig <martin at ximian.com>
Now blogging !  http://primates.ximian.com/~martin/blog



From umuff at quark.com  Tue Feb 10 16:35:12 2004
From: umuff at quark.com (Urs C Muff)
Date: Tue, 10 Feb 2004 14:35:12 -0700
Subject: [Mono-devel-list] Compile error on PPC: from CVS
In-Reply-To: <1076344270.7047.157.camel@lalo4.micasa>
References: <1076344270.7047.157.camel@lalo4.micasa>
Message-ID: <023E2D48-5C11-11D8-B645-0003938D4EE2@quark.com>

cc  -g -O2 -fPIC -c -o Mono.Posix/map.o Mono.Posix/map.c
Mono.Posix/map.c: In function `map_Mono_Posix_OpenFlags':
Mono.Posix/map.c:32: error: `O_SYNC' undeclared (first use in this 
function)
Mono.Posix/map.c:32: error: (Each undeclared identifier is reported 
only once
Mono.Posix/map.c:32: error: for each function it appears in.)
make[2]: *** [Mono.Posix/map.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

Any idea what's going on?

  - Urs



From met at uberstats.com  Tue Feb 10 16:53:26 2004
From: met at uberstats.com (Met @ Uber)
Date: Tue, 10 Feb 2004 16:53:26 -0500
Subject: [Mono-devel-list] Sharing, Memory, and Collection Pools
Message-ID: <1076450006.5208.18.camel@rasmus>

I have a object pool that holds database connections which I would like
other programs to make use of.  So a common example would be a a client
application making a soap request to a server which grabs a connection
from the pool to run its queries.  While this first request is still
being processed, another person via soap request some other information
from the server, which grabs another connection from the pool.  Since
these request seem like a start and stop of a process, does the
connection pool get re-instantiated with each request?  So if I hit the
server, does it turn on the pool and then turn it off at the end of my
request, subsequently doing that each time a user hits hits a page?  If
so, is there a way that I can make the pool stay open between requests
so that it can appropriately pass off connections for use (which seems
like the best way - so you do not have to continually start and stop
database connections).

How would something like this be done in C#/.NET?  Is it a way I compile
a .dll or does it have to do with the way XSP/Apache/IIS service a
request?

Thanks advance,

~ Matthew



From fxjrlists at yahoo.com.br  Tue Feb 10 19:08:05 2004
From: fxjrlists at yahoo.com.br (Francisco Figueiredo Jr.)
Date: Tue, 10 Feb 2004 22:08:05 -0200
Subject: [Mono-devel-list] Sharing, Memory, and Collection Pools
In-Reply-To: <1076450006.5208.18.camel@rasmus>
References: <1076450006.5208.18.camel@rasmus>
Message-ID: <40297265.9060602@yahoo.com.br>

Met @ Uber wrote:
> I have a object pool that holds database connections which I would like
> other programs to make use of.  So a common example would be a a client
> application making a soap request to a server which grabs a connection
> from the pool to run its queries.  While this first request is still
> being processed, another person via soap request some other information
> from the server, which grabs another connection from the pool.  Since
> these request seem like a start and stop of a process, does the
> connection pool get re-instantiated with each request? 
 > So if I hit the
 > server, does it turn on the pool and then turn it off at the end of my
 > request, subsequently doing that each time a user hits hits a page? 
  > If
 > so, is there a way that I can make the pool stay open between requests
 > so that it can appropriately pass off connections for use (which seems
 > like the best way - so you do not have to continually start and stop
 > database connections).
 >

The fact the connection pool get re-instantiated with each request 
depends on how you hold the connection pool object reference.

Suppose an object of the class ConnectionPoolManager.

if you instantiate a new ConnectionPoolManager each time you did the 
request, you would end up with a reinstantiation with each request.

The trick here to avoid that is to make the instance "static". Which 
means it will have only one, or as many instances as you want, and they 
would "remain" in memory between requests.

To get just one instance you would apply the singleton pattern.

The idea of the static here is that the reference would have its 
lifetime tied to the application domain which first loaded the class 
which holds the static instance. This way, only if this class is 
reloaded in the app domain is that it would remove the instance.


So, if you have the connection pool manager as an static instance, you 
wouldn't have re-instantiations between each request.



> How would something like this be done in C#/.NET?  Is it a way I compile
> a .dll or does it have to do with the way XSP/Apache/IIS service a
> request?
> 

You can do it with plain c#. Just create you .dll with a function which 
create a static reference to your ConnectionPoolManager object and you 
are ready. :)


I hope it helps.


-- 
Regards,

Francisco Figueiredo Jr.
Membro Fundador do Projeto MonoBrasil - MonoBrasil Project Founder Member


-------------
"Science without religion is lame;
religion without science is blind."

                   ~ Albert Einstein


From phil at noggle.biz  Wed Feb 11 02:15:21 2004
From: phil at noggle.biz (Philip Tricca)
Date: Wed, 11 Feb 2004 02:15:21 -0500
Subject: [Mono-devel-list] Monodoc - custom documentation
Message-ID: <1076483721.8822.100.camel@dhcppc5>

I've been spending some time trying to use Monodoc to generate
documentation, and have run into some trouble. Through directions posted
by Miguel in an old Mono-list posting (see URL below) I've managed to
generate the .zip .tree and .sources files rather easily. However after
copying these files to the sources directory (monodoc --get-sourcesdir)
no changes are reflected in the actual monodoc browser. I've played
around with  the monodoc.xml file just to see if I can get any changes
displayed in the GUI, and have been able to add nodes to the base "Mono
Documentation" level, but nothing beyond that. The generated .zip file
contains plenty of information about my test class, so I think I'm just
missing a final step. Any help would be great.

http://lists.ximian.com/archives/public/mono-list/2003-December/017237.html

Truly,
 - Phil



From brunofr at olympum.com  Wed Feb 11 03:54:55 2004
From: brunofr at olympum.com (brunofr at olympum.com)
Date: Wed, 11 Feb 2004 02:54:55 -0600
Subject: [Mono-devel-list] Monodoc - custom documentation
In-Reply-To: <1076483721.8822.100.camel@dhcppc5>
References: <1076483721.8822.100.camel@dhcppc5>
Message-ID: <1076489695.4029eddf1c2a0@webmail.olympum.com>

Hi!

Dunno if really helps, but ... with an out-of-the-box Mono, Gtk# and Monodoc, I
am able to add docs to the various element in Monodoc. I have a file
jninet-docs.source:

<?xml version="1.0"?>
<monodoc>
  <source provider="ecma" basefile="jninet-docs" path="various"/>
</monodoc>

and my Makefile runs the Monodoc assembler and installs over the monodoc lib
directory the .tree .zip and .source files.

all: jninet-docs.zip jninet-docs.tree

jninet-docs.zip jninet-docs.tree: en/*/*.xml en/*.xml
	mono $(ASSEMBLER) --ecma en -o jninet-docs

install: jninet-docs.zip jninet-docs.tree 
	install -m 644 jninet-docs.zip jninet-docs.tree `monodoc --get-sourcesdir`
	install -m 644 jninet-docs.source `monodoc --get-sourcesdir`

I am not getting any issues showing my namespace then under the "Various" node. 

Bruno

Quoting Philip Tricca <phil at noggle.biz>:
> I've been spending some time trying to use Monodoc to generate
> documentation, and have run into some trouble. Through directions posted
> by Miguel in an old Mono-list posting (see URL below) I've managed to
> generate the .zip .tree and .sources files rather easily. However after
> copying these files to the sources directory (monodoc --get-sourcesdir)
> no changes are reflected in the actual monodoc browser. I've played
> around with  the monodoc.xml file just to see if I can get any changes
> displayed in the GUI, and have been able to add nodes to the base "Mono
> Documentation" level, but nothing beyond that. The generated .zip file
> contains plenty of information about my test class, so I think I'm just
> missing a final step. Any help would be great.
> 
> http://lists.ximian.com/archives/public/mono-list/2003-December/017237.html
> 
> Truly,
>  - Phil
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 





From martin at ximian.com  Wed Feb 11 04:17:35 2004
From: martin at ximian.com (Martin Baulig)
Date: Wed, 11 Feb 2004 10:17:35 +0100
Subject: [Mono-devel-list] Re: Compile error on PPC: from CVS
In-Reply-To: <023E2D48-5C11-11D8-B645-0003938D4EE2@quark.com>
References: <1076344270.7047.157.camel@lalo4.micasa>
	 <023E2D48-5C11-11D8-B645-0003938D4EE2@quark.com>
Message-ID: <1076491055.1657.18.camel@gondor.martin.baulig>

On Tue, 2004-02-10 at 22:35, Urs C Muff wrote:
> cc  -g -O2 -fPIC -c -o Mono.Posix/map.o Mono.Posix/map.c
> Mono.Posix/map.c: In function `map_Mono_Posix_OpenFlags':
> Mono.Posix/map.c:32: error: `O_SYNC' undeclared (first use in this 
> function)
> Mono.Posix/map.c:32: error: (Each undeclared identifier is reported 
> only once
> Mono.Posix/map.c:32: error: for each function it appears in.)

Apparently, Mono.Posix/map.c is a generated file (from make-map.c) and
O_SYNC should be defined in <fcntl.h>.  So either your map.c doesn't
#include <fcntl.h> or it's not defined there.
--
Martin Baulig <martin at ximian.com>
Now blogging !  http://primates.ximian.com/~martin/blog



From Alain.ROUGE at enac.fr  Wed Feb 11 04:45:07 2004
From: Alain.ROUGE at enac.fr (ROUGE Alain)
Date: Wed, 11 Feb 2004 10:45:07 +0100
Subject: [Mono-devel-list] testing gdi+without SWF
Message-ID: <OF0415C73E.B4E26C5D-ONC1256E37.00346BA6@enac.fr>

hi,

Thanks for your reply Jordi, Andreas.

I can render System.Drawing in a Bitmap and invoke xv. It's ok.

That said,  to test and debug System.Drawing,  it's much easier to render 
directly to screen.
I don't want any UI, I just need a top level window to render 
System.Drawing.

Is it possible to hack System.Drawing to render directly to screen in a 
top level window without SWF?

ar.


From chris at turchin.net  Wed Feb 11 06:14:04 2004
From: chris at turchin.net (Chris Turchin)
Date: Wed, 11 Feb 2004 03:14:04 -0800 (PST)
Subject: [Mono-devel-list] testing gdi+without SWF
In-Reply-To: <OF0415C73E.B4E26C5D-ONC1256E37.00346BA6@enac.fr>
References: <OF0415C73E.B4E26C5D-ONC1256E37.00346BA6@enac.fr>
Message-ID: <Pine.LNX.4.55.0402110310090.11992@cigale.pelemele.com>

Hi Alain,

If you create a Gdk.Window then there is a method SetBackPixmap() which I assume
could be useful for you (though I have not tried it myself).

Gdk.Window
	SetBackPixmap(Pixmap pixmap, bool parent_relative)

		pixmap: an object of type Gdk.Pixmap
		parent_relative: bool

Regards,

--chris


On Wed, 11 Feb 2004, ROUGE Alain wrote:

> hi,
>
> Thanks for your reply Jordi, Andreas.
>
> I can render System.Drawing in a Bitmap and invoke xv. It's ok.
>
> That said,  to test and debug System.Drawing,  it's much easier to render
> directly to screen.
> I don't want any UI, I just need a top level window to render
> System.Drawing.
>
> Is it possible to hack System.Drawing to render directly to screen in a
> top level window without SWF?
>
> ar.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>


From joergr at voelcker.com  Wed Feb 11 07:22:32 2004
From: joergr at voelcker.com (=?iso-8859-1?Q?J=F6rg_Rosenkranz?=)
Date: Wed, 11 Feb 2004 13:22:32 +0100
Subject: [Mono-devel-list] Problems with Webservice client
Message-ID: <23BE0C16E0C22F48B3FB5B0BD6B5307B279661@visdd003.devdd.vi.lan>

Hello Lluis,

> -----Original Message-----
> From: Lluis Sanchez [mailto:lluis at ximian.com] 
> Sent: Tuesday, February 10, 2004 6:17 PM
> 
> Are you trying with current CVS?
> 

I have tested it with yesterday's and today's CVS version
and still get exceptions. There are many calls without 
problems but the exceptions show up regularly. 
I recognized following exceptions in the last tests:

WebException:	Request error. Return code was: BadRequest
Status:		RequestCanceled
Stack Trace: 
    in <0x00115> System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveResponse (System.Net.WebResponse,System.Web.Services.Protocols.SoapClientMessage,System.Web.Services.Protocols.SoapExtension[])
    in <0x0007d> (wrapper remoting-invoke-with-check) System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveResponse (System.Net.WebResponse,System.Web.Services.Protocols.SoapClientMessage,System.Web.Services.Protocols.SoapExtension[])
    in <0x0021f> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
    ...

WebException:	The request timed out
Status:		Timeout
Stack Trace: 
    in <0x001f2> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
	...

WebException:	Error getting response stream
Status:		ReceiveFailure
Stack Trace: 
    in <0x001f2> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
    ...


The web service works against a LDAP directory, so response
times of some seconds are usual. The timeout of our web 
service client is set to 3 minutes.

Any ideas to isolate this problem are appreciated.

Thanks,
Joerg




From joergr at voelcker.com  Wed Feb 11 08:17:07 2004
From: joergr at voelcker.com (=?iso-8859-1?Q?J=F6rg_Rosenkranz?=)
Date: Wed, 11 Feb 2004 14:17:07 +0100
Subject: [Mono-devel-list] Problems with Webservice client
Message-ID: <23BE0C16E0C22F48B3FB5B0BD6B5307B279664@visdd003.devdd.vi.lan>

One additional notice:
I've gone through the Apache logs of the server hosting our PHP
web service and found some interesting entries:

access_log:
192.168.1.2 - - [11/Feb/2004:11:07:20 +0100] "POST /itforschool/webservice/wsdr.php HTTP/1.1" 200 734
192.168.1.2 - - [11/Feb/2004:11:07:20 +0100] "<?xml version=\"1.0\" encoding=\"utf-8\"?><soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"><soap:Body><q1:addApplikationtoPerson xmlns:q1=\"urn:Raptor\"><uidviapplikation href=\"#id1\" /><uidviperson xsi:type=\"xsd:string\">7e8d4bfb-fe54-42b9-a673-2dc47fd7e663</uidviperson></q1:addApplikationtoPerson><q2:Array id=\"id1\" q2:arrayType=\"xsd:string[1]\" xmlns:q2=\"http://schemas.xmlsoap.org/soap/encoding/\"><Item xsi:type=\"xsd:string\">bdfb45d5-0826-47b0-8917-45045a3464b0</Item></q2:Array></soap:Body></soap:Envelope>POST /itforschool/webservice/wsdr.php HTTP/1.1" 400 367
192.168.1.2 - - [11/Feb/2004:11:07:22 +0100] "POST /itforschool/webservice/wsdr.php HTTP/1.1" 200 734

error_log:
[Wed Feb 11 11:07:20 2004] [error] [client 192.168.1.2] request failed: erroneous characters after protocol string: <?xml version=\"1.0\" encoding=\"utf-8\"?><soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"><soap:Body><q1:addApplikationtoPerson xmlns:q1=\"urn:Raptor\"><uidviapplikation href=\"#id1\" /><uidviperson xsi:type=\"xsd:string\">7e8d4bfb-fe54-42b9-a673-2dc47fd7e663</uidviperson></q1:addApplikationtoPerson><q2:Array id=\"id1\" q2:arrayType=\"xsd:string[1]\" xmlns:q2=\"http://schemas.xmlsoap.org/soap/encoding/\"><Item xsi:type=\"xsd:string\">bdfb45d5-0826-47b0-8917-45045a3464b0</Item></q2:Array></soap:Body></soap:Envelope>POST /itforschool/webservice/wsdr.php HTTP/1.1

Resulting exception in our log file:
Wednesday, 11 February 2004 11:07:20 - Errors occured
    Got Exception: Request error. Return code was: BadRequest
    Status: RequestCanceled
    Stack Trace: 
    in <0x00115> System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveResponse (System.Net.WebResponse,System.Web.Services.Protocols.SoapClientMessage,System.Web.Services.Protocols.SoapExtension[])
    in <0x0007d> (wrapper remoting-invoke-with-check) System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveResponse (System.Net.WebResponse,System.Web.Services.Protocols.SoapClientMessage,System.Web.Services.Protocols.SoapExtension[])
    in <0x0021f> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
    ...
    

The header of the HTTP request send to the server seems to be missing.

Joerg.
    

> -----Original Message-----
> From: mono-devel-list-admin at lists.ximian.com 
> [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of 
> J?rg Rosenkranz
> Sent: Wednesday, February 11, 2004 1:23 PM
> To: lluis at ximian.com
> Cc: mono-devel-list at ximian.com
> Subject: RE: [Mono-devel-list] Problems with Webservice client
> 
> 
> Hello Lluis,
> 
> > -----Original Message-----
> > From: Lluis Sanchez [mailto:lluis at ximian.com] 
> > Sent: Tuesday, February 10, 2004 6:17 PM
> > 
> > Are you trying with current CVS?
> > 
> 
> I have tested it with yesterday's and today's CVS version
> and still get exceptions. There are many calls without 
> problems but the exceptions show up regularly. 
> I recognized following exceptions in the last tests:
> 
> WebException:	Request error. Return code was: BadRequest
> Status:		RequestCanceled
> Stack Trace: 
>     in <0x00115> 
> System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveRe
> sponse 
> (System.Net.WebResponse,System.Web.Services.Protocols.SoapClie
> ntMessage,System.Web.Services.Protocols.SoapExtension[])
>     in <0x0007d> (wrapper remoting-invoke-with-check) 
> System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveRe
> sponse 
> (System.Net.WebResponse,System.Web.Services.Protocols.SoapClie
> ntMessage,System.Web.Services.Protocols.SoapExtension[])
>     in <0x0021f> 
> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke 
> (string,object[])
>     ...
> 
> WebException:	The request timed out
> Status:		Timeout
> Stack Trace: 
>     in <0x001f2> 
> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke 
> (string,object[])
> 	...
> 
> WebException:	Error getting response stream
> Status:		ReceiveFailure
> Stack Trace: 
>     in <0x001f2> 
> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke 
> (string,object[])
>     ...
> 
> 
> The web service works against a LDAP directory, so response
> times of some seconds are usual. The timeout of our web 
> service client is set to 3 minutes.
> 
> Any ideas to isolate this problem are appreciated.
> 
> Thanks,
> Joerg
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 


From lluis at ximian.com  Wed Feb 11 08:35:35 2004
From: lluis at ximian.com (Lluis Sanchez)
Date: Wed, 11 Feb 2004 14:35:35 +0100
Subject: [Mono-devel-list] Problems with Webservice client
In-Reply-To: <23BE0C16E0C22F48B3FB5B0BD6B5307B279664@visdd003.devdd.vi.lan>
References: <23BE0C16E0C22F48B3FB5B0BD6B5307B279664@visdd003.devdd.vi.lan>
Message-ID: <1076506535.4826.12.camel@portatil.aticatacs>

Hi!

Thanks for the info. There are a couple of bug reports in bugzilla about
this issue (52169 and 53980). I'll start working on it.

Lluis.


On dc, 2004-02-11 at 14:17, J?rg Rosenkranz wrote:
> One additional notice:
> I've gone through the Apache logs of the server hosting our PHP
> web service and found some interesting entries:
> 
> access_log:
> 192.168.1.2 - - [11/Feb/2004:11:07:20 +0100] "POST /itforschool/webservice/wsdr.php HTTP/1.1" 200 734
> 192.168.1.2 - - [11/Feb/2004:11:07:20 +0100] "<?xml version=\"1.0\" encoding=\"utf-8\"?><soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"><soap:Body><q1:addApplikationtoPerson xmlns:q1=\"urn:Raptor\"><uidviapplikation href=\"#id1\" /><uidviperson xsi:type=\"xsd:string\">7e8d4bfb-fe54-42b9-a673-2dc47fd7e663</uidviperson></q1:addApplikationtoPerson><q2:Array id=\"id1\" q2:arrayType=\"xsd:string[1]\" xmlns:q2=\"http://schemas.xmlsoap.org/soap/encoding/\"><Item xsi:type=\"xsd:string\">bdfb45d5-0826-47b0-8917-45045a3464b0</Item></q2:Array></soap:Body></soap:Envelope>POST /itforschool/webservice/wsdr.php HTTP/1.1" 400 367
> 192.168.1.2 - - [11/Feb/2004:11:07:22 +0100] "POST /itforschool/webservice/wsdr.php HTTP/1.1" 200 734
> 
> error_log:
> [Wed Feb 11 11:07:20 2004] [error] [client 192.168.1.2] request failed: erroneous characters after protocol string: <?xml version=\"1.0\" encoding=\"utf-8\"?><soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\"><soap:Body><q1:addApplikationtoPerson xmlns:q1=\"urn:Raptor\"><uidviapplikation href=\"#id1\" /><uidviperson xsi:type=\"xsd:string\">7e8d4bfb-fe54-42b9-a673-2dc47fd7e663</uidviperson></q1:addApplikationtoPerson><q2:Array id=\"id1\" q2:arrayType=\"xsd:string[1]\" xmlns:q2=\"http://schemas.xmlsoap.org/soap/encoding/\"><Item xsi:type=\"xsd:string\">bdfb45d5-0826-47b0-8917-45045a3464b0</Item></q2:Array></soap:Body></soap:Envelope>POST /itforschool/webservice/wsdr.php HTTP/1.1
> 
> Resulting exception in our log file:
> Wednesday, 11 February 2004 11:07:20 - Errors occured
>     Got Exception: Request error. Return code was: BadRequest
>     Status: RequestCanceled
>     Stack Trace: 
>     in <0x00115> System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveResponse (System.Net.WebResponse,System.Web.Services.Protocols.SoapClientMessage,System.Web.Services.Protocols.SoapExtension[])
>     in <0x0007d> (wrapper remoting-invoke-with-check) System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveResponse (System.Net.WebResponse,System.Web.Services.Protocols.SoapClientMessage,System.Web.Services.Protocols.SoapExtension[])
>     in <0x0021f> System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke (string,object[])
>     ...
>     
> 
> The header of the HTTP request send to the server seems to be missing.
> 
> Joerg.
>     
> 
> > -----Original Message-----
> > From: mono-devel-list-admin at lists.ximian.com 
> > [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of 
> > J?rg Rosenkranz
> > Sent: Wednesday, February 11, 2004 1:23 PM
> > To: lluis at ximian.com
> > Cc: mono-devel-list at ximian.com
> > Subject: RE: [Mono-devel-list] Problems with Webservice client
> > 
> > 
> > Hello Lluis,
> > 
> > > -----Original Message-----
> > > From: Lluis Sanchez [mailto:lluis at ximian.com] 
> > > Sent: Tuesday, February 10, 2004 6:17 PM
> > > 
> > > Are you trying with current CVS?
> > > 
> > 
> > I have tested it with yesterday's and today's CVS version
> > and still get exceptions. There are many calls without 
> > problems but the exceptions show up regularly. 
> > I recognized following exceptions in the last tests:
> > 
> > WebException:	Request error. Return code was: BadRequest
> > Status:		RequestCanceled
> > Stack Trace: 
> >     in <0x00115> 
> > System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveRe
> > sponse 
> > (System.Net.WebResponse,System.Web.Services.Protocols.SoapClie
> > ntMessage,System.Web.Services.Protocols.SoapExtension[])
> >     in <0x0007d> (wrapper remoting-invoke-with-check) 
> > System.Web.Services.Protocols.SoapHttpClientProtocol:ReceiveRe
> > sponse 
> > (System.Net.WebResponse,System.Web.Services.Protocols.SoapClie
> > ntMessage,System.Web.Services.Protocols.SoapExtension[])
> >     in <0x0021f> 
> > System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke 
> > (string,object[])
> >     ...
> > 
> > WebException:	The request timed out
> > Status:		Timeout
> > Stack Trace: 
> >     in <0x001f2> 
> > System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke 
> > (string,object[])
> > 	...
> > 
> > WebException:	Error getting response stream
> > Status:		ReceiveFailure
> > Stack Trace: 
> >     in <0x001f2> 
> > System.Web.Services.Protocols.SoapHttpClientProtocol:Invoke 
> > (string,object[])
> >     ...
> > 
> > 
> > The web service works against a LDAP directory, so response
> > times of some seconds are usual. The timeout of our web 
> > service client is set to 3 minutes.
> > 
> > Any ideas to isolate this problem are appreciated.
> > 
> > Thanks,
> > Joerg
> > 
> > 
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> > 



From umuff at quark.com  Wed Feb 11 08:38:51 2004
From: umuff at quark.com (Urs C Muff)
Date: Wed, 11 Feb 2004 06:38:51 -0700
Subject: [Mono-devel-list] Bugzilla
Message-ID: <A0A6C9D9-5C97-11D8-B645-0003938D4EE2@quark.com>

Would it be possible to add 'Mac OS X', 'Panther (10.3)', 'Jaguar 
(10.2)' as OS to the list in bugzilla?  That would help query for PPC 
bugs!

- Urs



From Alain.ROUGE at enac.fr  Wed Feb 11 09:19:45 2004
From: Alain.ROUGE at enac.fr (ROUGE Alain)
Date: Wed, 11 Feb 2004 15:19:45 +0100
Subject: [Mono-devel-list] testing gdi+ without SWF/gtk#
Message-ID: <OFB7CC122C.186D850D-ONC1256E37.004D89CA@enac.fr>

hi,

Thanks for your reply Chris.
Gdk.Window is perhaps a solution but I'm looking for something simpler 
without SWF and without gtk#.
I wonder if  it is possible to hack System.Drawing/libgdiplus/cairo to 
directly render graphic primitives in a top level window.
anyone an idea please?

ar.


From rshade at dvsconsulting.com  Wed Feb 11 09:22:19 2004
From: rshade at dvsconsulting.com (Robert Shade)
Date: Wed, 11 Feb 2004 09:22:19 -0500 (EST)
Subject: [Mono-devel-list] Compile error on PPC: from CVS
In-Reply-To: <023E2D48-5C11-11D8-B645-0003938D4EE2@quark.com>
References: <1076344270.7047.157.camel@lalo4.micasa>
    <023E2D48-5C11-11D8-B645-0003938D4EE2@quark.com>
Message-ID: <55465.66.21.237.217.1076509339.squirrel@www.dvsconsulting.com>

(Just realized that I only sent this privately and not to the list)

See bugs 53748 and 53749.

rob

> cc  -g -O2 -fPIC -c -o Mono.Posix/map.o Mono.Posix/map.c
> Mono.Posix/map.c: In function `map_Mono_Posix_OpenFlags':
> Mono.Posix/map.c:32: error: `O_SYNC' undeclared (first use in this
> function)
> Mono.Posix/map.c:32: error: (Each undeclared identifier is reported
> only once
> Mono.Posix/map.c:32: error: for each function it appears in.)
> make[2]: *** [Mono.Posix/map.o] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all-recursive] Error 1
>
> Any idea what's going on?
>
>   - Urs
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>


From rkumar at novell.com  Wed Feb 11 11:34:12 2004
From: rkumar at novell.com (Ravindra Kumar)
Date: Wed, 11 Feb 2004 09:34:12 -0700
Subject: [Mono-devel-list] testing gdi+ without SWF/gtk#
Message-ID: <s029f720.005@prv-mail25.provo.novell.com>

Hello,
You might want to have a look at Cairo samples provided with
Cairo library. These are available from Cairo cvs server. But, I 
don't think that you can render from System.Drawing in that way.
Prolly, you can insert your rendering code at places inside libgdiplus
code. Needless to say, it is going to be an ugly hack.

HTH.
Ravindra

>>> "ROUGE Alain" <Alain.ROUGE at enac.fr> 2/11/2004 7:49:45 PM >>>
hi,

Thanks for your reply Chris.
Gdk.Window is perhaps a solution but I'm looking for something simpler

without SWF and without gtk#.
I wonder if  it is possible to hack System.Drawing/libgdiplus/cairo to

directly render graphic primitives in a top level window.
anyone an idea please?

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


From Alain.ROUGE at enac.fr  Wed Feb 11 12:14:22 2004
From: Alain.ROUGE at enac.fr (ROUGE Alain)
Date: Wed, 11 Feb 2004 18:14:22 +0100
Subject: [Mono-devel-list] testing gdi+ without SWF/gtk#
Message-ID: <OFF4D04FEC.50F03D01-ONC1256E37.005DACFE@enac.fr>

thanks for your help Ravindra.

I'll hack a bit libgdiplus to add rendering to top level window wo 
swf/gtk#.
Needless to say it is an ugly hack :-) but very useful to debug big 
application with thousand of drawing methods .
swf is broken, gdk is an ugly thing and I don't want to render to a file, 
so I have no choice.

ar.


From umuff at QUARK.com  Wed Feb 11 13:49:24 2004
From: umuff at QUARK.com (Urs Muff)
Date: Wed, 11 Feb 2004 11:49:24 -0700
Subject: [Mono-devel-list] PPC (Panther) compile issues
Message-ID: <A70185F8290B6E4B92F848A60D21481D18E883@usmxsrv1.quark.com>

Anyone here that was able to compile Mono.Posix on Panther?
Please help me with the medication to the Makefile, I'm stuck there.

- Urs C. Muff



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

From rshade at dvsconsulting.com  Wed Feb 11 14:37:00 2004
From: rshade at dvsconsulting.com (Robert Shade)
Date: Wed, 11 Feb 2004 14:37:00 -0500 (EST)
Subject: [Mono-devel-list] PPC (Panther) compile issues
In-Reply-To: <A70185F8290B6E4B92F848A60D21481D18E883@usmxsrv1.quark.com>
References: <A70185F8290B6E4B92F848A60D21481D18E883@usmxsrv1.quark.com>
Message-ID: <55941.192.168.0.93.1076528220.squirrel@www.dvsconsulting.com>

This patch (hack) will allow it to compile.

You will also need to add "#include <sys/aio.h>" to map.c.  I have it
right below #include <fcntl.h>. (Bug 53748)

rob

> Anyone here that was able to compile Mono.Posix on Panther?
> Please help me with the medication to the Makefile, I'm stuck there.
>
> - Urs C. Muff
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: posix.diff
Type: application/octet-stream
Size: 1497 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040211/6968f570/attachment.obj 

From alramire at ecs.syr.edu  Wed Feb 11 18:18:10 2004
From: alramire at ecs.syr.edu (Alvaro A. Ramirez)
Date: Wed, 11 Feb 2004 18:18:10 -0500
Subject: [Mono-devel-list] shared memory warnings
Message-ID: <1076541490.2547.2.camel@stella>

Hello everyone. Today I started receiving the following warnings when I
tried to compile anything with mcs. I have not changed anything for my
installation, working directory, or anything else. Now I receive the
following warning. Should I worry about this? How can I fix this?

** (/usr/local/bin/mcs.exe:23906): WARNING **: Shared memory sanity
check failed.
 
** (/usr/local/bin/mcs.exe:23906): WARNING **: Failed to attach shared
memory! Falling back to non-shared handles

Regards, 

Alvaro




From alramire at ecs.syr.edu  Wed Feb 11 18:30:15 2004
From: alramire at ecs.syr.edu (Alvaro A. Ramirez)
Date: Wed, 11 Feb 2004 18:30:15 -0500
Subject: [Mono-devel-list] shared memory warnings [fixed]
In-Reply-To: <1076541490.2547.2.camel@stella>
References: <1076541490.2547.2.camel@stella>
Message-ID: <1076542215.2452.1.camel@stella>

Sorry about that. Problem fixed. Had to remove the .wapi directory in my
home directory. Everything fixed after that. 

On Wed, 2004-02-11 at 18:18, Alvaro A. Ramirez wrote:
> Hello everyone. Today I started receiving the following warnings when I
> tried to compile anything with mcs. I have not changed anything for my
> installation, working directory, or anything else. Now I receive the
> following warning. Should I worry about this? How can I fix this?
> 
> ** (/usr/local/bin/mcs.exe:23906): WARNING **: Shared memory sanity
> check failed.
>  
> ** (/usr/local/bin/mcs.exe:23906): WARNING **: Failed to attach shared
> memory! Falling back to non-shared handles
> 
> Regards, 
> 
> Alvaro
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From ndhameja at panaceasoftware.com  Wed Feb 11 18:48:05 2004
From: ndhameja at panaceasoftware.com (Namit Dhameja)
Date: Wed, 11 Feb 2004 15:48:05 -0800
Subject: [Mono-devel-list] Http Remoting problem
Message-ID: <005901c3f0f9$7ee29f90$7001a8c0@Namitws>

Hi,
    I am trying to port our server from windows to Linux (Mono 0.3). We were trying to get remoting working between a Windows client and the Linux server.
    Using "http" remoting didn't work (some attribute error), so I changed remoting to use 'tcp', than it worked great.     
    The FAQ says that both the remoting types are working, so is it just me or a well know problem.

-Best Regards,
Namit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040211/3e893fcf/attachment.html 

From ndhameja at panaceasoftware.com  Wed Feb 11 18:53:48 2004
From: ndhameja at panaceasoftware.com (Namit Dhameja)
Date: Wed, 11 Feb 2004 15:53:48 -0800
Subject: [Mono-devel-list] Regex: 'Split' function problem.
Message-ID: <006701c3f0fa$4b2e1f70$7001a8c0@Namitws>

Hi,
    I ran into problems when using the following code:

 parseWith = "/";
 Regex regPath = new Regex(parseWith,RegexOptions.RightToLeft);
 return regPath.Split(parseString);

Basically it throws an exception at 'regPath.Split', the workaround is to use the code below:

char[] c = {'/'};
string[] pS = parseString.Split(c,parseString.Length-1);
return pS;

-Best Regards,
Namit.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040211/1bb450f4/attachment.html 

From lluis at ximian.com  Wed Feb 11 19:02:14 2004
From: lluis at ximian.com (Lluis Sanchez)
Date: Thu, 12 Feb 2004 01:02:14 +0100
Subject: [Mono-devel-list] Http Remoting problem
In-Reply-To: <005901c3f0f9$7ee29f90$7001a8c0@Namitws>
References: <005901c3f0f9$7ee29f90$7001a8c0@Namitws>
Message-ID: <1076544134.2645.1.camel@portatil.aticatacs>

On dj, 2004-02-12 at 00:48, Namit Dhameja wrote:
> Hi,
>     I am trying to port our server from windows to Linux (Mono
> 0.3). We were trying to get remoting working between a Windows client
> and the Linux server.
>     Using "http" remoting didn't work (some attribute error), so I
> changed remoting to use 'tcp', than it worked great.     
>     The FAQ says that both the remoting types are working, so is it
> just me or a well know problem.

The HttpChannel is implemented, but it is not as mature as the
TcpChannel. Could you file a bug report in bugzilla with a simple test
case?

Thanks!

>  
> -Best Regards,
> Namit.



From psonek at email.cz  Wed Feb 11 05:16:01 2004
From: psonek at email.cz (psonek at email.cz)
Date: Wed, 11 Feb 2004 11:16:01 +0100 (CET)
Subject: [Mono-devel-list] System.Drawing.Drawing2D.HatchStyle little bug?
Message-ID: <402A00E1.000001.11322@db1.email.atc>

Hi,
I think I got tiny bug in HatchStyle.cs. This happens:

radek at linux:> mcs switch-test.cs /r:System.Drawing.dll
error CS0152: The label `case + 21:' is already present on this switch 
statement
Compilation failed: 1 error(s), 0 warnings

--- Code is here:

using System.Drawing.Drawing2D;
class Foo {
        static void Main () {
                HatchStyle style = HatchStyle.DarkUpwardDiagonal;
                switch (style) {
                        case HatchStyle.DarkUpwardDiagonal:
                                Console.WriteLine("DarkUpward");
                                break;
                        case HatchStyle.WideUpwardDiagonal:
                                Console.WriteLine("WideUpward");
                                break;
                }
        }
}

It's because WideUpwardDiagonal=21 is defined in HatchStyle.cs while it 
should be WideUpwardDiagonal=23.

I also want to ask, if it is ok that compiler didnt tell the file in which 
error occured and also no line number is mentioned. 

                                                           Radek

PS: sorry if i posted this twice - not sure now.

________________________________________________________________________________
Objevte kouzlo digit?ln? fotografie s fotoapar?ty Hewlett-Packard. V Albico internetov?m obchodu V?s ?ek? dobr? n?kup! http://www.email.cz/aio




From lluis at ideary.com  Wed Feb 11 08:08:34 2004
From: lluis at ideary.com (Lluis Sanchez)
Date: Wed, 11 Feb 2004 14:08:34 +0100
Subject: [Mono-devel-list] IChannelReceiver.Parse
In-Reply-To: <A70185F8290B6E4B92F848A60D21481D18E865@usmxsrv1.quark.com>
References: <A70185F8290B6E4B92F848A60D21481D18E865@usmxsrv1.quark.com>
Message-ID: <1076504914.4832.6.camel@portatil.aticatacs>

Hi!

I'm not sure to understand what are you trying to do, but you can get
the channel url for an object using the method GetUrlsForUri().

Channel.Parse() returns null if the provided url is not valid for the
channel. Maybe our Parse implementation is stricter than MS.NET one.
What's the result of ToUrl, and for which method does it fail?

Lluis.

On ds, 2004-02-07 at 00:21, Urs Muff wrote:
> Hi Lluis,
> 
> I have some issues with the TcpChannel: the following function works
> fine on .Net:
> 
>                 public static string GetChannelUri(RemotingProtocol
> protocol)
> 
>                 {
> 
>                         IChannelReceiver channel =
> GetChannel(protocol);
> 
>                         string objectUri;
> 
>                         return channel != null ?
> channel.Parse(ToUrl(protocol,new System.IO.MemoryStream()),out
> objectUri) : null;
> 
>                 }
> 
> The GetChannel function will return the right channel object depending
> on protocol (like Tcp, Iiop, Http, ...) and I would like to return the
> channel Uri so that I can build a complete Uri to use in
> Activator.GetObject.
> 
> It seems to return null instead of the channel Uri.
> 
> How am I supposed to get the channel Uri in mono?
> 
> Kindest regards,
> 
> - Urs C. Muff
> Software Architect              - Research Lab, Quark EIF
> Quark Inc.
> 
> UMuff at Quark.Com         - X6360
> +1 (303) 894 3360
> 
> CONFIDENTIALITY NOTICE
> 
> This e-mail transmission and any documents, files, or previous e-mail
> messages appended or attached to it, may contain information that is
> confidential or legally privileged. If you are not the intended
> recipient, or a person responsible for delivering it to the intended
> recipient, you are hereby notified that you must not read this
> transmission and that any disclosure, copying, printing, distribution,
> or use of the information contained or attached to this transmission
> is STRICTLY PROHIBITED. If you have received this transmission in
> error, please immediately notify the sender by telephone +1 (303)
> 894-3360 or return e-mail message umuff at quark.com and delete the
> original transmission, its attachments, and any copies without reading
> or saving in any manner. Thank you.
> 



From rkumar at novell.com  Thu Feb 12 07:26:24 2004
From: rkumar at novell.com (Ravindra)
Date: Thu, 12 Feb 2004 17:56:24 +0530
Subject: [Mono-devel-list] System.Drawing.Drawing2D.HatchStyle little
	bug?
In-Reply-To: <402A00E1.000001.11322@db1.email.atc>
References: <402A00E1.000001.11322@db1.email.atc>
Message-ID: <1076588784.22789.1964.camel@ravi>

Radek,
It is already fixed in CVS. Please update your code.
However, thanks for reporting this.

-Ravindra

On Wed, 2004-02-11 at 15:46, psonek at email.cz wrote:
> Hi,
> I think I got tiny bug in HatchStyle.cs. This happens:
> 
> radek at linux:> mcs switch-test.cs /r:System.Drawing.dll
> error CS0152: The label `case + 21:' is already present on this switch 
> statement
> Compilation failed: 1 error(s), 0 warnings
> 
> --- Code is here:
> 
> using System.Drawing.Drawing2D;
> class Foo {
>         static void Main () {
>                 HatchStyle style = HatchStyle.DarkUpwardDiagonal;
>                 switch (style) {
>                         case HatchStyle.DarkUpwardDiagonal:
>                                 Console.WriteLine("DarkUpward");
>                                 break;
>                         case HatchStyle.WideUpwardDiagonal:
>                                 Console.WriteLine("WideUpward");
>                                 break;
>                 }
>         }
> }
> 
> It's because WideUpwardDiagonal=21 is defined in HatchStyle.cs while it 
> should be WideUpwardDiagonal=23.
> 
> I also want to ask, if it is ok that compiler didnt tell the file in which 
> error occured and also no line number is mentioned. 
> 
>                                                            Radek
> 
> PS: sorry if i posted this twice - not sure now.
> 
> ________________________________________________________________________________
> Objevte kouzlo digit??ln?? fotografie s fotoapar??ty Hewlett-Packard. V Albico internetov??m obchodu V??s ??ek?? dobr?? n??kup! http://www.email.cz/aio
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From eric.durand-tremblay.1 at ulaval.ca  Thu Feb 12 11:30:52 2004
From: eric.durand-tremblay.1 at ulaval.ca (Eric Durand-Tremblay)
Date: Thu, 12 Feb 2004 11:30:52 -0500
Subject: [Mono-devel-list] Writing assembly
Message-ID: <402BAA3C.1000909@ulaval.ca>

Hello all,

Does anyone know a way to emit (with reflection) an already existing 
class (compiled in C#).  We looked at System.Reflection.Emit namespace 
but we are only able to save dynamicaly created assembly.

It could be usefull to do this when it is time to make our assembly 
compatible with MS runtime.  (Like saving some base class to assembly)

Thanks,

-------------------------------
Eric Durand Tremblay
TIP-Mono Team
Blogging : http://aeglos.dyndns.org/tip-mono



From 05mauben at hawken.edu  Thu Feb 12 12:15:25 2004
From: 05mauben at hawken.edu (Ben Maurer)
Date: Thu, 12 Feb 2004 12:15:25 -0500
Subject: [Mono-devel-list] Writing assembly
Message-ID: <s02b6e6d.040@gm004.hawken.edu>

Hello,

No, there is not a way to do this easily. Your best option is to use a Perl script that would take the compiled class and turn it into S.R.E code to emit the same IL.

One other possibility is that the runtime guys could hack something up for you that would copy the code from one assembly into one that is being built. However, this prevents you from using your impl on the MS runtime (eg, you cant copy just your code and compile/run on MS). Although this seems unimportant, it actually opens some unique testing possibilities. For example, you can run a run a regex on a set of random string data under MS and your impl, and see if they come out the same. Or you can do some performance testing of how fast your compiler is. Not a big deal, but if you dont have to loose it you should not.

Also, for code that will be going into many assemblies, you should optimize it a bit by hand for size. Eg, mcs does not emit short jumps, but you can code those in yourself. There are many other ways you can work on reducing size, and some pretty cool tricks you can do in IL.

-- Ben

>>> Eric Durand-Tremblay <eric.durand-tremblay.1 at ulaval.ca> 02/12/04 11:34 AM >>>
Hello all,

Does anyone know a way to emit (with reflection) an already existing 
class (compiled in C#).  We looked at System.Reflection.Emit namespace 
but we are only able to save dynamicaly created assembly.

It could be usefull to do this when it is time to make our assembly 
compatible with MS runtime.  (Like saving some base class to assembly)

Thanks,

-------------------------------
Eric Durand Tremblay
TIP-Mono Team
Blogging : http://aeglos.dyndns.org/tip-mono

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



From met at uberstats.com  Thu Feb 12 12:22:57 2004
From: met at uberstats.com (Met @ Uber)
Date: Thu, 12 Feb 2004 12:22:57 -0500
Subject: [Mono-devel-list] Fedora Core 2 Upgrade
Message-ID: <1076606577.7530.1.camel@rasmus>

Is there any reason to believe that updating to Fedora Core 2 test 1
with Gnome 2.5.3 and the 2.6 kernel will break Mono/Gtk#/etc ?

~ Matthew



From 05mauben at hawken.edu  Thu Feb 12 12:33:07 2004
From: 05mauben at hawken.edu (Ben Maurer)
Date: Thu, 12 Feb 2004 12:33:07 -0500
Subject: [Mono-devel-list] Fedora Core 2 Upgrade
Message-ID: <s02b72a5.057@gm004.hawken.edu>

I have heard of a few people using Gnome2.5, and it working fine. There should not be major problems.

Martin works on the kernel 2.6 version and seems to be doing fine.

As always, it is a test, use it at our own risk. OTOH, it would be great to have some feedback if there are any breaking bugs that we need to resolve or we need to report to RedHat.

-- Ben

>>> "Met @ Uber" <met at uberstats.com> 02/12/04 12:25 PM >>>
Is there any reason to believe that updating to Fedora Core 2 test 1
with Gnome 2.5.3 and the 2.6 kernel will break Mono/Gtk#/etc ?

~ Matthew

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



From miguel at novell.com  Thu Feb 12 12:46:36 2004
From: miguel at novell.com (Miguel de Icaza)
Date: Thu, 12 Feb 2004 12:46:36 -0500
Subject: [Mono-devel-list] Preview of 0.30.1 avaialble.
Message-ID: <1076607996.4883.1379.camel@erandi.boston.ximian.com>

Hello,

    This is a preview of the Mono 0.30.1, it only contains a couple of
simple bug fixes to the compiler (when reporting a delegate-signature 
error, the compiler would crash;  And it adds a new operator rule that
was missing from the early ECMA drafts) as well as fixing some http web
client issues.

    Preview tarball is available here:

	http://primates.ximian.com/~miguel/tmp/mono-0.30.1.tar.gz

    I would appreciate feedback on whether this works for you or not.

Miguel.


From eric.durand-tremblay.1 at ulaval.ca  Thu Feb 12 13:09:29 2004
From: eric.durand-tremblay.1 at ulaval.ca (Eric Durand-Tremblay)
Date: Thu, 12 Feb 2004 13:09:29 -0500
Subject: [Mono-devel-list] Writing assembly
In-Reply-To: <s02b6e6d.041@gm004.hawken.edu>
References: <s02b6e6d.041@gm004.hawken.edu>
Message-ID: <402BC159.5020604@ulaval.ca>

Thank you for the quick response.

This is not a problem,  we will eventually rewrite dynamically our base 
class and merge it with the dynamic assembly. (I asked out of laziness 
;) ) The only problem is that it cost a lot of compile time for each 
regex.  An other possibility is to dynamically compile the base class 
only when saving to an assembly.  Hence we will keep our compile time 
when compiling usual regex.

Actually, MS use base class to achieve this ( RegexRunner ) It is 
exactly why we have compatibility issues.  Note that we use the IMachine 
Interface like  mono interpreter.

For now, we concentrate on getting it all to run. We will be happy to 
introduce some tweaking later.

Eric

Ben Maurer a ?crit :

>Hello,
>
>No, there is not a way to do this easily. Your best option is to use a Perl script that would take the compiled class and turn it into S.R.E code to emit the same IL.
>
>One other possibility is that the runtime guys could hack something up for you that would copy the code from one assembly into one that is being built. However, this prevents you from using your impl on the MS runtime (eg, you cant copy just your code and compile/run on MS). Although this seems unimportant, it actually opens some unique testing possibilities. For example, you can run a run a regex on a set of random string data under MS and your impl, and see if they come out the same. Or you can do some performance testing of how fast your compiler is. Not a big deal, but if you dont have to loose it you should not.
>
>Also, for code that will be going into many assemblies, you should optimize it a bit by hand for size. Eg, mcs does not emit short jumps, but you can code those in yourself. There are many other ways you can work on reducing size, and some pretty cool tricks you can do in IL.
>
>-- Ben
>
>  
>
>>>>Eric Durand-Tremblay <eric.durand-tremblay.1 at ulaval.ca> 02/12/04 11:34 AM >>>
>>>>        
>>>>
>Hello all,
>
>Does anyone know a way to emit (with reflection) an already existing 
>class (compiled in C#).  We looked at System.Reflection.Emit namespace 
>but we are only able to save dynamicaly created assembly.
>
>It could be usefull to do this when it is time to make our assembly 
>compatible with MS runtime.  (Like saving some base class to assembly)
>
>Thanks,
>
>-------------------------------
>Eric Durand Tremblay
>TIP-Mono Team
>Blogging : http://aeglos.dyndns.org/tip-mono
>
>_______________________________________________
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>  
>




From mathpup at mylinuxisp.com  Thu Feb 12 12:27:02 2004
From: mathpup at mylinuxisp.com (Marcus)
Date: Thu, 12 Feb 2004 12:27:02 -0500
Subject: [Mono-devel-list] Preview of 0.30.1 avaialble.
In-Reply-To: <1076607996.4883.1379.camel@erandi.boston.ximian.com>
References: <1076607996.4883.1379.camel@erandi.boston.ximian.com>
Message-ID: <200402121227.02536.mathpup@mylinuxisp.com>

Could you describe or point me to the operator rule in question?


On Thursday 12 February 2004 12:46 pm, Miguel de Icaza wrote:
> Hello,
>
>     This is a preview of the Mono 0.30.1, it only contains a couple of
> simple bug fixes to the compiler (when reporting a delegate-signature
> error, the compiler would crash;  And it adds a new operator rule that
> was missing from the early ECMA drafts) as well as fixing some http web
> client issues.


From 05mauben at hawken.edu  Thu Feb 12 13:39:03 2004
From: 05mauben at hawken.edu (Ben Maurer)
Date: Thu, 12 Feb 2004 13:39:03 -0500
Subject: [Mono-devel-list] Writing assembly
Message-ID: <s02b820e.053@gm004.hawken.edu>

Yeah, you should only compile the pre-written code if you are saving to an assembly.

The time to add the code is not really a problem. There is really not that much cost to generating the actual code. I think you will find that parsing the Regex and making a strategy is much more costly than is spitting out some pre generated code. Also, remember the CompileToAssembly case is not really performance critical.

As always, do concentrate on getting it working. Once you guys have that, you can look at performance. I would be happy to lend you a hand if you want it.

Am very excited to see this sort of thing working. Some day, we are probably going to be doing a compiled version of XPath/XQuery/XSLT, so it will be interesting to see another similar piece of code. (MS has this for whidbey)

-- Ben

>>> Eric Durand-Tremblay <eric.durand-tremblay.1 at ulaval.ca> 02/12/04 13:11 PM >>>
Thank you for the quick response.

This is not a problem,  we will eventually rewrite dynamically our base 
class and merge it with the dynamic assembly. (I asked out of laziness 
;) ) The only problem is that it cost a lot of compile time for each 
regex.  An other possibility is to dynamically compile the base class 
only when saving to an assembly.  Hence we will keep our compile time 
when compiling usual regex.

Actually, MS use base class to achieve this ( RegexRunner ) It is 
exactly why we have compatibility issues.  Note that we use the IMachine 
Interface like  mono interpreter.

For now, we concentrate on getting it all to run. We will be happy to 
introduce some tweaking later.

Eric

Ben Maurer a ?crit :

>Hello,
>
>No, there is not a way to do this easily. Your best option is to use a Perl script that would take the compiled class and turn it into S.R.E code to emit the same IL.
>
>One other possibility is that the runtime guys could hack something up for you that would copy the code from one assembly into one that is being built. However, this prevents you from using your impl on the MS runtime (eg, you cant copy just your code and compile/run on MS). Although this seems unimportant, it actually opens some unique testing possibilities. For example, you can run a run a regex on a set of random string data under MS and your impl, and see if they come out the same. Or you can do some performance testing of how fast your compiler is. Not a big deal, but if you dont have to loose it you should not.
>
>Also, for code that will be going into many assemblies, you should optimize it a bit by hand for size. Eg, mcs does not emit short jumps, but you can code those in yourself. There are many other ways you can work on reducing size, and some pretty cool tricks you can do in IL.
>
>-- Ben
>
>  
>
>>>>Eric Durand-Tremblay <eric.durand-tremblay.1 at ulaval.ca> 02/12/04 11:34 AM >>>
>>>>        
>>>>
>Hello all,
>
>Does anyone know a way to emit (with reflection) an already existing 
>class (compiled in C#).  We looked at System.Reflection.Emit namespace 
>but we are only able to save dynamicaly created assembly.
>
>It could be usefull to do this when it is time to make our assembly 
>compatible with MS runtime.  (Like saving some base class to assembly)
>
>Thanks,
>
>-------------------------------
>Eric Durand Tremblay
>TIP-Mono Team
>Blogging : http://aeglos.dyndns.org/tip-mono
>
>_______________________________________________
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>  
>





From jordi at ximian.com  Thu Feb 12 14:21:47 2004
From: jordi at ximian.com (Jordi Mas)
Date: Thu, 12 Feb 2004 20:21:47 +0100
Subject: [Mono-devel-list] testing gdi+ without SWF/gtk#
In-Reply-To: <OFB7CC122C.186D850D-ONC1256E37.004D89CA@enac.fr>
References: <OFB7CC122C.186D850D-ONC1256E37.004D89CA@enac.fr>
Message-ID: <402BD24B.4070506@ximian.com>

En/na ROUGE Alain ha escrit:

>hi,
>
>Thanks for your reply Chris.
>Gdk.Window is perhaps a solution but I'm looking for something simpler 
>without SWF and without gtk#.
>I wonder if  it is possible to hack System.Drawing/libgdiplus/cairo to 
>directly render graphic primitives in a top level window.
>anyone an idea please?
>  
>
Cairo is a vector graphics library it does not provide any window 
managment function.  My suggestion is to use gtk#.

Good luck!

Jordi,



From jdegante at linuxware.com.mx  Thu Feb 12 15:20:54 2004
From: jdegante at linuxware.com.mx (Jorge De Gante)
Date: Thu, 12 Feb 2004 14:20:54 -0600
Subject: [Mono-devel-list] DataAdapter retrieves only two records
Message-ID: <1076617254.6414.4.camel@jorge.linuxware.net>

Hello Everybody

With Mono 0.29 this method returns all records in query. But with
version 0.30 only returns two records no matter what query executes.
I'm workin with MySQL and, I've checked the query in the mysql shell an
runs OK.

public DataTable CreateDataTable(string in_columns, string in_relation,
string in_condicion, string in_orden)
{
try
{
	string sql;
	if (in_columns == "")
	{
		in_columns = "*";
	}
	if (in_relation == "")
	{
		in_relation = table_name;
	}
	sql = "SELECT " + in_columns;
	sql += " FROM " + in_relation; 
	if (in_condicion != "")
	sql += " WHERE " + in_condicion;
	if (in_orden != "")     
	sql += " ORDER BY " + in_orden;
	Console.WriteLine("sql del CreateDataAdapter = " + sql);
	DataSet dataset = new DataSet(table_name);
	IDbDataAdapter dataadapter = Globals.CreateDataAdapter(sql);
	dataadapter.FillSchema(dataset, SchemaType.Mapped);
	dataadapter.Fill(dataset);
	return dataset.Tables[0];
}
catch (Exception ex)
{
	Console.WriteLine("Error al crear el DataTable: \n" + ex.Message);
	throw ex;
}
}

There is a bug in dataadapter or in dataset?

Please check it out.



From ChrisD at monkey.biz  Thu Feb 12 15:40:39 2004
From: ChrisD at monkey.biz (Chris Day)
Date: Fri, 13 Feb 2004 07:40:39 +1100
Subject: Loose vs Lose (was RE: [Mono-devel-list] Writing assembly)
Message-ID: <572D2FC4793D8C4BA6BC37E65EED384E1276FA@MKServer01.monkey.monkey.tv>

This is not meant to be a criticism of Ben personally, but I see this so
often that someone must be teaching this somewhere or it has been
ingrained from other people constantly using it, especially on Slashdot.
Frankly I am about to _lose_ it!

There seems a tendency for people to mix up _lose_ and _loose_, which
mean completely different things.  Normally, since English as a language
is quite _loose_, I can usually forgive this, especially on the internet
as English is not everyone's first language. However, for (I assume)
quite intelligent people, getting this wrong should not be a daily
occurrence!

Thank you for reading if you have got this far and go nuts on my grammar
if you wish since I'm being a word nazi! :))

Cheers,
Chris

Meanings taken from dictionary.com

Loose - 
Not fastened, restrained, or contained: loose bricks. 
Not taut, fixed, or rigid: a loose anchor line; a loose chair leg. 
Free from confinement or imprisonment; unfettered: criminals loose in
the neighborhood; dogs that are loose on the streets. 
Not tight-fitting or tightly fitted: loose shoes. 
Not bound, bundled, stapled, or gathered together: loose papers. 
Not compact or dense in arrangement or structure: loose gravel. 
Lacking a sense of restraint or responsibility; idle: loose talk. 
Not formal; relaxed: a loose atmosphere at the club. 
Lacking conventional moral restraint in sexual behavior. 
Not literal or exact: a loose translation. 
Characterized by a free movement of fluids in the body: a loose cough;
loose bowels.

Lose -
To be unsuccessful in retaining possession of; mislay: He's always
losing his car keys. 

To be deprived of (something one has had): lost her art collection in
the fire; lost her job. 
To be left alone or desolate because of the death of: lost his wife. 
To be unable to keep alive: a doctor who has lost very few patients. 
To be unable to keep control or allegiance of: lost his temper at the
meeting; is losing supporters by changing his mind. 
To fail to win; fail in: lost the game; lost the court case. 
To fail to use or take advantage of: Don't lose a chance to improve your
position. 
To fail to hear, see, or understand: We lost the plane in the fog. I
lost her when she started speaking about thermodynamics. 

To let (oneself) become unable to find the way. 
To remove (oneself), as from everyday reality into a fantasy world. 
To rid oneself of: lost five pounds. 
To consume aimlessly; waste: lost a week in idle occupations. 
To wander from or become ignorant of: lose one's way. 

To elude or outdistance: lost their pursuers. 
To be outdistanced by: chased the thieves but lost them. 
To become slow by (a specified amount of time). Used of a timepiece. 
To cause or result in the loss of: Failure to reply to the advertisement
lost her the job. 
To cause to be destroyed. Usually used in the passive: Both planes were
lost in the crash. 
To cause to be damned. 

> -----Original Message-----
> From: Ben Maurer [mailto:05mauben at hawken.edu] 
> Sent: Friday, 13 February 2004 4:15 AM
> To: mono-devel-list at lists.ximian.com; eric.durand-tremblay.1 at ulaval.ca
> Subject: Re: [Mono-devel-list] Writing assembly
snip
> testing of how fast your compiler is. Not a big deal, but if 
> you dont have to loose it you should not.
snip


From bmaurer at users.sourceforge.net  Thu Feb 12 16:13:47 2004
From: bmaurer at users.sourceforge.net (Ben Maurer)
Date: Thu, 12 Feb 2004 16:13:47 -0500
Subject: Loose vs Lose (was RE: [Mono-devel-list] Writing assembly)
In-Reply-To: <572D2FC4793D8C4BA6BC37E65EED384E1276FA@MKServer01.monkey.monkey.tv>
References: 
	 <572D2FC4793D8C4BA6BC37E65EED384E1276FA@MKServer01.monkey.monkey.tv>
Message-ID: <1076620426.30454.36.camel@Ben>

Actually, I know quite well the difference.

The main issue is that I was writing this at school, which has keyboards
that are pretty sticky (think, many people use the computer after lunch
:-).

-- Ben

On Thu, 2004-02-12 at 15:40, Chris Day wrote:
> This is not meant to be a criticism of Ben personally, but I see this so
> often that someone must be teaching this somewhere or it has been
> ingrained from other people constantly using it, especially on Slashdot.
> Frankly I am about to _lose_ it!
> 
> There seems a tendency for people to mix up _lose_ and _loose_, which
> mean completely different things.  Normally, since English as a language
> is quite _loose_, I can usually forgive this, especially on the internet
> as English is not everyone's first language. However, for (I assume)
> quite intelligent people, getting this wrong should not be a daily
> occurrence!
> 
> Thank you for reading if you have got this far and go nuts on my grammar
> if you wish since I'm being a word nazi! :))
> 
> Cheers,
> Chris
> 
> Meanings taken from dictionary.com
> 
> Loose - 
> Not fastened, restrained, or contained: loose bricks. 
> Not taut, fixed, or rigid: a loose anchor line; a loose chair leg. 
> Free from confinement or imprisonment; unfettered: criminals loose in
> the neighborhood; dogs that are loose on the streets. 
> Not tight-fitting or tightly fitted: loose shoes. 
> Not bound, bundled, stapled, or gathered together: loose papers. 
> Not compact or dense in arrangement or structure: loose gravel. 
> Lacking a sense of restraint or responsibility; idle: loose talk. 
> Not formal; relaxed: a loose atmosphere at the club. 
> Lacking conventional moral restraint in sexual behavior. 
> Not literal or exact: a loose translation. 
> Characterized by a free movement of fluids in the body: a loose cough;
> loose bowels.
> 
> Lose -
> To be unsuccessful in retaining possession of; mislay: He's always
> losing his car keys. 
> 
> To be deprived of (something one has had): lost her art collection in
> the fire; lost her job. 
> To be left alone or desolate because of the death of: lost his wife. 
> To be unable to keep alive: a doctor who has lost very few patients. 
> To be unable to keep control or allegiance of: lost his temper at the
> meeting; is losing supporters by changing his mind. 
> To fail to win; fail in: lost the game; lost the court case. 
> To fail to use or take advantage of: Don't lose a chance to improve your
> position. 
> To fail to hear, see, or understand: We lost the plane in the fog. I
> lost her when she started speaking about thermodynamics. 
> 
> To let (oneself) become unable to find the way. 
> To remove (oneself), as from everyday reality into a fantasy world. 
> To rid oneself of: lost five pounds. 
> To consume aimlessly; waste: lost a week in idle occupations. 
> To wander from or become ignorant of: lose one's way. 
> 
> To elude or outdistance: lost their pursuers. 
> To be outdistanced by: chased the thieves but lost them. 
> To become slow by (a specified amount of time). Used of a timepiece. 
> To cause or result in the loss of: Failure to reply to the advertisement
> lost her the job. 
> To cause to be destroyed. Usually used in the passive: Both planes were
> lost in the crash. 
> To cause to be damned. 
> 
> > -----Original Message-----
> > From: Ben Maurer [mailto:05mauben at hawken.edu] 
> > Sent: Friday, 13 February 2004 4:15 AM
> > To: mono-devel-list at lists.ximian.com; eric.durand-tremblay.1 at ulaval.ca
> > Subject: Re: [Mono-devel-list] Writing assembly
> snip
> > testing of how fast your compiler is. Not a big deal, but if 
> > you dont have to loose it you should not.
> snip
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From ChrisD at monkey.biz  Thu Feb 12 16:32:06 2004
From: ChrisD at monkey.biz (Chris Day)
Date: Fri, 13 Feb 2004 08:32:06 +1100
Subject: Loose vs Lose (was RE: [Mono-devel-list] Writing assembly)
Message-ID: <572D2FC4793D8C4BA6BC37E65EED384E1276FB@MKServer01.monkey.monkey.tv>

Ben,

It was not mean as a go at you per se, just a comment in the general
(mis)usage of these words that I have seen all too often.  Obviously
some people make a typo, or have a sticky keyboard...it was just a
general observation.

Sorry if my comments offended :)

Chris



> -----Original Message-----
> From: Ben Maurer [mailto:bmaurer at users.sourceforge.net] 
> Sent: Friday, 13 February 2004 8:14 AM
> To: Chris Day
> Cc: Mono Development
> Subject: Re: Loose vs Lose (was RE: [Mono-devel-list] Writing 
> assembly)
> 
> 
> Actually, I know quite well the difference.
> 
> The main issue is that I was writing this at school, which 
> has keyboards that are pretty sticky (think, many people use 
> the computer after lunch :-).
> 
> -- Ben
> 
> On Thu, 2004-02-12 at 15:40, Chris Day wrote:
> > This is not meant to be a criticism of Ben personally, but 
> I see this 
> > so often that someone must be teaching this somewhere or it 
> has been 
> > ingrained from other people constantly using it, especially on 
> > Slashdot. Frankly I am about to _lose_ it!
> > 
> > There seems a tendency for people to mix up _lose_ and 
> _loose_, which 
> > mean completely different things.  Normally, since English as a 
> > language is quite _loose_, I can usually forgive this, 
> especially on 
> > the internet as English is not everyone's first language. 
> However, for 
> > (I assume) quite intelligent people, getting this wrong 
> should not be 
> > a daily occurrence!
> > 
> > Thank you for reading if you have got this far and go nuts on my 
> > grammar if you wish since I'm being a word nazi! :))
> > 
> > Cheers,
> > Chris
> > 
> > Meanings taken from dictionary.com
> > 
> > Loose -
> > Not fastened, restrained, or contained: loose bricks. 
> > Not taut, fixed, or rigid: a loose anchor line; a loose chair leg. 
> > Free from confinement or imprisonment; unfettered: 
> criminals loose in
> > the neighborhood; dogs that are loose on the streets. 
> > Not tight-fitting or tightly fitted: loose shoes. 
> > Not bound, bundled, stapled, or gathered together: loose papers. 
> > Not compact or dense in arrangement or structure: loose gravel. 
> > Lacking a sense of restraint or responsibility; idle: loose talk. 
> > Not formal; relaxed: a loose atmosphere at the club. 
> > Lacking conventional moral restraint in sexual behavior. 
> > Not literal or exact: a loose translation. 
> > Characterized by a free movement of fluids in the body: a 
> loose cough;
> > loose bowels.
> > 
> > Lose -
> > To be unsuccessful in retaining possession of; mislay: He's always 
> > losing his car keys.
> > 
> > To be deprived of (something one has had): lost her art 
> collection in 
> > the fire; lost her job. To be left alone or desolate because of the 
> > death of: lost his wife. To be unable to keep alive: a 
> doctor who has 
> > lost very few patients. To be unable to keep control or 
> allegiance of: 
> > lost his temper at the meeting; is losing supporters by 
> changing his 
> > mind. To fail to win; fail in: lost the game; lost the court case.
> > To fail to use or take advantage of: Don't lose a chance to 
> improve your
> > position. 
> > To fail to hear, see, or understand: We lost the plane in the fog. I
> > lost her when she started speaking about thermodynamics. 
> > 
> > To let (oneself) become unable to find the way.
> > To remove (oneself), as from everyday reality into a fantasy world. 
> > To rid oneself of: lost five pounds. 
> > To consume aimlessly; waste: lost a week in idle occupations. 
> > To wander from or become ignorant of: lose one's way. 
> > 
> > To elude or outdistance: lost their pursuers.
> > To be outdistanced by: chased the thieves but lost them. 
> > To become slow by (a specified amount of time). Used of a 
> timepiece. 
> > To cause or result in the loss of: Failure to reply to the 
> advertisement
> > lost her the job. 
> > To cause to be destroyed. Usually used in the passive: Both 
> planes were
> > lost in the crash. 
> > To cause to be damned. 
> > 
> > > -----Original Message-----
> > > From: Ben Maurer [mailto:05mauben at hawken.edu]
> > > Sent: Friday, 13 February 2004 4:15 AM
> > > To: mono-devel-list at lists.ximian.com; 
> eric.durand-tremblay.1 at ulaval.ca
> > > Subject: Re: [Mono-devel-list] Writing assembly
> > snip
> > > testing of how fast your compiler is. Not a big deal, but if
> > > you dont have to loose it you should not.
> > snip
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com 
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> 


From vguzev at yandex.ru  Thu Feb 12 17:41:57 2004
From: vguzev at yandex.ru (Vadim B. Guzev)
Date: Fri, 13 Feb 2004 01:41:57 +0300
Subject: [Mono-devel-list] Processes
Message-ID: <009d01c3f1b9$6c32faf0$1117010a@HOME>

Hello, mono-devel-list at lists.ximian.com!


1.) Can anyone explain me why Mono creates so much threads even on simple
examples?
For example, compile the following example:
8<--------------------------------------------------------------------------
-
using System;

public class A {
 public static void Main ( string[] args ) {
  Console.ReadLine();
 }
}
8<--------------------------------------------------------------------------
-

And run it. When it requests to press "Enter" switch to another console and
do 'ps ux'.
You'll see something like this:

8<--------------------------------------------------------------------------
-
vadim    23826  0.2  0.4 14828 4356 pts/3    S    23:55   0:00 mono a.exe
vadim    23827  0.0  0.2  9328 1876 ?        S    23:55   0:00 mono a.exe
vadim    23828  0.0  0.4 14828 4356 pts/3    S    23:55   0:00 mono a.exe
vadim    23829  0.0  0.4 14828 4356 pts/3    S    23:55   0:00 mono a.exe
vadim    23830  0.8  0.4 14828 4356 pts/3    S    23:55   0:00 mono a.exe
vadim    23834  3.0  0.1  2360 1316 pts/6    S    23:55   0:00 -bash
vadim    23876  0.0  0.0  2536  684 pts/6    R    23:55   0:00 ps ux
8<--------------------------------------------------------------------------
-

5 threads!!! Is't OK? (I'm using Mono 0.29 on Linux)


2.) Compile the following two files:

8<-----------------------------A.cs----------------------------------------
using System;
using System.Diagnostics;

public class A {
 public static void Main ( string[] args ) {
  ProcessStartInfo psi = new ProcessStartInfo();
  psi.FileName = "mono";
  psi.Arguments = "b.exe";

  Process p = new Process();
  p.Start( psi );
 }
}

8<--------------------------------------------------------------------------
-

8<------------------------B.cs---------------------------------------------
using System;
using System.Threading;

public class b {
 public static void Main( string[] args ) {
  Console.WriteLine( "This is b process!" );
  while ( true ) { Thread.Sleep( 1000 ); };
 }
}
8<--------------------------------------------------------------------------
-

mcs a.cs -o a.exe
mcs b.cs -o b.exe

And run a.exe.
Then do 'ps ux'. You'll see that there still exists a process a.exe,
although the application a.exe has finished it's execution:

8<--------------------------------------------------------------------------
-
vadim    24060  0.0  0.2  9348 1900 ?        S    00:45   0:00 mono a.exe
vadim    24064  0.0  0.4 14896 4416 ?        S    00:45   0:00 /usr/bin/mono
b.exe
vadim    24065  0.0  0.4 14896 4416 ?        S    00:45   0:00 /usr/bin/mono
b.exe
vadim    24066  0.0  0.4 14896 4416 ?        S    00:45   0:00 /usr/bin/mono
b.exe
vadim    24067  0.0  0.4 14896 4416 ?        S    00:45   0:00 /usr/bin/mono
b.exe
8<--------------------------------------------------------------------------
-

Why does it happen? Is it a normal behaviour?

This is a very critical questions for our system as the number of
simultaneously running processes there can be big enough. And if mono will
multiply this number by four (five)... you can understand what'll happen...
:-(



Best regards,
Vadim B. Guzev



From danielmorgan at verizon.net  Thu Feb 12 20:46:04 2004
From: danielmorgan at verizon.net (Daniel Morgan)
Date: Thu, 12 Feb 2004 20:46:04 -0500
Subject: Loose vs Lose (was RE: [Mono-devel-list] Writing assembly)
In-Reply-To: <572D2FC4793D8C4BA6BC37E65EED384E1276FA@MKServer01.monkey.monkey.tv>
Message-ID: <OEEFLJJACNOBNHOAAKNJAEMFCCAA.danielmorgan@verizon.net>

I have more important things to do...

-----Original Message-----
From: mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com]On Behalf Of Chris Day
Sent: Thursday, February 12, 2004 3:41 PM
To: mono-devel-list at lists.ximian.com
Subject: Loose vs Lose (was RE: [Mono-devel-list] Writing assembly)


This is not meant to be a criticism of Ben personally, but I see this so
often that someone must be teaching this somewhere or it has been
ingrained from other people constantly using it, especially on Slashdot.
Frankly I am about to _lose_ it!

There seems a tendency for people to mix up _lose_ and _loose_, which
mean completely different things.  Normally, since English as a language
is quite _loose_, I can usually forgive this, especially on the internet
as English is not everyone's first language. However, for (I assume)
quite intelligent people, getting this wrong should not be a daily
occurrence!

Thank you for reading if you have got this far and go nuts on my grammar
if you wish since I'm being a word nazi! :))

Cheers,
Chris

Meanings taken from dictionary.com

Loose - 
Not fastened, restrained, or contained: loose bricks. 
Not taut, fixed, or rigid: a loose anchor line; a loose chair leg. 
Free from confinement or imprisonment; unfettered: criminals loose in
the neighborhood; dogs that are loose on the streets. 
Not tight-fitting or tightly fitted: loose shoes. 
Not bound, bundled, stapled, or gathered together: loose papers. 
Not compact or dense in arrangement or structure: loose gravel. 
Lacking a sense of restraint or responsibility; idle: loose talk. 
Not formal; relaxed: a loose atmosphere at the club. 
Lacking conventional moral restraint in sexual behavior. 
Not literal or exact: a loose translation. 
Characterized by a free movement of fluids in the body: a loose cough;
loose bowels.

Lose -
To be unsuccessful in retaining possession of; mislay: He's always
losing his car keys. 

To be deprived of (something one has had): lost her art collection in
the fire; lost her job. 
To be left alone or desolate because of the death of: lost his wife. 
To be unable to keep alive: a doctor who has lost very few patients. 
To be unable to keep control or allegiance of: lost his temper at the
meeting; is losing supporters by changing his mind. 
To fail to win; fail in: lost the game; lost the court case. 
To fail to use or take advantage of: Don't lose a chance to improve your
position. 
To fail to hear, see, or understand: We lost the plane in the fog. I
lost her when she started speaking about thermodynamics. 

To let (oneself) become unable to find the way. 
To remove (oneself), as from everyday reality into a fantasy world. 
To rid oneself of: lost five pounds. 
To consume aimlessly; waste: lost a week in idle occupations. 
To wander from or become ignorant of: lose one's way. 

To elude or outdistance: lost their pursuers. 
To be outdistanced by: chased the thieves but lost them. 
To become slow by (a specified amount of time). Used of a timepiece. 
To cause or result in the loss of: Failure to reply to the advertisement
lost her the job. 
To cause to be destroyed. Usually used in the passive: Both planes were
lost in the crash. 
To cause to be damned. 

> -----Original Message-----
> From: Ben Maurer [mailto:05mauben at hawken.edu] 
> Sent: Friday, 13 February 2004 4:15 AM
> To: mono-devel-list at lists.ximian.com; eric.durand-tremblay.1 at ulaval.ca
> Subject: Re: [Mono-devel-list] Writing assembly
snip
> testing of how fast your compiler is. Not a big deal, but if 
> you dont have to loose it you should not.
snip
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


From miguel at ximian.com  Thu Feb 12 22:17:23 2004
From: miguel at ximian.com (Miguel de Icaza)
Date: Thu, 12 Feb 2004 22:17:23 -0500
Subject: [Mono-devel-list] Processes
In-Reply-To: <009d01c3f1b9$6c32faf0$1117010a@HOME>
References: <009d01c3f1b9$6c32faf0$1117010a@HOME>
Message-ID: <1076642243.4883.2234.camel@erandi.boston.ximian.com>

Hello,

> 5 threads!!! Is't OK? (I'm using Mono 0.29 on Linux)

Let me explain:

	One of them is actually a separate process, not a thread, which
	is used for io handle sharing.  This will be shared by any mono 
	invocations in your system, so it only counts once.

	One is used by the GC (semantics of .NET) 

	The main thread becomes the manager, and your code is actually
	executed on a separate thread.

Miguel.


From miguel at ximian.com  Thu Feb 12 22:19:01 2004
From: miguel at ximian.com (Miguel de Icaza)
Date: Thu, 12 Feb 2004 22:19:01 -0500
Subject: [Mono-devel-list] Preview of 0.30.1 avaialble.
In-Reply-To: <200402121227.02536.mathpup@mylinuxisp.com>
References: <1076607996.4883.1379.camel@erandi.boston.ximian.com>
	 <200402121227.02536.mathpup@mylinuxisp.com>
Message-ID: <1076642341.4883.2237.camel@erandi.boston.ximian.com>

> Could you describe or point me to the operator rule in question?

Certainly, from the ChangeLog:

2004-02-07  Miguel de Icaza  <miguel at ximian.com>

	* assign.cs (Assign.DoResolve): When dealing with compound
	assignments, there is a new rule in ECMA C# 2.4 (might have been
	there before, but it is documented here) that states that in:

	a op= b;

	If b is of type int, and the `op' is a shift-operator, then the
	above is evaluated as:

	a = (int) a op b 



From erdut2 at ulaval.ca  Thu Feb 12 11:16:54 2004
From: erdut2 at ulaval.ca (Eric Durand-Tremblay)
Date: Thu, 12 Feb 2004 11:16:54 -0500
Subject: [Mono-devel-list] Regex: 'Split' function problem.
In-Reply-To: <006701c3f0fa$4b2e1f70$7001a8c0@Namitws>
References: <006701c3f0fa$4b2e1f70$7001a8c0@Namitws>
Message-ID: <402BA6F6.9000309@ulaval.ca>

Namit Dhameja a ?crit :

> Hi,
>     I ran into problems when using the following code:
>  
>  parseWith = "/";
>  Regex regPath = new Regex(parseWith,RegexOptions.RightToLeft);
>  return regPath.Split(parseString);
>  
> Basically it throws an exception at 'regPath.Split', the workaround is 
> to use the code below:
>  
> char[] c = {'/'};
> string[] pS = parseString.Split(c,parseString.Length-1);
> return pS;
>  
> -Best Regards,
> Namit.
>
Hello Namit,

It would be helpfull if you could write a bug in bugzilla.  I will check 
it soon.

Eric Durand-Tremblay
TIP-Mono Team
Blog : http://aeglos.dyndns.org/tip-mono/



From carlosga at telefonica.net  Fri Feb 13 10:13:09 2004
From: carlosga at telefonica.net (=?ISO-8859-1?Q?Carlos_Guzm=E1n_=C1lvarez?=)
Date: Fri, 13 Feb 2004 16:13:09 +0100
Subject: [Mono-devel-list] DbDataAdapter.Fill problems
Message-ID: <402CE985.4080102@telefonica.net>

Hello:

I'm having problems with the DbDataAdapter.Fill method, i'm running the 
nunit test suite of the Firebird .NET Data Provider under Fedora Core 1 
using latest mono CVS sources, the test cases that are giving problems 
to me are mainly related to the DataAdapter ( but all of them are 
running fine under Windows using .NET 1.0 ).

The problem is that DbDataAdapter.Fill seems to be no loading any rows, 
in a little sample like this:

string sql = "select * from TEST where int_field = @int_field";
FbCommand command = new FbCommand(sql, connection, transaction);
FbDataAdapter adapter = new FbDataAdapter(command);

adapter.SelectCommand.Parameters.Add("@int_field", 
FbDbType.Integer).Value = 1;		

DataSet ds = new DataSet();
adapter.Fill(ds, "TEST");

It needs to load one row but it's loading none, i ave checked that the 
command is correct and returns one row using a DataReader.

If needed i can fill a bug report at Bugzilla and provide a complete 
test case.


--
Best regards

Carlos Guzm?n ?lvarez
Vigo-Spain



From yoros at wanadoo.es  Fri Feb 13 11:43:50 2004
From: yoros at wanadoo.es (yoros at wanadoo.es)
Date: Fri, 13 Feb 2004 17:43:50 +0100
Subject: [Mono-devel-list] DbDataAdapter.Fill problems
In-Reply-To: <402CE985.4080102@telefonica.net>
References: <402CE985.4080102@telefonica.net>
Message-ID: <20040213164350.GA2462@phantom.matrix.com>

On Fri, Feb 13, 2004 at 04:13:09PM +0100, Carlos Guzm?n ?lvarez wrote:
> Hello:
> 
> I'm having problems with the DbDataAdapter.Fill method, i'm running the 
> nunit test suite of the Firebird .NET Data Provider under Fedora Core 1 
> using latest mono CVS sources, the test cases that are giving problems 
> to me are mainly related to the DataAdapter ( but all of them are 
> running fine under Windows using .NET 1.0 ).
> 
> The problem is that DbDataAdapter.Fill seems to be no loading any rows, 
> in a little sample like this:
> 
> string sql = "select * from TEST where int_field = @int_field";
> FbCommand command = new FbCommand(sql, connection, transaction);
> FbDataAdapter adapter = new FbDataAdapter(command);
> 
> adapter.SelectCommand.Parameters.Add("@int_field", 
> FbDbType.Integer).Value = 1;		
> 
> DataSet ds = new DataSet();
> adapter.Fill(ds, "TEST");
> 
> It needs to load one row but it's loading none, i ave checked that the 
> command is correct and returns one row using a DataReader.
> 
> If needed i can fill a bug report at Bugzilla and provide a complete 
> test case.
> 

I noticed that if I use any "relation" or "constraint" the Fill method
doesn't fill all the data (maybe 1 or 2 records)...

You can try to turn off all constraints, unique and pkeys.

Regards,

    Pedro

-- 
Pedro Mart?nez Juli?
\  yoros at terra.es
)|    yoros at wanadoo.es
/        http://yoros.dyndns.org
Socio HispaLinux #311
Usuario Linux #275438 - http://counter.li.org
GnuPG public information:  pub  1024D/74F1D3AC
Key fingerprint = 8431 7B47 D2B4 5A46 5F8E  534F 588B E285 74F1 D3AC


From ndhameja at panaceasoftware.com  Fri Feb 13 12:03:32 2004
From: ndhameja at panaceasoftware.com (Namit Dhameja)
Date: Fri, 13 Feb 2004 09:03:32 -0800
Subject: [Mono-devel-list] Regex: 'Split' function problem.
References: <E1Argar-0005l9-00@panacea>
Message-ID: <018901c3f253$4f728b20$7001a8c0@Namitws>

Hi Eric,
    I have added the bug to bugzilla. Thanks for taking a look.
    The ID is: http://bugzilla.ximian.com/show_bug.cgi?id=54242
-Best Regards,
Namit.

> ----- Original Message ----- 
> From: "Eric Durand-Tremblay" <erdut2 at ulaval.ca>
> To: <mono-devel-list at lists.ximian.com>
> Cc: "Namit Dhameja" <ndhameja at panaceasoftware.com>
> Sent: Thursday, February 12, 2004 8:16 AM
> Subject: Re: [Mono-devel-list] Regex: 'Split' function problem.
>
>
> > Namit Dhameja a ?crit :
> >
> > > Hi,
> > >     I ran into problems when using the following code:
> > >
> > >  parseWith = "/";
> > >  Regex regPath = new Regex(parseWith,RegexOptions.RightToLeft);
> > >  return regPath.Split(parseString);
> > >
> > > Basically it throws an exception at 'regPath.Split', the workaround is
> > > to use the code below:
> > >
> > > char[] c = {'/'};
> > > string[] pS = parseString.Split(c,parseString.Length-1);
> > > return pS;
> > >
> > > -Best Regards,
> > > Namit.
> > >
> > Hello Namit,
> >
> > It would be helpfull if you could write a bug in bugzilla.  I will check
> > it soon.
> >
> > Eric Durand-Tremblay
> > TIP-Mono Team
> > Blog : http://aeglos.dyndns.org/tip-mono/
> >
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
>
>
>



From carlosga at telefonica.net  Fri Feb 13 14:23:57 2004
From: carlosga at telefonica.net (=?ISO-8859-1?Q?Carlos_Guzm=E1n_=C1lvarez?=)
Date: Fri, 13 Feb 2004 20:23:57 +0100
Subject: [Mono-devel-list] DbDataAdapter.Fill problems
In-Reply-To: <20040213164350.GA2462@phantom.matrix.com>
References: <402CE985.4080102@telefonica.net> <20040213164350.GA2462@phantom.matrix.com>
Message-ID: <402D244D.1090400@telefonica.net>

Hello:

> I noticed that if I use any "relation" or "constraint" the Fill method
> doesn't fill all the data (maybe 1 or 2 records)...
> 
> You can try to turn off all constraints, unique and pkeys.

Huummmm jus my opinion but this is not a real solution to the problem as 
the same code works nice in .NET 1.0, i think i will try to take a look 
at the DbDataAdapter.Fill method if i have time.




--
Best regards

Carlos Guzm?n ?lvarez
Vigo-Spain


From carlosga at telefonica.net  Fri Feb 13 15:51:43 2004
From: carlosga at telefonica.net (=?ISO-8859-1?Q?Carlos_Guzm=E1n_=C1lvarez?=)
Date: Fri, 13 Feb 2004 21:51:43 +0100
Subject: [Mono-devel-list] DbDataAdapter.Fill problems
In-Reply-To: <402CE985.4080102@telefonica.net>
References: <402CE985.4080102@telefonica.net>
Message-ID: <402D38DF.3070203@telefonica.net>

Hello:

> It needs to load one row but it's loading none, i ave checked that the 
> command is correct and returns one row using a DataReader.

After some review, the problem, in my case, seems to be in the 
DataRow.SetColumnValue method that doesn't handle columns with array 
data ( the tables has blob and array fields defined, blob fields are 
filled with data ).

There are any special reason why this is not supported ??




--
Best regards

Carlos Guzm?n ?lvarez
Vigo-Spain


From duncan at ximian.com  Fri Feb 13 17:13:31 2004
From: duncan at ximian.com (Duncan Mak)
Date: Fri, 13 Feb 2004 17:13:31 -0500
Subject: [Mono-devel-list] Re: [Mono-patches] libgdiplus/src brush.h,NONE,1.1
 solidbrush.h,NONE,1.1 ChangeLog,1.5,1.6 gdip.h,1.4,1.5 brush.c,1.2,1.3
 solidbrush.c,1.2,1.3 pen.c,1.1.1.1,1.2 stringformat.c,1.1,1.2
In-Reply-To: <20040213160107.9EAE894745@mono-cvs.ximian.com>
References: <20040213160107.9EAE894745@mono-cvs.ximian.com>
Message-ID: <1076710411.27163.21.camel@diphthong>

Hello Ravindra,

I saw that you've been committing changes to libgdiplus, here are some
questions and comments.

On Fri, 2004-02-13 at 11:01, Ravindra Kumar  wrote:
> Modified Files:
> 	ChangeLog gdip.h brush.c solidbrush.c pen.c stringformat.c 
> Added Files:
> 	brush.h solidbrush.h 
>
> --- NEW FILE: brush.h
> /* Structures */
> typedef struct _Graphics GpGraphics;

It doesn't seem right to me that we're defining Graphics here within
brush.h. Is it possible that we make a graphics.h and include that
instead?

> +2004-02-13  Ravindra <rkumar at novell.com>
> +	* brush.h: Added. Moving brushes to OO-C.
> +	* solidbrush.h: Added. Moving brushes to OO-C.

Just calling OO-C doesn't really mean anything. Could you list the
actual changes you made in the future?

> +	* gdip.h: Moved out some methods to new headers.

Please list the methods that you moved.

> +	* brush.c, solidbrush.c: Changes related to OO-C.
> +	* pen.c: Modifications related to changes in solidbrush.

What are these modifications?

> Index: gdip.h
> +#include "brush.h"

If you include this later in the file, I think you can avoid moving the
code around. By keeping all the general enums and structures before
other header files, we can ensure that the name lookup will happen
correctly.

> @@ -66,30 +68,6 @@
> -typedef enum {
> -    Ok = 0,
> -    GenericError = 1,
> -    InvalidParameter = 2,
> -    OutOfMemory = 3,
> -    ObjectBusy = 4,
> -    InsufficientBuffer = 5,
> -    NotImplemented = 6,
> -    Win32Error = 7,
> -    WrongState = 8,
> -    Aborted = 9,
> -    FileNotFound = 10,
> -    ValueOverflow = 11,
> -    AccessDenied = 12,
> -    UnknownImageFormat = 13,
> -    FontFamilyNotFound = 14,
> -    FontStyleNotFound = 15,
> -    NotTrueTypeFont = 16,
> -    UnsupportedGdiplusVersion = 17,
> -    GdiplusNotInitialized = 18,
> -    PropertyNotFound = 19,
> -    PropertyNotSupported = 20
> -} GpStatus;

Why did you move this to brush.h? The GpStatus enum is the primary
return type used by all the functions in GDI+, I don't think it is
specific to Brush at all. Shouldn't it stay within gdip.h?

> -typedef struct {
> +typedef struct _Graphics {
>  	cairo_t         *ct;
>  	cairo_matrix_t  *copy_of_ctm;
>  	void            *hdc;
>  	int             hdc_busy_count;
>  	void            *image;
>  	int             type; 
> -} GpGraphics;
> +} Graphics;

Why did you have to rename this?

thanks,

Duncan.


From duncan at ximian.com  Fri Feb 13 17:18:53 2004
From: duncan at ximian.com (Duncan Mak)
Date: Fri, 13 Feb 2004 17:18:53 -0500
Subject: [Mono-devel-list] Re: [Mono-patches] libgdiplus/src stringformat.c,NONE,1.1
 ChangeLog,1.4,1.5 Makefile.am,1.2,1.3 font.c,1.1,1.2 gdip.h,1.3,1.4
 general.c,1.1.1.1,1.2 graphics.c,1.4,1.5 solidbrush.c,1.1.1.1,1.2
In-Reply-To: <20040213150232.0E9B094745@mono-cvs.ximian.com>
References: <20040213150232.0E9B094745@mono-cvs.ximian.com>
Message-ID: <1076710732.27157.26.camel@diphthong>

Hello Jordi,

On Fri, 2004-02-13 at 10:02, Jordi Mas  wrote:
> Index: gdip.h
> +// NOTE: This file includes some internal cairo definitions to
> +// avoid to define them again you should have it in your include path
> +// it is part of the standard cairo development package
> +#include <cairoint.h>
> +

This is not true, cairoint.h is Cairo's own internal helper and it is
not part of the standard Cairo development package. There is a note at
the top of cairoint.h:

/*
 * These definitions are solely for use by the implementation of Cairo
 * and constitute no kind of standard.  If you need any of these
 * functions, please drop me a note.  Either the library needs new
 * functionality, or there's a way to do what you need using the
 * existing published interfaces. cworth at isi.edu
 */

If you need functionality that is currently hidden within cairoint.h,
you should write to the cairo mailing list (cairo at cairographics.org) and
work out a way for Cairo to expose that API publicly.

Duncan.


From chris at iBankTech.NET  Fri Feb 13 20:05:43 2004
From: chris at iBankTech.NET (Chris Capel)
Date: Fri, 13 Feb 2004 19:05:43 -0600
Subject: [Mono-devel-list] New compiler--CIL/CTS questions
Message-ID: <AC4E9FFE068E2147A9E0568EB7A94D2C5F93@ibt-server1.iBankTech.NET>

Hello, all.

I'm in the planning phases of writing a Lisp compiler for the CLI, and
I'm stuck trying to figure out how to implement dynamic functions
(lambdas and macros, basically) efficiently using CIL, and cooperating
as much as possible with the CTS.  The problem is, I don't see any way
to generate a method at runtime and then call it without using lots and
lots and lots of really slow, excruciatingly non-dynamic reflection.
The best I've managed so far is this:

AssemblyName n = new AssemblyName();
n.Name = "test";
AssemblyBuilder asm =
	AppDomain.CurrentDomain.DefineDynamicAssembly(n,
AssemblyBuilderAccess.RunAndSave);
ModuleBuilder m = asm.DefineDynamicModule("test.exe", "test.exe");
MethodBuilder meth = m.DefineGlobalMethod("MyMethod",
MethodAttributes.Static
	| MethodAttributes.Public, CallingConventions.Standard,
	typeof(void), null);
ILGenerator il = meth.GetILGenerator();
il.Emit(OpCodes.Ldstr, "Hello world");
il.EmitCall(OpCodes.Call, typeof(Console).GetMethod("WriteLine",
	new Type[] { typeof(string) }),
	null);
il.Emit(OpCodes.Ret);
m.CreateGlobalFunctions();
m.GetMethod("MyMethod").Invoke(null, null);

As you can see, this involves creating a module, or at *least* a type
(although I'm not even sure you can call methods on types in a non-baked
module or create new types in a baked one), for every single new
function you want to run, unless you interpret the function manually.  I
mean, I want to have an interpreter, but there's no question that to be
useful, this has to be a compiled language.  Even if this *wasn't* way
too much overhead, there's the issue that any types you created can't be
cleaned up later.  They're going to stick around in your application
domain until you quit.  Never garbage collected.  Never removed from
memory.  They'll just collect and accrue in your dynamic module until it
bursts.  Also, there's a conspicuous lack of any CIL instructions having
to do with dynamic-anything.  Does it bother anyone besides me that you
couldn't write the CTS using CIL, in anything nearly resembling
efficient?

The only thing that occurs to me, given my limited knowledge of the CLI,
is to provide, like most other Lisp compilers, a normal interpreted
mode, and require that the compile function be used only at the
module/package/source file level, so that the overhead doesn't become to
great during debugging. But that solution doesn't solve the lambda/macro
problem (can you imagine the compiler creating a new type every time a
macro was expanded?), which is basically the
ever-growing-number-of-types-that-you-can't-get-rid-of problem; it
doesn't even mitigate it that much.  In fact, it's probably not any
better than making Lisp a non-interactive language, just like any old C
family member.

I read a posting on some MIT list that the CLI was too restrictive to
efficiently implement Lisp.  After reading the ECMA CLI spec, and
experimenting with the System.Reflection.Emit classes pertinent, I'm
beginning to agree.  And that's just a big shame.

Chris Capel


From danielmorgan at verizon.net  Sat Feb 14 00:37:54 2004
From: danielmorgan at verizon.net (Daniel Morgan)
Date: Sat, 14 Feb 2004 00:37:54 -0500
Subject: [Mono-devel-list] DbDataAdapter.Fill problems
In-Reply-To: <402D38DF.3070203@telefonica.net>
Message-ID: <OEEFLJJACNOBNHOAAKNJIEMNCCAA.danielmorgan@verizon.net>

Carlos,

Because we left array support in DataRow.SetColumnValue to be implemented by
you! :-)

Just kidding...

It's ommission was not known at the time of implementation.  You are welcome
to add that missing piece.

Happy hacking,
Daniel

-----Original Message-----
From: mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com]On Behalf Of Carlos
Guzm?n ?lvarez
Sent: Friday, February 13, 2004 3:52 PM
To: mono-devel
Subject: Re: [Mono-devel-list] DbDataAdapter.Fill problems


Hello:

> It needs to load one row but it's loading none, i ave checked that the
> command is correct and returns one row using a DataReader.

After some review, the problem, in my case, seems to be in the
DataRow.SetColumnValue method that doesn't handle columns with array
data ( the tables has blob and array fields defined, blob fields are
filled with data ).

There are any special reason why this is not supported ??




--
Best regards

Carlos Guzm?n ?lvarez
Vigo-Spain
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list



From carlosga at telefonica.net  Sat Feb 14 03:40:47 2004
From: carlosga at telefonica.net (=?ISO-8859-1?Q?Carlos_Guzm=E1n_=C1lvarez?=)
Date: Sat, 14 Feb 2004 09:40:47 +0100
Subject: [Mono-devel-list] DbDataAdapter.Fill problems
In-Reply-To: <OEEFLJJACNOBNHOAAKNJIEMNCCAA.danielmorgan@verizon.net>
References: <OEEFLJJACNOBNHOAAKNJIEMNCCAA.danielmorgan@verizon.net>
Message-ID: <402DDF0F.5010604@telefonica.net>

Hello:

> Because we left array support in DataRow.SetColumnValue to be implemented by
> you! :-)
> 
> Just kidding...

hehe :)

> It's ommission was not known at the time of implementation.  You are welcome
> to add that missing piece.

Ok i'm going to try to review it, i will send a patch to the list if i 
get it to work correctly.



--
Best regards

Carlos Guzm?n ?lvarez
Vigo-Spain


From malekith at pld-linux.org  Sat Feb 14 04:48:49 2004
From: malekith at pld-linux.org (Michal Moskal)
Date: Sat, 14 Feb 2004 10:48:49 +0100
Subject: [Mono-devel-list] New compiler--CIL/CTS questions
In-Reply-To: <AC4E9FFE068E2147A9E0568EB7A94D2C5F93@ibt-server1.iBankTech.NET>
References: <AC4E9FFE068E2147A9E0568EB7A94D2C5F93@ibt-server1.iBankTech.NET>
Message-ID: <20040214094849.GA7850@roke.freak>

On Fri, Feb 13, 2004 at 07:05:43PM -0600, Chris Capel wrote:
> Hello, all.
> 
> I'm in the planning phases of writing a Lisp compiler for the CLI, and
> I'm stuck trying to figure out how to implement dynamic functions
> (lambdas and macros, basically) efficiently using CIL, and cooperating
> as much as possible with the CTS.  The problem is, I don't see any way
> to generate a method at runtime and then call it without using lots and
> lots and lots of really slow, excruciatingly non-dynamic reflection.

You don't need to generate code for each lambda expression. That is you
need to generate it once, and then pass the code along with closure.
As I am not familiar with lisp, syntax but to give you an idea:

(def adder (x) (lambda (y) (x + y))

Now you compile this to something like:

interface Function {
  object apply (object arg);
}

class adder_closure {
  int x;
}

class lambda_1 : Function {
  adder_closure clo;
  
  lambda_1 (adder_closure c) { clo = c; }
  
  object apply (object arg)
  {
    return clo.x + (int)arg;
  }
}

class someclass {
  Function adder (int _x) {
    adder_closure clo = new adder_closure ();
    clo.x = _x;
    return new lambda_1 (clo);
  }
}

Instead of using Function interface, you can also use delegates, but
beware that delegate invocation is about 5 times slower then method
invocation, and creation is about 10-20 times slower, then adder_closure
+ lambda_1 creation. This what I have just shown on the other hand works
quite nice (I have bootstraping compiler using this).

I'm sorry, if you already know all this -- but you asked for lambdas.

Have you looked at Hot Dog Scheme compiler? Maybe they come out with
something better.

BTW: your question (as well as my reply :-) can be considered off topic 
here, as this list is devoted to discuss mono, not .NET in general.


-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?


From jordi at ximian.com  Sat Feb 14 07:20:22 2004
From: jordi at ximian.com (Jordi Mas)
Date: Sat, 14 Feb 2004 13:20:22 +0100
Subject: [Mono-devel-list] Re: [Mono-patches] libgdiplus/src stringformat.c,NONE,1.1	ChangeLog,1.4,1.5
 Makefile.am,1.2,1.3 font.c,1.1,1.2 gdip.h,1.3,1.4	general.c,1.1.1.1,1.2 graphics.c,1.4,1.5
 solidbrush.c,1.1.1.1,1.2
In-Reply-To: <1076710732.27157.26.camel@diphthong>
References: <20040213150232.0E9B094745@mono-cvs.ximian.com> <1076710732.27157.26.camel@diphthong>
Message-ID: <402E1286.5000804@ximian.com>

En/na Duncan Mak ha escrit:

>Hello Jordi,
>
>On Fri, 2004-02-13 at 10:02, Jordi Mas  wrote:
>  
>
>>Index: gdip.h
>>+// NOTE: This file includes some internal cairo definitions to
>>+// avoid to define them again you should have it in your include path
>>+// it is part of the standard cairo development package
>>+#include <cairoint.h>
>>+
>>    
>>
>
>This is not true, cairoint.h is Cairo's own internal helper and it is
>not part of the standard Cairo development package. There is a note at
>the top of cairoint.h:
>  
>

Well, I wanted to say that you can find the include in the Cairo 
development packet but it is not installed by default because it's internal.

>If you need functionality that is currently hidden within cairoint.h,
>you should write to the cairo mailing list (cairo at cairographics.org) and
>work out a way for Cairo to expose that API publicly.
>  
>
We are in a process of implementing the font handeling. It's not clear 
which functions we are going to need yet and which internal cairo 
functions we will need access to. Until the implementation is finished 
and working, I do not think that makes sense to request additions or 
changes to the Cairo people.

Salut,

Jordi,



From vargaz at freemail.hu  Sat Feb 14 07:24:53 2004
From: vargaz at freemail.hu (Varga Zoltan)
Date: Sat, 14 Feb 2004 13:24:53 +0100 (CET)
Subject: [Mono-devel-list] New compiler--CIL/CTS questions
Message-ID: <freemail.20040114132453.91914@fm10.freemail.hu>

                                      Hi,

  Take a look at the DynamicMethod class from Net 1.2:

http://longhorn.msdn.microsoft.com/lhsdk/ref/ns/system.reflection.emit/c/dynamicmethod/dynamicmethod.aspx

It allows creation of dynamic methods without creating a
module/type.
This class is implemented in mono.

               bye

                     Zoltan




From chris at iBankTech.NET  Sat Feb 14 13:00:56 2004
From: chris at iBankTech.NET (Chris Capel)
Date: Sat, 14 Feb 2004 12:00:56 -0600
Subject: [Mono-devel-list] New compiler--CIL/CTS questions
Message-ID: <AC4E9FFE068E2147A9E0568EB7A94D2C5CA2@ibt-server1.iBankTech.NET>

> Have you looked at Hot Dog Scheme compiler? Maybe they come out with
> something better.
 
You'd think so, eh? But I checked the source--it appears it's just an
interpreter.  Of course, I only gave it a quick scan--I could be mistaken--but
I didn't see a single Reflection.Emit related statement, nor any file i/o.
 
As to your suggested solution: the problem is that Lisp doesn't have a
run-time/compile-time distinction. The compiler and library are the same,
and linked to the final executable. The compiler, to be a real Lisp, has to
assume that any function definitions are being done at run-time. I'm not sure
I understood what you were aiming for--the compiler generating C# code?
I assume that you meant I would emit these types at runtime. Even still,
(though I appreciate your example) your code is little more than mapping
lisp primitives through a consideribly dense layer of object-oriented code,
which goes against the purported point of the CLI, which is to allow lots of
different languages to be implemented in a common runtime environment,
not to be built on top of each other, or even the CTS itself, according to the
spec. Though just what power it offers outside of the CTS is questionable.

> BTW: your question (as well as my reply :-) can be considered off topic
> here, as this list is devoted to discuss mono, not .NET in general.
 
Oh, I dunno. It's debateable. Developing a new compiler for mono could be
considered mono related. The fact that it would work on any CLI compliant
runtime is incidental. Besides, I didn't see any more appropriate mono-* list,
and I figure you people have implemented a runtime, so you must be pretty
familiar with it.
 
> Take a look at the DynamicMethod class from Net 1.2
 
Thanks, Zoltan. Do you know if this class performs well enough to be used
as the primary function-calling mechanism of a language?
 
Chris C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040214/ba92d400/attachment.html 

From bmaurer at users.sourceforge.net  Sun Feb 15 01:10:45 2004
From: bmaurer at users.sourceforge.net (Ben Maurer)
Date: Sun, 15 Feb 2004 01:10:45 -0500
Subject: [Mono-devel-list] PATCH: Lazily allocate ArrayList buffers
Message-ID: <1076825445.3280.12.camel@Ben>

Hello,

Attached is a patch that makes ArrayLists allocate their buffers only on
the first addition to the list. For example the following code:

ArrayList ar = new ArrayList ();
ar = null;

will not allocate an object [].

Running the profiler on a few applications, it seems that the patch has
some effect. One notable example is MonoDevelop where it prevented 2/3
of the allocations of arraylists.

It seems that MS implements this behavior in the v2 framework. Using a
beta of the code, I ran:

ArrayList ar = new ArrayList ()
COnsole.WriteLine (ar.Capacity);

It returned 0. This seems to indicate that the capacity (which is the
size of the array) is zero until something has been added.

For my patch, I made it so that the outside behavior would not change,
the code fudges having a 16 capacity when the list is empty. Our nunit
tests probe for this case. However, I wonder if we really should do
this.

The nunit tests pass after the patch.

-- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: corlib-array-list.patch
Type: text/x-patch
Size: 2341 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040215/ecd6a025/attachment.bin 

From avd at openlinksw.com  Sun Feb 15 02:01:04 2004
From: avd at openlinksw.com (Aleksey Demakov)
Date: Sun, 15 Feb 2004 13:01:04 +0600
Subject: [Mono-devel-list] problem compiling mono with gcc 2.95
Message-ID: <402F1930.7000305@openlinksw.com>

Hi all,

I have a problem compiling mono with gcc 2.95.4:

gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../libgc/include 
-I/home/avd/include/glib-2.0 -I/home/avd/lib/glib-2.0/include 
-D_REENTRANT -I/home/avd/include/glib-2.0 
-I/home/avd/lib/glib-2.0/include -DGC_LINUX_THREADS 
-DMONO_USE_EXC_TABLES -D_GNU_SOURCE -D_REENTRANT -fexceptions 
-D_FILE_OFFSET_BITS=64 -g -O2 -fno-strict-aliasing -g -Wall -Wunused 
-Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes 
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual 
-Wcast-align -Wwrite-strings -Wp,-MD,.deps/mini-x86.pp -c mini-x86.c 
      -fPIC -DPIC -o .libs/mini-x86.lo
mini-x86.c: In function `indent':
mini-x86.c:117: parse error before `int'
mini-x86.c:118: `v' undeclared (first use in this function)
mini-x86.c:118: (Each undeclared identifier is reported only once
mini-x86.c:118: for each function it appears in.)

Could you please take a look at the attached patch.

Regards,
Aleksey
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mini-x86.c.patch
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040215/07d8012b/attachment.pl 

From cpoole at pooleconsulting.com  Sun Feb 15 14:02:21 2004
From: cpoole at pooleconsulting.com (Charlie Poole)
Date: Sun, 15 Feb 2004 11:02:21 -0800
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <Sea2-F63CllPF6p0V7n00015cb6@hotmail.com>
Message-ID: <OFEAJFLCBPECFKICJIOJGEIBNLAA.cpoole@pooleconsulting.com>

Hi All,

I'm working under Windows to develop the next release of NUnit, and I'm
testing under Mono as well as MS .NET.

In order to be sure I'm running under mono in a particlular test execution,
I'm using
typeof( System.Object  ).Assembly.CodeBase and looking for "Mono" in the
path.

This is pretty kludgy and only of course depends on the location in which
I've installed Mono.

Any better suggestions?

Charlie Poole
cpoole at pooleconsulting.org




From gert.driesen at pandora.be  Sun Feb 15 14:23:03 2004
From: gert.driesen at pandora.be (Gert Driesen)
Date: Sun, 15 Feb 2004 20:23:03 +0100
Subject: [Mono-devel-list] Detecting Mono
References: <OFEAJFLCBPECFKICJIOJGEIBNLAA.cpoole@pooleconsulting.com>
Message-ID: <002201c3f3f9$22007f10$0200a8c0@mother>

Charlie,

For NAnt we use the following code to detect whether we're running on the
Mono runtime :

if (Type.GetType("Mono.Runtime", false) != null) {
    // we're on Mono
    IsMono = true;
} else {
    IsMono = false;
}

Hope this helps,

Gert

----- Original Message ----- 
From: "Charlie Poole" <cpoole at pooleconsulting.com>
To: <mono-devel-list at lists.ximian.com>
Sent: Sunday, February 15, 2004 8:02 PM
Subject: [Mono-devel-list] Detecting Mono


> Hi All,
>
> I'm working under Windows to develop the next release of NUnit, and I'm
> testing under Mono as well as MS .NET.
>
> In order to be sure I'm running under mono in a particlular test
execution,
> I'm using
> typeof( System.Object  ).Assembly.CodeBase and looking for "Mono" in the
> path.
>
> This is pretty kludgy and only of course depends on the location in which
> I've installed Mono.
>
> Any better suggestions?
>
> Charlie Poole
> cpoole at pooleconsulting.org
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>



From cpoole at pooleconsulting.com  Sun Feb 15 14:35:20 2004
From: cpoole at pooleconsulting.com (Charlie Poole)
Date: Sun, 15 Feb 2004 11:35:20 -0800
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <002201c3f3f9$22007f10$0200a8c0@mother>
Message-ID: <OFEAJFLCBPECFKICJIOJKEICNLAA.cpoole@pooleconsulting.com>

Ah... much better. :-)

Charlie

> -----Original Message-----
> From: Gert Driesen [mailto:gert.driesen at pandora.be]
> Sent: Sunday, February 15, 2004 11:23 AM
> To: Charlie Poole; mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-devel-list] Detecting Mono
>
>
> Charlie,
>
> For NAnt we use the following code to detect whether we're running on the
> Mono runtime :
>
> if (Type.GetType("Mono.Runtime", false) != null) {
>     // we're on Mono
>     IsMono = true;
> } else {
>     IsMono = false;
> }
>
> Hope this helps,
>
> Gert
>
> ----- Original Message -----
> From: "Charlie Poole" <cpoole at pooleconsulting.com>
> To: <mono-devel-list at lists.ximian.com>
> Sent: Sunday, February 15, 2004 8:02 PM
> Subject: [Mono-devel-list] Detecting Mono
>
>
> > Hi All,
> >
> > I'm working under Windows to develop the next release of NUnit, and I'm
> > testing under Mono as well as MS .NET.
> >
> > In order to be sure I'm running under mono in a particlular test
> execution,
> > I'm using
> > typeof( System.Object  ).Assembly.CodeBase and looking for "Mono" in the
> > path.
> >
> > This is pretty kludgy and only of course depends on the
> location in which
> > I've installed Mono.
> >
> > Any better suggestions?
> >
> > Charlie Poole
> > cpoole at pooleconsulting.org
> >
> >
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
>
>




From carlosga at telefonica.net  Sun Feb 15 17:43:31 2004
From: carlosga at telefonica.net (=?ISO-8859-1?Q?Carlos_Guzm=E1n_=C1lvarez?=)
Date: Sun, 15 Feb 2004 23:43:31 +0100
Subject: [Mono-devel-list] [ANN] Firebird .NET Data Provider 1.5 Release Candidate 5 released
Message-ID: <402FF613.8000405@telefonica.net>

Hello:

Firebird .NET Data Provider 1.5 Release Candidate 5 available for download.

Release Changes:

- Bug fixes.


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


You can read the Changelog at:

https://sourceforge.net/project/shownotes.php?release_id=216995


You can download binarys for .NET 1.0 at:

http://prdownloads.sourceforge.net/firebird/FirebirdNETProvider1.5-RC5-NET1.0.exe?download


You can download binarys for .NET 1.1 at:

http://prdownloads.sourceforge.net/firebird/FirebirdNETProvider1.5-RC5-NET1.1.exe?download


You can download sources at:

http://prdownloads.sourceforge.net/firebird/FirebirdNETProvider1.5-RC5-Src.zip?download


You can download documentation at:

http://prdownloads.sourceforge.net/firebird/FirebirdNETProvider1.5-RC5-Doc.zip?download




CVS Tag: NP_1_5_RC5



-- 
Best regards

Carlos Guzm?n ?lvarez
Vigo-Spain





From psonek2 at seznam.cz  Sun Feb 15 17:48:49 2004
From: psonek2 at seznam.cz (=?us-ascii?Q?radek=20polak?=)
Date: Sun, 15 Feb 2004 23:48:49 +0100 (CET)
Subject: [Mono-devel-list] =?us-ascii?Q?Re=3A=20Testing=20GDI=2B=20without=20SWF?=
In-Reply-To: <13313.39926-18814-1423627238-1076780079@seznam.cz>
Message-ID: <1264.43146-18809-2143405852-1076885329@seznam.cz>

Hi,
there was some talking about testing GDI+ on simple X window. I did some hacking and taken Xlib wrapper from PNet. It compiles under mono and you can draw some graphics primitives to window with it. I made homepage for this at http://psonek.webzdarma.cz/. *Warning* the hack is really ugly, anyways enjoy it.  Radek

PS: i wanted to test gdiplus bitmap drawing, but didnt have much luck since GetPixel function seems to be not implemented yet and i have no idea how to read pixels from Graphics object or image. Yes i know i am newbie :-)


From thomas.uhl at topalis.com  Sun Feb 15 15:53:14 2004
From: thomas.uhl at topalis.com (Thomas Uhl)
Date: Sun, 15 Feb 2004 21:53:14 +0100
Subject: [Mono-devel-list] COBOL frontend for Mono?
Message-ID: <1076878394.3770.18.camel@localhost.localdomain>

Hi all,

I just would like to know, whether there exists already some effort
on developing a COBOL compiler for Mono?

yours
  Tom
-- 
----------------------------------------------------------------------
Thomas Uhl                                      thomas.uhl at topalis.com
Topalis AG                                    phone: +49 711 88770-111
Lilienthalstr. 2                                fax: +49 711 88770-199
70825 Stuttgart-Korntal, Germany                cel: +49 170 7917711
----------------------------------------------------------------------



From Matt.Davey at finetix.com  Mon Feb 16 04:53:37 2004
From: Matt.Davey at finetix.com (Matt Davey)
Date: Mon, 16 Feb 2004 09:53:37 -0000
Subject: [Mono-devel-list] COBOL frontend for Mono?
References: <1076878394.3770.18.camel@localhost.localdomain>
Message-ID: <023501c3f472$c0496370$03fea8c0@ukfin.co.uk>

U should be able to use any .NET COBOL compiler, since Mono effectively runs
IL code hence Fujitsu NetCOBOL  should work

Later

----- Original Message ----- 
From: "Thomas Uhl" <thomas.uhl at topalis.com>
To: <mono-devel-list at lists.ximian.com>
Sent: Sunday, February 15, 2004 8:53 PM
Subject: [Mono-devel-list] COBOL frontend for Mono?


> Hi all,
>
> I just would like to know, whether there exists already some effort
> on developing a COBOL compiler for Mono?
>
> yours
>   Tom
> -- 
> ----------------------------------------------------------------------
> Thomas Uhl                                      thomas.uhl at topalis.com
> Topalis AG                                    phone: +49 711 88770-111
> Lilienthalstr. 2                                fax: +49 711 88770-199
> 70825 Stuttgart-Korntal, Germany                cel: +49 170 7917711
> ----------------------------------------------------------------------
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>



From jeroen at sumatra.nl  Mon Feb 16 05:16:31 2004
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Mon, 16 Feb 2004 11:16:31 +0100
Subject: [Mono-devel-list] metadata.c asserts when building ikvm
Message-ID: <788B535AB1F9CB49BB9C229372B50ACC04C92E@LEMBU.sumatrasoftware.com>

Hi,

I'm trying to build ikvm on the current (cvs) Mono and I get the
following assertion failure:

** ERROR **: file metadata.c: line 909 (mono_metadata_decode_row_col):
assertion failed: (col < mono_metadata_table_count (bitfield))

Regards,
Jeroen


From lupus at ximian.com  Mon Feb 16 07:37:52 2004
From: lupus at ximian.com (Paolo Molaro)
Date: Mon, 16 Feb 2004 13:37:52 +0100
Subject: [Mono-devel-list] New compiler--CIL/CTS questions
In-Reply-To: <AC4E9FFE068E2147A9E0568EB7A94D2C5CA2@ibt-server1.iBankTech.NET>
References: <AC4E9FFE068E2147A9E0568EB7A94D2C5CA2@ibt-server1.iBankTech.NET>
Message-ID: <20040216123751.GJ15746@debian.org>

On 02/14/04 Chris Capel wrote:
> As to your suggested solution: the problem is that Lisp doesn't have a
> run-time/compile-time distinction. The compiler and library are the same,
> and linked to the final executable. The compiler, to be a real Lisp, has to
> assume that any function definitions are being done at run-time. I'm not sure
> I understood what you were aiming for--the compiler generating C# code?

No, he presented the pseudo code (in C#) that you would be generating at
runtime using Reflection.Emit to implement closures in the CLI.

> I assume that you meant I would emit these types at runtime. Even still,
> (though I appreciate your example) your code is little more than mapping
> lisp primitives through a consideribly dense layer of object-oriented code,
> which goes against the purported point of the CLI, which is to allow lots of
> different languages to be implemented in a common runtime environment,

Why do you care about the implementation? It's like complaining that
many functional systems are implemented through "a considerably dense layer 
of C code and assembly". The CLI offers a fairly comprehensive instruction
set and some runtime methods: using them you can implement C#, VB,
javascript, cobol, scheme, python, java etc... Sure, some of the
implementations may incur a speed hit when implemented on the CLR,
because of the need to implement special semantics that differ from the
expected ones. But the hit is most of the time reasonable if you're
willing to spend some time on the compiler (and it's repaid by being
able to easily interface with code written in other languages).
I guess what you're looking for is a runtime that implements lisp
primitives, so you can write your lisp compiler almost with no code:-)
That's nice, but you wouldn't get any interoperability and any of the
above languages would run a lot slower on that VM.
If you have proposals for how to integrate 'lisp primitives' with teh
CLR, please, present them as many people here would love to discuss the
issues. Just complaining that the CLR doesn't provide lisp primitives
(when they can most likely be easily implemented with Re.Emit...) is not
helpful (last time I checked hw lisp machines are not in much use nowadays, 
maybe there are a few reasons...).

> Oh, I dunno. It's debateable. Developing a new compiler for mono could be
> considered mono related. The fact that it would work on any CLI compliant
> runtime is incidental. Besides, I didn't see any more appropriate mono-* list,
> and I figure you people have implemented a runtime, so you must be pretty
> familiar with it.

I think mono-devel is appropriate for discussing how to make the mono and
the CLR better at handling different languages.

> > Take a look at the DynamicMethod class from Net 1.2
>  
> Thanks, Zoltan. Do you know if this class performs well enough to be used
> as the primary function-calling mechanism of a language?

Function calls are a little more costly with delegates than with direct
calls (usually 2-3 times slower for empty methods): if your functions
actually do something it's not much of an issues (of course, where it
matters, you could build smarts in your compiler to do away with the
otherhead).

lupus

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


From rkumar at novell.com  Mon Feb 16 09:35:26 2004
From: rkumar at novell.com (Ravindra)
Date: Mon, 16 Feb 2004 20:05:26 +0530
Subject: [Mono-devel-list] Re: [Mono-patches] libgdiplus/src brush.h,NONE,1.1
 solidbrush.h,NONE,1.1 ChangeLog,1.5,1.6 gdip.h,1.4,1.5 brush.c,1.2,1.3
 solidbrush.c,1.2,1.3 pen.c,1.1.1.1,1.2 stringformat.c,1.1,1.2
In-Reply-To: <1076710411.27163.21.camel@diphthong>
References: <20040213160107.9EAE894745@mono-cvs.ximian.com>
	 <1076710411.27163.21.camel@diphthong>
Message-ID: <1076942125.2424.7.camel@ravi>

Hey Duncan,
Thanks for your comments. I have elaborated more on my changes in the
changelog, for the rest of the comments, please read below.

Regards,
Ravindra

On Sat, 2004-02-14 at 03:43, Duncan Mak wrote:
> It doesn't seem right to me that we're defining Graphics here within
> brush.h. Is it possible that we make a graphics.h and include that
> instead?
I have moved GpGraphics and GpStatus back to gdip.h.

> If you include this later in the file, I think you can avoid moving the
> code around. By keeping all the general enums and structures before
> other header files, we can ensure that the name lookup will happen
> correctly.
Yes, now I have done that.

> > @@ -66,30 +68,6 @@
> > -typedef enum {
> > -    Ok = 0,
> > -    GenericError = 1,
> > -    InvalidParameter = 2,
> > -    OutOfMemory = 3,
> > -    ObjectBusy = 4,
> > -    InsufficientBuffer = 5,
> > -    NotImplemented = 6,
> > -    Win32Error = 7,
> > -    WrongState = 8,
> > -    Aborted = 9,
> > -    FileNotFound = 10,
> > -    ValueOverflow = 11,
> > -    AccessDenied = 12,
> > -    UnknownImageFormat = 13,
> > -    FontFamilyNotFound = 14,
> > -    FontStyleNotFound = 15,
> > -    NotTrueTypeFont = 16,
> > -    UnsupportedGdiplusVersion = 17,
> > -    GdiplusNotInitialized = 18,
> > -    PropertyNotFound = 19,
> > -    PropertyNotSupported = 20
> > -} GpStatus;
> 
> Why did you move this to brush.h? The GpStatus enum is the primary
> return type used by all the functions in GDI+, I don't think it is
> specific to Brush at all. Shouldn't it stay within gdip.h?
That was my mistake. I did it just to make gcc silent.

> > -typedef struct {
> > +typedef struct _Graphics {
> >  	cairo_t         *ct;
> >  	cairo_matrix_t  *copy_of_ctm;
> >  	void            *hdc;
> >  	int             hdc_busy_count;
> >  	void            *image;
> >  	int             type; 
> > -} GpGraphics;
> > +} Graphics;
> 
> Why did you have to rename this?
I renamed this because I had another typedef for the same. This is reverted now.
I have incorporated all of your comments now.



From ndrochak at gol.com  Mon Feb 16 10:27:11 2004
From: ndrochak at gol.com (Nick Drochak)
Date: Tue, 17 Feb 2004 00:27:11 +0900
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <OFEAJFLCBPECFKICJIOJGEIBNLAA.cpoole@pooleconsulting.com>
Message-ID: <E1AskeM-0002s1-QJ@smtp01.fields.gol.com>

| -----Original Message-----
| From: mono-devel-list-admin at lists.ximian.com
| [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Charlie Poole
| Sent: Monday, February 16, 2004 4:02 AM
| To: mono-devel-list at lists.ximian.com
| Subject: [Mono-devel-list] Detecting Mono
| 
| Hi All,
| 
| I'm working under Windows to develop the next release of NUnit, and I'm
| testing under Mono as well as MS .NET.
| 
| In order to be sure I'm running under mono in a particlular test
execution,

Charlie,

It'd be great if we had some attributes like "IgnoreDotNet" and "IgnoreMono"
with which we could decorate a test to avoid running tests on specific
CLR's.  My quick hack to the code would be to change
TestCaseBuilder.HasIgnoreAttribute() check for the full Ignore, or see what
runtime we are on and check for the specific attributes accordingly.

Thanks,
Nick D.



From bernard at ugsolutions.com  Mon Feb 16 11:20:50 2004
From: bernard at ugsolutions.com (Bernie Solomon)
Date: Mon, 16 Feb 2004 08:20:50 -0800
Subject: [Mono-devel-list] sparc mini
Message-ID: <001901c3f4a8$d78bc3d0$3962f486@net.plm.eds.com>

Since I've been discussing this with someone re doing some work to get it
going I was just wondering if anyone else out there is working on the Sparc
port (V8 or V9) of mini? Just trying to avoid duplication.

Thanks

Bernie



From umuff at quark.com  Mon Feb 16 11:31:33 2004
From: umuff at quark.com (Urs C Muff)
Date: Mon, 16 Feb 2004 09:31:33 -0700
Subject: [Mono-devel-list] build error on Mac OS X
Message-ID: <953283CE-609D-11D8-8C11-0003938D4EE2@quark.com>

I'm getting this error, since this morning:
ld: Undefined symbols:
_mono_arch_create_jump_trampoline

during making 'mini'.

This is new, and looks like either a partial check-in, or someone broke 
the Mac build over the weekend.

- Urs



From dedalo at ferengi.com.ar  Mon Feb 16 11:45:04 2004
From: dedalo at ferengi.com.ar (Rodrigo Roman)
Date: Mon, 16 Feb 2004 13:45:04 -0300
Subject: [Mono-devel-list] Mod_mono devel
Message-ID: <C168A0E8725B2F41BC8C1BC97EC66BA42E8359@soporte.ferengi.com.ar>

Is there any list specifically for mod_mono?
Who is taking care of its development at this moment? (apache.org page
seems really outdated)
Is there any plan to get rid of the intermediate file that comunicates
apache with mono server executable?

Thanks!


From lupus at ximian.com  Mon Feb 16 12:08:55 2004
From: lupus at ximian.com (Paolo Molaro)
Date: Mon, 16 Feb 2004 18:08:55 +0100
Subject: [Mono-devel-list] sparc mini
In-Reply-To: <001901c3f4a8$d78bc3d0$3962f486@net.plm.eds.com>
References: <001901c3f4a8$d78bc3d0$3962f486@net.plm.eds.com>
Message-ID: <20040216170855.GO15746@debian.org>

On 02/16/04 Bernie Solomon wrote:
> Since I've been discussing this with someone re doing some work to get it
> going I was just wondering if anyone else out there is working on the Sparc
> port (V8 or V9) of mini? Just trying to avoid duplication.

No one is working on it that I know. The current sparc code in cvs was based
on an old version of the ppc code and many of the sparc-specific changes
there don't look correct, so it's probably better to start from a fresh
copy.

lupus

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


From jaak at zd.com.pl  Mon Feb 16 12:08:42 2004
From: jaak at zd.com.pl (Jaroslaw Kowalski)
Date: Mon, 16 Feb 2004 18:08:42 +0100
Subject: [Mono-devel-list] Detecting Mono
References: <E1AskeM-0002s1-QJ@smtp01.fields.gol.com>
Message-ID: <002001c3f4af$87522e70$2000a8c0@jarekxp>

> It'd be great if we had some attributes like "IgnoreDotNet" and
"IgnoreMono"
> with which we could decorate a test to avoid running tests on specific
> CLR's.  My quick hack to the code would be to change
> TestCaseBuilder.HasIgnoreAttribute() check for the full Ignore, or see
what
> runtime we are on and check for the specific attributes accordingly.

How about using a textual name of the plaftorm for this purpose? The naming
schema could be adopted from NAnt, e.g:

net-1.0
net-1.1
net-1.2
netcf-1.0
sscli-1.0
mono-1.0

This way we could even employ some wildcards. Like "mono-1.*" to represent
any mono v1.x.

Same thing should apply to OSes ("platforms" in NAnt terminology). One
should be able to run the test on a particular OS or platform. For example
if your test uses filesystemwatcher it shouldn't be ran on Win95.

Some ideas below:

[Test]
[IgnoreOnFramework("net-1.0")]
void A()
{
}

[Test]
[IgnoreOnFramework("net-1.1")] // this would not run on .NET 1.1
void B()
{
}

[Test]
[IgnoreOnFramework("net-1.*")]    // this would not run on ALL .NET
platforms
void C()
{
}

[Test]
[IgnoreOnPlatform(Platform.Win32)]    // this would not run on Win32
platforms
void D()
{
}

[Test]
[IgnoreOnPlatform(Platform.Unix)]    // this would not run on Unix platforms
void E()
{
}

[Test]
[RunOnPlatform(Platform.Win32)]    // this would run only on Win32 platforms
void F()
{
}

[Test]
[RunOnFramework("mono-1.*")]    // this would run only on Mono
void G()
{
}

There are more (open source) tools that target multiple platforms/oses. I
think it would be great to have some agreement on this attribute usage. For
example in NAnt we're discussing the possibility of implementing os-specific
or platform-specific tasks,types or functions in a single codebase. We've
tentatively decided that using such attributes is a way to go.

BTW. I think that the "excluded because of the framework/os" status
shouldn't be the same thing as "ignored" in NUnit. Tests are "ignored"
because they are known to temporarily fail, while RunOn... and IgnoreOn...
means something different here.

Jarek



From chris at turchin.net  Mon Feb 16 12:18:14 2004
From: chris at turchin.net (Chris Turchin)
Date: Mon, 16 Feb 2004 09:18:14 -0800 (PST)
Subject: [Mono-devel-list] Mod_mono devel
In-Reply-To: <C168A0E8725B2F41BC8C1BC97EC66BA42E8359@soporte.ferengi.com.ar>
References: <C168A0E8725B2F41BC8C1BC97EC66BA42E8359@soporte.ferengi.com.ar>
Message-ID: <Pine.LNX.4.55.0402160853110.11057@cigale.pelemele.com>

Hi Rodrigo,

On Mon, 16 Feb 2004, Rodrigo Roman wrote:

> Is there any list specifically for mod_mono?
> Who is taking care of its development at this moment? (apache.org page
> seems really outdated)

When I file bug reports it is Gonzalo who fixes them ;-) Which is to say, you
can post bugs in bugzilla - i found this one: 52763 - from Jackson in System.Web
under Mono Class Libraries, for example :-)

> Is there any plan to get rid of the intermediate file that comunicates
> apache with mono server executable?

IIRC, this is not really a "file" but a unix socket, which is then used for
communication with the backend (see the afore mentioned bug or the FAQ for
more info). The old mod_mono did this differently (via the embedding api but I
think has some other problems and is more difficult to install).

> Thanks!

hope that helps,
--chris


From lezis at st.com.br  Mon Feb 16 12:27:25 2004
From: lezis at st.com.br (=?ISO-8859-1?Q?Leandro_Andr=E9_Zis?=)
Date: Mon, 16 Feb 2004 14:27:25 -0300
Subject: [Mono-devel-list] New compiler--CIL/CTS questions
In-Reply-To: <20040216123751.GJ15746@debian.org>
References: <AC4E9FFE068E2147A9E0568EB7A94D2C5CA2@ibt-server1.iBankTech.NET> <20040216123751.GJ15746@debian.org>
Message-ID: <4030FD7D.5010605@st.com.br>

Hi

There is a project in microsoft research called ILX that proposes 
functional extensions to IL like closures.
They implemented a Caml in .Net using ILX.

The adress is:
http://research.microsoft.com/projects/ilx/ilx.aspx

Paolo Molaro wrote:

>On 02/14/04 Chris Capel wrote:
>  
>
>>As to your suggested solution: the problem is that Lisp doesn't have a
>>run-time/compile-time distinction. The compiler and library are the same,
>>and linked to the final executable. The compiler, to be a real Lisp, has to
>>assume that any function definitions are being done at run-time. I'm not sure
>>I understood what you were aiming for--the compiler generating C# code?
>>    
>>
>
>No, he presented the pseudo code (in C#) that you would be generating at
>runtime using Reflection.Emit to implement closures in the CLI.
>
>  
>
>>I assume that you meant I would emit these types at runtime. Even still,
>>(though I appreciate your example) your code is little more than mapping
>>lisp primitives through a consideribly dense layer of object-oriented code,
>>which goes against the purported point of the CLI, which is to allow lots of
>>different languages to be implemented in a common runtime environment,
>>    
>>
>
>Why do you care about the implementation? It's like complaining that
>many functional systems are implemented through "a considerably dense layer 
>of C code and assembly". The CLI offers a fairly comprehensive instruction
>set and some runtime methods: using them you can implement C#, VB,
>javascript, cobol, scheme, python, java etc... Sure, some of the
>implementations may incur a speed hit when implemented on the CLR,
>because of the need to implement special semantics that differ from the
>expected ones. But the hit is most of the time reasonable if you're
>willing to spend some time on the compiler (and it's repaid by being
>able to easily interface with code written in other languages).
>I guess what you're looking for is a runtime that implements lisp
>primitives, so you can write your lisp compiler almost with no code:-)
>That's nice, but you wouldn't get any interoperability and any of the
>above languages would run a lot slower on that VM.
>If you have proposals for how to integrate 'lisp primitives' with teh
>CLR, please, present them as many people here would love to discuss the
>issues. Just complaining that the CLR doesn't provide lisp primitives
>(when they can most likely be easily implemented with Re.Emit...) is not
>helpful (last time I checked hw lisp machines are not in much use nowadays, 
>maybe there are a few reasons...).
>
>  
>
>>Oh, I dunno. It's debateable. Developing a new compiler for mono could be
>>considered mono related. The fact that it would work on any CLI compliant
>>runtime is incidental. Besides, I didn't see any more appropriate mono-* list,
>>and I figure you people have implemented a runtime, so you must be pretty
>>familiar with it.
>>    
>>
>
>I think mono-devel is appropriate for discussing how to make the mono and
>the CLR better at handling different languages.
>
>  
>
>>>Take a look at the DynamicMethod class from Net 1.2
>>>      
>>>
>> 
>>Thanks, Zoltan. Do you know if this class performs well enough to be used
>>as the primary function-calling mechanism of a language?
>>    
>>
>
>Function calls are a little more costly with delegates than with direct
>calls (usually 2-3 times slower for empty methods): if your functions
>actually do something it's not much of an issues (of course, where it
>matters, you could build smarts in your compiler to do away with the
>otherhead).
>
>lupus
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040216/0104f312/attachment.html 

From cpoole at pooleconsulting.com  Mon Feb 16 12:36:42 2004
From: cpoole at pooleconsulting.com (Charlie Poole)
Date: Mon, 16 Feb 2004 09:36:42 -0800
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <E1AskeM-0002s1-QJ@smtp01.fields.gol.com>
Message-ID: <002901c3f4b3$79effc40$8119fea9@siena>

Hi Nick,

We have plans for a Platform attribute in the next release - which is
how the question came up. This is not quite what you are suggesting, at
least as I envisioned it.

1. The platform is specified as os platform (e.g. linux) or a framework
(e.g. mono) or possibly a combination of the two if that seems useful.

2. The attribute is applied when loading - rather than running the tests
- so that a test for a different platform is not even seen in the tree.

3. Not having any attribute means run on all platforms.

4. A possible extension is to allow saying all platforms except mono.

Any comments on this approach?

Charlie Poole
cpoole at pooleconsulting.com

> -----Original Message-----
> From: Nick Drochak [mailto:ndrochak at gol.com] 
> Sent: Monday, February 16, 2004 7:27 AM
> To: 'Charlie Poole'; mono-devel-list at lists.ximian.com
> Subject: RE: [Mono-devel-list] Detecting Mono
> 
> 
> | -----Original Message-----
> | From: mono-devel-list-admin at lists.ximian.com
> | [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf 
> Of Charlie 
> | Poole
> | Sent: Monday, February 16, 2004 4:02 AM
> | To: mono-devel-list at lists.ximian.com
> | Subject: [Mono-devel-list] Detecting Mono
> | 
> | Hi All,
> | 
> | I'm working under Windows to develop the next release of NUnit, and 
> | I'm testing under Mono as well as MS .NET.
> | 
> | In order to be sure I'm running under mono in a particlular test
> execution,
> 
> Charlie,
> 
> It'd be great if we had some attributes like "IgnoreDotNet" 
> and "IgnoreMono" with which we could decorate a test to avoid 
> running tests on specific CLR's.  My quick hack to the code 
> would be to change
> TestCaseBuilder.HasIgnoreAttribute() check for the full 
> Ignore, or see what runtime we are on and check for the 
> specific attributes accordingly.
> 
> Thanks,
> Nick D.
> 
> 




From tiago.lima at vianw.pt  Mon Feb 16 12:52:01 2004
From: tiago.lima at vianw.pt (Tiago Lima)
Date: Mon, 16 Feb 2004 17:52:01 +0000
Subject: [Mono-devel-list] Monotalk rises !
Message-ID: <200402161752.01354.tiago.lima@vianw.pt>

Hi,

I guess I could get monotalk to work with the new gtk-sharp 0.16 version... 
well it works fine but it could be better... :)
Here is the patch...

Aha ! Now the GtkSourceView.dll is browsable...
Next step is gtksourceview documentation... :)

	Tiago Lima
-------------- next part --------------
A non-text attachment was scrubbed...
Name: monotalk.diff
Type: text/x-diff
Size: 5180 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040216/5188acd0/attachment.bin 

From cpoole at pooleconsulting.com  Mon Feb 16 12:52:48 2004
From: cpoole at pooleconsulting.com (Charlie Poole)
Date: Mon, 16 Feb 2004 09:52:48 -0800
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <002001c3f4af$87522e70$2000a8c0@jarekxp>
Message-ID: <002c01c3f4b5$b42d9550$8119fea9@siena>

Hi Jarek,

Elaborating on my earlier reply to Nick - Nunit itself /is/ one of those
apps that runs on multiple platforms and needs this facility. Currently,
we detect Win98 /in/ the test for AssemblyWatcher and just pass it if we
are on that platform. This seems better to me than ignoring, as yellow
is just another kind of red to me. :-)

That's where the logic comes from for simply leaving things out of the
test tree if they are for some other platform: they can never be run,
and none of the three colors really makes sense.

Now that I think of it, an ignore type check is probably at least as
common as a positive check. The syntax I was imagining was something
like:

	[Platform("net-1.0,net-1.1")]

Perhaps an alternative would be to also support

	[Platform( Exclude="mono" )]

Charlie Poole
cpoole at pooleconsulting.com



> -----Original Message-----
> From: mono-devel-list-admin at lists.ximian.com 
> [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of 
> Jaroslaw Kowalski
> Sent: Monday, February 16, 2004 9:09 AM
> To: Nick Drochak; 'Charlie Poole'; mono-devel-list at lists.ximian.com
> Cc: ! nant
> Subject: Re: [Mono-devel-list] Detecting Mono
> 
> 
> > It'd be great if we had some attributes like "IgnoreDotNet" and
> "IgnoreMono"
> > with which we could decorate a test to avoid running tests 
> on specific 
> > CLR's.  My quick hack to the code would be to change
> > TestCaseBuilder.HasIgnoreAttribute() check for the full 
> Ignore, or see
> what
> > runtime we are on and check for the specific attributes accordingly.
> 
> How about using a textual name of the plaftorm for this 
> purpose? The naming schema could be adopted from NAnt, e.g:
> 
> net-1.0
> net-1.1
> net-1.2
> netcf-1.0
> sscli-1.0
> mono-1.0
> 
> This way we could even employ some wildcards. Like "mono-1.*" 
> to represent any mono v1.x.
> 
> Same thing should apply to OSes ("platforms" in NAnt 
> terminology). One should be able to run the test on a 
> particular OS or platform. For example if your test uses 
> filesystemwatcher it shouldn't be ran on Win95.
> 
> Some ideas below:
> 
> [Test]
> [IgnoreOnFramework("net-1.0")]
> void A()
> {
> }
> 
> [Test]
> [IgnoreOnFramework("net-1.1")] // this would not run on .NET 
> 1.1 void B() { }
> 
> [Test]
> [IgnoreOnFramework("net-1.*")]    // this would not run on ALL .NET
> platforms
> void C()
> {
> }
> 
> [Test]
> [IgnoreOnPlatform(Platform.Win32)]    // this would not run on Win32
> platforms
> void D()
> {
> }
> 
> [Test]
> [IgnoreOnPlatform(Platform.Unix)]    // this would not run on 
> Unix platforms
> void E()
> {
> }
> 
> [Test]
> [RunOnPlatform(Platform.Win32)]    // this would run only on 
> Win32 platforms
> void F()
> {
> }
> 
> [Test]
> [RunOnFramework("mono-1.*")]    // this would run only on Mono
> void G()
> {
> }
> 
> There are more (open source) tools that target multiple 
> platforms/oses. I think it would be great to have some 
> agreement on this attribute usage. For example in NAnt we're 
> discussing the possibility of implementing os-specific or 
> platform-specific tasks,types or functions in a single 
> codebase. We've tentatively decided that using such 
> attributes is a way to go.
> 
> BTW. I think that the "excluded because of the framework/os" 
> status shouldn't be the same thing as "ignored" in NUnit. 
> Tests are "ignored" because they are known to temporarily 
> fail, while RunOn... and IgnoreOn... means something different here.
> 
> Jarek
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com 
> http://lists.ximian.com/mailman/listinfo/mono-> devel-list
> 




From bmaurer at users.sourceforge.net  Mon Feb 16 13:23:03 2004
From: bmaurer at users.sourceforge.net (Ben Maurer)
Date: Mon, 16 Feb 2004 13:23:03 -0500
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <002c01c3f4b5$b42d9550$8119fea9@siena>
References: <002c01c3f4b5$b42d9550$8119fea9@siena>
Message-ID: <1076955783.17910.48.camel@Ben>

I really, really dont think this is the way to go.

Software should not work like this:
"if you are running on windows, pressing `foo' will result in blah. As
an exception, on windows 98, nothing will happen. On linux, it will do
bar if it is running on RedHat 9 or Fedora, but will do baz if it is
running on any other linux system."

You might have a feature that is implemented in different ways on
different systems -- for example, maybe on Windows you store a key in
the registry, but on Linux you store it in a dot file.

In the above case, your test should *not* look like this:

[Test] [Platform ("!linux")]
public void TestWinSettings ()
{
    Settings.Store (foo, bar);
    AssertEquals (Registry.Get (foo), bar);
}


[Test] [Platform ("linux")]
public void TestLinuxSettings ()
{
    Settings.Store (foo, bar);
    AssertEquals (GConf.Get (foo), bar);
}

Rather, you should write your test like:

[Test]
public void TestSettings ()
{
    Setttings.Store (foo, bar);
    AssertEquals (Settings.Get (foo), bar);
}

You should be running the tests on the *result* not the implementation.

Now, I realize some platforms will not support something specifc. Lets
say you want to make NUnit runnable as a service (eg, so that you could
run tests in the background). Right now, Mono does not really support
this (you can work around it via some command line stuff, but we do not
support the api). Rather then testing for *mono* you should test for the
*feature*. In your code, you should write something like:

#if CAN_RUN_AS_SERVICE
   // APIs for running as service
#endif

In your tests, you can write:

#if CAN_RUN_AS_SERVICE
  // my service test suite
#endif

You could even have these tests in a special assembly that you only used
if the service feature was enabled.

One other problem I realize exists is that you might know a specific
feature fails right now under mono. Rather than not running the test, I
would rather see a feature where you could write:

[Test]
[Note ("This test fails on Mono, see Ximian bugzilla #12345")]
public void MyTest ()
{
}

You could allow someone to also annotate that with:
[KnownFailSet ("MONO_FAILURES")]

Then, when run under Mono you can do:

nunit-however-you-invoke-the-thing /knownfailset:MONO_FAILURES

The program could then still give you the nice Red/Green light.

This actually has nice uses for normal usage. For example, lets say I am
programming feature `Foo'. What I can do is to add 20 tests that I know
will fail. Then I can build up the Foo feature. As I am writing code, I
can test to make sure I did not cause any regressions. Before, without
this annotation, I would have to count the number of failures, and make
sure no regressions were happening. With this sort of markup, I could
avoid that and just get a red/green. As I am going, i can remove the tag
from sub-components that I have implemented, to make sure I am not
regressing on my newly written code.

Having different tests for different platforms implies that you intend
for the program to work differently in each platform. This isnt really
consistant with having a program that is really cross platform.

On Mon, 2004-02-16 at 12:52, Charlie Poole wrote:
> Hi Jarek,
> 
> Elaborating on my earlier reply to Nick - Nunit itself /is/ one of those
> apps that runs on multiple platforms and needs this facility. Currently,
> we detect Win98 /in/ the test for AssemblyWatcher and just pass it if we
> are on that platform. This seems better to me than ignoring, as yellow
> is just another kind of red to me. :-)
> 
> That's where the logic comes from for simply leaving things out of the
> test tree if they are for some other platform: they can never be run,
> and none of the three colors really makes sense.
> 
> Now that I think of it, an ignore type check is probably at least as
> common as a positive check. The syntax I was imagining was something
> like:
> 
> 	[Platform("net-1.0,net-1.1")]
> 
> Perhaps an alternative would be to also support
> 
> 	[Platform( Exclude="mono" )]
> 
> Charlie Poole
> cpoole at pooleconsulting.com
> 
> 
> 
> > -----Original Message-----
> > From: mono-devel-list-admin at lists.ximian.com 
> > [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of 
> > Jaroslaw Kowalski
> > Sent: Monday, February 16, 2004 9:09 AM
> > To: Nick Drochak; 'Charlie Poole'; mono-devel-list at lists.ximian.com
> > Cc: ! nant
> > Subject: Re: [Mono-devel-list] Detecting Mono
> > 
> > 
> > > It'd be great if we had some attributes like "IgnoreDotNet" and
> > "IgnoreMono"
> > > with which we could decorate a test to avoid running tests 
> > on specific 
> > > CLR's.  My quick hack to the code would be to change
> > > TestCaseBuilder.HasIgnoreAttribute() check for the full 
> > Ignore, or see
> > what
> > > runtime we are on and check for the specific attributes accordingly.
> > 
> > How about using a textual name of the plaftorm for this 
> > purpose? The naming schema could be adopted from NAnt, e.g:
> > 
> > net-1.0
> > net-1.1
> > net-1.2
> > netcf-1.0
> > sscli-1.0
> > mono-1.0
> > 
> > This way we could even employ some wildcards. Like "mono-1.*" 
> > to represent any mono v1.x.
> > 
> > Same thing should apply to OSes ("platforms" in NAnt 
> > terminology). One should be able to run the test on a 
> > particular OS or platform. For example if your test uses 
> > filesystemwatcher it shouldn't be ran on Win95.
> > 
> > Some ideas below:
> > 
> > [Test]
> > [IgnoreOnFramework("net-1.0")]
> > void A()
> > {
> > }
> > 
> > [Test]
> > [IgnoreOnFramework("net-1.1")] // this would not run on .NET 
> > 1.1 void B() { }
> > 
> > [Test]
> > [IgnoreOnFramework("net-1.*")]    // this would not run on ALL .NET
> > platforms
> > void C()
> > {
> > }
> > 
> > [Test]
> > [IgnoreOnPlatform(Platform.Win32)]    // this would not run on Win32
> > platforms
> > void D()
> > {
> > }
> > 
> > [Test]
> > [IgnoreOnPlatform(Platform.Unix)]    // this would not run on 
> > Unix platforms
> > void E()
> > {
> > }
> > 
> > [Test]
> > [RunOnPlatform(Platform.Win32)]    // this would run only on 
> > Win32 platforms
> > void F()
> > {
> > }
> > 
> > [Test]
> > [RunOnFramework("mono-1.*")]    // this would run only on Mono
> > void G()
> > {
> > }
> > 
> > There are more (open source) tools that target multiple 
> > platforms/oses. I think it would be great to have some 
> > agreement on this attribute usage. For example in NAnt we're 
> > discussing the possibility of implementing os-specific or 
> > platform-specific tasks,types or functions in a single 
> > codebase. We've tentatively decided that using such 
> > attributes is a way to go.
> > 
> > BTW. I think that the "excluded because of the framework/os" 
> > status shouldn't be the same thing as "ignored" in NUnit. 
> > Tests are "ignored" because they are known to temporarily 
> > fail, while RunOn... and IgnoreOn... means something different here.
> > 
> > Jarek
> > 
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com 
> > http://lists.ximian.com/mailman/listinfo/mono-> devel-list
> > 
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From ndhameja at panaceasoftware.com  Mon Feb 16 14:53:35 2004
From: ndhameja at panaceasoftware.com (Namit Dhameja)
Date: Mon, 16 Feb 2004 11:53:35 -0800
Subject: [Mono-devel-list] string in case statement cannot > 64 chars
Message-ID: <026901c3f4c6$90214fb0$7001a8c0@Namitws>

Hi all,
In case statements, the maximum length of the string is 64 bytes. That is,
<-------------------------------------------------------------->
 strName = "{http://schemas.xmlsoap.org/ws/2003/03/business-process/}partnerLinks";
 switch (strName)
 {
 case "{http://schemas.xmlsoap.org/ws/2003/03/business-process/}partnerLinks":
            System.Console.WriteLine ("Found it"); break;
 default:  System.Console.WriteLine ("Not Found it"); break;
 }
<-------------------------------------------------------------------------------->
 
 This code will print "Not Found it".
 
 On .Net the above code works just fine. I am not aware of the maximum string
 length possible under .Net. If 64 characters is indeed the specification and
 not a bug than perhaps the compiler should issue some sort of warning about it.
 Maybe it would be a better idea to make the string length the same as microsoft .Net.

 -Best Regards,
 Namit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040216/b115db90/attachment.html 

From bmaurer at users.sourceforge.net  Mon Feb 16 15:28:25 2004
From: bmaurer at users.sourceforge.net (Ben Maurer)
Date: Mon, 16 Feb 2004 15:28:25 -0500
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <003101c3f4be$bc9aefe0$8119fea9@siena>
References: <003101c3f4be$bc9aefe0$8119fea9@siena>
Message-ID: <1076961172.17910.66.camel@Ben>

On Mon, 2004-02-16 at 13:57, Charlie Poole wrote:
> So - using your example - if an application stored settings somewhere it
> should have acceptance tests to determine that settings are saved and
> stored correctly. The test should work whether the registry or a file or
> some other approach is used to saving the settings.
> 
> However, the same app would probably have a unit test for it's registry
> access code. That test would only be run in the win32 environment. If
> you're not heavily into unit testing and particulary TDD, this may not
> make sense. However, a large part of the Nunit user community is into
> those things and so are the developers. :-)

I don't really think that is valid. Tests should probe how the code
works on the *outside* not the inside. For example, you would not write
a test that used Reflection to get the fields of a class and test if
they were set to the right value. You would use a publicly exposed API.
Likewise, you shouldnt go about probing the storage format of your
settings.

Tests really shouldnt assert things about how the code looks inside.

I can see the argument here in a setup where, say, you could use a MySQL
db or a MSSQL db and were expected to interop with other programs.
However, I think that the best way to do this case is just to build
seperate assemblies for each provider and only run the tests on
platforms where the provider is supported. However, you dont need to
change NUnit to support this.

> Your thoughts on known failures are interesting. It had not occurred to
> me that there may be a difference between something that doesn't work on
> a platform - and never will - and something that is expected (hoped?) to
> work some time in the future. For some projects, the distinction is not
> important but it probably is for others. I'll have to think on that.

Actually, I am not thinking of this in terms of platforms, I am talking
about known failures in general. I really dont like [Ignore] because it
makes you *not* run the test.

You could extend this to allowing the decleration of groups by saying:

[Group ("FILED_BUGS")]
[Note ("see bug#12345"]
..

And then run on the command line like:

nunit /ignore-group:FILED_BUGS

or you could do:

nunit /known-fail:FILED_BUGS
(so maybe you would get a gold star or something if one of the known
failures was made green ;-).

-- Ben



From richard.torkar at htu.se  Mon Feb 16 15:55:06 2004
From: richard.torkar at htu.se (Richard Torkar)
Date: Mon, 16 Feb 2004 21:55:06 +0100
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <1076961172.17910.66.camel@Ben>
References: <003101c3f4be$bc9aefe0$8119fea9@siena>
	 <1076961172.17910.66.camel@Ben>
Message-ID: <1076964906.31360.4.camel@localhost>

On Mon, 2004-02-16 at 21:28, Ben Maurer wrote:
> On Mon, 2004-02-16 at 13:57, Charlie Poole wrote:
> > However, the same app would probably have a unit test for it's registry
> > access code. That test would only be run in the win32 environment. If
> > you're not heavily into unit testing and particulary TDD, this may not
> > make sense. However, a large part of the Nunit user community is into
> > those things and so are the developers. :-)
> 
> I don't really think that is valid. Tests should probe how the code
> works on the *outside* not the inside. For example, you would not write
> a test that used Reflection to get the fields of a class and test if
> they were set to the right value. You would use a publicly exposed API.
> Likewise, you shouldnt go about probing the storage format of your
> settings.
> 
> Tests really shouldnt assert things about how the code looks inside.

Depends on what test methodology you use. 

What you are talking about Ben is a pure black-box approach. If that is
the case - then sure! But if you have a white-box approach or a mixture
between bb and wb then it is very valid to "look inside the box".

Everyone who has tested anything more than a simple Hello World
application knows that a pure black-box approache does not catch all
faults. Usually one uses several different methodologies and techniques
- but you know that Ben ;-)


/Richard



From cpoole at pooleconsulting.com  Mon Feb 16 16:23:00 2004
From: cpoole at pooleconsulting.com (Charlie Poole)
Date: Mon, 16 Feb 2004 13:23:00 -0800
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <1076961172.17910.66.camel@Ben>
Message-ID: <004401c3f4d3$0e874a10$8119fea9@siena>

Ben,

Following the particular theory of testing you describe, you would
definitely not have a need for this feature. But some people follow
other approaches. For example, I like to do TDD and to only write unit
tests insofar as they are needed to drive the design. After that, I
focus on acceptance tests. But other folks continue to work at the unit
test level until they have full "coverage" - in whatever sense it
matters to them. I could discuss this at greater length, but I'm afraid
that it's not particularly on topic here.

Open software like Nunit - or Mono for that matter - needs to satisfy
the people who use it. Arguments like "Nobody should want this"
generally lose out in the face of folks who actually have a use for a
feature, particlarly if one of them is prepared to implement it.

Charlie Poole
cpoole at pooleconsulting.com

> -----Original Message-----
> From: Ben Maurer [mailto:bmaurer at users.sourceforge.net] 
> Sent: Monday, February 16, 2004 12:28 PM
> To: Charlie Poole
> Cc: Mono Development
> Subject: RE: [Mono-devel-list] Detecting Mono
> 
> 
> On Mon, 2004-02-16 at 13:57, Charlie Poole wrote:
> > So - using your example - if an application stored settings 
> somewhere 
> > it should have acceptance tests to determine that settings 
> are saved 
> > and stored correctly. The test should work whether the 
> registry or a 
> > file or some other approach is used to saving the settings.
> > 
> > However, the same app would probably have a unit test for it's 
> > registry access code. That test would only be run in the win32 
> > environment. If you're not heavily into unit testing and 
> particulary 
> > TDD, this may not make sense. However, a large part of the 
> Nunit user 
> > community is into those things and so are the developers. :-)
> 
> I don't really think that is valid. Tests should probe how 
> the code works on the *outside* not the inside. For example, 
> you would not write a test that used Reflection to get the 
> fields of a class and test if they were set to the right 
> value. You would use a publicly exposed API. Likewise, you 
> shouldnt go about probing the storage format of your settings.
> 
> Tests really shouldnt assert things about how the code looks inside.
> 
> I can see the argument here in a setup where, say, you could 
> use a MySQL db or a MSSQL db and were expected to interop 
> with other programs. However, I think that the best way to do 
> this case is just to build seperate assemblies for each 
> provider and only run the tests on platforms where the 
> provider is supported. However, you dont need to change NUnit 
> to support this.
> 
> > Your thoughts on known failures are interesting. It had not 
> occurred 
> > to me that there may be a difference between something that doesn't 
> > work on a platform - and never will - and something that is 
> expected 
> > (hoped?) to work some time in the future. For some projects, the 
> > distinction is not important but it probably is for others. 
> I'll have 
> > to think on that.
> 
> Actually, I am not thinking of this in terms of platforms, I 
> am talking about known failures in general. I really dont 
> like [Ignore] because it makes you *not* run the test.
> 
> You could extend this to allowing the decleration of groups by saying:
> 
> [Group ("FILED_BUGS")]
> [Note ("see bug#12345"]
> ..
> 
> And then run on the command line like:
> 
> nunit /ignore-group:FILED_BUGS
> 
> or you could do:
> 
> nunit /known-fail:FILED_BUGS
> (so maybe you would get a gold star or something if one of 
> the known failures was made green ;-).
> 
> -- Ben
> 
> 




From bmaurer at users.sourceforge.net  Mon Feb 16 17:05:29 2004
From: bmaurer at users.sourceforge.net (Ben Maurer)
Date: Mon, 16 Feb 2004 17:05:29 -0500
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <004401c3f4d3$0e874a10$8119fea9@siena>
References: <004401c3f4d3$0e874a10$8119fea9@siena>
Message-ID: <1076969128.17910.83.camel@Ben>

Well, the problem is that you are not *really* trying to detect the
operating system here.

For example, Mono could be running on Windows, in which case you would
be able to use the registry. You could have it running on PPC, do you
know what to do then? What if we are running on Wine and we decide to
make an interop layer with the windows registry? What if it is running
on Rotor, do you know how to detect that?

By detecting the runtime, you are not getting an answer to the question
you are trying to ask which is `can this operating system do the
registry'.

So rather than seeing:

[Platform ("! Mono")]

I would rather see:

[RequiresFeature ("Registry")]

I realize this takes a little bit of time to maintain, but if you are
maintaining xplatform software, it is probably not that big of an issue
in the scope of things.

I would also encourge something like the `known failures' feature to
keep peole from shoving bugs in the runtime under the rug.

Testing for the platform is really just making a guess about feature
support, which is what it seems you are really asking for. I would
really rather see NUnit provide support for and encourge users to make
use of the real solution, which is to actually test for the features in
question.

-- Ben

On Mon, 2004-02-16 at 16:23, Charlie Poole wrote:
> Ben,
> 
> Following the particular theory of testing you describe, you would
> definitely not have a need for this feature. But some people follow
> other approaches. For example, I like to do TDD and to only write unit
> tests insofar as they are needed to drive the design. After that, I
> focus on acceptance tests. But other folks continue to work at the unit
> test level until they have full "coverage" - in whatever sense it
> matters to them. I could discuss this at greater length, but I'm afraid
> that it's not particularly on topic here.
> 
> Open software like Nunit - or Mono for that matter - needs to satisfy
> the people who use it. Arguments like "Nobody should want this"
> generally lose out in the face of folks who actually have a use for a
> feature, particlarly if one of them is prepared to implement it.
> 
> Charlie Poole
> cpoole at pooleconsulting.com
> 
> > -----Original Message-----
> > From: Ben Maurer [mailto:bmaurer at users.sourceforge.net] 
> > Sent: Monday, February 16, 2004 12:28 PM
> > To: Charlie Poole
> > Cc: Mono Development
> > Subject: RE: [Mono-devel-list] Detecting Mono
> > 
> > 
> > On Mon, 2004-02-16 at 13:57, Charlie Poole wrote:
> > > So - using your example - if an application stored settings 
> > somewhere 
> > > it should have acceptance tests to determine that settings 
> > are saved 
> > > and stored correctly. The test should work whether the 
> > registry or a 
> > > file or some other approach is used to saving the settings.
> > > 
> > > However, the same app would probably have a unit test for it's 
> > > registry access code. That test would only be run in the win32 
> > > environment. If you're not heavily into unit testing and 
> > particulary 
> > > TDD, this may not make sense. However, a large part of the 
> > Nunit user 
> > > community is into those things and so are the developers. :-)
> > 
> > I don't really think that is valid. Tests should probe how 
> > the code works on the *outside* not the inside. For example, 
> > you would not write a test that used Reflection to get the 
> > fields of a class and test if they were set to the right 
> > value. You would use a publicly exposed API. Likewise, you 
> > shouldnt go about probing the storage format of your settings.
> > 
> > Tests really shouldnt assert things about how the code looks inside.
> > 
> > I can see the argument here in a setup where, say, you could 
> > use a MySQL db or a MSSQL db and were expected to interop 
> > with other programs. However, I think that the best way to do 
> > this case is just to build seperate assemblies for each 
> > provider and only run the tests on platforms where the 
> > provider is supported. However, you dont need to change NUnit 
> > to support this.
> > 
> > > Your thoughts on known failures are interesting. It had not 
> > occurred 
> > > to me that there may be a difference between something that doesn't 
> > > work on a platform - and never will - and something that is 
> > expected 
> > > (hoped?) to work some time in the future. For some projects, the 
> > > distinction is not important but it probably is for others. 
> > I'll have 
> > > to think on that.
> > 
> > Actually, I am not thinking of this in terms of platforms, I 
> > am talking about known failures in general. I really dont 
> > like [Ignore] because it makes you *not* run the test.
> > 
> > You could extend this to allowing the decleration of groups by saying:
> > 
> > [Group ("FILED_BUGS")]
> > [Note ("see bug#12345"]
> > ..
> > 
> > And then run on the command line like:
> > 
> > nunit /ignore-group:FILED_BUGS
> > 
> > or you could do:
> > 
> > nunit /known-fail:FILED_BUGS
> > (so maybe you would get a gold star or something if one of 
> > the known failures was made green ;-).
> > 
> > -- Ben
> > 
> > 
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From cpoole at pooleconsulting.com  Mon Feb 16 17:37:54 2004
From: cpoole at pooleconsulting.com (Charlie Poole)
Date: Mon, 16 Feb 2004 14:37:54 -0800
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <1076969128.17910.83.camel@Ben>
Message-ID: <004601c3f4dd$88847e00$8119fea9@siena>

Actually, I'm detecting something called "platform" which is some
combination of OS and framework. As the designer of a piece of software,
I may have decided to make use of certain facilities on certain
platforms, other facilities on other platforms. If so, I need to detect
the platforms.

OTOH, if I've decided to dynamically check for the presence of a
feature, the application itself should do that and should recover from
the absence of the feature appropriately. In that case, my tests will
need some moderately complex logic to determine whether they can run in
the environment or not.

I think it all comes down to what works well for the design of a
particular application. 

By the way, your [RequiresFeature("Registry")] can be simulated manually
using the latest Nunit code by using [Category("Registry")] and then
including or excluding that category from the test run.

Charlie Poole
cpoole at pooleconsulting.com

> -----Original Message-----
> From: mono-devel-list-admin at lists.ximian.com 
> [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of 
> Ben Maurer
> Sent: Monday, February 16, 2004 2:05 PM
> To: Charlie Poole
> Cc: 'Mono Development'
> Subject: RE: [Mono-devel-list] Detecting Mono
> 
> 
> Well, the problem is that you are not *really* trying to 
> detect the operating system here.
> 
> For example, Mono could be running on Windows, in which case 
> you would be able to use the registry. You could have it 
> running on PPC, do you know what to do then? What if we are 
> running on Wine and we decide to make an interop layer with 
> the windows registry? What if it is running on Rotor, do you 
> know how to detect that?
> 
> By detecting the runtime, you are not getting an answer to 
> the question you are trying to ask which is `can this 
> operating system do the registry'.
> 
> So rather than seeing:
> 
> [Platform ("! Mono")]
> 
> I would rather see:
> 
> [RequiresFeature ("Registry")]
> 
> I realize this takes a little bit of time to maintain, but if 
> you are maintaining xplatform software, it is probably not 
> that big of an issue in the scope of things.
> 
> I would also encourge something like the `known failures' 
> feature to keep peole from shoving bugs in the runtime under the rug.
> 
> Testing for the platform is really just making a guess about 
> feature support, which is what it seems you are really asking 
> for. I would really rather see NUnit provide support for and 
> encourge users to make use of the real solution, which is to 
> actually test for the features in question.
> 
> -- Ben
> 
> On Mon, 2004-02-16 at 16:23, Charlie Poole wrote:
> > Ben,
> > 
> > Following the particular theory of testing you describe, you would 
> > definitely not have a need for this feature. But some people follow 
> > other approaches. For example, I like to do TDD and to only 
> write unit 
> > tests insofar as they are needed to drive the design. After that, I 
> > focus on acceptance tests. But other folks continue to work at the 
> > unit test level until they have full "coverage" - in 
> whatever sense it 
> > matters to them. I could discuss this at greater length, but I'm 
> > afraid that it's not particularly on topic here.
> > 
> > Open software like Nunit - or Mono for that matter - needs 
> to satisfy 
> > the people who use it. Arguments like "Nobody should want this" 
> > generally lose out in the face of folks who actually have a 
> use for a 
> > feature, particlarly if one of them is prepared to implement it.
> > 
> > Charlie Poole
> > cpoole at pooleconsulting.com
> > 
> > > -----Original Message-----
> > > From: Ben Maurer [mailto:bmaurer at users.sourceforge.net]
> > > Sent: Monday, February 16, 2004 12:28 PM
> > > To: Charlie Poole
> > > Cc: Mono Development
> > > Subject: RE: [Mono-devel-list] Detecting Mono
> > > 
> > > 
> > > On Mon, 2004-02-16 at 13:57, Charlie Poole wrote:
> > > > So - using your example - if an application stored settings
> > > somewhere
> > > > it should have acceptance tests to determine that settings
> > > are saved
> > > > and stored correctly. The test should work whether the
> > > registry or a
> > > > file or some other approach is used to saving the settings.
> > > > 
> > > > However, the same app would probably have a unit test for it's
> > > > registry access code. That test would only be run in the win32 
> > > > environment. If you're not heavily into unit testing and 
> > > particulary
> > > > TDD, this may not make sense. However, a large part of the
> > > Nunit user
> > > > community is into those things and so are the developers. :-)
> > > 
> > > I don't really think that is valid. Tests should probe how
> > > the code works on the *outside* not the inside. For example, 
> > > you would not write a test that used Reflection to get the 
> > > fields of a class and test if they were set to the right 
> > > value. You would use a publicly exposed API. Likewise, you 
> > > shouldnt go about probing the storage format of your settings.
> > > 
> > > Tests really shouldnt assert things about how the code 
> looks inside.
> > > 
> > > I can see the argument here in a setup where, say, you could
> > > use a MySQL db or a MSSQL db and were expected to interop 
> > > with other programs. However, I think that the best way to do 
> > > this case is just to build seperate assemblies for each 
> > > provider and only run the tests on platforms where the 
> > > provider is supported. However, you dont need to change NUnit 
> > > to support this.
> > > 
> > > > Your thoughts on known failures are interesting. It had not
> > > occurred
> > > > to me that there may be a difference between something that 
> > > > doesn't
> > > > work on a platform - and never will - and something that is 
> > > expected
> > > > (hoped?) to work some time in the future. For some projects, the
> > > > distinction is not important but it probably is for others. 
> > > I'll have
> > > > to think on that.
> > > 
> > > Actually, I am not thinking of this in terms of platforms, I
> > > am talking about known failures in general. I really dont 
> > > like [Ignore] because it makes you *not* run the test.
> > > 
> > > You could extend this to allowing the decleration of groups by 
> > > saying:
> > > 
> > > [Group ("FILED_BUGS")]
> > > [Note ("see bug#12345"]
> > > ..
> > > 
> > > And then run on the command line like:
> > > 
> > > nunit /ignore-group:FILED_BUGS
> > > 
> > > or you could do:
> > > 
> > > nunit /known-fail:FILED_BUGS
> > > (so maybe you would get a gold star or something if one of
> > > the known failures was made green ;-).
> > > 
> > > -- Ben
> > > 
> > > 
> > 
> > 
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com 
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com 
> http://lists.ximian.com/mailman/listinfo/mono-> devel-list
> 




From umuff at QUARK.com  Mon Feb 16 18:16:50 2004
From: umuff at QUARK.com (Urs Muff)
Date: Mon, 16 Feb 2004 16:16:50 -0700
Subject: FW: [Mono-devel-list] build error on Mac OS X
Message-ID: <A70185F8290B6E4B92F848A60D21481D18E8AE@usmxsrv1.quark.com>

<vargaz> umuff71: fixed in cvs. thanks for reporting it.
<umuff71> vargaz: when did that get checked in?  just now? 
<vargaz> yes
<vargaz> umuff71: now

And it compiles/links now, but when running mono:
** ERROR **: file tramp-ppc.c: line 485 (mono_arch_create_jump_trampoline):
should not be reached

- Urs

-----Original Message-----
From: mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Urs C Muff
Sent: Monday, February 16, 2004 9:32 AM
To: mono-devel-list at ximian.com
Subject: [Mono-devel-list] build error on Mac OS X

I'm getting this error, since this morning:
ld: Undefined symbols:
_mono_arch_create_jump_trampoline

during making 'mini'.

This is new, and looks like either a partial check-in, or someone broke 
the Mac build over the weekend.

- Urs

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


From bmaurer at users.sourceforge.net  Mon Feb 16 19:24:46 2004
From: bmaurer at users.sourceforge.net (Ben Maurer)
Date: Mon, 16 Feb 2004 19:24:46 -0500
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <004601c3f4dd$88847e00$8119fea9@siena>
References: <004601c3f4dd$88847e00$8119fea9@siena>
Message-ID: <1076972127.17910.99.camel@Ben>

Well, it sounds like that Category is really the way to go. So you can
do:

[Category ("WIN_ONLY")]

Then, in whatever script you use to run nunit (or, if you are doing the
tests manually, somehow via the GUI), you can detect windows.

Really, the harness that you are running the tests in (eg, a shell
script) is going to know best what kind of environment it is putting the
test under. Any sort of autodetection is really a guess at the exact
platform. As well, it is very possible that the trait you try to test
for will change in a future version. 

As a side note, what do you need to test the existance of a framework
for? The only use I am able to see for this is the ignorring of a test
that fails on a specific framework due to a bug. I would really rather
see this implemented with [KnownFailure] sort of thing. The
[KnownFailure] concept actually has alot of use in other contexts (eg,
known not to work until the blah team finishes foo feature). 

Really, the only reason to test for a framework should be if you are
integrating with it (for example, a profiling tool that makes custom
calls for each fx). If that is not a case, it would be better to have a
bug filed in our bugzilla and an annotation made to the test case.

-- Ben

On Mon, 2004-02-16 at 17:37, Charlie Poole wrote:
> Actually, I'm detecting something called "platform" which is some
> combination of OS and framework. As the designer of a piece of software,
> I may have decided to make use of certain facilities on certain
> platforms, other facilities on other platforms. If so, I need to detect
> the platforms.
> 
> OTOH, if I've decided to dynamically check for the presence of a
> feature, the application itself should do that and should recover from
> the absence of the feature appropriately. In that case, my tests will
> need some moderately complex logic to determine whether they can run in
> the environment or not.
> 
> I think it all comes down to what works well for the design of a
> particular application. 
> 
> By the way, your [RequiresFeature("Registry")] can be simulated manually
> using the latest Nunit code by using [Category("Registry")] and then
> including or excluding that category from the test run.
> 
> Charlie Poole
> cpoole at pooleconsulting.com
> 
> > -----Original Message-----
> > From: mono-devel-list-admin at lists.ximian.com 
> > [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of 
> > Ben Maurer
> > Sent: Monday, February 16, 2004 2:05 PM
> > To: Charlie Poole
> > Cc: 'Mono Development'
> > Subject: RE: [Mono-devel-list] Detecting Mono
> > 
> > 
> > Well, the problem is that you are not *really* trying to 
> > detect the operating system here.
> > 
> > For example, Mono could be running on Windows, in which case 
> > you would be able to use the registry. You could have it 
> > running on PPC, do you know what to do then? What if we are 
> > running on Wine and we decide to make an interop layer with 
> > the windows registry? What if it is running on Rotor, do you 
> > know how to detect that?
> > 
> > By detecting the runtime, you are not getting an answer to 
> > the question you are trying to ask which is `can this 
> > operating system do the registry'.
> > 
> > So rather than seeing:
> > 
> > [Platform ("! Mono")]
> > 
> > I would rather see:
> > 
> > [RequiresFeature ("Registry")]
> > 
> > I realize this takes a little bit of time to maintain, but if 
> > you are maintaining xplatform software, it is probably not 
> > that big of an issue in the scope of things.
> > 
> > I would also encourge something like the `known failures' 
> > feature to keep peole from shoving bugs in the runtime under the rug.
> > 
> > Testing for the platform is really just making a guess about 
> > feature support, which is what it seems you are really asking 
> > for. I would really rather see NUnit provide support for and 
> > encourge users to make use of the real solution, which is to 
> > actually test for the features in question.
> > 
> > -- Ben
> > 
> > On Mon, 2004-02-16 at 16:23, Charlie Poole wrote:
> > > Ben,
> > > 
> > > Following the particular theory of testing you describe, you would 
> > > definitely not have a need for this feature. But some people follow 
> > > other approaches. For example, I like to do TDD and to only 
> > write unit 
> > > tests insofar as they are needed to drive the design. After that, I 
> > > focus on acceptance tests. But other folks continue to work at the 
> > > unit test level until they have full "coverage" - in 
> > whatever sense it 
> > > matters to them. I could discuss this at greater length, but I'm 
> > > afraid that it's not particularly on topic here.
> > > 
> > > Open software like Nunit - or Mono for that matter - needs 
> > to satisfy 
> > > the people who use it. Arguments like "Nobody should want this" 
> > > generally lose out in the face of folks who actually have a 
> > use for a 
> > > feature, particlarly if one of them is prepared to implement it.
> > > 
> > > Charlie Poole
> > > cpoole at pooleconsulting.com
> > > 
> > > > -----Original Message-----
> > > > From: Ben Maurer [mailto:bmaurer at users.sourceforge.net]
> > > > Sent: Monday, February 16, 2004 12:28 PM
> > > > To: Charlie Poole
> > > > Cc: Mono Development
> > > > Subject: RE: [Mono-devel-list] Detecting Mono
> > > > 
> > > > 
> > > > On Mon, 2004-02-16 at 13:57, Charlie Poole wrote:
> > > > > So - using your example - if an application stored settings
> > > > somewhere
> > > > > it should have acceptance tests to determine that settings
> > > > are saved
> > > > > and stored correctly. The test should work whether the
> > > > registry or a
> > > > > file or some other approach is used to saving the settings.
> > > > > 
> > > > > However, the same app would probably have a unit test for it's
> > > > > registry access code. That test would only be run in the win32 
> > > > > environment. If you're not heavily into unit testing and 
> > > > particulary
> > > > > TDD, this may not make sense. However, a large part of the
> > > > Nunit user
> > > > > community is into those things and so are the developers. :-)
> > > > 
> > > > I don't really think that is valid. Tests should probe how
> > > > the code works on the *outside* not the inside. For example, 
> > > > you would not write a test that used Reflection to get the 
> > > > fields of a class and test if they were set to the right 
> > > > value. You would use a publicly exposed API. Likewise, you 
> > > > shouldnt go about probing the storage format of your settings.
> > > > 
> > > > Tests really shouldnt assert things about how the code 
> > looks inside.
> > > > 
> > > > I can see the argument here in a setup where, say, you could
> > > > use a MySQL db or a MSSQL db and were expected to interop 
> > > > with other programs. However, I think that the best way to do 
> > > > this case is just to build seperate assemblies for each 
> > > > provider and only run the tests on platforms where the 
> > > > provider is supported. However, you dont need to change NUnit 
> > > > to support this.
> > > > 
> > > > > Your thoughts on known failures are interesting. It had not
> > > > occurred
> > > > > to me that there may be a difference between something that 
> > > > > doesn't
> > > > > work on a platform - and never will - and something that is 
> > > > expected
> > > > > (hoped?) to work some time in the future. For some projects, the
> > > > > distinction is not important but it probably is for others. 
> > > > I'll have
> > > > > to think on that.
> > > > 
> > > > Actually, I am not thinking of this in terms of platforms, I
> > > > am talking about known failures in general. I really dont 
> > > > like [Ignore] because it makes you *not* run the test.
> > > > 
> > > > You could extend this to allowing the decleration of groups by 
> > > > saying:
> > > > 
> > > > [Group ("FILED_BUGS")]
> > > > [Note ("see bug#12345"]
> > > > ..
> > > > 
> > > > And then run on the command line like:
> > > > 
> > > > nunit /ignore-group:FILED_BUGS
> > > > 
> > > > or you could do:
> > > > 
> > > > nunit /known-fail:FILED_BUGS
> > > > (so maybe you would get a gold star or something if one of
> > > > the known failures was made green ;-).
> > > > 
> > > > -- Ben
> > > > 
> > > > 
> > > 
> > > 
> > > _______________________________________________
> > > 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
> > 
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From gonzalo at ximian.com  Mon Feb 16 21:18:21 2004
From: gonzalo at ximian.com (Gonzalo Paniagua Javier)
Date: Tue, 17 Feb 2004 03:18:21 +0100
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <OFEAJFLCBPECFKICJIOJGEIBNLAA.cpoole@pooleconsulting.com>
References: <OFEAJFLCBPECFKICJIOJGEIBNLAA.cpoole@pooleconsulting.com>
Message-ID: <1076983803.939.20.camel@localhost>

El dom, 15-02-2004 a las 20:02, Charlie Poole escribi?:
> Hi All,
> 
> I'm working under Windows to develop the next release of NUnit, and I'm
> testing under Mono as well as MS .NET.
> 
> In order to be sure I'm running under mono in a particlular test execution,
> I'm using
> typeof( System.Object  ).Assembly.CodeBase and looking for "Mono" in the
> path.

I would get the custom attributes of typeof (object).Assembly and, for
example, AssemblyProductAttribute is "MONO CLI".

-Gonzalo




From cpoole at pooleconsulting.com  Tue Feb 17 02:53:16 2004
From: cpoole at pooleconsulting.com (Charlie Poole)
Date: Mon, 16 Feb 2004 23:53:16 -0800
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <1076972127.17910.99.camel@Ben>
Message-ID: <OFEAJFLCBPECFKICJIOJGEKONLAA.cpoole@pooleconsulting.com>

> As a side note, what do you need to test the existance of a framework
> for? The only use I am able to see for this is the ignorring of a test
> that fails on a specific framework due to a bug. I would really rather
> see this implemented with [KnownFailure] sort of thing. The
> [KnownFailure] concept actually has alot of use in other contexts (eg,
> known not to work until the blah team finishes foo feature).
>
> Really, the only reason to test for a framework should be if you are
> integrating with it (for example, a profiling tool that makes custom
> calls for each fx). If that is not a case, it would be better to have a
> bug filed in our bugzilla and an annotation made to the test case.

If it's the case that there's an actual bug which might be fixed in short
order, I'd leave that test in place and ignore it. But if it's a case that a
feature has not been developed and won't be developed for a while - or
possibly never - then I think I'd decide to provide the functionality
through some other means. A good example of this is porting to the compact
framework where you don't get .NET remoting and some parts of Reflection are
missing "by design".

Charlie Poole
cpoole at pooleconsulting.com




From ndrochak at gol.com  Tue Feb 17 03:37:18 2004
From: ndrochak at gol.com (Nick D)
Date: Tue, 17 Feb 2004 17:37:18 +0900
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <002c01c3f4b5$b42d9550$8119fea9@siena>
Message-ID: <E1At0jL-00024g-0F@smtp01.fields.gol.com>

>| -----Original Message-----
>| From: Charlie Poole [mailto:cpoole at pooleconsulting.com]
>| Sent: Tuesday, February 17, 2004 2:53 AM
>| To: 'Jaroslaw Kowalski'; 'Nick Drochak'; mono-devel-list at lists.ximian.com
>| Cc: '! nant'
>| Subject: RE: [Mono-devel-list] Detecting Mono
>| 
>| Now that I think of it, an ignore type check is probably at least as
>| common as a positive check. The syntax I was imagining was something
>| like:
>| 
>| 	[Platform("net-1.0,net-1.1")]
>| 
>| Perhaps an alternative would be to also support
>| 
>| 	[Platform( Exclude="mono" )]
>| 

This sounds great.  Also, I agree that they shouldn't even be loading into
the tree.

Thanks,
Nick



From martin at ximian.com  Tue Feb 17 03:42:59 2004
From: martin at ximian.com (Martin Baulig)
Date: Tue, 17 Feb 2004 09:42:59 +0100
Subject: [Mono-devel-list] PATCH: Lazily allocate ArrayList buffers
In-Reply-To: <1076825445.3280.12.camel@Ben>
References: <1076825445.3280.12.camel@Ben>
Message-ID: <1077007378.1657.58.camel@gondor.martin.baulig>

On Sun, 2004-02-15 at 07:10, Ben Maurer wrote:

> Attached is a patch that makes ArrayLists allocate their buffers only on
> the first addition to the list. For example the following code:
> 
> ArrayList ar = new ArrayList ();
> ar = null;
> 
> will not allocate an object [].
> 
> Running the profiler on a few applications, it seems that the patch has
> some effect. One notable example is MonoDevelop where it prevented 2/3
> of the allocations of arraylists.
> 
> It seems that MS implements this behavior in the v2 framework. Using a
> beta of the code, I ran:
> 
> ArrayList ar = new ArrayList ()
> COnsole.WriteLine (ar.Capacity);
> 
> It returned 0. This seems to indicate that the capacity (which is the
> size of the array) is zero until something has been added.

Hi Ben,

your patch looks great, but I think we should really make Capacity
return 0 in this case.

--
Martin Baulig <martin at ximian.com>
Now blogging !  http://primates.ximian.com/~martin/blog



From steinar.herland at gecko.no  Tue Feb 17 03:59:01 2004
From: steinar.herland at gecko.no (Steinar Herland)
Date: Tue, 17 Feb 2004 09:59:01 +0100
Subject: [Mono-devel-list] PATCH: Lazily allocate ArrayList buffers
Message-ID: <C942D94A4D3A1C478312E64BCA97E54A0133AF@caesar.gecko.no>

How about #define this according to the appropriate framework-version?

-----Original Message-----
From: mono-devel-list-admin at lists.ximian.com
[mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of Martin
Baulig
Sent: 17. februar 2004 09:43
To: Ben Maurer
Cc: Mono Development
Subject: Re: [Mono-devel-list] PATCH: Lazily allocate ArrayList buffers

On Sun, 2004-02-15 at 07:10, Ben Maurer wrote:

> Attached is a patch that makes ArrayLists allocate their buffers only
on
> the first addition to the list. For example the following code:
> 
> ArrayList ar = new ArrayList ();
> ar = null;
> 
> will not allocate an object [].
> 
> Running the profiler on a few applications, it seems that the patch
has
> some effect. One notable example is MonoDevelop where it prevented 2/3
> of the allocations of arraylists.
> 
> It seems that MS implements this behavior in the v2 framework. Using a
> beta of the code, I ran:
> 
> ArrayList ar = new ArrayList ()
> COnsole.WriteLine (ar.Capacity);
> 
> It returned 0. This seems to indicate that the capacity (which is the
> size of the array) is zero until something has been added.

Hi Ben,

your patch looks great, but I think we should really make Capacity
return 0 in this case.

--
Martin Baulig <martin at ximian.com>
Now blogging !  http://primates.ximian.com/~martin/blog

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




From ndrochak at gol.com  Tue Feb 17 03:59:34 2004
From: ndrochak at gol.com (Nick D)
Date: Tue, 17 Feb 2004 17:59:34 +0900
Subject: [Mono-devel-list] Detecting Mono
In-Reply-To: <1076955783.17910.48.camel@Ben>
Message-ID: <E1At14t-00030B-JH@smtp01.fields.gol.com>

>| -----Original Message-----
>| From: Ben Maurer [mailto:bmaurer at users.sourceforge.net]
>| Sent: Tuesday, February 17, 2004 3:23 AM
>| To: Charlie Poole
>| Cc: 'Jaroslaw Kowalski'; 'Nick Drochak'; Mono Development; '! nant'
>| Subject: RE: [Mono-devel-list] Detecting Mono
>| 
>| I really, really dont think this is the way to go.
>| 
>| Software should not work like this:
>| "if you are running on windows, pressing `foo' will result in blah. As
>| an exception, on windows 98, nothing will happen. On linux, it will do
>| bar if it is running on RedHat 9 or Fedora, but will do baz if it is
>| running on any other linux system."
>| 
>| You might have a feature that is implemented in different ways on
>| different systems -- for example, maybe on Windows you store a key in
>| the registry, but on Linux you store it in a dot file.

This depends on what exactly you are testing and what other concerns you are
addressing.  At a certain level of granularity it does matter.  A unit test
to make sure the dot file got the value is different from the unit test to
make sure the registry got updated. Unit tests can and should test different
levels of abstraction.

>| Having different tests for different platforms implies that you intend
>| for the program to work differently in each platform. This isnt really
>| consistant with having a program that is really cross platform.

We already have this with .NET 1.1 vs. .NET 1.0. As bugs get fixed, for
example, we have different results in different versions of .NET.  I think
the Platform attribute is a nice, consistent extension that handles this
nicely. I can think of a few other issues this allows us to handle:
 - Places we choose not to have bug-for-bug compatibility with .NET
 - File related mis-matches due to differences in the OS's, e.g.
permissions.
 - Stuff I don't even know about yet that will come from the PPC version of
mono running on a Mac

I agree this is a tool that needs to be used correctly and carefully--more
like a surgeon with a scalpel than a lumberjack with a magic chainsaw :)

We just need to keep our eyes open and watch the patches coming in on tests.

Regards,
Nick D.



From thomas.uhl at topalis.com  Mon Feb 16 16:10:58 2004
From: thomas.uhl at topalis.com (Thomas Uhl)
Date: Mon, 16 Feb 2004 22:10:58 +0100
Subject: [Mono-devel-list] Re: COBOL frontend for Mono?
Message-ID: <1076965858.6948.7.camel@localhost.localdomain>

I am interested in an OSS version of COBOL running on Mono.
Is there anybody interested in wokring on a project like that?

Yours
  Tom
-- 
----------------------------------------------------------------------
Thomas Uhl                                      thomas.uhl at topalis.com
Topalis AG                                    phone: +49 711 88770-111
Lilienthalstr. 2                                fax: +49 711 88770-199
70825 Stuttgart-Korntal, Germany                cel: +49 170 7917711
----------------------------------------------------------------------



From krisolav at hotmail.com  Mon Feb 16 18:22:21 2004
From: krisolav at hotmail.com (Kris Bradley)
Date: Mon, 16 Feb 2004 15:22:21 -0800
Subject: [Mono-devel-list] web services, custom types, and XmlInclude
Message-ID: <BAY12-F96GndRcNvx2W0002b5f2@hotmail.com>

I?d like to have a web service method that returns an array of custom types. 
  I wrote a simple test that works under MS .NET, but not under Mono.  For 
example:

	[WebMethod]
	[XmlInclude(typeof(ComplexThing))]
	public ArrayList foo()
	{
		ArrayList list = new ArrayList();
		list.Add(new ComplexThing("abc", 1.1f));
		list.Add(new ComplexThing("xyz", 2.0f));
		return list;
	}

The code for ComplexThing is:

	public class ComplexThing
	{
		public ComplexThing() {}

		public ComplexThing(string name, float val)
		{
			this.name = name;
			this.val = val;
		}
		public string name;
		public float val;
	}

When I run this under Mono, I get the error:

	Invalid type: TestService.ComplexThing

Is this not supported?  Is there a better way to do this?

Thanks,
- Kris

_________________________________________________________________
Keep up with high-tech trends here at "Hook'd on Technology." 
http://special.msn.com/msnbc/hookedontech.armx



From lluis at ximian.com  Tue Feb 17 06:28:33 2004
From: lluis at ximian.com (Lluis Sanchez)
Date: Tue, 17 Feb 2004 12:28:33 +0100
Subject: [Mono-devel-list] web services, custom types, and XmlInclude
In-Reply-To: <BAY12-F96GndRcNvx2W0002b5f2@hotmail.com>
References: <BAY12-F96GndRcNvx2W0002b5f2@hotmail.com>
Message-ID: <1077017312.4377.4.camel@portatil.aticatacs>

Hi!

This is not currently supported. If you file a bug report in Bugzilla
with this sample I'll try to fix it.

Thanks,
Lluis.

On dt, 2004-02-17 at 00:22, Kris Bradley wrote:
> Id like to have a web service method that returns an array of custom types. 
>   I wrote a simple test that works under MS .NET, but not under Mono.  For 
> example:
> 
> 	[WebMethod]
> 	[XmlInclude(typeof(ComplexThing))]
> 	public ArrayList foo()
> 	{
> 		ArrayList list = new ArrayList();
> 		list.Add(new ComplexThing("abc", 1.1f));
> 		list.Add(new ComplexThing("xyz", 2.0f));
> 		return list;
> 	}
> 
> The code for ComplexThing is:
> 
> 	public class ComplexThing
> 	{
> 		public ComplexThing() {}
> 
> 		public ComplexThing(string name, float val)
> 		{
> 			this.name = name;
> 			this.val = val;
> 		}
> 		public string name;
> 		public float val;
> 	}
> 
> When I run this under Mono, I get the error:
> 
> 	Invalid type: TestService.ComplexThing
> 
> Is this not supported?  Is there a better way to do this?



> 
> Thanks,
> - Kris
> 
> _________________________________________________________________
> Keep up with high-tech trends here at "Hook'd on Technology." 
> http://special.msn.com/msnbc/hookedontech.armx
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



From martin at ximian.com  Tue Feb 17 06:47:26 2004
From: martin at ximian.com (Martin Baulig)
Date: Tue, 17 Feb 2004 12:47:26 +0100
Subject: [Mono-devel-list] Building mcs with generics profile
In-Reply-To: <1075805745.15390.8.camel@nova>
References: <20040117234127.GW4888@ox.compsoc.net>
	 <LNEAJLBKIAFKOPHEICIDOEPNDEAA.spouliot@videotron.ca>
	 <20040120102245.GB4888@ox.compsoc.net>  <1075805745.15390.8.camel@nova>
Message-ID: <1077018446.1657.64.camel@gondor.martin.baulig>

On Tue, 2004-02-03 at 11:55, Alan Jenkins wrote:
> I have just downloaded mono/mcs 0.30.  I followed the instructions in
> the mono docs to build mcs using the generics profile (after building &
> installing mono).  It fails because it tries to compile the source for
> gmcs.exe using gmcs.exe:

Hello,

I don't know what you're trying to do, but I think what you're looking
for is the `net_1_2' profile.

This is what you should use to get the latest features of .NET 1.2.

Generics support is still very experimental and shouldn't be used unless
you want to help with its development.

--
Martin Baulig <martin at ximian.com>
Now blogging !  http://primates.ximian.com/~martin/blog



From tiago.lima at vianw.pt  Tue Feb 17 07:51:01 2004
From: tiago.lima at vianw.pt (Tiago Lima)
Date: Tue, 17 Feb 2004 12:51:01 +0000
Subject: [Mono-devel-list] How to get annonymous access to monodevelop sources ?
Message-ID: <200402171251.01814.tiago.lima@vianw.pt>

Hi,

How do I get annonymous acces to monodevelop sources ?
Is it still in svn?

	Tiago Lima


From fawad at fawad.net  Tue Feb 17 10:18:03 2004
From: fawad at fawad.net (Fawad Halim)
Date: Tue, 17 Feb 2004 09:18:03 -0600
Subject: [Mono-devel-list] How to get annonymous access to monodevelop
 sources ?
In-Reply-To: <200402171251.01814.tiago.lima@vianw.pt>
References: <200402171251.01814.tiago.lima@vianw.pt>
Message-ID: <403230AB.10307@fawad.net>

Hi,
    Anonsvn is currently broken. You can get snapshots from

http://devservices.go-mono.com/MonoDevelop/

-fawad

Tiago Lima wrote:

>Hi,
>
>How do I get annonymous acces to monodevelop sources ?
>Is it still in svn?
>
>	Tiago Lima
>


From krisolav at hotmail.com  Tue Feb 17 11:28:51 2004
From: krisolav at hotmail.com (Kris Bradley)
Date: Tue, 17 Feb 2004 08:28:51 -0800
Subject: [Mono-devel-list] web services, custom types, and XmlInclude
Message-ID: <BAY12-F122WJAaQ9z7M00033606@hotmail.com>

Great, thank you.  The bug is here:
    http://bugzilla.ximian.com/show_bug.cgi?id=54461


----Original Message Follows----
From: Lluis Sanchez <lluis at ximian.com>
Reply-To: lluis at ximian.com
To: Kris Bradley <krisolav at hotmail.com>
CC: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-devel-list] web services, custom types, and XmlInclude
Date: Tue, 17 Feb 2004 12:28:33 +0100

Hi!

This is not currently supported. If you file a bug report in Bugzilla
with this sample I'll try to fix it.

Thanks,
Lluis.

On dt, 2004-02-17 at 00:22, Kris Bradley wrote:
 > Id like to have a web service method that returns an array of custom 
types.
 >   I wrote a simple test that works under MS .NET, but not under Mono.  
For
 > example:
 >
 > 	[WebMethod]
 > 	[XmlInclude(typeof(ComplexThing))]
 > 	public ArrayList foo()
 > 	{
 > 		ArrayList list = new ArrayList();
 > 		list.Add(new ComplexThing("abc", 1.1f));
 > 		list.Add(new ComplexThing("xyz", 2.0f));
 > 		return list;
 > 	}
 >
 > The code for ComplexThing is:
 >
 > 	public class ComplexThing
 > 	{
 > 		public ComplexThing() {}
 >
 > 		public ComplexThing(string name, float val)
 > 		{
 > 			this.name = name;
 > 			this.val = val;
 > 		}
 > 		public string name;
 > 		public float val;
 > 	}
 >
 > When I run this under Mono, I get the error:
 >
 > 	Invalid type: TestService.ComplexThing
 >
 > Is this not supported?  Is there a better way to do this?



 >
 > Thanks,
 > - Kris
 >
 > _________________________________________________________________
 > Keep up with high-tech trends here at "Hook'd on Technology."
 > http://special.msn.com/msnbc/hookedontech.armx
 >
 > _______________________________________________
 > 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

_________________________________________________________________
Take off on a romantic weekend or a family adventure to these great U.S. 
locations. http://special.msn.com/local/hotdestinations.armx



From TRedkar at ViewCentral.com  Tue Feb 17 11:49:00 2004
From: TRedkar at ViewCentral.com (Redkar, Tejaswi)
Date: Tue, 17 Feb 2004 08:49:00 -0800
Subject: [Mono-devel-list] System.Messaging
Message-ID: <13D0C4D68495D411865E001083FCCE6DF38DBF@mail.viewcentral.com>

Hi!

Anybody implementing System.Messaging?

Thanks
Tejaswi


From tiago.lima at vianw.pt  Tue Feb 17 12:32:42 2004
From: tiago.lima at vianw.pt (Tiago Lima)
Date: Tue, 17 Feb 2004 17:32:42 +0000
Subject: [Mono-devel-list] Internal representation of a language in gtksourceview(-sharp) ?
Message-ID: <200402171732.42698.tiago.lima@vianw.pt>

Hi,

How does the Language that is read from a .lang file gets represented in C# ?
Is there a way to create a language in c# instead of reading it from a file ?

For example:

	SourceLanguagesManager _languagesManager = new SourceLanguagesManager();
			
	SourceLanguage lang = 
_languagesManager.GetLanguageFromMimeType("text/x-csharp");

I can only see the Gtk.TextTag's but not more than that... I would want to see 
the "start-regex", "keyword" and other inner "XML" stuff...

Thanks,
	Tiago Lima


From mark.easton at blinksoftware.co.uk  Tue Feb 17 17:24:16 2004
From: mark.easton at blinksoftware.co.uk (Mark Easton)
Date: Tue, 17 Feb 2004 22:24:16 -0000
Subject: [Mono-devel-list] Winelib/PInvoke question...
In-Reply-To: <001901c3f4a8$d78bc3d0$3962f486@net.plm.eds.com>
Message-ID: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>

Okay this is possibly a stupid question, but is it possible to use
winelib as a standard shared library for P/Invoke purposes?  I know that
one of the SWF implementations does just this, but it's my understanding
that the Mono winelib implementation was re-jigged specifically for the
SWF implementation.

Cheers

Mark



From jonpryor at vt.edu  Tue Feb 17 20:10:24 2004
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Tue, 17 Feb 2004 20:10:24 -0500
Subject: [Mono-devel-list] Winelib/PInvoke question...
In-Reply-To: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>
Message-ID: <1077066622.17796.11.camel@melchior.magi>

Below...

On Tue, 2004-02-17 at 17:24, Mark Easton wrote:
> Okay this is possibly a stupid question, but is it possible to use
> winelib as a standard shared library for P/Invoke purposes?  I know that
> one of the SWF implementations does just this, but it's my understanding
> that the Mono winelib implementation was re-jigged specifically for the
> SWF implementation.

Yes, the winelib that Mono used was "re-jigged" so that it could be
loaded through "normal" means (dlopen(3)).  By default, Wine likes/needs
to be in charge of loading libraries, as Windows makes several
guarantees about DLL loading that Unix shared libraries don't.  (For
example, Windows ensures that all DLLs get notified when a thread is
created and destroyed, among other things.)

The last time I remember seeing this come up on Wine Traffic, the
consensus was that Wine would likely never officially support the
loading of Wine libraries through non-Wine means, though this may have
changed since then.  You can find the archives here:

	http://www.kerneltraffic.org/wine/archives/html

 - Jon




From ndhameja at panaceasoftware.com  Tue Feb 17 22:00:07 2004
From: ndhameja at panaceasoftware.com (Namit Dhameja)
Date: Tue, 17 Feb 2004 19:00:07 -0800
Subject: [Mono-devel-list] string in case statement cannot > 64 chars
References: <026901c3f4c6$90214fb0$7001a8c0@Namitws>
Message-ID: <001f01c3f5cb$50b68150$7001a8c0@Namitws>

Hi,
   I have submitted a bug against the compiler http://bugzilla.ximian.com/show_bug.cgi?id=54473 about the string problem as I am not sure how to classify this bug.
-Best Regards,
Namit.
  ----- Original Message ----- 
  From: Namit Dhameja 
  To: Mono-devel-list at lists.ximian.com 
  Sent: Monday, February 16, 2004 11:53 AM
  Subject: [Mono-devel-list] string in case statement cannot > 64 chars


  Hi all,
  In case statements, the maximum length of the string is 64 bytes. That is,
  <-------------------------------------------------------------->
   strName = "{http://schemas.xmlsoap.org/ws/2003/03/business-process/}partnerLinks";
   switch (strName)
   {
   case "{http://schemas.xmlsoap.org/ws/2003/03/business-process/}partnerLinks":
              System.Console.WriteLine ("Found it"); break;
   default:  System.Console.WriteLine ("Not Found it"); break;
   }
  <-------------------------------------------------------------------------------->
   
  This code will print "Not Found it".
   
  On .Net the above code works just fine. I am not aware of the maximum string
   length possible under .Net. If 64 characters is indeed the specification and
   not a bug than perhaps the compiler should issue some sort of warning about it.
   Maybe it would be a better idea to make the string length the same as microsoft .Net.

   -Best Regards,
   Namit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040217/81dd99cd/attachment.html 

From ndhameja at panaceasoftware.com  Tue Feb 17 22:24:45 2004
From: ndhameja at panaceasoftware.com (Namit Dhameja)
Date: Tue, 17 Feb 2004 19:24:45 -0800
Subject: [Mono-devel-list] HttpWebRequest problem
Message-ID: <003201c3f5ce$c18eb890$7001a8c0@Namitws>

Hi all,
    I am having a problem while sending out "HttpWebRequest". The problem is unless you close the output stream the message is not getting sent, so the response stream basically times out. Flushing the stream also does not send the message. Sample code 

/// <summary>
/// Serialize SOAP data.
/// Set the content length of the string being posted.
/// </summary>
protected Stream stmRequest;

public void sendHttpData()
{
 stmRequest = req.GetRequestStream();
 byte[] b = ASCIIEncoding.Default.GetBytes(messageToSend);
 stmRequest.Write(b,0,b.Length);
 stmRequest.Flush();
 stmRequest.Close ();   // -------------Had to be added <WORKAROUND>
}

Could someone suggest me any other way, is this a well know problem?.

-Best Regards,
Namit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040217/ce7832c0/attachment.html 

From miguel at ximian.com  Wed Feb 18 00:01:06 2004
From: miguel at ximian.com (Miguel de Icaza)
Date: Wed, 18 Feb 2004 00:01:06 -0500
Subject: [Mono-devel-list] sparc mini
In-Reply-To: <001901c3f4a8$d78bc3d0$3962f486@net.plm.eds.com>
References: <001901c3f4a8$d78bc3d0$3962f486@net.plm.eds.com>
Message-ID: <1077080466.11677.169.camel@erandi.boston.ximian.com>

Hello,

> Since I've been discussing this with someone re doing some work to get it
> going I was just wondering if anyone else out there is working on the Sparc
> port (V8 or V9) of mini? Just trying to avoid duplication.

I know that Zoltan was interested in this effort, you might want to keep
him in the loop ;-)

Miguel


From miguel at ximian.com  Wed Feb 18 00:09:50 2004
From: miguel at ximian.com (Miguel de Icaza)
Date: Wed, 18 Feb 2004 00:09:50 -0500
Subject: [Mono-devel-list] Mod_mono devel
In-Reply-To: <C168A0E8725B2F41BC8C1BC97EC66BA42E8359@soporte.ferengi.com.ar>
References: <C168A0E8725B2F41BC8C1BC97EC66BA42E8359@soporte.ferengi.com.ar>
Message-ID: <1077080989.11677.173.camel@erandi.boston.ximian.com>

Hey!

> Is there any list specifically for mod_mono?
> Who is taking care of its development at this moment? (apache.org page
> seems really outdated)

We have kind of taken over maintenance.  When I say "we" I mean, Gonzalo
;-)

Miguel


From atsushi at ximian.com  Wed Feb 18 01:18:15 2004
From: atsushi at ximian.com (Atsushi Eno)
Date: Wed, 18 Feb 2004 15:18:15 +0900
Subject: [Mono-devel-list] Char.IsXXX() patch: from InternalCall to managed
Message-ID: <403303A7.8000705@ximian.com>

Hello,

I found that existing Char.IsWhitespace() and Char.IsSeparator() are
slower than MS.NET. I found that they are InternalCall, so I tried to
implement them in Char.cs natively and the got 2x speed. So I think
it would be better if we move these (and the same kind of) methods
into managed world.

BTW, Char.IsWhiteSpace() and g_unichar_isspace() are different in
some characters such as vertical space ('\v').

If it does not matter, I'll commit the patch later.

Thanks,
Atsushi Eno

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: charperf.patch
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040218/0883660f/attachment.pl 

From michi at zeroc.com  Tue Feb 17 20:36:28 2004
From: michi at zeroc.com (Michi Henning)
Date: Wed, 18 Feb 2004 11:36:28 +1000
Subject: [Mono-devel-list] Thread safety of readonly data members?
In-Reply-To: <1077066622.17796.11.camel@melchior.magi>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE> <1077066622.17796.11.camel@melchior.magi>
Message-ID: <4032C19C.20501@zeroc.com>

I have a question regarding thread safety...

Consider:

class Class1
{
     Class1()
     {
         _val = 42;
     }

     public int getVal()
     {
         return _val;
     }

     private readonly int _val;
}

In a threaded environment, is it necessary to interlock
inside the constructor and getVal() to ensure that
threads get the correct value? In other words,
do I have to write it as follows?

class Class1
{
     Class1()
     {
         lock(this)
         {
             _val = 42;
         }
     }

     public int getVal()
     {
         lock(this)
         {
             return _val;
         }
     }

     private readonly int _val;
}

In C++, the lock is necessary because, on SMP
machines, memory consistency isn't guaranteed without
the lock. But I don't know whether the same is true
for C#.

What if the member variable is not readonly (but will
never be modified, except for the initial assignment
in the constructor)? Is accessing the value thread-safe
without a lock in that case?

What about const members? Is access to those safe without
a lock?

And what about static members that are (conceptually)
immutable (only initialized in the constructor and
never assigned again)? Is the lock required there?

Any difference in memory consistency models between
Mono and .NET? (I need to write code that is portable
to both platforms.)

Thanks muchly,

Michi.




From jonpryor at vt.edu  Wed Feb 18 06:49:35 2004
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Wed, 18 Feb 2004 06:49:35 -0500
Subject: [Mono-devel-list] Thread safety of readonly data members?
In-Reply-To: <4032C19C.20501@zeroc.com>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>
	 <1077066622.17796.11.camel@melchior.magi>  <4032C19C.20501@zeroc.com>
Message-ID: <1077104974.19836.22.camel@melchior.magi>

Below...

On Tue, 2004-02-17 at 20:36, Michi Henning wrote:
> I have a question regarding thread safety...
> 
> Consider:
> 
> class Class1
> {
>      Class1()
>      {
>          _val = 42;
>      }
> 
>      public int getVal()
>      {
>          return _val;
>      }
> 
>      private readonly int _val;
> }
> 
> In a threaded environment, is it necessary to interlock
> inside the constructor and getVal() to ensure that
> threads get the correct value?
<snip/>
> In C++, the lock is necessary because, on SMP
> machines, memory consistency isn't guaranteed without
> the lock. But I don't know whether the same is true
> for C#.

I would think whether or not the lock is required, in either
environment, would depend on how you create your class instances.  Do
you allow your code to possibly invoke both the constructor and the
method at the same time?

In C++, if your object is globally allocated, locking isn't necessary
(see the description about static members for an explanation).  If your
object is heap allocated, then you need locks around all your callee
code, NOT within your class, just to ensure that the pointer is non-null
(avoiding crashes):

	// This won't work...
	Class1* pClass;
	void thread1 () {pClass = new Class1();}
	void thread2 () {pClass->getVal();}

So no, the lock is NOT necessary in C++.  It depends on a number of
factors.  The lock is only necessary if you had multiple member
functions (NOT including the constructor) that could change the
underlying member variable.  If you allow your code to invoke both a
constructor and a member function at the same time, YOUR CODE IS BROKEN.

Moving on to Mono, one major problem is that the CLI standard, as
currently specified, uses effectively the same memory consistency model
as Java.  Meaning, C++ techniques such as double-checked locking ARE NOT
VALID:

	private static Class1 foo;

	public static Foo {
		get {
			// This will likely work on most platforms, such
			// as x86, but it is NOT guaranteed to work on 
			// all potential hardware platforms.
			if (foo == null) {
				lock (typeof(Something)) {
					if (foo == null)
						foo = new Class1();
				}
			}
		}
	}

In C++, you could use code similar to the above, and you WOULD NOT need
to lock both the class constructor and the accessor methods, as the
calling code ensures that the class has properly constructed before
invoking any member functions.

The problem is that double-checked locking isn't really portable in
.NET, so you either need to (a) always lock the code that will construct
the object, or (b) use the static loader lock, described below.

> What if the member variable is not readonly (but will
> never be modified, except for the initial assignment
> in the constructor)? Is accessing the value thread-safe
> without a lock in that case?

I would expect that this is similar/identical to the readonly variable
case.  "readonly" only means that the compiler will check your code to
ensure that the variables don't change after you've initialized them in
the constructor.  The runtime may do some checking on them, but I'm not
entirely sure about that.

> What about const members? Is access to those safe without
> a lock?

Const members are safe, as these are "burned" into the CIL, and cannot
be changed without recompiling.  They're just like enumeration members.
You can't change enumeration values after you've compiled. :-)

> And what about static members that are (conceptually)
> immutable (only initialized in the constructor and
> never assigned again)? Is the lock required there?

No.  Static members are initialized by the class constructor (".cctor"),
and the runtime has an internal lock to ensure that only one thread
executes the class constructor.

	// Initializing static members either "inline" or in the static
	// class constructor is *always* thread safe.
	public static readonly string Hello = "Hello";
	public static readonly Class1 Something;
	static MyClass ()
	{
		Something = new Class1 ();
	}

You can think of them as C++ global variables, which are initialized by
the C++ runtime libraries *before* main() is called, so you can assume
that there will only be a single thread initializing the class.  On the
other hand, the is no guarantee about order of initialization *between*
global variables in different compilation units, so there are still
problems with global variables in C++.

> Any difference in memory consistency models between
> Mono and .NET? (I need to write code that is portable
> to both platforms.)

If there are, file them in bugzilla. :-)

 - Jon




From gonzalo at ximian.com  Wed Feb 18 06:53:52 2004
From: gonzalo at ximian.com (Gonzalo Paniagua Javier)
Date: Wed, 18 Feb 2004 12:53:52 +0100
Subject: [Mono-devel-list] HttpWebRequest problem
In-Reply-To: <003201c3f5ce$c18eb890$7001a8c0@Namitws>
References: <003201c3f5ce$c18eb890$7001a8c0@Namitws>
Message-ID: <1077105232.30373.32.camel@localhost>

El mi?, 18-02-2004 a las 04:24, Namit Dhameja escribi?:
> Hi all,
>     I am having a problem while sending out "HttpWebRequest". The
> problem is unless you close the output stream the message is not
> getting sent, so the response stream basically times out. Flushing the
> stream also does not send the message. Sample code 
>  
> /// <summary>
> /// Serialize SOAP data.
> /// Set the content length of the string being posted.
> /// </summary>
> protected Stream stmRequest;
> public void sendHttpData()
> {
>  stmRequest = req.GetRequestStream();
>  byte[] b = ASCIIEncoding.Default.GetBytes(messageToSend);
>  stmRequest.Write(b,0,b.Length);
>  stmRequest.Flush();
>  stmRequest.Close ();   // -------------Had to be added <WORKAROUND>
> }
>  
> Could someone suggest me any other way, is this a well know problem?.

That's not a bug. It's a feature. MS .NET behaves that way.

-Gonzalo

 




From tiago.lima at vianw.pt  Wed Feb 18 06:55:52 2004
From: tiago.lima at vianw.pt (Tiago Lima)
Date: Wed, 18 Feb 2004 11:55:52 +0000
Subject: [Mono-devel-list] To draw or not to draw that is the question :)
Message-ID: <200402181155.53004.tiago.lima@vianw.pt>

Hi,

I've explored GTK and I saw that drawing in Gtk.DrawingArea involves using 
Gdk.Drawable which in turn requires learning some of Pango (?)... I guess 
Pango implements what I think it is the functionality of System.Drawing, no?
Now, I'am confused what library I should use to "draw"...
Should I use System.Windows.Forms (with Mono-wine or something?) or should I 
use GTK and use that Pango thing?

I dont know what is being made in this direction so I dont know what to do....

Another question is what should I use to do image manipulation (resize, 
chopping, do thumbnails, etc) in a server (in ASP.NET for example) without 
installing the whole X package ?

Thanks,
	Tiago Lima


From 05mauben at hawken.edu  Wed Feb 18 08:02:55 2004
From: 05mauben at hawken.edu (Ben Maurer)
Date: Wed, 18 Feb 2004 08:02:55 -0500
Subject: [Mono-devel-list] Char.IsXXX() patch: from InternalCall to
	managed
Message-ID: <s0331c44.068@gm004.hawken.edu>

Hey Atsushi,

Very good catch. Actually, this has alot of impact because in the
future, this method might be able to be inlined.

For IsWhitespace, I would rather see all the switch elements enumerated
out. This is going to be faster than calling the other method, even if
it will get inlined (as I understand it, that is the design of the
Switch statement).

Also, rather than the magic characters, can you please use constants and
a quick comment describing what they are:

// This character is the `foo' character. it is a whitespace character
const char seperator_foo = '\u2029';

Here:
+    int i = (int) c;
+    return i >= 0x2000 && i <= 0x200b

you should be able to do:

return c >= '\u2000' && c <= '\u200b';

-- Ben

>>> Atsushi Eno <atsushi at ximian.com> 02/18/04 01:19 AM >>>
Hello,

I found that existing Char.IsWhitespace() and Char.IsSeparator() are
slower than MS.NET. I found that they are InternalCall, so I tried to
implement them in Char.cs natively and the got 2x speed. So I think
it would be better if we move these (and the same kind of) methods
into managed world.

BTW, Char.IsWhiteSpace() and g_unichar_isspace() are different in
some characters such as vertical space ('\v').

If it does not matter, I'll commit the patch later.

Thanks,
Atsushi Eno




From 05mauben at hawken.edu  Wed Feb 18 08:07:14 2004
From: 05mauben at hawken.edu (Ben Maurer)
Date: Wed, 18 Feb 2004 08:07:14 -0500
Subject: [Mono-devel-list] string in case statement cannot > 64
	chars
Message-ID: <s0331d3b.075@gm004.hawken.edu>

Hello,

I actually took a look at this last night. It turns out that there is a
runtime bug. Basically, what MCS emits is that it calls
String::IsInterned on the string. It then does a pointer compare on the
constant versions of the string. This allows you to avoid a high number
of char based compares.

For some reason, the 64 char string is not interned as it should be.

I isolated the problem to simple function calls. Hopefully, the runtime
people can get this solved.

Thanks for the report, this is a pretty obscure issue. Very good catch.

-- Ben

>>> "Namit Dhameja" <ndhameja at panaceasoftware.com> 02/17/04 22:01 PM >>>
Hi,
   I have submitted a bug against the compiler
http://bugzilla.ximian.com/show_bug.cgi?id=54473 about the string
problem as I am not sure how to classify this bug.
-Best Regards,
Namit.
  ----- Original Message ----- 
  From: Namit Dhameja 
  To: Mono-devel-list at lists.ximian.com 
  Sent: Monday, February 16, 2004 11:53 AM
  Subject: [Mono-devel-list] string in case statement cannot > 64 chars


  Hi all,
  In case statements, the maximum length of the string is 64 bytes. That
is,
  <-------------------------------------------------------------->
   strName =
"{http://schemas.xmlsoap.org/ws/2003/03/business-process/}partnerLinks";
   switch (strName)
   {
   case
"{http://schemas.xmlsoap.org/ws/2003/03/business-process/}partnerLinks":
              System.Console.WriteLine ("Found it"); break;
   default:  System.Console.WriteLine ("Not Found it"); break;
   }
 
<-------------------------------------------------------------------------------->
   
  This code will print "Not Found it".
   
  On .Net the above code works just fine. I am not aware of the maximum
string
   length possible under .Net. If 64 characters is indeed the
specification and
   not a bug than perhaps the compiler should issue some sort of warning
about it.
   Maybe it would be a better idea to make the string length the same as
microsoft .Net.

   -Best Regards,
   Namit.



From rafaelteixeirabr at hotmail.com  Wed Feb 18 08:24:26 2004
From: rafaelteixeirabr at hotmail.com (A Rafael D Teixeira)
Date: Wed, 18 Feb 2004 10:24:26 -0300
Subject: [Mono-devel-list] System.Messaging
Message-ID: <Sea2-F19YNyZFEXlBBx0002ad24@hotmail.com>

>From: "Redkar, Tejaswi" <TRedkar at ViewCentral.com>
>
>Hi!
>
>Anybody implementing System.Messaging?
>
>Thanks
>Tejaswi

I and others stubbed it, a long time ago, but  since no one has been 
actively developing it. See my also dormant MonoQLE project for the backend 
server for the namespace. Nowadays we are thinking of  following the 
Longhorn path, implementing our version of the Indigo technology, instead of 
  implementing System.Messaging as it is now.

Anyway, if you want to help, you're welcome,

Best regards,

Rafael Teixeira
Brazilian Polymath
Mono Hacker since 16 Jul 2001
MonoBrasil Founding Member - Membro Fundador do MonoBrasil
English Blog: http://monoblog.blogspot.com/
Brazilian Portuguese Blog: http://monoblog.weblogger.terra.com.br/



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

_________________________________________________________________
MSN Messenger: instale gr?tis e converse com seus amigos. 
http://messenger.msn.com.br



From Alain.ROUGE at enac.fr  Wed Feb 18 08:21:33 2004
From: Alain.ROUGE at enac.fr (ROUGE Alain)
Date: Wed, 18 Feb 2004 14:21:33 +0100
Subject: [Mono-devel-list] to draw or not to draw
Message-ID: <OFB0177A33.C167F903-ONC1256E3E.0047B73D@enac.fr>

hi,

System.Drawing is the only clear API.
You've to wait for a couple of month untill SWF is reactived.
In short Gdk/Pango  is not a serious API to write complicated graphics 
with text.

The official position from mono developpers is to use gdk# but it is a 
terrible API for drawing.
I wrote a graphic application under gtkmm/gdkmm/pangomm and it was 
terrible.
That's my feeling. forget gdk and pango.

ar.


From atsushi at ximian.com  Wed Feb 18 07:43:33 2004
From: atsushi at ximian.com (Atsushi Eno)
Date: Wed, 18 Feb 2004 21:43:33 +0900
Subject: [Mono-devel-list] Char.IsXXX() patch: from InternalCall to managed
In-Reply-To: <403303A7.8000705@ximian.com>
References: <403303A7.8000705@ximian.com>
Message-ID: <40335DF5.5020401@ximian.com>


> I found that existing Char.IsWhitespace() and Char.IsSeparator() are
> slower than MS.NET. I found that they are InternalCall, so I tried to
> implement them in Char.cs natively and the got 2x speed. So I think
> it would be better if we move these (and the same kind of) methods
> into managed world.

Ok, it could be still more efficient. Now I added another IsDigit()
implementation (it is "optimized" specifically for digits).
It enhanced the speed nearly 2.5x to 3x and now faster than MS.NET,
especially the char is in ASCII range.

BTW, we have other IsXXX() methods:

	- IsControl()
	- IsLetter()
	- IsLower()
	- IsNumber()
	- IsPunctuation()
	- IsSurrogate()
	- IsSystem()
	- IsUpper()

It can be easily done (with an easy program like attached one).
Any volunteers on them?

Atsushi Eno

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: chartest.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040218/cfb5b576/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: optimize-char.patch
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040218/cfb5b576/attachment-0001.pl 

From tiago.lima at vianw.pt  Wed Feb 18 08:38:25 2004
From: tiago.lima at vianw.pt (Tiago Lima)
Date: Wed, 18 Feb 2004 13:38:25 +0000
Subject: [Mono-devel-list] to draw or not to draw
In-Reply-To: <OFB0177A33.C167F903-ONC1256E3E.0047B73D@enac.fr>
References: <OFB0177A33.C167F903-ONC1256E3E.0047B73D@enac.fr>
Message-ID: <200402181338.25498.tiago.lima@vianw.pt>

Humm... ok...
And what about wxWindows ? Is wx.NET an option ?

Is System.Windows.Forms stable in mono? Do you recomend trying monoWine ?

Thanks,
	Tiago Lima

On Wednesday 18 February 2004 13:21, ROUGE Alain wrote:
> hi,
>
> System.Drawing is the only clear API.
> You've to wait for a couple of month untill SWF is reactived.
> In short Gdk/Pango  is not a serious API to write complicated graphics
> with text.
>
> The official position from mono developpers is to use gdk# but it is a
> terrible API for drawing.
> I wrote a graphic application under gtkmm/gdkmm/pangomm and it was
> terrible.
> That's my feeling. forget gdk and pango.
>
> ar.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list


From atsushi at ximian.com  Wed Feb 18 09:25:05 2004
From: atsushi at ximian.com (Atsushi Eno)
Date: Wed, 18 Feb 2004 23:25:05 +0900
Subject: [Mono-devel-list] Char.IsXXX() patch: from InternalCall to	managed
In-Reply-To: <s0331c44.068@gm004.hawken.edu>
References: <s0331c44.068@gm004.hawken.edu>
Message-ID: <403375C1.6040104@ximian.com>

Hello,

> For IsWhitespace, I would rather see all the switch elements enumerated
> out. This is going to be faster than calling the other method, even if
> it will get inlined (as I understand it, that is the design of the
> Switch statement).

Yeah. I noticed that and fixed in the second patch ;-)

> Also, rather than the magic characters, can you please use constants and
> a quick comment describing what they are:

nod.

> you should be able to do:
> return c >= '\u2000' && c <= '\u200b';

Okay, it would be better. Thanks!

Atsushi Eno



From Alain.ROUGE at enac.fr  Wed Feb 18 09:35:55 2004
From: Alain.ROUGE at enac.fr (ROUGE Alain)
Date: Wed, 18 Feb 2004 15:35:55 +0100
Subject: [Mono-devel-list] to draw or not to draw
Message-ID: <OF1094B3BA.3A8D6433-ONC1256E3E.004E82E8@enac.fr>

SWF is not stable and is broken under Mono.
again you've got to wait got for a couple of month to have a working SWF 
under Mono.
That's said SWF throught wine is not really robust,  gtk# is more robust 
but gdk is very weak for drawing.
SD is usable but you've to render to a bitmap.

So it is impossible to write a real world application with complicated 
graphics under Mono. for the moment.
It 's seems that few people are interested in drawing in the mono galaxy. 
I don't understand why Novell/Ximian/Suse don't hire a team of developpers 
to work on wine, gdiplus, SD, SWF.
That's a strategic area for me. not for miguel. :-(

wxWindows is not a native widget set. so not a good solution for me.

Perhaps you should use gkt# and write a decent layer on the top of gdk# to 
handle drawing in the spirit of SD.

ar.






From jackson at ximian.com  Wed Feb 18 10:02:45 2004
From: jackson at ximian.com (Jackson Harper)
Date: Wed, 18 Feb 2004 07:02:45 -0800
Subject: [Mono-devel-list] to draw or not to draw
In-Reply-To: <OF1094B3BA.3A8D6433-ONC1256E3E.004E82E8@enac.fr>
References: <OF1094B3BA.3A8D6433-ONC1256E3E.004E82E8@enac.fr>
Message-ID: <1077116565.19399.4.camel@localhost.localdomain>

On Wed, 2004-02-18 at 06:35, ROUGE Alain wrote:

> It 's seems that few people are interested in drawing in the mono galaxy. 
> I don't understand why Novell/Ximian/Suse don't hire a team of developpers 
> to work on wine, gdiplus, SD, SWF.
> That's a strategic area for me. not for miguel. :-(

  I quick count shows that there are more Novell employees working full
time on those areas then any other one area of Mono. 

Jackson





From gabor at z10n.net  Wed Feb 18 11:06:23 2004
From: gabor at z10n.net (gabor)
Date: Wed, 18 Feb 2004 17:06:23 +0100
Subject: [Mono-devel-list] Thread safety of readonly data members?
In-Reply-To: <1077104974.19836.22.camel@melchior.magi>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>
	 <1077066622.17796.11.camel@melchior.magi>  <4032C19C.20501@zeroc.com>
	 <1077104974.19836.22.camel@melchior.magi>
Message-ID: <1077120383.20309.5.camel@wintermute.atriaky.sk>

On Wed, 2004-02-18 at 12:49, Jonathan Pryor wrote:
> Moving on to Mono, one major problem is that the CLI standard, as
> currently specified, uses effectively the same memory consistency model
> as Java.  Meaning, C++ techniques such as double-checked locking ARE NOT
> VALID:
> 
> 	private static Class1 foo;
> 
> 	public static Foo {
> 		get {
> 			// This will likely work on most platforms, such
> 			// as x86, but it is NOT guaranteed to work on 
> 			// all potential hardware platforms.
> 			if (foo == null) {
> 				lock (typeof(Something)) {
> 					if (foo == null)
> 						foo = new Class1();
> 				}
> 			}
> 		}
> 	}
> 
> In C++, you could use code similar to the above, and you WOULD NOT need
> to lock both the class constructor and the accessor methods, as the
> calling code ensures that the class has properly constructed before
> invoking any member functions.
> 
> The problem is that double-checked locking isn't really portable in
> .NET, so you either need to (a) always lock the code that will construct
> the object, or (b) use the static loader lock, described below.

hmmm.. could you explain one more time why is that code wrong?
 for example can you give me an example when it goes wrong?

for me it seems that it really guarantees that only 1 thread will be
able to construct the object.

and btw.  is reading or writing a native/simple/non-object ( i don't
know the exact term for this. i mean something like int, char and so on)
an atomic operation?

for example if i have two threads, one writes to a variable randomly 1
or 10. the other thread reads the variable in a loop and writes it to
the screen. can i be sure that i will only see the numbers 1 and 10? 

thanks,
gabor



From daniel at rawbyte.com  Wed Feb 18 10:09:03 2004
From: daniel at rawbyte.com (Daniel Lopez)
Date: Wed, 18 Feb 2004 07:09:03 -0800
Subject: [Mono-devel-list] Mod_mono devel
In-Reply-To: <1077080989.11677.173.camel@erandi.boston.ximian.com>
References: <C168A0E8725B2F41BC8C1BC97EC66BA42E8359@soporte.ferengi.com.ar> <1077080989.11677.173.camel@erandi.boston.ximian.com>
Message-ID: <20040218150903.GB5624@rawbyte.com>

> > Is there any list specifically for mod_mono?
> > Who is taking care of its development at this moment? (apache.org page
> > seems really outdated)
> 
> We have kind of taken over maintenance.  When I say "we" I mean, Gonzalo
> ;-)

I finally launched my company last week, so now that is done I hope I will be
"back from among the dead" soon ;)

Un saludo

Daniel



From gonzalo at ximian.com  Wed Feb 18 11:18:30 2004
From: gonzalo at ximian.com (Gonzalo Paniagua Javier)
Date: Wed, 18 Feb 2004 17:18:30 +0100
Subject: [Mono-devel-list] Thread safety of readonly data members?
In-Reply-To: <1077120383.20309.5.camel@wintermute.atriaky.sk>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>
	 <1077066622.17796.11.camel@melchior.magi>  <4032C19C.20501@zeroc.com>
	 <1077104974.19836.22.camel@melchior.magi>
	 <1077120383.20309.5.camel@wintermute.atriaky.sk>
Message-ID: <1077121092.31288.49.camel@localhost>

El mi?, 18-02-2004 a las 17:06, gabor escribi?:
> On Wed, 2004-02-18 at 12:49, Jonathan Pryor wrote:
> > Moving on to Mono, one major problem is that the CLI standard, as
> > currently specified, uses effectively the same memory consistency model
> > as Java.  Meaning, C++ techniques such as double-checked locking ARE NOT
> > VALID:
> > 
> > 	private static Class1 foo;
> > 
> > 	public static Foo {
> > 		get {
> > 			// This will likely work on most platforms, such
> > 			// as x86, but it is NOT guaranteed to work on 
> > 			// all potential hardware platforms.
> > 			if (foo == null) {
> > 				lock (typeof(Something)) {
> > 					if (foo == null)
> > 						foo = new Class1();
> > 				}
> > 			}
> > 		}
> > 	}
> > 
> > In C++, you could use code similar to the above, and you WOULD NOT need
> > to lock both the class constructor and the accessor methods, as the
> > calling code ensures that the class has properly constructed before
> > invoking any member functions.
> > 
> > The problem is that double-checked locking isn't really portable in
> > .NET, so you either need to (a) always lock the code that will construct
> > the object, or (b) use the static loader lock, described below.
> 
> hmmm.. could you explain one more time why is that code wrong?
>  for example can you give me an example when it goes wrong?

There's an explanation in
http://research.microsoft.com/~birrell/papers/ThreadsCSharp.pdf (which
is listed in http://www.go-mono.com/papers.html).

-Gonzalo




From gonzalo at ximian.com  Wed Feb 18 11:19:40 2004
From: gonzalo at ximian.com (Gonzalo Paniagua Javier)
Date: Wed, 18 Feb 2004 17:19:40 +0100
Subject: [Mono-devel-list] Mod_mono devel
In-Reply-To: <20040218150903.GB5624@rawbyte.com>
References: <C168A0E8725B2F41BC8C1BC97EC66BA42E8359@soporte.ferengi.com.ar>
	 <1077080989.11677.173.camel@erandi.boston.ximian.com>
	 <20040218150903.GB5624@rawbyte.com>
Message-ID: <1077121180.31288.51.camel@localhost>

El mi?, 18-02-2004 a las 16:09, Daniel Lopez escribi?:
> > > Is there any list specifically for mod_mono?
> > > Who is taking care of its development at this moment? (apache.org page
> > > seems really outdated)
> > 
> > We have kind of taken over maintenance.  When I say "we" I mean, Gonzalo
> > ;-)
> 
> I finally launched my company last week, so now that is done I hope I will be
> "back from among the dead" soon ;)

Nice! (for both, the launch and your back ;-).

-Gonzalo




From ndhameja at panaceasoftware.com  Wed Feb 18 12:36:45 2004
From: ndhameja at panaceasoftware.com (Namit Dhameja)
Date: Wed, 18 Feb 2004 09:36:45 -0800
Subject: [Mono-devel-list] HttpWebRequest problem
References: <003201c3f5ce$c18eb890$7001a8c0@Namitws> <1077105232.30373.32.camel@localhost>
Message-ID: <000b01c3f645$c74833c0$7001a8c0@Namitws>

Hi Gonzalo,
    I am porting the code from Windows (MS .NET) to Linux (Mono). And I did
not have the same experience with "HttpWebRequest". That is, I did not have
to close the connection on MS .NET, "Flush()" seemed to do the trick.
    Actually closing the connection seems an acceptable workaround. I just
wanted to bring to your notice that there is a difference in behaviour.

-Best Regards,
Namit.


----- Original Message ----- 
From: "Gonzalo Paniagua Javier" <gonzalo at ximian.com>
To: "Mono Development" <mono-devel-list at lists.ximian.com>
Sent: Wednesday, February 18, 2004 3:53 AM
Subject: Re: [Mono-devel-list] HttpWebRequest problem


> El mi?, 18-02-2004 a las 04:24, Namit Dhameja escribi?:
> > Hi all,
> >     I am having a problem while sending out "HttpWebRequest". The
> > problem is unless you close the output stream the message is not
> > getting sent, so the response stream basically times out. Flushing the
> > stream also does not send the message. Sample code
> >
> > /// <summary>
> > /// Serialize SOAP data.
> > /// Set the content length of the string being posted.
> > /// </summary>
> > protected Stream stmRequest;
> > public void sendHttpData()
> > {
> >  stmRequest = req.GetRequestStream();
> >  byte[] b = ASCIIEncoding.Default.GetBytes(messageToSend);
> >  stmRequest.Write(b,0,b.Length);
> >  stmRequest.Flush();
> >  stmRequest.Close ();   // -------------Had to be added <WORKAROUND>
> > }
> >
> > Could someone suggest me any other way, is this a well know problem?.
>
> That's not a bug. It's a feature. MS .NET behaves that way.
>
> -Gonzalo
>
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>



From gonzalo at ximian.com  Wed Feb 18 12:52:33 2004
From: gonzalo at ximian.com (Gonzalo Paniagua Javier)
Date: Wed, 18 Feb 2004 18:52:33 +0100
Subject: [Mono-devel-list] HttpWebRequest problem
In-Reply-To: <000b01c3f645$c74833c0$7001a8c0@Namitws>
References: <003201c3f5ce$c18eb890$7001a8c0@Namitws>
	 <1077105232.30373.32.camel@localhost>
	 <000b01c3f645$c74833c0$7001a8c0@Namitws>
Message-ID: <1077126753.30384.61.camel@localhost>

El mi?, 18-02-2004 a las 18:36, Namit Dhameja escribi?:
> Hi Gonzalo,
>     I am porting the code from Windows (MS .NET) to Linux (Mono). And I did
> not have the same experience with "HttpWebRequest". That is, I did not have
> to close the connection on MS .NET, "Flush()" seemed to do the trick.
>     Actually closing the connection seems an acceptable workaround. I just
> wanted to bring to your notice that there is a difference in behaviour.

Really? I tested it just before replying your previous mail and Flush ()
(without Close) did nothing.

If you have a small test case the behaves in another way under MS,
please, file a bug report in bugzilla.ximian.com.

Thanks.

-Gonzalo




From gabor at z10n.net  Wed Feb 18 13:06:43 2004
From: gabor at z10n.net (gabor)
Date: Wed, 18 Feb 2004 19:06:43 +0100
Subject: [Mono-devel-list] Thread safety of readonly data members?
In-Reply-To: <1077121092.31288.49.camel@localhost>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>
	 <1077066622.17796.11.camel@melchior.magi>  <4032C19C.20501@zeroc.com>
	 <1077104974.19836.22.camel@melchior.magi>
	 <1077120383.20309.5.camel@wintermute.atriaky.sk>
	 <1077121092.31288.49.camel@localhost>
Message-ID: <1077127603.9530.0.camel@dubb>

On Wed, 2004-02-18 at 17:18, Gonzalo Paniagua Javier wrote:
> El mi??, 18-02-2004 a las 17:06, gabor escribi??:
> > On Wed, 2004-02-18 at 12:49, Jonathan Pryor wrote:
> > > Moving on to Mono, one major problem is that the CLI standard, as
> > > currently specified, uses effectively the same memory consistency model
> > > as Java.  Meaning, C++ techniques such as double-checked locking ARE NOT
> > > VALID:
> > > 
> > > 	private static Class1 foo;
> > > 
> > > 	public static Foo {
> > > 		get {
> > > 			// This will likely work on most platforms, such
> > > 			// as x86, but it is NOT guaranteed to work on 
> > > 			// all potential hardware platforms.
> > > 			if (foo == null) {
> > > 				lock (typeof(Something)) {
> > > 					if (foo == null)
> > > 						foo = new Class1();
> > > 				}
> > > 			}
> > > 		}
> > > 	}
> > > 
> > > In C++, you could use code similar to the above, and you WOULD NOT need
> > > to lock both the class constructor and the accessor methods, as the
> > > calling code ensures that the class has properly constructed before
> > > invoking any member functions.
> > > 
> > > The problem is that double-checked locking isn't really portable in
> > > .NET, so you either need to (a) always lock the code that will construct
> > > the object, or (b) use the static loader lock, described below.
> > 
> > hmmm.. could you explain one more time why is that code wrong?
> >  for example can you give me an example when it goes wrong?
> 
> There's an explanation in
> http://research.microsoft.com/~birrell/papers/ThreadsCSharp.pdf (which
> is listed in http://www.go-mono.com/papers.html).


thanks....phew.... i never EVER thought that something like that could
happen ...
time to forget all the C knowledge :)))

gabor



From gonzalo at ximian.com  Wed Feb 18 13:16:32 2004
From: gonzalo at ximian.com (Gonzalo Paniagua Javier)
Date: Wed, 18 Feb 2004 19:16:32 +0100
Subject: [Mono-devel-list] Re: Exception in global_asax, Session_Start not called
In-Reply-To: <1077126794.3792.17.camel@leonardo.hotfeet.ch>
References: <1077126794.3792.17.camel@leonardo.hotfeet.ch>
Message-ID: <1077127776.31301.64.camel@localhost>

El mi?, 18-02-2004 a las 18:53, Juraj Skripsky escribi?:
> Hello,
> 
> The attached files work fine on MS.Net but fail on Mono (0.30.1).
> 
> The problems are:
> - exception on access to the <object>-declared properties
> "myApplication" in the auto-generated class "global_asax".
> - "Session_Start" in global.asax is never called.
> 
> Should I file a bug report?

I tried this with current CVS and it worked. AFAIR, the final bits for
supporting <object> were added just after 0.30 (and 0.30.1).

-Gonzalo




From beauche at softhome.net  Wed Feb 18 13:23:51 2004
From: beauche at softhome.net (Francois Beauchemin)
Date: Wed, 18 Feb 2004 13:23:51 -0500
Subject: [Mono-devel-list] Regex: 'Split' function problem.
In-Reply-To: <018901c3f253$4f728b20$7001a8c0@Namitws>
References: <E1Argar-0005l9-00@panacea> <018901c3f253$4f728b20$7001a8c0@Namitws>
Message-ID: <4033ADB7.4090006@softhome.net>

Hi , since I work on regex  IL Compilation with Eric, I've looked this 
bug and I find that RegexOption.RightToLeft does not work at all.

See this bug for more details :  
http://bugzilla.ximian.com/show_bug.cgi?id=54537

I will look ahead to find why this does not work since we are 
implementing the same algoritm in IL than the interpreter.

Francois
TIP-MONO Team ( a university project )
http://aeglos.dyndns.org/tip-mono

Namit Dhameja wrote:

>Hi Eric,
>    I have added the bug to bugzilla. Thanks for taking a look.
>    The ID is: http://bugzilla.ximian.com/show_bug.cgi?id=54242
>-Best Regards,
>Namit.
>
>  
>



From gustav-w-s at online.de  Wed Feb 18 14:04:30 2004
From: gustav-w-s at online.de (Gustav Schauwecker)
Date: Wed, 18 Feb 2004 20:04:30 +0100
Subject: [Mono-devel-list] Weird behavior of DateTime poperties in asp controls
Message-ID: <200402182004.30379.gustav-w-s@online.de>

It seems that DateTime poperties are not parsed correctly (at least on my 
system).
for example the asp:calendar control:

<asp:calendar runat="server" SelectedDate="01.05.2004" />

this one works as long as the day number is lower than 13. If the day number 
is between 13 and 23 no day is selected. And if it is above 23 a server error 
is raised, for example:

 Cannot parse 2004/25/02 as System.DateTime

If have tried different date formats but that did not help. The error is not 
calendar specific. I stumbled on this strange behavior while developing my 
own control.

My System: mono-0.30.1, mod_mono-0.7, xsp-0.9

Can anyone reproduce this?

Gustl


From krisolav at hotmail.com  Wed Feb 18 17:04:23 2004
From: krisolav at hotmail.com (Kris Bradley)
Date: Wed, 18 Feb 2004 14:04:23 -0800
Subject: [Mono-devel-list] wsdl tool exception: "Text node cannot appear in this state"
Message-ID: <BAY12-F70VAxEP57X7o00037722@hotmail.com>

I'm consistently getting this exception from the wsdl tool:

    Error: System.Xml.XmlException: Text node cannot appear in this state. 
Line 3, position 1.
    in <0x0005a> System.Xml.XmlTextReader:ReadText (bool)
    in <0x00225> System.Xml.XmlTextReader:ReadContent ()
    in <0x001a7> System.Xml.XmlTextReader:Read ()
    in <0x00097> System.Xml.XmlReader:MoveToContent ()
    in <0x00116> Mono.WebServices.Driver:Run (string[])

The MS wsdl tool worked fine on the same services.  Has anyone else seen 
this?
Thanks,
- Kris

_________________________________________________________________
Dream of owning a home? Find out how in the First-time Home Buying Guide. 
http://special.msn.com/home/firsthome.armx



From jonpryor at vt.edu  Wed Feb 18 17:46:52 2004
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Wed, 18 Feb 2004 17:46:52 -0500
Subject: [Mono-devel-list] Thread safety of readonly data members?
In-Reply-To: <1077120383.20309.5.camel@wintermute.atriaky.sk>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>
	 <1077066622.17796.11.camel@melchior.magi> <4032C19C.20501@zeroc.com>
	 <1077104974.19836.22.camel@melchior.magi>
	 <1077120383.20309.5.camel@wintermute.atriaky.sk>
Message-ID: <1077144408.19836.30.camel@melchior.magi>

Below...

On Wed, 2004-02-18 at 11:06, gabor wrote:
> On Wed, 2004-02-18 at 12:49, Jonathan Pryor wrote:
> > Moving on to Mono, one major problem is that the CLI standard, as
> > currently specified, uses effectively the same memory consistency model
> > as Java.  Meaning, C++ techniques such as double-checked locking ARE NOT
> > VALID:

<snip what="double checked locking example"/>

> > In C++, you could use code similar to the above, and you WOULD NOT need
> > to lock both the class constructor and the accessor methods, as the
> > calling code ensures that the class has properly constructed before
> > invoking any member functions.

I forgot to mention this, but in C++ the static member would also need
to be declared as "volatile" for double-checked locking to properly
work, IIRC.
 
> > The problem is that double-checked locking isn't really portable in
> > .NET, so you either need to (a) always lock the code that will construct
> > the object, or (b) use the static loader lock, described below.
> 
> hmmm.. could you explain one more time why is that code wrong?
>  for example can you give me an example when it goes wrong?
> 
> for me it seems that it really guarantees that only 1 thread will be
> able to construct the object.

The problem is that the code (double-checked locking) *does* work.  On
x86.  And probably numerous other platforms.  But it's not *guaranteed*
to work on *all* platforms.  That's the problem.

See: http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx

To quote (liberally) from Chris Brumme's blog:

	if (a == null)
	{
		lock(obj)
		{
			if (a == null) a = new  A();
		}
	}

	....

        However,  we have to assume that a series of stores have taken
        place during construction  of ?a?.  Those stores can be 
        arbitrarily reordered, including the possibility of delaying
        them until after  the publishing store which assigns the new
        object to ?a?.  At that point, there is a small window before
        the store.release implied by leaving the lock.  Inside that
        window, other CPUs can navigate through the reference ?a? and
        see a partially constructed  instance.
        
In other words, "Oops," because the memory model is (1) weaker than
developers expect, and (2) not reproducible on commodity hardware.

> and btw.  is reading or writing a native/simple/non-object ( i don't
> know the exact term for this. i mean something like int, char and so on)
> an atomic operation?

It's atomic if the object's size is less than a machine word.  So Int32
can be assumed to be read atomically on all platforms, but Int64 can not
(it'll be atomic on 64-bit platforms, but not in 32-bit x86).

Though, strictly speaking, this is machine/hardware/architecture
dependent.  You probably wouldn't want to assume this, but it's a fairly
reasonable assumption for most platforms.

> for example if i have two threads, one writes to a variable randomly 1
> or 10. the other thread reads the variable in a loop and writes it to
> the screen. can i be sure that i will only see the numbers 1 and 10? 

For all platforms I know of, yes.  But I don't know of all possible
platforms, and there's a potentially infinite number of future
platforms, so this isn't guaranteed to be true.  It will *probably* be
true, because if it weren't, a whole number of potential software
optimizations becomes difficult, but it's not a sure thing.

 - Jon




From cwitty at newtonlabs.com  Wed Feb 18 18:09:02 2004
From: cwitty at newtonlabs.com (Carl Witty)
Date: 18 Feb 2004 15:09:02 -0800
Subject: [Mono-devel-list] Thread safety of readonly data members?
In-Reply-To: <1077144408.19836.30.camel@melchior.magi>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>
	 <1077066622.17796.11.camel@melchior.magi> <4032C19C.20501@zeroc.com>
	 <1077104974.19836.22.camel@melchior.magi>
	 <1077120383.20309.5.camel@wintermute.atriaky.sk>
	 <1077144408.19836.30.camel@melchior.magi>
Message-ID: <1077145742.11995.11.camel@flare>

On Wed, 2004-02-18 at 14:46, Jonathan Pryor wrote:
> <snip what="double checked locking example"/>
> 
> > > In C++, you could use code similar to the above, and you WOULD NOT need
> > > to lock both the class constructor and the accessor methods, as the
> > > calling code ensures that the class has properly constructed before
> > > invoking any member functions.
> 
> I forgot to mention this, but in C++ the static member would also need
> to be declared as "volatile" for double-checked locking to properly
> work, IIRC.

Are you sure this works?  This would require that compilers for some
platforms (at least for Alpha) put memory-barrier instructions around
accesses of volatile variables; I'd check to make sure that this really
happens before relying on double-checked locking with that compiler.

Carl Witty






From jonpryor at vt.edu  Wed Feb 18 18:36:14 2004
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Wed, 18 Feb 2004 18:36:14 -0500
Subject: [Mono-devel-list] Thread safety of readonly data members?
In-Reply-To: <004701c3f655$2bcfd640$0101010a@qld.bigpond.net.au>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>
	 <1077066622.17796.11.camel@melchior.magi> <4032C19C.20501@zeroc.com>
	 <1077104974.19836.22.camel@melchior.magi>
	 <004701c3f655$2bcfd640$0101010a@qld.bigpond.net.au>
Message-ID: <1077147373.22151.42.camel@melchior.magi>

Below...

On Wed, 2004-02-18 at 14:24, Michi Henning wrote:
> Jonathan Pyor wrote:
<snip/>
> Uh, sorry, but that's not correct. On SMP machines, things can happen
> in the following order:
> 
> - Thread 1, running on CPU 1, reads a variable. This loads a cache line
>   on CPU 1 containing the variable. It is possible for the instance of
> Class1
>   to be adjacent in memory to the variable just read by Thread 1, and to
>   be loaded into the cache on CPU 1 as well, because a single cache line
>   can hold more than one variable.
> 
> - Thread 2 constructs the Class1 instance and initializes the _val member.
> 
> - Thread 1 calls getVal() on the instance. Because the corresponding
>   memory location is in the cache, it is served from the cache, and
>   thread 1 reads whatever garbage is in that memory location.
> 
> Without a memory barrier, there is no way for Thread 1 to know that
> Thread 2 has modified the contents of the memory that holds _val.

In C++, here's the main question: where is Class1 allocated, and what
type is it?  There are only three potential answers:

  1.  Globally: class instance (Class1 global): constructor
      will be initialized before main() is executed.  Unless you're
      creating threads from within the constructor (are you insane?!),
      you don't need to worry about running within a multi-threaded
      environment.

      Here, your scenario isn't possible, as only one thread is present.

  2.  On the stack: Unless threads share stack space (!), this isn't
      a problem.

  3.  On the Heap: Here, your scenario is present.  However, in order to
      share the class instance between threads, the pointer needs to be
      globally allocated, in which case it will be default-initialized 
      to the null pointer.  So in your scenario, when Thread 1 reads in
      the memory block containing class instance, it reads NULL, 
      executes the member function, and your program DIES.

      The only time this wouldn't occur is when you're allocating a new
      instance over an old instance:

          Class1* p = new Class1 ();
          // ...
          p = new Class1 ();

      In this case, you better have an intervening delete, or you have 
      a memory leak, and you should set the pointer to NULL after the
      delete (to avoid double-deletions), reducing this scenario to the
      first.

      Translation: Properly coded, you WILL NOT have one thread access
      a class instance before it's been fully constructed, UNLESS your
      architecture doesn't have atomic writes for pointers.

Do you need a write barrier?  Yes.  The easiest way to do this is to
just mark the pointer as "volatile", requiring that the compiler always
re-check the memory on reads.

> So, I guess another way to phrase my question is to ask whether
> C# guarantees to insert a memory barrier at the end of the
> constructor if readonly members were initialized by that constructor.

No.  See other posts about the lax memory model semantics provided by
the CLI standard.

> > Moving on to Mono, one major problem is that the CLI standard, as
> > currently specified, uses effectively the same memory consistency model
> > as Java.  Meaning, C++ techniques such as double-checked locking ARE NOT
> > VALID:
> 
> Aha. OK -- that answers my question, thanks!
> 
> Could you point me at where the CLI memory consistency model is defined?
> I couldn't find any such thing in the C# documentation.

You don't want the C# standard, you want the CLI standard, ECMA 335:

	http://www.ecma-international.org/publications/standards/Ecma-335.htm

In my printed version, you want Partition I, section 11.6 (Memory Model
and Optimizations).

<snip/>

> > Const members are safe, as these are "burned" into the CIL, and cannot
> > be changed without recompiling.  They're just like enumeration members.
> > You can't change enumeration values after you've compiled. :-)
> 
> Hmmm... Even those wouldn't be necessarily safe. The would be
> safe only if the language definition guarantees that const members
> end up in the initialized data segment. However, an equally valid
> implementation for const members would be to initialize them
> at run time, during program startup. In that case, all bets would
> be off. So, does the CLR or C# guarantee that const members
> are in the initialized data segment?

Const members are *so* const, that the compiler is permitted to inline
their values so that cross-assembly references are removed.  So:

	enum Foo {Bar = 42;}
	Foo foo = Foo.Bar;

is basically the same as

	int foo = 42;

With the added provision that some static type checking is present, but
as far as the runtime is concerned enumerations are silently convertible
to the underlying integer type.

Of course, that doesn't hold for System.String instances, but you can
safely assume that all constants will be initialized in a thread-safe
manner.  The runtime ensures this.  (If it doesn't, it's a runtime bug.)

> > > And what about static members that are (conceptually)
> > > immutable (only initialized in the constructor and
> > > never assigned again)? Is the lock required there?
> >
> > No.  Static members are initialized by the class constructor (".cctor"),
> > and the runtime has an internal lock to ensure that only one thread
> > executes the class constructor.
> 
> Right. But without the reading thread grabbing the lock, there is
> nothing to tell the hardware that the thread may be reading
> inconsistent memory, I would think.

The runtime runs the class constructors from within a global runtime
lock.  No other threads can access any class members (fields, methods,
constructors, etc.) until the class constructor finishes executing.  And
if the class constructor generates an exception, you get a
TypeLoadException, and you'll NEVER be able to access *anything* on the
class.

> > // Initializing static members either "inline" or in the static
> > // class constructor is *always* thread safe.
> > public static readonly string Hello = "Hello";
> > public static readonly Class1 Something;
> > static MyClass ()
> > {
> > Something = new Class1 ();
> > }
> 
> Hmmm. So if another thread reads Something, what ensures
> that the second thread doesn't read from a stale cache line?

The runtime ensures that this can't happen.  How that's done is
implementation dependent. :-)

 - Jon




From jonpryor at vt.edu  Wed Feb 18 19:18:17 2004
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Wed, 18 Feb 2004 19:18:17 -0500
Subject: [Mono-devel-list] Thread safety of readonly data members?
In-Reply-To: <1077145742.11995.11.camel@flare>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>
	 <1077066622.17796.11.camel@melchior.magi> <4032C19C.20501@zeroc.com>
	 <1077104974.19836.22.camel@melchior.magi>
	 <1077120383.20309.5.camel@wintermute.atriaky.sk>
	 <1077144408.19836.30.camel@melchior.magi> <1077145742.11995.11.camel@flare>
Message-ID: <1077149896.22151.51.camel@melchior.magi>

Below...

On Wed, 2004-02-18 at 18:09, Carl Witty wrote:
<snip/>
> > I forgot to mention this, but in C++ the static member would also need
> > to be declared as "volatile" for double-checked locking to properly
> > work, IIRC.
> 
> Are you sure this works?  This would require that compilers for some
> platforms (at least for Alpha) put memory-barrier instructions around
> accesses of volatile variables; I'd check to make sure that this really
> happens before relying on double-checked locking with that compiler.

I am reasonably sure this works.  At least, this is generally what most
books on threading that I've read have recommended.

Furthermore, the C++ standard I have, in section 1.9 (Program execution)
has the following statements:

        7.  Accessing an object designated by a volatile lvalue (3.10),
        modifying an object, calling a library I/O function, or calling
        a function that does any of these operations are all side
        effects, which are changes in the state of the execution
        environment...  At certain specified points in the execution
        sequence called sequence points, all side effects of previous
        evaluations shall be complete and no side effects of subsequent
        evaluations shall have taken place.  [Sequence points occur
        after every complete statement.]
        
        ...
        
        11.  The least requirements on a conforming implementation are:
                - At sequence points, volatile objects are stable in the
                sense that previous evaluations are complete and
                subsequent evaluations have not yet occurred.
                ...

This would imply to me that my understanding is correct, but I haven't
written a compiler, so I could be wrong.

 - Jon




From iain at mccoy.id.au  Wed Feb 18 20:43:33 2004
From: iain at mccoy.id.au (Iain McCoy)
Date: Thu, 19 Feb 2004 12:43:33 +1100
Subject: [Mono-devel-list] Weird behavior of DateTime poperties in asp
	controls
In-Reply-To: <200402182004.30379.gustav-w-s@online.de>
References: <200402182004.30379.gustav-w-s@online.de>
Message-ID: <1077155013.1226.2.camel@artefact>

On Thu, 2004-02-19 at 06:04, Gustav Schauwecker wrote:
> It seems that DateTime poperties are not parsed correctly (at least on my 
> system).
> for example the asp:calendar control:
> 
> <asp:calendar runat="server" SelectedDate="01.05.2004" />
> 
> this one works as long as the day number is lower than 13. If the day number 
> is between 13 and 23 no day is selected. And if it is above 23 a server error 
> is raised, for example:
> 
>  Cannot parse 2004/25/02 as System.DateTime
> 
This is just a guess, but I think it's possible that the required date
format is DD.MM.YYYY, but you're giving it MM.DD.YYYY - that is, you are
supplying days where you should supply months and vice versa.

-- 
Iain McCoy <iain at mccoy.id.au>



From cwitty at newtonlabs.com  Wed Feb 18 23:11:24 2004
From: cwitty at newtonlabs.com (Carl Witty)
Date: 18 Feb 2004 20:11:24 -0800
Subject: [Mono-devel-list] Thread safety of readonly data members?
In-Reply-To: <1077149896.22151.51.camel@melchior.magi>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>
	 <1077066622.17796.11.camel@melchior.magi> <4032C19C.20501@zeroc.com>
	 <1077104974.19836.22.camel@melchior.magi>
	 <1077120383.20309.5.camel@wintermute.atriaky.sk>
	 <1077144408.19836.30.camel@melchior.magi> <1077145742.11995.11.camel@flare>
	 <1077149896.22151.51.camel@melchior.magi>
Message-ID: <1077163883.12153.10.camel@flare>

On Wed, 2004-02-18 at 16:18, Jonathan Pryor wrote:
> Below...
> 
> On Wed, 2004-02-18 at 18:09, Carl Witty wrote:
> <snip/>
> > > I forgot to mention this, but in C++ the static member would also need
> > > to be declared as "volatile" for double-checked locking to properly
> > > work, IIRC.
> > 
> > Are you sure this works?  This would require that compilers for some
> > platforms (at least for Alpha) put memory-barrier instructions around
> > accesses of volatile variables; I'd check to make sure that this really
> > happens before relying on double-checked locking with that compiler.
> 
> I am reasonably sure this works.  At least, this is generally what most
> books on threading that I've read have recommended.
> 
> Furthermore, the C++ standard I have, in section 1.9 (Program execution)
> has the following statements:
> 
>         7.  Accessing an object designated by a volatile lvalue (3.10),
>         modifying an object, calling a library I/O function, or calling
>         a function that does any of these operations are all side
>         effects, which are changes in the state of the execution
>         environment...  At certain specified points in the execution
>         sequence called sequence points, all side effects of previous
>         evaluations shall be complete and no side effects of subsequent
>         evaluations shall have taken place.  [Sequence points occur
>         after every complete statement.]
>         
>         ...
>         
>         11.  The least requirements on a conforming implementation are:
>                 - At sequence points, volatile objects are stable in the
>                 sense that previous evaluations are complete and
>                 subsequent evaluations have not yet occurred.
>                 ...
> 
> This would imply to me that my understanding is correct, but I haven't
> written a compiler, so I could be wrong.

But according to section 1.9, paragraphs 1 and 6, the compiler is
allowed to move non-volatile reads and writes up or down past volatile
reads or writes.  I don't think paragraph 11 is relevant; we're
discussing volatile pointers to non-volatile objects, not volatile
objects.

And no amount of "volatile" will help, unless the compiler surrounds
accesses to volatiles with memory barriers (a memory barrier is a
special instruction which guarantees that modifications to memory made
by one processor are visible to another processor).  My guess is that
most compilers do not automatically emit memory barriers for volatile
accesses (for instance, in a quick check through the Alpha code
generator in the gcc 2.95.3 source tree I happened to have lying about,
I didn't see any evidence that it used memory barriers for anything
besides synchronizing data and instruction caches on a single
processor).

I recommend reading:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Carl Witty



From gustav-w-s at online.de  Thu Feb 19 01:21:16 2004
From: gustav-w-s at online.de (Gustav Schauwecker)
Date: Thu, 19 Feb 2004 07:21:16 +0100
Subject: [Mono-devel-list] Weird behavior of DateTime poperties in asp controls
In-Reply-To: <1077155013.1226.2.camel@artefact>
References: <200402182004.30379.gustav-w-s@online.de> <1077155013.1226.2.camel@artefact>
Message-ID: <200402190721.16979.gustav-w-s@online.de>

On Thursday 19 February 2004 02:43, Iain McCoy wrote:
> This is just a guess, but I think it's possible that the required date
> format is DD.MM.YYYY, but you're giving it MM.DD.YYYY - that is, you are
> supplying days where you should supply months and vice versa.

I tried all date formats I could imagine but that did not help.
I found out this is a localization problem. Everything works fine if I unset 
LC_ALL before mod-mono-server gets startet. My LC_ALL was set to de_DE.

Here is a small list of dates that work/don't work with LC_ALL=de_DE
doesn't work		works
24/02/2004		10/02/2004 (result: 10. Feb 2004)
2004/13/03		2004/12/03 (result: 12. Mar 2004)
28.03.2004		03.05.2004 (result:  3. May 2004)

If LC_ALL is not set the date format is: MM.dd.yyyy
with LC_ALL=de_DE it is: dd.MM.yyyy

I guess this is a mod-mono-server problem

Gustl


From josh_gerdes at yahoo.com  Wed Feb 18 10:45:56 2004
From: josh_gerdes at yahoo.com (J. Gerdes)
Date: Wed, 18 Feb 2004 07:45:56 -0800 (PST)
Subject: [Mono-devel-list] Compile MCS 0.30.1 on windows
Message-ID: <20040218154556.762.qmail@web40411.mail.yahoo.com>

I am attempting to successfully compile both mono and
mcs (and eventually gtk-sharp 0.16) on windows (XP
SP1) with cygwin and I have had some success with a
successful build of mono 0.30.1 by slightly modifying
these instructions I found on the mono-devel list:

http://lists.ximian.com/archives/public/mono-devel-list/2004-January/003439.html

The snag I am having is when I try to compile the mcs
0.30.1 source.  When I run make I get the following
error:

$ make
make[1]: Entering directory
`/home/jgerdes/src/mcs-0.30.1/build'
make[1]: Leaving directory
`/home/jgerdes/src/mcs-0.30.1/build'
cd: can't cd to jay
make: *** [all-recursive] Error 1

I have noticed that the source does not contain the
jay directory but the cvs version does.  I am
currently just trying to get a downloadable release
version of mcs compiled and I was wondering if anyone
has seen this issue and how they went about solving
it.

I also would suggest putting some sort of updated
instructions on how to get all of these great tools
compiled on windows on the mono site.  It would be
very helpful for everyone trying to work with them on
windows.  I will be more than happy to send on the
instructions I have once I get them working fully.

Thanks,

Josh


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools


From derek.mcumber at datamtnsol.com  Wed Feb 18 11:19:47 2004
From: derek.mcumber at datamtnsol.com (Derek McUmber)
Date: Wed, 18 Feb 2004 11:19:47 -0500
Subject: [Mono-devel-list] file-io.c question and help requested
Message-ID: <403390A3.9040302@datamtnsol.com>

Hi all:

I am looking for some insight on a mono problem I have in
mono/metadata/file-io.c

I have been working on a port of mono to Win98 and have
only a couple dozen changes that will need to be inserted
into the build.  I will do a writeup of those changes and
ask for help once I have it working.

My current issue is with the w32API call in gcc called
GetFileAttributes.

The following code will crash a Win95/98 machine by
hanging the kernel (so I assume) on the second execution
of the .exe.  (doesn't seem to matter how many times I loop.)

using System;
using System.IO;
class X
{

	public static void Main ()
	{
		string path = "C:\\anyfile.txt";

		for (int i = 0; i < 1000; i++) {
			if (!File.Exists(path)) {
				Console.WriteLine("Not found.");
			} else {
				Console.WriteLine("Found.");
			}
		}
	}
}

It hangs the OS at the internal call GetFileAttributes

I notice in a debug version of mono that the
output from file-io.c looks like this:

	Calling GetFileAttributes "anyfile.txt"
	Calling GetFileAttributes "anyfile.txt"
	Returned from GetFileAttributes status: 1
	Returned from GetFileAttributes status: 1
	Error code from GetFileAttributes status: 0
	Error code from GetFileAttributes status: 0

At this point, the machine stops and I need to power down
and reboot.

A.  Could mono.exe be unloading the kernal upon exit of the app?
A.Test:  I try to LoadLibrary("Kernal32.dll") before the
GetFileAttributes call, every time, and I get the error code
1157 (dll_not_found) and I still hang.

B.  Win98 kernel is not handling threading/context switching
properly.

One guess is that this windows library isn't completely threadsafe on
Win98 since the same code executes fine on WinXP/2000.

Should I find a way to block mono for this call on Win98
(a few in file-io.c) so that it must not allow this behavior?

C.  On the web, someone on the web changed their implementation
of file existence to use a different api call (FileNext?)
and the problem went away.....  Should I try this and would we
want to change mono?

I know that a change like this will have implications for the
code base and want to find an elegant solution.

Thanks in advance,

Derek



From js at hotfeet.ch  Wed Feb 18 12:53:14 2004
From: js at hotfeet.ch (Juraj Skripsky)
Date: Wed, 18 Feb 2004 18:53:14 +0100
Subject: [Mono-devel-list] Exception in global_asax, Session_Start not called
Message-ID: <1077126794.3792.17.camel@leonardo.hotfeet.ch>

Hello,

The attached files work fine on MS.Net but fail on Mono (0.30.1).

The problems are:
- exception on access to the <object>-declared properties
"myApplication" in the auto-generated class "global_asax".
- "Session_Start" in global.asax is never called.

Should I file a bug report?


---
Juraj Skripsky <juraj at hotfeet.ch>
HotFeet - developing the web
Technopark Zurich
Switzerland
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: global.asax
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040218/4127c2e7/attachment.pl 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040218/4127c2e7/attachment.html 

From michi at zeroc.com  Wed Feb 18 14:24:49 2004
From: michi at zeroc.com (Michi Henning)
Date: Thu, 19 Feb 2004 05:24:49 +1000
Subject: [Mono-devel-list] Thread safety of readonly data members?
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE> <1077066622.17796.11.camel@melchior.magi>  <4032C19C.20501@zeroc.com> <1077104974.19836.22.camel@melchior.magi>
Message-ID: <004701c3f655$2bcfd640$0101010a@qld.bigpond.net.au>

Jonathan Pyor wrote:

> I would think whether or not the lock is required, in either
> environment, would depend on how you create your class instances.  Do
> you allow your code to possibly invoke both the constructor and the
> method at the same time?

No -- construction and access can't overlap. getVal() is called by
another thread some time after construction completes.

> So no, the lock is NOT necessary in C++.

Uh, sorry, but that's not correct. On SMP machines, things can happen
in the following order:

- Thread 1, running on CPU 1, reads a variable. This loads a cache line
  on CPU 1 containing the variable. It is possible for the instance of
Class1
  to be adjacent in memory to the variable just read by Thread 1, and to
  be loaded into the cache on CPU 1 as well, because a single cache line
  can hold more than one variable.

- Thread 2 constructs the Class1 instance and initializes the _val member.

- Thread 1 calls getVal() on the instance. Because the corresponding
  memory location is in the cache, it is served from the cache, and
  thread 1 reads whatever garbage is in that memory location.

Without a memory barrier, there is no way for Thread 1 to know that
Thread 2 has modified the contents of the memory that holds _val.

So, I guess another way to phrase my question is to ask whether
C# guarantees to insert a memory barrier at the end of the
constructor if readonly members were initialized by that constructor.

> Moving on to Mono, one major problem is that the CLI standard, as
> currently specified, uses effectively the same memory consistency model
> as Java.  Meaning, C++ techniques such as double-checked locking ARE NOT
> VALID:

Aha. OK -- that answers my question, thanks!

Could you point me at where the CLI memory consistency model is defined?
I couldn't find any such thing in the C# documentation.

>
> private static Class1 foo;
>
> public static Foo {
> get {
> // This will likely work on most platforms, such
> // as x86, but it is NOT guaranteed to work on
> // all potential hardware platforms.
> if (foo == null) {
> lock (typeof(Something)) {
> if (foo == null)
> foo = new Class1();
> }
> }
> }
> }
>
> In C++, you could use code similar to the above, and you WOULD NOT need
> to lock both the class constructor and the accessor methods, as the
> calling code ensures that the class has properly constructed before
> invoking any member functions.
>
> The problem is that double-checked locking isn't really portable in
> .NET, so you either need to (a) always lock the code that will construct
> the object, or (b) use the static loader lock, described below.
>
> > What if the member variable is not readonly (but will
> > never be modified, except for the initial assignment
> > in the constructor)? Is accessing the value thread-safe
> > without a lock in that case?
>
> I would expect that this is similar/identical to the readonly variable
> case.  "readonly" only means that the compiler will check your code to
> ensure that the variables don't change after you've initialized them in
> the constructor.  The runtime may do some checking on them, but I'm not
> entirely sure about that.
>
> > What about const members? Is access to those safe without
> > a lock?
>
> Const members are safe, as these are "burned" into the CIL, and cannot
> be changed without recompiling.  They're just like enumeration members.
> You can't change enumeration values after you've compiled. :-)

Hmmm... Even those wouldn't be necessarily safe. The would be
safe only if the language definition guarantees that const members
end up in the initialized data segment. However, an equally valid
implementation for const members would be to initialize them
at run time, during program startup. In that case, all bets would
be off. So, does the CLR or C# guarantee that const members
are in the initialized data segment?

> > And what about static members that are (conceptually)
> > immutable (only initialized in the constructor and
> > never assigned again)? Is the lock required there?
>
> No.  Static members are initialized by the class constructor (".cctor"),
> and the runtime has an internal lock to ensure that only one thread
> executes the class constructor.

Right. But without the reading thread grabbing the lock, there is
nothing to tell the hardware that the thread may be reading
inconsistent memory, I would think.

> // Initializing static members either "inline" or in the static
> // class constructor is *always* thread safe.
> public static readonly string Hello = "Hello";
> public static readonly Class1 Something;
> static MyClass ()
> {
> Something = new Class1 ();
> }

Hmmm. So if another thread reads Something, what ensures
that the second thread doesn't read from a stale cache line?

Cheers,

Michi.
--
Michi Henning              Ph: +61 4 1118-2700
ZeroC, Inc.                http://www.zeroc.com




From michi at zeroc.com  Wed Feb 18 14:26:46 2004
From: michi at zeroc.com (Michi Henning)
Date: Thu, 19 Feb 2004 05:26:46 +1000
Subject: [Mono-devel-list] Thread safety of readonly data members?
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE> <1077066622.17796.11.camel@melchior.magi>  <4032C19C.20501@zeroc.com> <1077104974.19836.22.camel@melchior.magi> <1077120383.20309.5.camel@wintermute.atriaky.sk> <1077121092.31288.49.camel@localhost>
Message-ID: <004801c3f655$2be84040$0101010a@qld.bigpond.net.au>

Gonzalo Paniagua Javier wrote:

> There's an explanation in
> http://research.microsoft.com/~birrell/papers/ThreadsCSharp.pdf (which
> is listed in http://www.go-mono.com/papers.html).

Ah, excellent, thanks for that link! That answers my question: the lock
is required in all cases.

Cheers,

Michi.

--
Michi Henning              Ph: +61 4 1118-2700
ZeroC, Inc.                http://www.zeroc.com

 



From michi at zeroc.com  Wed Feb 18 14:28:54 2004
From: michi at zeroc.com (Michi Henning)
Date: Thu, 19 Feb 2004 05:28:54 +1000
Subject: [Mono-devel-list] Thread safety of readonly data members?
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE> <1077066622.17796.11.camel@melchior.magi>  <4032C19C.20501@zeroc.com> <1077104974.19836.22.camel@melchior.magi> <1077120383.20309.5.camel@wintermute.atriaky.sk>
Message-ID: <005401c3f655$f7abf280$0101010a@qld.bigpond.net.au>

gabor wrote:

> and btw.  is reading or writing a native/simple/non-object ( i don't
> know the exact term for this. i mean something like int, char and so on)
> an atomic operation?
> 
> for example if i have two threads, one writes to a variable randomly 1
> or 10. the other thread reads the variable in a loop and writes it to
> the screen. can i be sure that i will only see the numbers 1 and 10? 

Given the explanations in

http://research.microsoft.com/~birrell/papers/ThreadsCSharp.pdf

the other thread can actually read absolutely anything and may not
see either 1 or 10.

Cheers,

Michi.

--
Michi Henning              Ph: +61 4 1118-2700
ZeroC, Inc.                http://www.zeroc.com



From michi at zeroc.com  Wed Feb 18 20:24:07 2004
From: michi at zeroc.com (Michi Henning)
Date: Thu, 19 Feb 2004 11:24:07 +1000
Subject: [Mono-devel-list] Thread safety of readonly data members?
In-Reply-To: <1077147373.22151.42.camel@melchior.magi>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>	 <1077066622.17796.11.camel@melchior.magi> <4032C19C.20501@zeroc.com>	 <1077104974.19836.22.camel@melchior.magi>	 <004701c3f655$2bcfd640$0101010a@qld.bigpond.net.au> <1077147373.22151.42.camel@melchior.magi>
Message-ID: <40341037.9030204@zeroc.com>

Jonathan Pryor wrote:

> In C++, here's the main question: where is Class1 allocated, and what
> type is it?  There are only three potential answers:
> 
>   1.  Globally: class instance (Class1 global): constructor
>       will be initialized before main() is executed.  Unless you're
>       creating threads from within the constructor (are you insane?!),
>       you don't need to worry about running within a multi-threaded
>       environment.
> 
>       Here, your scenario isn't possible, as only one thread is present.

I think that is correct (assuming no threads are created in a global
constructor.

>   2.  On the stack: Unless threads share stack space (!), this isn't
>       a problem.

Hmmm... It's not uncommon for one thread to hold a pointer to a stack-
allocated variable in another thread, so I guess the problem could
arise in that case.

>   3.  On the Heap: Here, your scenario is present.  However, in order to
>       share the class instance between threads, the pointer needs to be
>       globally allocated, in which case it will be default-initialized 
>       to the null pointer.

I don't understand that one. Consider:

Thread 1 (some time after main() was entered):

    Class1 *p = new Class1;

    // Pass p to Thread 2 or, alteratively, assign p to some
    // global variable, properly protected by a lock.

    lock(someMutex);
    global_p = p;
    unlock(someMutex);

Thread 2:

    // Use the passed p to call getVal() or, alternatively,
    // read the global variable containing p, again properly
    // protected by a lock, and then call getVal().

    lock(someMutex);
    Class1 *p = global_p;
    unlock(someMutex);
    // ...
    p->getVal();  // Problem here, I think

The problem here is that p is passed correctly, but no lock is
ever acquired that would protect the contents of the instance
pointed to by p, namely _val.

If Thread 2 previously has read a variable on the heap and
the cache line containing that variable also happens to contain
the instance of Class1, Thread 2 can read a stale value of _val
when it calls getVal(), no?

>       Translation: Properly coded, you WILL NOT have one thread access
>       a class instance before it's been fully constructed, UNLESS your
>       architecture doesn't have atomic writes for pointers.

My concern isn't accessing the value before the instance is constructed.
The concern is reading a stale value of _val some time after the instance
is constructed. Without a lock in the constructor and getVal(), I don't
see any way the hardware could figure out when it might possibly reading
stale memory.

> Do you need a write barrier?  Yes.  The easiest way to do this is to
> just mark the pointer as "volatile", requiring that the compiler always
> re-check the memory on reads.

I've never been comfortable with the semantics of volatile. I agree,
things should work correctly if something is marked as volatile,
but I'm not sure the C++ standard actually guarantees that a memory
barrier will be placed around a volatile access by the compiler.
I think all that volatile guarantees is that memory will be read
on access, so things will work correctly, for example, for memory-
mapped registers. But I'm not sure that volatile guarantees memory
consistency.

And, of course, in C#, there is no volatile keyword, so I guess
I still have to use a hard lock.

>>So, I guess another way to phrase my question is to ask whether
>>C# guarantees to insert a memory barrier at the end of the
>>constructor if readonly members were initialized by that constructor.
> 
> 
> No.  See other posts about the lax memory model semantics provided by
> the CLI standard.

OK, thanks, that is the main thing I was concerned about.


>>Could you point me at where the CLI memory consistency model is defined?
>>I couldn't find any such thing in the C# documentation.
> 
> 
> You don't want the C# standard, you want the CLI standard, ECMA 335:
> 
> 	http://www.ecma-international.org/publications/standards/Ecma-335.htm

Thanks muchly!

>>>Const members are safe, as these are "burned" into the CIL, and cannot
>>>be changed without recompiling.  They're just like enumeration members.
>>>You can't change enumeration values after you've compiled. :-)
>>
>>Hmmm... Even those wouldn't be necessarily safe. The would be
>>safe only if the language definition guarantees that const members
>>end up in the initialized data segment. However, an equally valid
>>implementation for const members would be to initialize them
>>at run time, during program startup. In that case, all bets would
>>be off. So, does the CLR or C# guarantee that const members
>>are in the initialized data segment?
> 
> 
> Const members are *so* const, that the compiler is permitted to inline
> their values so that cross-assembly references are removed.  So:
> 
> 	enum Foo {Bar = 42;}
> 	Foo foo = Foo.Bar;
> 
> is basically the same as
> 
> 	int foo = 42;

Hmmm... Doesn't the language spec say that things will be initialized
some time before they are accessed, but not necessarily on program
startup? If the compiler generates code to do lazy initialization, I
think things could still go wrong?

>>>No.  Static members are initialized by the class constructor (".cctor"),
>>>and the runtime has an internal lock to ensure that only one thread
>>>executes the class constructor.
>>
>>Right. But without the reading thread grabbing the lock, there is
>>nothing to tell the hardware that the thread may be reading
>>inconsistent memory, I would think.
> 
> 
> The runtime runs the class constructors from within a global runtime
> lock.  No other threads can access any class members (fields, methods,
> constructors, etc.) until the class constructor finishes executing.  And
> if the class constructor generates an exception, you get a
> TypeLoadException, and you'll NEVER be able to access *anything* on the
> class.

Sure, but I'm not concerned about accessing the instance before it is
constructed, but about accessing the contents of the instance after
construction without holding a lock. In that case, I don't think the
hardware can know that I might possibly be reading stale memory.

Cheers,

Michi.



From michi at zeroc.com  Wed Feb 18 20:39:41 2004
From: michi at zeroc.com (Michi Henning)
Date: Thu, 19 Feb 2004 11:39:41 +1000
Subject: [Mono-devel-list] Thread safety of readonly data members?
In-Reply-To: <40341037.9030204@zeroc.com>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>	 <1077066622.17796.11.camel@melchior.magi> <4032C19C.20501@zeroc.com>	 <1077104974.19836.22.camel@melchior.magi>	 <004701c3f655$2bcfd640$0101010a@qld.bigpond.net.au> <1077147373.22151.42.camel@melchior.magi> <40341037.9030204@zeroc.com>
Message-ID: <403413DD.1040607@zeroc.com>

Michi Henning wrote:

> And, of course, in C#, there is no volatile keyword, so I guess
> I still have to use a hard lock.

Oops, how embarrassing :-(  Just found this in the doc:

	volatile <declaration>

	The system always reads the current value of a
	volatile object at the point it is requested, even
	if the previous instruction asked for a value from
	the same object. Also, the value of the object is
	written immediately on assignment.

	The volatile modifier is usually used for a field that
	is accessed by multiple threads without using the lock
	statement to serialize access. Using the volatile modifier
	ensures that one thread retrieves the most up-to-date value
	written by another thread.

Well, that definitely answers my question :-)

Sorry for all the unnecessary noise I made!

Cheers,

Michi.




From jonpryor at vt.edu  Thu Feb 19 06:52:24 2004
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Thu, 19 Feb 2004 06:52:24 -0500
Subject: [Mono-devel-list] Thread safety of readonly data members?
In-Reply-To: <40341037.9030204@zeroc.com>
References: <009701c3f5a4$c78e9dc0$0300a8c0@GLENBURGIE>
	 <1077066622.17796.11.camel@melchior.magi> <4032C19C.20501@zeroc.com>
	 <1077104974.19836.22.camel@melchior.magi>
	 <004701c3f655$2bcfd640$0101010a@qld.bigpond.net.au>
	 <1077147373.22151.42.camel@melchior.magi>  <40341037.9030204@zeroc.com>
Message-ID: <1077191541.23057.18.camel@melchior.magi>

Below...

On Wed, 2004-02-18 at 20:24, Michi Henning wrote:

<snip/>

> Hmmm... It's not uncommon for one thread to hold a pointer to a stack-
> allocated variable in another thread, so I guess the problem could
> arise in that case.

I've never seen this, and consider it an bizarre idea.  The whole point
of having stack-allocated objects is so that you *don't* have to
lock/share them.  Plus, I'd expect that you'd have difficulties ensuring
the the stack-allocated object lives long enough for the other thread to
*not* corrupt memory when the function exits scope...

<snip/>

> If Thread 2 previously has read a variable on the heap and
> the cache line containing that variable also happens to contain
> the instance of Class1, Thread 2 can read a stale value of _val
> when it calls getVal(), no?

Answer: no.  I would suggest you pick up a book on hardware
architecture.  I used "Parallel Computer Architecture: A
Hardware/Software Approach" by David E. Culler and Jaswinder Pal Singh
in my Computer Architecture classes.  I won't call it wonderful (the
index is lacking in some ways), but it's thorough.

There are several ways for the hardware to ensure that stale values
don't remain within the cache lines, including:
  - Bus Snooping
  - Three-State MSI (Modified, Shared, Invalid) Write-Back Invalidation 
    Protocol
  - Four-State MESI (Modified, Exclusive-Clean, Shared, Invalid)
    Write-Back Invalidation Protocol, which is used by all Pentium-Pro
    and above Intel processors.

The hardware is designed to help you with cache coherence.  The scenario
you're describing SHOULD NOT happen.

What you do need to worry about is that you have memory barriers when
you want them.  It was my understanding that reading/writing to volatile
memory was a way of inserting memory barriers in C++.

<snip/>

> I've never been comfortable with the semantics of volatile. I agree,
> things should work correctly if something is marked as volatile,
> but I'm not sure the C++ standard actually guarantees that a memory
> barrier will be placed around a volatile access by the compiler.
> I think all that volatile guarantees is that memory will be read
> on access, so things will work correctly, for example, for memory-
> mapped registers. But I'm not sure that volatile guarantees memory
> consistency.

I don't think C++ provides any other mechanism within the standard.

Then again, C++ wasn't originally designed for a threaded environment,
and I keep reading articles implying that the next major version (C++
0x) will have additional features for threading, though they may just be
referring to the boost::threading libraries.

> And, of course, in C#, there is no volatile keyword, so I guess
> I still have to use a hard lock.

I see you answered this yourself already.

<snip/>

> Hmmm... Doesn't the language spec say that things will be initialized
> some time before they are accessed, but not necessarily on program
> startup? If the compiler generates code to do lazy initialization, I
> think things could still go wrong?

What the runtime does is out of our (the programmers) hands.  So if the
runtime does the wrong thing, it's a runtime bug.  The programmer needs
some assurance that const members will actually be initialized before
first use, or it's *impossible* to do *anything* reliably.

The runtime *must* ensure that const members are initialized in a
thread-safe manner, so that programs can't see the value change.

<snip/>

> Sure, but I'm not concerned about accessing the instance before it is
> constructed, but about accessing the contents of the instance after
> construction without holding a lock. In that case, I don't think the
> hardware can know that I might possibly be reading stale memory.

The hardware can know, as I alluded to above.

 - Jon




From 05mauben at hawken.edu  Thu Feb 19 08:11:12 2004
From: 05mauben at hawken.edu (Ben Maurer)
Date: Thu, 19 Feb 2004 08:11:12 -0500
Subject: [Mono-devel-list] Performance w/ boxing
Message-ID: <s0346fcd.083@gm004.hawken.edu>

Hey guys,

Today I posted a blog entry about the performance of boxing. Someone
posted that MS was a few times faster on the test. My first reaction was
that this was a GC problem, however given the nature of the test case,
the generational GC does not give MS much of an advantage. I am not
really sure what is up.

I would be interested if any of the runtime guys have any ideas about
how to speed this up. The code is below:

using System; 

class T { 
     const int iters = 10, value = 32; 
      
     public static int fib (int n) { 
          if (n < 2) return 1; 
          return fib (n-2) + fib (n-1); 
     } 
      
     public static object fib_box (object n) { 
          int nn = (int) n; 
          if (nn < 2) return 1; 
          return (int) fib_box (nn-2) + (int) fib_box (nn-1); 
     } 
      
     public static void Main () { 
          // jit everything, so we dont get funk 
          fib (1); 
          fib_box (1); 
          { DateTime foo = DateTime.Now; } 
           
          DateTime t1 = DateTime.Now; 
           
          for (int i = 0; i < iters; i ++) fib (value); 
           
          DateTime t2 = DateTime.Now; 
           
          for (int i = 0; i < iters; i ++) fib_box (value); 
           
          DateTime t3 = DateTime.Now; 
           
          Console.WriteLine ("NO BOXING  : {0}", t2 - t1); 
          Console.WriteLine ("WITH BOXING: {0}", t3 - t2); 
     } 
}

My results were:
NO BOXING  : 00:00:01.2031260
WITH BOXING: 00:00:59.2343780

Someone with windows tested and got:
C:\Playground\Mono>boxtest
NO BOXING : 00:00:02.7439456
WITH BOXING: 00:00:15.9729680

C:\Playground\Mono>mono boxtest.exe
NO BOXING : 00:00:03.6550000
WITH BOXING: 00:03:27.9590000



From lupus at ximian.com  Thu Feb 19 10:30:51 2004
From: lupus at ximian.com (Paolo Molaro)
Date: Thu, 19 Feb 2004 16:30:51 +0100
Subject: [Mono-devel-list] Performance w/ boxing
In-Reply-To: <s0346fcd.083@gm004.hawken.edu>
References: <s0346fcd.083@gm004.hawken.edu>
Message-ID: <20040219153051.GG15746@debian.org>

On 02/19/04 Ben Maurer wrote:
> Today I posted a blog entry about the performance of boxing. Someone
> posted that MS was a few times faster on the test. My first reaction was
> that this was a GC problem, however given the nature of the test case,
> the generational GC does not give MS much of an advantage. I am not

You obviously have no idea of how a generational GC works.

> I would be interested if any of the runtime guys have any ideas about
> how to speed this up. The code is below:

Of course we have ideas, we actually think about the cause of performance
issues.
Do you want a 50+% speedup over the current time? Use a generational GC.
A 10% speedup? Make stack unwinding work across the managed->unmanaged
boundary with any compiler.
Another 5-10% speedup? Get the jit to produce better code (especially
better register allocation).

lupus

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


From JGerdes at quilogy.com  Thu Feb 19 10:48:19 2004
From: JGerdes at quilogy.com (Josh Gerdes)
Date: Thu, 19 Feb 2004 09:48:19 -0600
Subject: [Mono-devel-list] Error compiling mcs 0.30.1 on windows
Message-ID: <766EBC6CFD9DDB4EAADF2E8082DFA95007A4744B@frontier.solutechinc.com>

I am attempting to successfully compile both mono and mcs (and
eventually gtk-sharp 0.16) on windows (XP SP1) with cygwin and I have
had some success with a successful build of mono 0.30.1 by slightly
modifying these instructions I found on the mono-devel list:
 
http://lists.ximian.com/archives/public/mono-devel-list/2004-January/003
439.html
 
The snag I am having is when I try to compile the mcs 0.30.1 source.
When I run make I get the following error:
 
=====================================================================
$ make
make[1]: Entering directory `/home/jgerdes/src/mcs-0.30.1/build'
make[1]: Leaving directory `/home/jgerdes/src/mcs-0.30.1/build'
make[1]: Entering directory `/home/jgerdes/src/mcs-0.30.1/jay'
gcc -mno-cygwin -DSKEL_DIRECTORY=\""/usr/local/share/jay"\" -g -O2 -c -o
closure
.o closure.c
gcc -mno-cygwin -DSKEL_DIRECTORY=\""/usr/local/share/jay"\" -g -O2 -c -o
error.o
 error.c
gcc -mno-cygwin -DSKEL_DIRECTORY=\""/usr/local/share/jay"\" -g -O2 -c -o
lalr.o
lalr.c
gcc -mno-cygwin -DSKEL_DIRECTORY=\""/usr/local/share/jay"\" -g -O2 -c -o
lr0.o l
r0.c
gcc -mno-cygwin -DSKEL_DIRECTORY=\""/usr/local/share/jay"\" -g -O2 -c -o
main.o
main.c
gcc -mno-cygwin -DSKEL_DIRECTORY=\""/usr/local/share/jay"\" -g -O2 -c -o
mkpar.o
 mkpar.c
gcc -mno-cygwin -DSKEL_DIRECTORY=\""/usr/local/share/jay"\" -g -O2 -c -o
output.
o output.c
gcc -mno-cygwin -DSKEL_DIRECTORY=\""/usr/local/share/jay"\" -g -O2 -c -o
reader.
o reader.c
gcc -mno-cygwin -DSKEL_DIRECTORY=\""/usr/local/share/jay"\" -g -O2 -c -o
symtab.
o symtab.c
gcc -mno-cygwin -DSKEL_DIRECTORY=\""/usr/local/share/jay"\" -g -O2 -c -o
verbose
.o verbose.c
gcc -mno-cygwin -DSKEL_DIRECTORY=\""/usr/local/share/jay"\" -g -O2 -c -o
warshal
l.o warshall.c
gcc -mno-cygwin -DSKEL_DIRECTORY=\""/usr/local/share/jay"\" -g -O2 -o
jay closur
e.o error.o lalr.o lr0.o main.o mkpar.o output.o reader.o symtab.o
verbose.o war
shall.o
main.o(.text+0x500): In function `create_file_names':
/home/jgerdes/src/mcs-0.30.1/jay/main.c:291: undefined reference to
`_mkstemp'
main.o(.text+0x50d):/home/jgerdes/src/mcs-0.30.1/jay/main.c:292:
undefined refer
ence to `_mkstemp'
main.o(.text+0x51a):/home/jgerdes/src/mcs-0.30.1/jay/main.c:293:
undefined refer
ence to `_mkstemp'
collect2: ld returned 1 exit status
make[1]: *** [jay] Error 1
make[1]: Leaving directory `/home/jgerdes/src/mcs-0.30.1/jay'
make: *** [all-recursive] Error 1
=====================================================================
 
 
I am currently just trying to get a downloadable release version of mcs
compiled and I was wondering if anyone has seen this issue and how they
went about solving it.  What is "_mkstemp" and how do I set the
reference for it?
 
I also would suggest putting some sort of updated instructions on how to
get all of these great tools compiled on windows on the mono site.  It
would be very helpful for everyone trying to work with them on windows.
I will be more than happy to send on the instructions I have once I get
them working fully.
 
Thanks,
 
Josh

 

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

From jackson at ximian.com  Thu Feb 19 11:04:59 2004
From: jackson at ximian.com (Jackson Harper)
Date: Thu, 19 Feb 2004 08:04:59 -0800
Subject: [Mono-devel-list] Exception in global_asax, Session_Start not
	called
In-Reply-To: <1077126794.3792.17.camel@leonardo.hotfeet.ch>
References: <1077126794.3792.17.camel@leonardo.hotfeet.ch>
Message-ID: <1077206698.23143.5.camel@localhost.localdomain>

Hello,

Please file a bug report and attach your test cases.

Thanks!
Jackson


On Wed, 2004-02-18 at 09:53, Juraj Skripsky wrote:
> Hello,
> 
> The attached files work fine on MS.Net but fail on Mono (0.30.1).
> 
> The problems are:
> - exception on access to the <object>-declared properties
> "myApplication" in the auto-generated class "global_asax".
> - "Session_Start" in global.asax is never called.
> 
> Should I file a bug report?
> 
> 
> ---
> Juraj Skripsky <juraj at hotfeet.ch>
> HotFeet - developing the web
> Technopark Zurich
> Switzerland



From olds at novell.com  Thu Feb 19 11:23:16 2004
From: olds at novell.com (Dale Olds)
Date: Thu, 19 Feb 2004 09:23:16 -0700
Subject: [Mono-devel-list] string corruption
Message-ID: <1077207795.2920.20.camel@jed.local>

Hi,

I have been seeing some strange behavior with strings apparently
forgetting their values, and have distilled it down to the attached test
case. The test case involves nested value types that have a reference
type member, though I'm not sure that is directly related to the
problem. The test case succeeds if the the call to GC.Collect() is
removed.

The test fails on mono .30.1. I have not run this test on .net, but the
original problem from which this test was derived did not fail on .net
(but did on mono). Since the string contents in all the nested structs
after the call to GC.Collect() appear to be random memory (remove the
return to see this), I can't imagine it would be good even if it was
like .net.

Any ideas? I am not currently running on a build from CVS, but can do so
if it would help to further test this.

Thanks,
--Dale

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: values.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040219/5a053cef/attachment.pl 

From olds at novell.com  Thu Feb 19 11:28:15 2004
From: olds at novell.com (Dale Olds)
Date: Thu, 19 Feb 2004 09:28:15 -0700
Subject: [Mono-devel-list] string corruption
Message-ID: <1077207795.2920.20.camel@jed.local>

Hi,

I have been seeing some strange behavior with strings apparently
forgetting their values, and have distilled it down to the attached test
case. The test case involves nested value types that have a reference
type member, though I'm not sure that is directly related to the
problem. The test case succeeds if the the call to GC.Collect() is
removed.

The test fails on mono .30.1. I have not run this test on .net, but the
original problem from which this test was derived did not fail on .net
(but did on mono). Since the string contents in all the nested structs
after the call to GC.Collect() appear to be random memory (remove the
return to see this), I can't imagine it would be good even if it was
like .net.

Any ideas? I am not currently running on a build from CVS, but can do so
if it would help to further test this.

Thanks,
--Dale

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: values.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040219/5a053cef/attachment-0001.pl 

From craig at ip80.com  Thu Feb 19 11:41:02 2004
From: craig at ip80.com (Craig Williams)
Date: Thu, 19 Feb 2004 11:41:02 -0500
Subject: [Mono-devel-list] drawing
Message-ID: <Sea2-DAV62pOlJrMjfF0000fbda@hotmail.com>

Hello,

I see that the Drawing namespace works via gdi+ on both Windows and Linux so I was wondering why we don't just
develop controls using that Library instead of relying on gtk+ which must be installed on Windows?

Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20040219/bd4bfe6a/attachment.html 

From webmaster at ajlopez.com  Thu Feb 19 12:09:24 2004
From: webmaster at ajlopez.com (Angel "Java" Lopez)
Date: Thu, 19 Feb 2004 14:09:24 -0300
Subject: [Mono-devel-list] drawing
References: <Sea2-DAV62pOlJrMjfF0000fbda@hotmail.com>
Message-ID: <005f01c3f70b$25c27df0$0201a8c0@exyzt.local>

Hi people!

I remember that this is the DotGNU approach.....

From:

http://www.dotgnu.org/pnet.html
"An advantage of our implementation of System.Windows.Forms is that we don't
try to wrap up third party widget sets like Gtk, Qt, Wine, etc. Instead, we
provide a basic drawing layer and then render the controls ourselves. The
approach is similar to Java Swing, in that all controls are implemented in
pure C#."

Angel "Java" Lopez
http://www.ajlopez.com/

----- Original Message ----- 
From: "Craig Williams" <craig at ip80.com>
To: <mono-devel-list at lists.ximian.com>
Sent: Thursday, February 19, 2004 1:41 PM
Subject: [Mono-devel-list] drawing


Hello,

I see that the Drawing namespace works via gdi+ on both Windows and Linux so
I was wondering why we don't just
develop controls using that Library instead of relying on gtk+ which must be
installed on Windows?

Craig



From 05mauben at hawken.edu  Thu Feb 19 13:04:38 2004
From: 05mauben at hawken.edu (Ben Maurer)
Date: Thu, 19 Feb 2004 13:04:38 -0500
Subject: [Mono-devel-list] Performance w/ boxing
Message-ID: <s034b475.095@gm004.hawken.edu>

Well, given that no objects are promoted past gen0 with the MS GC, I am
not sure how theirs is any better. (in a real life test, where there
were other allocations, their GC would obviously have an edge). Then
again, I will admit I do not know much about GCs ;-