[Mono-dev] [PATCH] Align the behavior of generic SortedList to .Net behavior
Hi,
can anyone review this patch that align the behavior of Keys and
Values Enumerator of SortedListTKey,TValue to the behavior of .NET
(I tested it on VS C# Express).
Changes on UnitTest are also provided.
Code is contributed under MIT/X11 license.
Best Regards
Torello Querci
Index: mcs/class/System/Test/System.Collections.Generic/SortedListTest.cs
===
--- mcs/class/System/Test/System.Collections.Generic/SortedListTest.cs (revisione 125931)
+++ mcs/class/System/Test/System.Collections.Generic/SortedListTest.cs (copia locale)
@@ -275,6 +275,54 @@
Assert.AreEqual (B, values [1]);
Assert.AreEqual (C, values [2]);
}
+
+ [Test]
+ [ExpectedException (typeof (InvalidOperationException))]
+ public void EnumeratorKeysInvalid () {
+ IEnumeratorint en=list.Keys.GetEnumerator ();
+ bool toDelete=true;
+ while (en.MoveNext ()) {
+if (toDelete) {
+ list.RemoveAt (1);
+ toDelete = false;
+}
+ }
+
+ }
+
+ [Test]
+ public void EnumeratorKeysReset () {
+ IEnumeratorint en=list.Keys.GetEnumerator ();
+ en.MoveNext ();
+ en.Reset ();
+ while (en.MoveNext ()) {
+ }
+
+ }
+
+ [Test]
+ [ExpectedException (typeof (InvalidOperationException))]
+ public void EnumeratorValuesInvalid () {
+ IEnumeratorstring en=list.Values.GetEnumerator ();
+ bool toDelete=true;
+ while (en.MoveNext ()) {
+if (toDelete) {
+ list.RemoveAt (1);
+ toDelete = false;
+}
+ }
+
+ }
+
+ [Test]
+ public void EnumeratorValuesReset () {
+ IEnumeratorstring en=list.Values.GetEnumerator ();
+ en.MoveNext ();
+ en.Reset ();
+ while (en.MoveNext ()) {
+ }
+
+ }
}
}
Index: mcs/class/System/System.Collections.Generic/SortedList.cs
===
--- mcs/class/System/System.Collections.Generic/SortedList.cs (revisione 125931)
+++ mcs/class/System/System.Collections.Generic/SortedList.cs (copia locale)
@@ -680,16 +680,16 @@
//
- private sealed class Enumerator : ICloneable, IDictionaryEnumerator, IEnumerator {
+ private class Enumerator : ICloneable, IDictionaryEnumerator, IEnumerator {
- private SortedListTKey, TValuehost;
- private int stamp;
- private int pos;
- private int size;
- private EnumeratorMode mode;
+ protected SortedListTKey, TValuehost;
+ protected int stamp;
+ protected int pos;
+ protected int size;
+ protected EnumeratorMode mode;
- private object currentKey;
- private object currentValue;
+ protected object currentKey;
+ protected object currentValue;
bool invalid = false;
@@ -878,8 +878,7 @@
public virtual IEnumeratorTKey GetEnumerator ()
{
-for (int i = 0; i host.Count; ++i)
- yield return host.KeyAt (i);
+return new KeysEnumerator(host);
}
//
@@ -926,6 +925,54 @@
}
}
+ private sealed class KeysEnumerator : Enumerator, IEnumeratorTKey {
+
+ public KeysEnumerator (SortedListTKey, TValue host) : base(host)
+ {
+ }
+
+ TKey IEnumeratorTKey.Current {
+get {
+ return (TKey)currentKey;
+}
+ }
+
+ object IEnumerator.Current {
+get {
+ return currentKey;
+}
+ }
+
+ public void Dispose () {
+currentKey=default (TKey);
+host=null;
+ }
+ }
+
+ private sealed class ValuesEnumerator : Enumerator, IEnumeratorTValue {
+
+ public ValuesEnumerator (SortedListTKey, TValue host) : base(host)
+ {
+ }
+
+ TValue IEnumeratorTValue.Current {
+get {
+ return (TValue)currentValue;
+}
+ }
+
+ object IEnumerator.Current {
+get {
+ return currentValue;
+}
+ }
+
+ public void Dispose () {
+currentKey=default (TKey);
+host=null;
+ }
+ }
+
private class ListValues : IListTValue, ICollection, IEnumerable {
private SortedListTKey, TValuehost;
@@ -1003,8 +1050,7 @@
public virtual IEnumeratorTValue GetEnumerator ()
{
-for (int i = 0; i host.Count; ++i)
- yield return host.ValueAt (i);
+return new ValuesEnumerator(host);
}
//
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar -- View this message in context: http://www.nabble.com/Qt-anyone--tp21863769p21864160.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
That crtical part you can code in Boo, using Boo Macros, which would perform just as you want, and have only the external API paying the call cost. Just an idea to leverage the multilanguage abilities in Mono/.NET. Fun, On Wed, Feb 4, 2009 at 2:18 PM, russell@realtimeworlds.com wrote: Yes but this is only for a very small class of functions that we know will work correctly within these constraints... its not for everyone I know, but it is still a feature that we would like to have. Russell -Original Message- From: Mark Probst [mailto:mark.pro...@gmail.com] Sent: 04 February 2009 16:14 To: Jb Evain Cc: Russell Kay; mono-devel-list@lists.ximian.com; sc...@ssblack.co.nz Subject: Re: [Mono-dev] gmcs and The Future On Wed, Feb 4, 2009 at 5:10 PM, Jb Evain j...@nurv.fr wrote: So I'm not expecting the C# compiler to output anything other than IL but just eliminate the calling overhead and not relying on the JIT to do the inlining. That's just not possible for a large majority of the cases, as it would cause a lot of access exceptions. You can't simply inline an instance method which reads a private field in its own type, inside another type for instance. Apart from the fact that if you're inlining a method from a different assembly by importing it you're not only depending on the interface of the assembly not to change in the future, but also on the implementation, which is a very bad idea. Mark -- Mark Probst http://www.complang.tuwien.ac.at/schani/ http://www.flickr.com/photos/schani/ http://schani.wordpress.com/ This email has been scanned by the MessageLabs Email Security System DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- I myself am made entirely of flaws, stitched together with good intentions. Augusten Burroughs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
Ok, great. The problem is exactly what you mentioned: with no website and no info... there's no way developers can get interested on it. SE1 escribió: pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpWebResponse ConnectStream blocks on empty stream
Hey Gonzalo, This does not appear to be fixed in SVN HEAD. It always takes 15 seconds (while I've explicitly set the ReadWriteTimeout to 50 seconds) to get the zero length response. I'm testing this on Windows. I get the exact same behavior on Linux with an older revision of Mono. I'll update my Linux version after I've added unit tests or standalone tests for a few more fixes. Gert -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Gonzalo Paniagua Javier Sent: woensdag 4 februari 2009 4:45 To: Arne Claassen Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] HttpWebResponse ConnectStream blocks on empty stream On Tue, 2009-02-03 at 09:29 -0800, Arne Claassen wrote: I've been having a problem with HttpWebResponse locking up on GetResponseSream and BeingGetResponseStream never returning on responses that have no content-length header and no content. On .NET this will return immediately, but on mono (1.9.1, 2.0.1 and 2.02) the read will block only to be killed if the request itself has a timeout. A simple repro is to his a site, get it's Etag/LastModified and hit it again for the 304 response which should have no content. However getting that response stream still shouldn't lock up. This issue has already been fixed. I don't know if it made it to 2.2, but the fix will be for sure in the upcoming 2.4. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.15/1923 - Release Date: 1/29/2009 7:13 AM ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
I wonder (may be a silly idea but) if there is any chance that mono team can take the initiative to derive the ECMA C# standard in future 2009/2/6 Rafael Teixeira mono...@gmail.com: That crtical part you can code in Boo, using Boo Macros, which would perform just as you want, and have only the external API paying the call cost. Just an idea to leverage the multilanguage abilities in Mono/.NET. Fun, On Wed, Feb 4, 2009 at 2:18 PM, russell@realtimeworlds.com wrote: Yes but this is only for a very small class of functions that we know will work correctly within these constraints... its not for everyone I know, but it is still a feature that we would like to have. Russell -Original Message- From: Mark Probst [mailto:mark.pro...@gmail.com] Sent: 04 February 2009 16:14 To: Jb Evain Cc: Russell Kay; mono-devel-list@lists.ximian.com; sc...@ssblack.co.nz Subject: Re: [Mono-dev] gmcs and The Future On Wed, Feb 4, 2009 at 5:10 PM, Jb Evain j...@nurv.fr wrote: So I'm not expecting the C# compiler to output anything other than IL but just eliminate the calling overhead and not relying on the JIT to do the inlining. That's just not possible for a large majority of the cases, as it would cause a lot of access exceptions. You can't simply inline an instance method which reads a private field in its own type, inside another type for instance. Apart from the fact that if you're inlining a method from a different assembly by importing it you're not only depending on the interface of the assembly not to change in the future, but also on the implementation, which is a very bad idea. Mark -- Mark Probst http://www.complang.tuwien.ac.at/schani/ http://www.flickr.com/photos/schani/ http://schani.wordpress.com/ This email has been scanned by the MessageLabs Email Security System DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- I myself am made entirely of flaws, stitched together with good intentions. Augusten Burroughs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpWebResponse ConnectStream blocks on empty stream
Gonzalo, It's related to the keep-alive timeout, which is 15 seconds. Also, the NoContentLength test in HttpWebRequestTest still does not pass; probably it's just my test that sucks though. Gert -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Gert Driesen Sent: vrijdag 6 februari 2009 13:12 To: 'Gonzalo Paniagua Javier'; 'Arne Claassen' Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] HttpWebResponse ConnectStream blocks on empty stream Hey Gonzalo, This does not appear to be fixed in SVN HEAD. It always takes 15 seconds (while I've explicitly set the ReadWriteTimeout to 50 seconds) to get the zero length response. I'm testing this on Windows. I get the exact same behavior on Linux with an older revision of Mono. I'll update my Linux version after I've added unit tests or standalone tests for a few more fixes. Gert -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Gonzalo Paniagua Javier Sent: woensdag 4 februari 2009 4:45 To: Arne Claassen Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] HttpWebResponse ConnectStream blocks on empty stream On Tue, 2009-02-03 at 09:29 -0800, Arne Claassen wrote: I've been having a problem with HttpWebResponse locking up on GetResponseSream and BeingGetResponseStream never returning on responses that have no content-length header and no content. On .NET this will return immediately, but on mono (1.9.1, 2.0.1 and 2.02) the read will block only to be killed if the request itself has a timeout. A simple repro is to his a site, get it's Etag/LastModified and hit it again for the 304 response which should have no content. However getting that response stream still shouldn't lock up. This issue has already been fixed. I don't know if it made it to 2.2, but the fix will be for sure in the upcoming 2.4. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.15/1923 - Release Date: 1/29/2009 7:13 AM ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.15/1923 - Release Date: 1/29/2009 7:13 AM ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] weird regression in 2.2 remoting
Hi, I'm having a lot of trouble with remoting and mono 2.2 in a very specific scenario. We extensively use PNUnit (Parallel NUnit) for testing our software. We run tests on Windows, Linux, MacOS x86 PPC and now Solaris. Well, I've just installed Mono 2.2 on MacOS PPC and PNUnit fails. It gets a problem initializing sockets when having to call back a remoting interface. It didn't happen on 2.0.1 and it doesn't happen on 2.4 preview 2. I was trying to isolate a test case but no way I can reproduce it outside the PNUnit. It fails too with official 2.2 on OpenSuse 11. The message is: An exception was thrown by the type initializer for System.Net.Sockets.Socket and the call stack points to TcpConnectionPool.cs:277 pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Mono 2.4 Preview 2...
Hi List, any chance of getting rid of this bug in 2.4 release ? https://bugzilla.novell.com/show_bug.cgi?id=473303 Best regards, Christian Prochnow -- Christian Prochnow Geschäftsführer SecuLogiX Systems GmbH Mohriner Allee 28 12347 Berlin http://www.seculogix.de mobile: +49 (0)177 313 02 57 fon: +49 (0)700 SECULOGIX Geschäftsführer: Christian Prochnow Handelsregister: B 96491, Amtsgericht Charlottenburg ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
Qyoto / Kimono Project http://ekarchive.elikirk.com/david/qyoto/ Here is a different project with a similar goal of creating CLR bindings for qt - qt4dotnet http://code.google.com/p/qt4dotnet/ If you google, you might be able to find ancient C# bindings to qt called qt# - but it has been abandoned. On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Please note, I am not saying anything is wrong with glib and its dependencies, I just think it would be neat to re-write mono using qt instead of glib. This way, you could write mono in C++ and have its internals OOP. Changing subject again, I think its good that there are many GUIs you can choose to use on top of mono: qyoto/kimono, asp.net, gtk#, swf, etc... --- On Fri, 2/6/09, pablosantosl...@terra.es pablosantosl...@terra.es wrote: From: pablosantosl...@terra.es pablosantosl...@terra.es Subject: Re: [Mono-dev] Qt anyone? To: SE1 ikr...@gmail.com Cc: mono-devel-list@lists.ximian.com Date: Friday, February 6, 2009, 6:51 AM Ok, great. The problem is exactly what you mentioned: with no website and no info... there's no way developers can get interested on it. SE1 escribió: pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
Daniel Morgan wrote: On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Can you elaborate on why glib should be replaced? For systems that don't support glib or where glib is undesirable, mono's eglib could be used instead, which is really tiny, BTW. A large part of mono applications is already relying on glib (as part of gtk/gtk#/gnome), so adding just another heavy dependency is not an option IMO. Not to speak about having to deal with 2 message queues, C++, license issues (Novell won't be able to re-release the runtime under a non GPL based license anymore). Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Generic Variance
This refactors some things from the previous patch and adds three new tests.
Index: tests/ChangeLog
===
--- tests/ChangeLog (revision 126049)
+++ tests/ChangeLog (working copy)
@@ -1,3 +1,15 @@
+2009-02-07 Scott Peterson lunchtimem...@gmail.com
+
+ This patch is contributed under the MIT/X11 license.
+
+ * gtest-variance-3.cs: Added test for covariance delegates.
+
+ * gtest-variance-4.cs: Added test for contravariant delegates.
+
+ * gtest-variance-5.cs: Added more complete interface variance test.
+
+ * known-issues-gmcs: Added the 3 new tests to the ignroe list.
+
2009-02-04 Scott Peterson lunchtimem...@gmail.com
This patch is contributed under the MIT/X11 license.
Index: tests/gtest-variance-4.cs
===
--- tests/gtest-variance-4.cs (revision 0)
+++ tests/gtest-variance-4.cs (revision 0)
@@ -0,0 +1,21 @@
+// Compiler options: -langversion:future
+
+delegate int Fooin T (T t);
+
+public class Test
+{
+ static int Main ()
+ {
+ string message = Hello World!;
+ Fooobject foo = (o) = o.GetHashCode ();
+ if (Bar (foo, message) != message.GetHashCode ())
+ return 1;
+
+ return 0;
+ }
+
+ static int Bar (Foostring foo, string s)
+ {
+ return foo(s);
+ }
+}
Index: tests/known-issues-gmcs
===
--- tests/known-issues-gmcs (revision 126049)
+++ tests/known-issues-gmcs (working copy)
@@ -10,5 +10,8 @@
gtest-230.cs
gtest-437.cs
-gtest-variance-1.cs IGNORE # Runtime support for variance is not yet in place
-gtest-variance-2.cs IGNORE
+gtest-variance-1.cs IGNORE # Runtime support for variance is not yet in place
+gtest-variance-2.cs IGNORE
+gtest-variance-3.cs IGNORE
+gtest-variance-4.cs IGNORE
+gtest-variance-5.cs IGNORE
Index: tests/gtest-variance-3.cs
===
--- tests/gtest-variance-3.cs (revision 0)
+++ tests/gtest-variance-3.cs (revision 0)
@@ -0,0 +1,21 @@
+// Compiler options: -langversion:future
+
+delegate T Fooout T ();
+
+public class Test
+{
+ static int Main ()
+ {
+ string message = Hello World!;
+ Foostring foo = () = message;
+ if (Bar (foo) != message.GetHashCode ())
+ return 1;
+
+ return 0;
+ }
+
+ static int Bar (Fooobject foo)
+ {
+ return foo().GetHashCode ();
+ }
+}
Index: tests/gtest-variance-5.cs
===
--- tests/gtest-variance-5.cs (revision 0)
+++ tests/gtest-variance-5.cs (revision 0)
@@ -0,0 +1,84 @@
+// Compiler options: -langversion:future
+
+interface ICovariantout T
+{
+ T Foo { get; }
+}
+
+interface IContravariantin T
+{
+ int Bar (T bar);
+}
+
+interface IBothVariants out T1, in T2 : ICovariantT1, IContravariantT2
+{
+}
+
+interface IInvariant T : ICovariantT, IContravariantT
+{
+}
+
+class BothVariants T1, T2 : IBothVariants T1, T2
+{
+ public BothVariants (T1 foo)
+ {
+ Foo = foo;
+ }
+
+ public T1 Foo { get; private set; }
+
+ public int Bar (T2 bar)
+ {
+ return bar.GetHashCode () ^ Foo.GetHashCode ();
+ }
+}
+
+class Invariant T : IInvariantT where T : new()
+{
+ public T Foo { get { return new T (); } }
+
+ public int Bar (T bar)
+ {
+ return bar.GetHashCode ();
+ }
+}
+
+class A
+{
+ public virtual string Fruit { get { return Apple; } }
+}
+
+class B : A
+{
+ public override string Fruit { get { return Banana; } }
+}
+
+class C : B
+{
+ public override string Fruit { get { return Carrot which I know is not a fruit but you better shut up about it before I cut you; } }
+}
+
+public class Test
+{
+ static int Main ()
+ {
+ var b = new B ();
+ var c = new C ();
+
+ IBothVariantsA, C both = new BothVariantsB,B (b);
+
+ if (both.Bar (c) != (b.GetHashCode () ^ c.GetHashCode ()))
+ return 1;
+
+ IInvariantB neither = new InvariantB ();
+ ICovariantA co = neither;
+ if (co.Foo.Fruit != Banana)
+ return 2;
+
+ IContravariantC contra = neither;
+ if (contra.Bar (c) != c.GetHashCode ())
+ return 3;
+
+ return 0;
+ }
+}
Index: mcs/generic.cs
===
--- mcs/generic.cs (revision 126049)
+++ mcs/generic.cs (working copy)
@@ -1302,7 +1302,61 @@
{
return ConstraintChecker.CheckConstraints (ec, open_type, gen_params, args.Arguments, loc);
}
+
+#if GMCS_SOURCE
+ static bool IsVariant (Type type)
+ {
+ return (type.GenericParameterAttributes GenericParameterAttributes.VarianceMask) != 0;
+ }
+
+ static bool IsCovariant (Type type)
+ {
+ return (type.GenericParameterAttributes GenericParameterAttributes.Covariant) != 0;
+ }
+
+ static bool IsContravariant (Type type)
+ {
+ return (type.GenericParameterAttributes GenericParameterAttributes.Contravariant) != 0;
+ }
+
+#endif
+
+ public bool VerifyVariantTypeParameters ()
+ {
+ return VerifyVariantTypeParameters (type);
+ }
+
+ bool VerifyVariantTypeParameters (Type type)
+ {
+#if GMCS_SOURCE
Re: [Mono-dev] Announcing Mono 2.4 Preview 2...
Hey Thomas, Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them: http://www.mono-project.com/Bugs Please add: Bug 473343 - [Regression] WebBrowser becomes unresponsive after Navigate (...) We just found it today. Thanks, -Brad ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Whatever the format of the forum, I would like it to be easy for anyone to participate. A wiki fits the bill, but it might be best to keep this program separate from the primary Mono wiki so that account permissions don't become conflated. What does someone in charge of the Mono site/wiki think (Miguel)? Like I mentioned, Google Groups is another option: it's easy for people to join the fray. It also allows you to organize information with pages, but those cannot be edited collaboratively like a wiki. In the mean time, interested parties, be thinking about your language ideas. Some good things to think about and/or write down might include: * What other languages have this feature, if any? * Example code of your language feature. * The code it would be replacing (i.e. how would I accomplish the same thing today, if possible). * Does this break backwards compatibility in any way (i.e. add a new keyword or such)? * What are the corner cases? Be thinking, and hopefully we'll all be able to share our ideas soon. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Isolated another Moq related VM bug.
Hi guys,
me again, found another Moq related VM bug. Submitted here:
https://bugzilla.novell.com/show_bug.cgi?id=473482
This one is peculiar, it fails on line: var t = ex.StackTrace;
Regards, Bas
using System;
public class Program
{
static void Main()
{
try
{
new Fooobject(0, 0);
}
catch (Exception ex)
{
var t = ex.StackTrace; ==
}
}
}
public class FooT : FooBase
{
int i;
int ii;
public Foo(int i, int ii)
{
this.i = i;
this.ii = ii;
this.iii = 0;
throw new Exception();
}
}
public abstract class FooBase
{
protected int iii;
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpWebResponse ConnectStream blocks on empty stream
On Fri, 2009-02-06 at 14:19 +0100, Gert Driesen wrote: Gonzalo, It's related to the keep-alive timeout, which is 15 seconds. Also, the NoContentLength test in HttpWebRequestTest still does not pass; probably it's just my test that sucks though. It's failing now for me. I'm working on a fix. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpWebResponse ConnectStream blocks on empty stream
On Fri, 2009-02-06 at 14:15 -0500, Gonzalo Paniagua Javier wrote: On Fri, 2009-02-06 at 14:19 +0100, Gert Driesen wrote: Gonzalo, It's related to the keep-alive timeout, which is 15 seconds. Also, the NoContentLength test in HttpWebRequestTest still does not pass; probably it's just my test that sucks though. It's failing now for me. I'm working on a fix. It's fixed now in HEAD and 2-4. Arne, Gert thanks! -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] solaris x86
Try http://blastwave.network.com/testing/mono-2.0,REV=2009.01.21-SunOS5.8-i386-CSW.pkg.gz I'll try to build 2.2 over the weekend. pablo Cetin Sert escribió: I'd like to know where these binaries can be downloaded. Regards, Cetin Sert 2009/2/6 pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es Hi, I've just finished running our internal PNUnit test suite on Open Solaris x86 with hand-compiled Mono 2.2. It works. The same is true for Solaris 10 x86. I've published a test binary release of Mono 2.0.1 for Solaris x86 in blastwave a few weeks ago. Next one will be 2.2. MWF runs on 2.0.1 but (at least on my tests) it was not stable enough. Regards, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
are there tutorials to build on Mac/Linux/Solaris? Daniel Morgan escribió: Qyoto / Kimono Project http://ekarchive.elikirk.com/david/qyoto/ Here is a different project with a similar goal of creating CLR bindings for qt - qt4dotnet http://code.google.com/p/qt4dotnet/ If you google, you might be able to find ancient C# bindings to qt called qt# - but it has been abandoned. On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Please note, I am not saying anything is wrong with glib and its dependencies, I just think it would be neat to re-write mono using qt instead of glib. This way, you could write mono in C++ and have its internals OOP. Changing subject again, I think its good that there are many GUIs you can choose to use on top of mono: qyoto/kimono, asp.net, gtk#, swf, etc... --- On Fri, 2/6/09, pablosantosl...@terra.es pablosantosl...@terra.es wrote: From: pablosantosl...@terra.es pablosantosl...@terra.es Subject: Re: [Mono-dev] Qt anyone? To: SE1 ikr...@gmail.com Cc: mono-devel-list@lists.ximian.com Date: Friday, February 6, 2009, 6:51 AM Ok, great. The problem is exactly what you mentioned: with no website and no info... there's no way developers can get interested on it. SE1 escribió: pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] solaris x86
Well, basically using a Solaris 10 or a OpenSolaris the process is not that hard at it used to be. Follow the instructions on the mono website and don't forget the magic command ulimit -Hs 10240 vi /usr/lib/pkgconfig/glib-2.0.pc - get rid of the -mt param export PKG_CONFIG_PATH=/usr/lib/pkgconfig:$PKG_CONFIG_PATH export PATH=/opt/csw/gcc3/bin:$PATH export CC=gcc export MAKE=gmake export TAR=gtar ulimit -Hs 10240 alias make=gmake export GREP=ggrep export SED=gsed alias ar=gar Cetin Sert escribió: Hi Pablo, Thank you very much for the binaries! Do you have any scripts, guidelines, blog posts etc. about the build process? Regards, Cetin Sert 2009/2/6 pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es Try http://blastwave.network.com/testing/mono-2.0,REV=2009.01.21-SunOS5.8-i386-CSW.pkg.gz I'll try to build 2.2 over the weekend. pablo Cetin Sert escribió: I'd like to know where these binaries can be downloaded. Regards, Cetin Sert 2009/2/6 pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es Hi, I've just finished running our internal PNUnit test suite on Open Solaris x86 with hand-compiled Mono 2.2. It works. The same is true for Solaris 10 x86. I've published a test binary release of Mono 2.0.1 for Solaris x86 in blastwave a few weeks ago. Next one will be 2.2. MWF runs on 2.0.1 but (at least on my tests) it was not stable enough. Regards, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
- Original Message - From: Robert Jordan robe...@gmx.net To: mono-devel-list@lists.ximian.com Sent: Saturday, February 07, 2009 1:33 AM Subject: Re: [Mono-dev] Qt anyone? Daniel Morgan wrote: On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Can you elaborate on why glib should be replaced? I can think of why it should be replaced, but seriously not with Qt... For systems that don't support glib or where glib is undesirable, mono's eglib could be used instead, which is really tiny, BTW. oh, I had not known of this one... maybe then I could get mono to build... A large part of mono applications is already relying on glib (as part of gtk/gtk#/gnome), so adding just another heavy dependency is not an option IMO. Not to speak about having to deal with 2 message queues, C++, license issues (Novell won't be able to re-release the runtime under a non GPL based license anymore). IMO: groan... as I see it, eliminating dependencies is the best. (sorry if all this is uninteresting or already exists, I have not investigated all this...). IMO, I would much rather people abstracted over the whole GUI issue, providing a generic API which would plug into whatever underlying GUI was available and it was told to use (and could multiplex the GUIs, unify message queues, ...). this could then be compared with AWT or similar, where AWT can go through Win32/GDI, GTK, Cocoa, or custom, ... (I could compare it to Swing, but I had largely stopped using Java well before there was Swing, and so have not really investigated how it works...). the main difference though is that it would be preferable if the framework had a separate frontend and backend, so that it would be possible to swap out the internal machinery and direct the same frontend API to different GUI frameworks at runtime (much like how the Linux VFS can manage multiple filesystem types). the purpose of this could be, for example, an app does most of its GUI as a custom OpenGL-based GUI (for example, I typically do this in my apps), but then may choose to pop up a dialog (such as, for example, a load/save dialog) using the native GUI. or maybe, the app is just GL based and wants to use its own GUI, not being plagued with having to be expected to target its output to GTK or similar... (or, for that matter, the API can provide its own GL-based backend, since it is usually not so difficult to make one piece of GL-based code cooperate with another, so long as the app is left with control over the drawing state, and the framework is not too agressive with how it uses GL). an example of this usecase could be, for example, allowing the app to direct the GUI rendering to a render-to-texture context, and directing any input back in through the surface, allowing the GUI to exist self-contained within a surface in a 3D world (meaning, the framework does not directly access the mouse or keyboard, rather events are fed-in through the backend). the framework can then be context-based, allowing for any number of separate GUI-spaces to exist. a render-to-pixel-buffer backend could also be useful (no GL dependencies allowed here), potentially for cases where neither an existing GUI framework or GL are available or desirable. I guess this does leave a slight complexity as to where fonts are stored and managed, so potentially some generic fonts could be managed by the frontend, but the backend manages drawing them, as well as other backend specific fonts. frontend would manage keeping track of widgets and a unified message gueue, but the backends would be responsible for drawing the widgets and possibly also for events. ... in the simple case though, the API could provide utility code to allow much more easily setting up and managing the GUI, and directing the output to GTK or Win32/GDI or similar (although, I would request the API not be structured much like GTK, as personally I find the general approach of GTK trying to make the app be a slave to itself to be a little offensive...). in my custom frameworks, I often end up with an update yourself call, as well as a draw yourself call (maybe N/A or NO-OP for a GTK or GDI based backend, likely these calls would be directed at the backend context rather than the frontend context?...). the app could then be responsible for making sure that these functions are called regularly (potentially per-context). all of this would allow both the flexibility of a customizable GUI, without forcing devs to go back to drawing all their own widgets, ... when the existing frameworks don't exactly work with what they want to do... this would be sort of like on the XBox/360, where the GUI can be used at the same time as the running game, and often the games will
Re: [Mono-dev] Generic Variance
And this adds more test logic (and fixes the tests that was already there).
Index: mono/metadata/class.c
===
--- mono/metadata/class.c (revision 126150)
+++ mono/metadata/class.c (working copy)
@@ -67,6 +67,7 @@
static void setup_generic_array_ifaces (MonoClass *class, MonoClass *iface, MonoMethod **methods, int pos);
static MonoMethod* mono_class_get_virtual_methods (MonoClass* klass, gpointer *iter);
+static gboolean mono_class_has_variant_generic_params (MonoClass *klass);
void (*mono_debugger_class_init_func) (MonoClass *klass) = NULL;
void (*mono_debugger_class_loaded_methods_func) (MonoClass *klass) = NULL;
@@ -2101,6 +2102,36 @@
return (key-interface_id - element-interface_id);
}
+static gboolean
+mono_class_is_variant_of (MonoClass *klass, MonoClass *vklass) {
+ int i;
+ MonoClass *generic = klass-generic_class-container_class;
+ MonoClass *vgeneric = vklass-generic_class-container_class;
+ MonoGenericContainer *container = vgeneric-generic_container;
+
+ if (generic != vgeneric)
+ return FALSE;
+
+ for (i = 0; i container-type_argc; i++) {
+ MonoClass *param_class = mono_class_from_mono_type (klass-generic_class-context.class_inst-type_argv [i]);
+ MonoClass *vparam_class = mono_class_from_mono_type (vklass-generic_class-context.class_inst-type_argv [i]);
+
+ // FIXME this is incorrect
+ if (param_class-valuetype || vparam_class-valuetype)
+ return FALSE;
+
+ if (container-type_params [i].flags GENERIC_PARAMETER_ATTRIBUTE_VARIANCE_MASK) {
+ if ((container-type_params [i].flags GENERIC_PARAMETER_ATTRIBUTE_CONTRAVARIANT) !mono_class_is_assignable_from (param_class, vparam_class))
+return FALSE;
+ if ((container-type_params [i].flags GENERIC_PARAMETER_ATTRIBUTE_COVARIANT) !mono_class_is_assignable_from (vparam_class, param_class))
+return FALSE;
+ } else if (param_class != vparam_class)
+ return FALSE;
+ }
+
+ return TRUE;
+}
+
int
mono_class_interface_offset (MonoClass *klass, MonoClass *itf) {
MonoClass **result = bsearch (
@@ -2116,6 +2147,21 @@
}
}
+int
+mono_class_interface_offset_with_variance (MonoClass *klass, MonoClass *itf) {
+ int i = mono_class_interface_offset (klass, itf);
+ if (i = 0) {
+ return i;
+ } else if (mono_class_has_variant_generic_params (itf)) {
+ for (i = 0; i klass-interface_offsets_count; i++) {
+ if (mono_class_is_variant_of (klass-interfaces_packed[i], itf)) {
+return klass-interface_offsets_packed [i];
+ }
+ }
+ }
+ return -1;
+}
+
static void
print_implemented_interfaces (MonoClass *klass) {
GPtrArray *ifaces = NULL;
@@ -5875,9 +5921,10 @@
container = klass-generic_class-container_class-generic_container;
- for (i = 0; i container-type_argc; ++i)
- if (container-type_params [i].flags (MONO_GEN_PARAM_VARIANT|MONO_GEN_PARAM_COVARIANT))
+ for (i = 0; i container-type_argc; ++i) {
+ if (container-type_params [i].flags GENERIC_PARAMETER_ATTRIBUTE_VARIANCE_MASK)
return TRUE;
+ }
return FALSE;
}
@@ -5919,55 +5966,23 @@
if (MONO_CLASS_IMPLEMENTS_INTERFACE (oklass, klass-interface_id))
return TRUE;
- if (mono_class_has_variant_generic_params (klass)) {
- if (oklass-generic_class) {
-int i;
-gboolean match = FALSE;
-MonoClass *container_class1 = klass-generic_class-container_class;
-MonoClass *container_class2 = oklass-generic_class-container_class;
+ if (mono_class_has_variant_generic_params (klass) oklass-generic_class) {
+ int i;
+ gboolean match = FALSE;
+ MonoClass *container_class1 = klass-generic_class-container_class;
+ MonoClass *container_class2 = oklass-generic_class-container_class;
-/*
- * Check whenever the generic definition of oklass implements the
- * generic definition of klass. The IMPLEMENTS_INTERFACE stuff is not usable
- * here since the relevant tables are not set up.
- */
-for (i = 0; i container_class2-interface_offsets_count; ++i)
- if ((container_class2-interfaces_packed [i] == container_class1) || (container_class2-interfaces_packed [i]-generic_class (container_class2-interfaces_packed [i]-generic_class-container_class == container_class1)))
- match = TRUE;
-
-if (match) {
- MonoGenericContainer *container;
-
- container = klass-generic_class-container_class-generic_container;
-
+ /*
+ * Check whenever the generic definition of oklass implements the
+ * generic definition of klass. The IMPLEMENTS_INTERFACE stuff is not usable
+ * here since the relevant tables are not set up.
+ */
+ for (i = 0; i container_class2-interface_offsets_count; ++i)
+if ((container_class2-interfaces_packed [i] == container_class1) || (container_class2-interfaces_packed [i]-generic_class (container_class2-interfaces_packed [i]-generic_class-container_class == container_class1)))
match = TRUE;
- for (i = 0; i container-type_argc; ++i) {
- MonoClass *param1_class = mono_class_from_mono_type
Re: [Mono-dev] Qt anyone?
- Original Message - From: Andrés G. Aragoneses kno...@gmail.com To: cr88...@hotmail.com Sent: Saturday, February 07, 2009 12:19 PM Subject: Re: Qt anyone? BGB wrote: - Original Message - From: Robert Jordan robe...@gmx.net To: mono-devel-list@lists.ximian.com Sent: Saturday, February 07, 2009 1:33 AM Subject: Re: [Mono-dev] Qt anyone? snip oh well, probably most people would not be so compelled by such an idea, but it is worth a try I guess... Your idea already exists. I don't know about AWT architecture, but a current technology that does this is XUL, and I believe Nokia is expanding it to add Qt into the mix (currently renders on Cocoa, Gtk, and Windows...). so, XUL is accessible from Mono and without involving a dependency on Mozilla's code?... this would be a critical factor (again, I have not looked into this). it is much like, one could argue, Swing exists, but it doesn't do people much good since it exists on the JVM and would have to be ported over... (likewise, me not being that terribly fammiliar with Canvas, which I would have to look into...). or Morphic exists, but it is the same situation... but, alas, something like this would be a good deal of effort defining and specifying things, followed then probably by implementing interfaces and then later implementing default components, ... I guess a much lighter-weight and simpler option would just be to do a custom C#-based GUI framework based on OpenGL, and blow off the larger problems (such as integrating with existing widget frameworks, or trying to provide a common frontend API with other frameworks). but, alas, I mostly develop things in C land anyways, so all this would not do me much good, me better off using my existing custom C-based GUI stuff... (when I was a good deal younger, I used GTK some, but IMO GTK was far more inconvinience and pain than it was worth, and it was much less effort to forsake it and draw my own widgets...). so, in my case (how it is approached): the app requests input state (keyboard and mouse state); this is passed to the GUI in a big update yourself call (the input is then passed to the widgets, which handle whatever input is directed to them); .. typically, here it does any internal stuff, like other update calls (for example: camera, console, world, ...). then the 3D world is set up and drawn (main scene graph or whatever else), .. later on, the app sets up the GL state (glOrtho, ...); draws any generic (non-GUI) overlays, ... calls the GUI's draw yourself handler, which then recursively tells all the widgets to draw themselves, ... .. (but, alas, this approach is widget-based rather than layer-based, so is arguably less ideal...). but, at least, my GUI stuff is more uniform and functional than my app's Scene-Graph support (where it proves problematic to have both a game-like live state while at the same time allowing a uniform interface to 3D modeling tasks, resulting in the creation of different specialized tools for different parts of the modeling, animation, mapping, ... process, even though the backend code is mostly shared...). but, oh well, whatever I guess... Regards. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] solaris x86
Hi Pablo, Do you know where can I find the pkginfo and similar input files to the package builder on Solaris? Did you make your own for the below package, or am I simply too dumb to locate them in the source tree? Thanks, Steffen Enni Date: Fri, 06 Feb 2009 20:35:25 +0100 From: pablosantosl...@terra.es pablosantosl...@terra.es Subject: Re: [Mono-dev] solaris x86 To: Cetin Sert cetin.s...@gmail.com, mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.com Message-ID: 498c90fd.6010...@terra.es Content-Type: text/plain; charset=ISO-8859-1; format=flowed Try http://blastwave.network.com/testing/mono-2.0,REV=2009.01.21-SunOS5.8-i386-CSW.pkg.gz I'll try to build 2.2 over the weekend. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
