From gonzalo@ximian.com Thu Aug 1 00:35:36 2002 From: gonzalo@ximian.com (Gonzalo Paniagua Javier) Date: 01 Aug 2002 01:35:36 +0200 Subject: [Mono-list] XSP HtmlControls and WebControls status In-Reply-To: <006101c238e1$3ddd1010$b9a93942@danpc> References: <20020731220028.GA21234@gollum.gnome-db.org> <006101c238e1$3ddd1010$b9a93942@danpc> Message-ID: <1028158538.538.56.camel@lalo2.micasa> El jue, 01-08-2002 a las 00:25, Daniel Morgan escribió: > What is "rendering"? I meant that most properties and methods are already in there, but Render () method is not implemented (and may be some supporting functions for this one. - Gonzalo From jparsons@jparsons.org Thu Aug 1 03:03:46 2002 From: jparsons@jparsons.org (Jared Parsons) Date: Wed, 31 Jul 2002 21:03:46 -0500 Subject: [Mono-list] CVS update error Message-ID: <20020731184132.26C8560@jparsons.org> I was trying to build Mono today from scratch and I'm running into the following CVS error. cvs server: Updating mono/samples/embed cvs update: move away mono/samples/embed/test.cs; it is in the way C mono/samples/embed/test.cs cvs update: move away mono/samples/embed/teste.c; it is in the way C mono/samples/embed/teste.c Upon receiving this error, I deleted both of the files and updated again. I received the same error so I just completley removed the directory embed and then did "cvs update -d". I received the exact same error. What do I need to do to resolve this issue. Mono will not build when the cvs error occurs. -- Jared Parsons CS2130 TA (jparsons@jparsons.org) From fjh@cs.mu.oz.au Thu Aug 1 03:39:59 2002 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Thu, 1 Aug 2002 12:39:59 +1000 Subject: [Mono-list] Announce: A .NET assembly -> native code generation tool (ala ngen for MONO) In-Reply-To: <1027932403.30838.60.camel@tequila> References: <214ABAB6BF4DC24EAD9AB1C7461DA6A101F302@buebe002.NOE.Nokia.com> <1027829025.3825.308.camel@erandi.boston.ximian.com> <1027932403.30838.60.camel@tequila> Message-ID: <20020801023959.GA30080@ceres.cs.mu.oz.au> On 29-Jul-2002, Dietmar Maurer wrote: > On Sun, 2002-07-28 at 06:03, Miguel de Icaza wrote: > > Zoltan wrote: > > > > > The first version of my ngen clone for MONO is available at: > > > > > > http://www.nexus.hu/vargaz2 Excellent. > > This announcement is of course really exciting. I have only taken a > > very superficial look so far at the code generator, but the approach is > > a very interesting idea. I will let Dietmar and Paolo comment further > > on it. I think this approach is a really good approach. > > What I wanted to look into was to use the JIT to generate code that > > would end up in a library, basically reusing the JIT, but turning on all > > the optimizations for this. > > This approach would also avoid much code duplication. This approach is what MS did. This approach sucks. You just won't get good performance that way. An ahead-of-time compiler can afford to spend a lot more time compiling, and as a result it can use much more sophisticated optimizations than a JIT compiler can. There's no point trying to duplicate all of GCC's optimizations in your JIT compiler; doing that would be a huge amount of code duplication. It's much better to reuse GCC's optimizer, as Zoltan has done. Note also that GCC's optimizer has already been ported to a lot more architectures than the mono JIT has been. For architectures where the choice is to use an interpreter or an ahead-of-time compiler, the ahead-of-time compiler should give a very significant speedup. -- Fergus Henderson | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From fjh@cs.mu.oz.au Thu Aug 1 03:56:28 2002 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Thu, 1 Aug 2002 12:56:28 +1000 Subject: [Mono-list] Announce: A .NET assembly -> native code generation tool (ala ngen for MONO) In-Reply-To: <20020729103402.GP22977@debian.org> References: <214ABAB6BF4DC24EAD9AB1C7461DA6A101F302@buebe002.NOE.Nokia.com> <1027829025.3825.308.camel@erandi.boston.ximian.com> <1027933698.2304.3.camel@tequila> <20020729103402.GP22977@debian.org> Message-ID: <20020801025628.GB30080@ceres.cs.mu.oz.au> On 29-Jul-2002, Paolo Molaro wrote: > My main concern with using gcc is that we might not be able to constrain > the gcc optimizer to obey the CLR rules (Zoltan notes the problem with > division by 0, for example). I think this is something which could be addressed by adding the appropriate option or options to GCC, and making any problematic optimizations conditional on these option(s). Note that GCC already needs to obey the Java/JVM rules -- this is required for gcj. I don't think the CLR rules are any harder, are they? In pratice this is not likely to be a significant issue anyway, since I would expect few .NET programs to really rely on strict adherence to these rules. If problems do occur, they can be addressed as they come up. -- Fergus Henderson | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From fjh@cs.mu.oz.au Thu Aug 1 04:00:56 2002 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Thu, 1 Aug 2002 13:00:56 +1000 Subject: [Mono-list] Announce: A .NET assembly -> native code generation tool (ala ngen for MONO) In-Reply-To: <214ABAB6BF4DC24EAD9AB1C7461DA6A101F302@buebe002.NOE.Nokia.com> References: <214ABAB6BF4DC24EAD9AB1C7461DA6A101F302@buebe002.NOE.Nokia.com> Message-ID: <20020801030055.GC30080@ceres.cs.mu.oz.au> The fixed-size arrays in ngen-runtime.c are security flaws, I think. They are prone to buffer overflow attacks. -- Fergus Henderson | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From mkestner@speakeasy.net Thu Aug 1 04:58:25 2002 From: mkestner@speakeasy.net (Mike Kestner) Date: 31 Jul 2002 22:58:25 -0500 Subject: [Mono-list] Pre-Built of GTK# Binaries In-Reply-To: <005201c238e1$09f4cb30$b9a93942@danpc> References: <005201c238e1$09f4cb30$b9a93942@danpc> Message-ID: <1028174306.1356.70.camel@localhost.localdomain> On Wed, 2002-07-31 at 17:24, Daniel Morgan wrote: > Is there anywhere I can get pre-built gtk# binaries? alp has gtk# debs. baselabs has rpms. You can get to those pages from the mono downloads page. Mike From fjh@cs.mu.oz.au Thu Aug 1 04:18:53 2002 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Thu, 1 Aug 2002 13:18:53 +1000 Subject: [Mono-list] Announce: A .NET assembly -> native codegeneration tool (ala ngen for MONO) In-Reply-To: <214ABAB6BF4DC24EAD9AB1C7461DA6A101F305@buebe002.NOE.Nokia.com> References: <214ABAB6BF4DC24EAD9AB1C7461DA6A101F305@buebe002.NOE.Nokia.com> Message-ID: <20020801031853.GD30080@ceres.cs.mu.oz.au> On 29-Jul-2002, Zoltan.2.Varga@nokia.com wrote: > > I originally wanted to write a GCC front end for CIL, but after looking at the gcc front end code, I decided against it :) Actually the C front end code is a lot more complicated than a GCC front end needs to be. You are better off looking at the "Treelang" example front-end. > The advantage of this approach against saving the JIT generated code is increased performance. The greatest disadvantage > is the long compilation time: It takes almost 3 minutes to compile corlib.dll to native code. Three minutes? Long? Sheesh, that's not even time for a coffee break ;-) A long compilation time is when you set it going overnight, and it still hasn't finished when you get back the next morning. Ah, the youth of today. Back in my day, when computers had 6k of RAM, and 4k of that was video RAM, and we had to hand-assemble our own code, ... ;-) ;-) ;-) -- Fergus Henderson | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From miguel@ximian.com Thu Aug 1 05:42:50 2002 From: miguel@ximian.com (Miguel de Icaza) Date: 01 Aug 2002 00:42:50 -0400 Subject: [Mono-list] Announce: A .NET assembly -> native code generation tool (ala ngen for MONO) In-Reply-To: <20020801023959.GA30080@ceres.cs.mu.oz.au> References: <214ABAB6BF4DC24EAD9AB1C7461DA6A101F302@buebe002.NOE.Nokia.com> <1027829025.3825.308.camel@erandi.boston.ximian.com> <1027932403.30838.60.camel@tequila> <20020801023959.GA30080@ceres.cs.mu.oz.au> Message-ID: <1028176969.21163.112.camel@erandi.boston.ximian.com> > This approach is what MS did. This approach sucks. > You just won't get good performance that way. > > An ahead-of-time compiler can afford to spend a lot more time compiling, > and as a result it can use much more sophisticated optimizations than > a JIT compiler can. When we say `Turn on all the optimizations' it means that you can turn all of the expensive optimizations on. There are many things that we can not do at JIT time that we can do effectively if we have a lot of time to spare. This is for instance what the Intel ORP JIT engine does: it does a fast JIT task that inserts profiling information into the code, and if those trigger a threshold, then the routine is re-JITed with the slow optimizing JIT engine. > Note also that GCC's optimizer has already been ported to a lot more > architectures than the mono JIT has been. For architectures where > the choice is to use an interpreter or an ahead-of-time compiler, > the ahead-of-time compiler should give a very significant speedup. Sure, and we are still evaluating the options, but we are going to improve the JIT engine. A large number of optimizations is performed on the intermediate representation which means that every target will benefit from it, the piece that is architecture dependent is the piece that actually matches a IR tree to native instructions. For instance, constant folding, propagation and inlining in the Mono JIT are all done on the intermediate representation. CSE, GCSE, invariant code motion and loop optimizations should all be performed on this IR, and not in an architecture specific one. Anyways, not advocating either case at this point, we will see how things mature, and we are helping and keeping a close look at Zoltan's approach. Maybe it will become the default, but lets keep a scientific mindset for now. Miguel. From dietmar@ximian.com Thu Aug 1 06:55:38 2002 From: dietmar@ximian.com (Dietmar Maurer) Date: 01 Aug 2002 07:55:38 +0200 Subject: [Mono-list] Announce: A .NET assembly -> native code generation tool (ala ngen for MONO) In-Reply-To: <20020801023959.GA30080@ceres.cs.mu.oz.au> References: <214ABAB6BF4DC24EAD9AB1C7461DA6A101F302@buebe002.NOE.Nokia.com> <1027829025.3825.308.camel@erandi.boston.ximian.com> <1027932403.30838.60.camel@tequila> <20020801023959.GA30080@ceres.cs.mu.oz.au> Message-ID: <1028181338.4760.11.camel@tequila> On Thu, 2002-08-01 at 04:39, Fergus Henderson wrote: > On 29-Jul-2002, Dietmar Maurer wrote: > > On Sun, 2002-07-28 at 06:03, Miguel de Icaza wrote: > > > Zoltan wrote: > > > > > > > The first version of my ngen clone for MONO is available at: > > > > > > > > http://www.nexus.hu/vargaz2 > > Excellent. > > > > This announcement is of course really exciting. I have only taken a > > > very superficial look so far at the code generator, but the approach is > > > a very interesting idea. I will let Dietmar and Paolo comment further > > > on it. > > I think this approach is a really good approach. > > > > What I wanted to look into was to use the JIT to generate code that > > > would end up in a library, basically reusing the JIT, but turning on all > > > the optimizations for this. > > > > This approach would also avoid much code duplication. > > This approach is what MS did. This approach sucks. > You just won't get good performance that way. Sure, but I also has some advantages. For example it works with exceptions and garbage collection. I have no idea how we can include GC support with the gcc approach. - Dietmar From jarek@atm.com.pl Thu Aug 1 08:26:47 2002 From: jarek@atm.com.pl (Jaroslaw Kowalski) Date: Thu, 1 Aug 2002 09:26:47 +0200 Subject: [Mono-list] CVS update error References: <20020731184132.26C8560@jparsons.org> Message-ID: <002301c2392c$cb9f1560$7020160a@atmlabi> I'm having the same problem, but on mcs/class/lib/.cvsignore Have no clue... Maybe some Real Time Clock problem? Jarek ----- Original Message ----- From: "Jared Parsons" To: Sent: Thursday, August 01, 2002 4:03 AM Subject: [Mono-list] CVS update error > I was trying to build Mono today from scratch and I'm running into the > following CVS error. > > cvs server: Updating mono/samples/embed > cvs update: move away mono/samples/embed/test.cs; it is in the way > C mono/samples/embed/test.cs > cvs update: move away mono/samples/embed/teste.c; it is in the way > C mono/samples/embed/teste.c > > Upon receiving this error, I deleted both of the files and updated again. I > received the same error so I just completley removed the directory embed and > then did "cvs update -d". I received the exact same error. What do I need > to do to resolve this issue. Mono will not build when the cvs error occurs. > > -- > Jared Parsons > CS2130 TA > (jparsons@jparsons.org) > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > From kevin-hua@woncore.com Thu Aug 1 05:04:05 2002 From: kevin-hua@woncore.com (=?GB2312?Q?=BB=AA=BA=EA=C1=C1?=) Date: Thu, 1 Aug 2002 12:4:5 +0800 Subject: [Mono-list] bug report Message-ID: <200208010404.g7144E300823@trna.ximian.com> hi, I am a c++ developer from China. And I want to represent a test program that will causes error under mono 0.13 for windows. However, it runs correctly under m$ .NET Framework. What causes this error under mono is redundant whitespace in format string for Console.WriteLine method. If remove these whitespaces, we will see that it gives the same result under mono as it does under m$ .net framework! sample code is as follows: using System; class FormatOut { public static int Main() { Console.WriteLine("Left Align 10:{0, -10}", 99); Console.WriteLine("Right Align 10:{0, 10}", 99); return 0; } } best regards for your amazing work ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡kevin-hua@woncore.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-08-01 From gonzalo@ximian.com Thu Aug 1 11:11:58 2002 From: gonzalo@ximian.com (Gonzalo Paniagua Javier) Date: 01 Aug 2002 12:11:58 +0200 Subject: [Mono-list] XSP HtmlControls and WebControls status In-Reply-To: <0252DA9D658BBD46880B050E509B3CC505D14508@mercury.epicsys.com> References: <0252DA9D658BBD46880B050E509B3CC505D14508@mercury.epicsys.com> Message-ID: <1028196719.1993.84.camel@lalo2.micasa> El jue, 01-08-2002 a las 00:37, ChongQing Xiao escribió: > Hi,Gonzala: Gonzalo ;-) > > You mean all the databinding of DataGrid and DataList is done? > I thought ADO.NET for mono is still in early stage. No, that is part of the "supporting methods for Render ()" ;-) - Gonzalo From gonzalo@ximian.com Thu Aug 1 11:19:01 2002 From: gonzalo@ximian.com (Gonzalo Paniagua Javier) Date: 01 Aug 2002 12:19:01 +0200 Subject: [Mono-list] bug report In-Reply-To: <200208010404.g7144E300823@trna.ximian.com> References: <200208010404.g7144E300823@trna.ximian.com> Message-ID: <1028197142.1993.88.camel@lalo2.micasa> El jue, 01-08-2002 a las 06:04, åŽå®äº® escribió: > using System; > > class FormatOut > { > public static int Main() > { > Console.WriteLine("Left Align 10:{0, -10}", 99); > Console.WriteLine("Right Align 10:{0, 10}", 99); > return 0; > } > } > I tried this sample (well, just changed the literal to say "Number:") and this is what i get: ~ $ ./kevin.exe Number: -199 Number: 199 ~ $ mono ./kevin.exe Number: -199 Number: 199 I'm using current CVS. It should also work with some previous versions (i believe that since 0.12). Cheers. - Gonzalo From dihlewis@yahoo.co.uk Thu Aug 1 11:22:14 2002 From: dihlewis@yahoo.co.uk (=?iso-8859-1?q?Dan=20Lewis?=) Date: Thu, 1 Aug 2002 11:22:14 +0100 (BST) Subject: [Mono-list] [PATCH] System.Text.RegularExpressions won't DTRT if you re-use patterns Message-ID: <20020801102214.85354.qmail@web13807.mail.yahoo.com> Hi Juli! Nice catch - I hadn't thought about that. Your patch does indeed solve the problem. However the parser is now being called for each new expression, whether it is in the cache or not. Perhaps a better long term solution would be to cache a structure in the lookup table. At the moment, FactoryCache maps (pattern, options) => (factory). It could be altered to map (pattern, options) => (factory, mapping, group_count), so that the Regex constructor could pull these details out too, and save both parse and compile time. Thanks, Dan. Juli Mallett wrote: >Hi, > >Currently in the Regex code, there is factory caching code, however things >like grouping need evaluated each time the Regex is constructed, the most >simple/obvious solution is to move that code out of the section that runs >only when there is no cached item in existence. This happens when one >constructs more than one Regex with the same pattern and the same options >and e.g. tries to use $1 in Replace(). Example code which throws bogus >exception would be something like: > >Foo = Regex.Replace(Foo, @"(.*)", "$1"); >// Here we get bogus exception >Foo = Regex.Replace(Foo, @"(.*)", "$1"); > >More or less. > >Here's a diff: > >http://toxic.magnesium.net/~flata/dump/Regex-factorycache-eval.diff > >Thanks, >juli. __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From gonzalo@ximian.com Thu Aug 1 11:23:49 2002 From: gonzalo@ximian.com (Gonzalo Paniagua Javier) Date: 01 Aug 2002 12:23:49 +0200 Subject: [Mono-list] bug report In-Reply-To: <1028197142.1993.88.camel@lalo2.micasa> References: <200208010404.g7144E300823@trna.ximian.com> <1028197142.1993.88.camel@lalo2.micasa> Message-ID: <1028197430.1993.93.camel@lalo2.micasa> El jue, 01-08-2002 a las 12:19, Gonzalo Paniagua Javier escribió: > > I tried this sample (well, just changed the literal to say "Number:") > and this is what i get: Oh, crap. You are right (i used a ':' instead of a ',' to format the numbers). I'll fix String.FormatSpecifier, which is the one failing. - Gonzalo From gonzalo@ximian.com Thu Aug 1 11:50:11 2002 From: gonzalo@ximian.com (Gonzalo Paniagua Javier) Date: 01 Aug 2002 12:50:11 +0200 Subject: [Mono-list] bug report In-Reply-To: <1028197430.1993.93.camel@lalo2.micasa> References: <200208010404.g7144E300823@trna.ximian.com> <1028197142.1993.88.camel@lalo2.micasa> <1028197430.1993.93.camel@lalo2.micasa> Message-ID: <1028199012.551.95.camel@lalo2.micasa> El jue, 01-08-2002 a las 12:23, Gonzalo Paniagua Javier escribió: > > I'll fix String.FormatSpecifier, which is the one failing. Fixed in CVS. Thanks. - Gonzalo From lupus@ximian.com Thu Aug 1 12:17:05 2002 From: lupus@ximian.com (Paolo Molaro) Date: Thu, 1 Aug 2002 13:17:05 +0200 Subject: [Mono-list] Combining Virtuoso and Mono In-Reply-To: <87ado8t31s.fsf@purple.uknet.private> References: <87ado8t31s.fsf@purple.uknet.private> Message-ID: <20020801111705.GK22977@debian.org> On 07/31/02 Tim Haynes wrote: > We know that such a thing is not immediate on your roadmap and thus would > be interested in considering donating results of our unmanaged interface > related development work to the Mono project if we could get some technical > support for our developers for getting started in this direction. As Miguel points out a possibility is to write a wrapper that mimics the ms hosting API, though their API is really orrible and I really want a clean interface for embedding mono. > Specifically, we would appreciate either a pointer to existing > documentation or assistance with the following points: > > - How do we register an instance handle in unmanaged memory for GC? Currently we don't provide an API specifically for that. You can use a MonoGHashTable (check the mono/utils/mono-hash.h): it works just like a GHashTable but you can store objects in there and they will be tracked by the GC if you store a pointer to the hash table on the stack or in a static variable. The alternative is to expose with a nice API the functionality provided in metadata/gc.c that is already exposed to C# code (GCHandle): this way you can not only ensure that an object that you store in unmanaged memory is not collected, but you can also get weak references to it. > - How do we call a method of an instance given the name and signature? There are two functions to call a managed method: MonoObject* mono_runtime_invoke (MonoMethod *method, void *obj, void **params, MonoObject **exc); and MonoObject* mono_runtime_invoke_array (MonoMethod *method, void *obj, MonoArray *params, MonoObject **exc); obj is the 'this' pointer, it should be NULL for static methods, a MonoObject* for object instances and a pointer to the value type for value types. The params array contains the arguments to the method with the same convention: MonoObject* pointers for object instances and pointers to the value type otherwise. The _invoke_array variant takes a C# object[] as the params argument (MonoArray *params): in this case the value types are boxed inside the respective reference representation. From unmanaged code you'll usually use the mono_runtime_invoke() variant. Note that this function doesn't handle virtual methods for you, it will exec the exact method you pass: we still need to expose a function to lookup the derived class implementation of a virtual method (there are examples of this in the code, though). You can pass NULL as the exc argument if you don't want to catch exceptions, otherwise, *exc will be set to the exception thrown, if any. if an exception is thrown, you can't use the MonoObject* result from the function. If the method returns a value type, it is boxed in an object reference. We have plans for providing an additional method that returns an unmanaged->managed thunk like this: void* mono_method_get_unmanaged_thunk (MonoMethod *method); You'll be able to store the returned pointer in a function pointer with the proper signature and call that directly from C: typedef gint32 (*GetHashCode) (MonoObject *obj); GetHashCode func = mono_method_get_unmanaged_thunk (System_Object_GetHashCode_method); gint32 hashvalue = func (myobject); It may not be possible to manage exceptions in that case, though. I need to think more about it. To get a MonoMethod there are several ways. You can get a MonoClass (the structure representing a type) using: MonoClass * mono_class_from_name (MonoImage *image, const char* name_space, const char *name); and then loop in the returned class method array until you get the one you're looking for. There are examples of such searches as static functions in several C files in metadata/*.c: we need to expose one through the API and remove the duplicates. The other, simpler, way is to use the functions in debug-helpers.h: there are examples of their use in monograph, mint and the jit as well. You basically use a string description of the method, like: "System.Object:GetHashCode()" and create a MonoMethodDesc out of it with: MonoMethodDesc* mono_method_desc_new (const char *name, gboolean include_namespace); You can then use: MonoMethod* mono_method_desc_search_in_class (MonoMethodDesc *desc, MonoClass *klass); MonoMethod* mono_method_desc_search_in_image (MonoMethodDesc *desc, MonoImage *image); to search for the method in a class or in an image. You would tipically do this just once at the start of the program and store the result for reuse somewhere. > - How do we pass C scalars and arrays to and from managed code? See above for simple scalar values. To pass arrays around, you'll need to build the proper MonoArray for the type (and copy the data as needed). MonoArray* mono_array_new (MonoDomain *domain, MonoClass *eclass, guint32 n); Creates a 1-dimensional array with size n for the type eclass. Common types are available accessing the mono_defaults structure: MonoArray* byte_array; guchar *mydata, *array_data; byte_array = mono_array_new (mono_domain_get (), mono_defaults.byte_class, 32); mydata = get_from_db (); array_data = mono_array_addr (byte_array, char, 0); memcpy (array_data, mydata, mono_array_length (byte_array)); mono_array_length() returns the number of elements in the array. If copying the data is too expensive (with large objects), you'll need to provide a different accessor, maybe a C# type that implements ICollection/IList and hook that with internalcalls. Hope this helps. lupus -- ----------------------------------------------------------------- lupus@debian.org debian/rules lupus@ximian.com Monkeys do it better From lupus@ximian.com Thu Aug 1 12:34:59 2002 From: lupus@ximian.com (Paolo Molaro) Date: Thu, 1 Aug 2002 13:34:59 +0200 Subject: [Mono-list] Announce: A .NET assembly -> native code generation tool (ala ngen for MONO) In-Reply-To: <20020801025628.GB30080@ceres.cs.mu.oz.au> References: <214ABAB6BF4DC24EAD9AB1C7461DA6A101F302@buebe002.NOE.Nokia.com> <1027829025.3825.308.camel@erandi.boston.ximian.com> <1027933698.2304.3.camel@tequila> <20020729103402.GP22977@debian.org> <20020801025628.GB30080@ceres.cs.mu.oz.au> Message-ID: <20020801113457.GL22977@debian.org> On 08/01/02 Fergus Henderson wrote: > On 29-Jul-2002, Paolo Molaro wrote: > > My main concern with using gcc is that we might not be able to constrain > > the gcc optimizer to obey the CLR rules (Zoltan notes the problem with > > division by 0, for example). > > I think this is something which could be addressed by adding the > appropriate option or options to GCC, and making any problematic > optimizations conditional on these option(s). Note that GCC already > needs to obey the Java/JVM rules -- this is required for gcj. > I don't think the CLR rules are any harder, are they? Well, yes, they are. Java doesn't have to deal with any of the .ovf opcode variants, for example. I'm not sure it would be enough to add some options to gcc, mostly because they apply to all the compilation run, not to specific cases, and that would limit the optimizations that gcc can do. > In pratice this is not likely to be a significant issue anyway, > since I would expect few .NET programs to really rely on strict > adherence to these rules. If problems do occur, they can be > addressed as they come up. The problem is that they _will_ come up and bite us in unexpected and hard to track ways. An extensive test suite is the only way to address this issue. lupus -- ----------------------------------------------------------------- lupus@debian.org debian/rules lupus@ximian.com Monkeys do it better From lupus@ximian.com Thu Aug 1 12:40:17 2002 From: lupus@ximian.com (Paolo Molaro) Date: Thu, 1 Aug 2002 13:40:17 +0200 Subject: [Mono-list] Announce: A .NET assembly -> native code generation tool (ala ngen for MONO) In-Reply-To: <20020801023959.GA30080@ceres.cs.mu.oz.au> References: <214ABAB6BF4DC24EAD9AB1C7461DA6A101F302@buebe002.NOE.Nokia.com> <1027829025.3825.308.camel@erandi.boston.ximian.com> <1027932403.30838.60.camel@tequila> <20020801023959.GA30080@ceres.cs.mu.oz.au> Message-ID: <20020801114016.GM22977@debian.org> On 08/01/02 Fergus Henderson wrote: > There's no point trying to duplicate all of GCC's optimizations in your > JIT compiler; doing that would be a huge amount of code duplication. > It's much better to reuse GCC's optimizer, as Zoltan has done. > > Note also that GCC's optimizer has already been ported to a lot more > architectures than the mono JIT has been. For architectures where > the choice is to use an interpreter or an ahead-of-time compiler, > the ahead-of-time compiler should give a very significant speedup. The jit is needed for several things anyway, you can't do without it, even if you have an ahead-of-time compiler. And there are several cases where the JIT can do better than any ahead-of-time compiler, even if it does less optimizations, simply beacuse it can do things based on assumptions you can make at runtime only. lupus -- ----------------------------------------------------------------- lupus@debian.org debian/rules lupus@ximian.com Monkeys do it better From Zoltan.2.Varga@nokia.com Thu Aug 1 12:42:10 2002 From: Zoltan.2.Varga@nokia.com (Zoltan.2.Varga@nokia.com) Date: Thu, 1 Aug 2002 13:42:10 +0200 Subject: [Mono-list] Announce: A .NET assembly -> native code generationtool (ala ngen for MONO) Message-ID: <214ABAB6BF4DC24EAD9AB1C7461DA6A1045108@buebe002.NOE.Nokia.com> Hi, > -----Original Message----- > From: ext Dietmar Maurer [mailto:dietmar@ximian.com] > Sent: 01. August 2002 7:56 > To: Fergus Henderson > Cc: Miguel de Icaza; Varga Zoltan.2 (NMP/Budapest); Mono List > Subject: Re: [Mono-list] Announce: A .NET assembly -> native code > generationtool (ala ngen for MONO) > > > On Thu, 2002-08-01 at 04:39, Fergus Henderson wrote: > > On 29-Jul-2002, Dietmar Maurer wrote: > > > On Sun, 2002-07-28 at 06:03, Miguel de Icaza wrote: > > > > Zoltan wrote: > > > > > > > > > The first version of my ngen clone for MONO is > available at: > > > > > > > > > > http://www.nexus.hu/vargaz2 > > > > Excellent. > > > > > > This announcement is of course really exciting. I have > only taken a > > > > very superficial look so far at the code generator, but > the approach is > > > > a very interesting idea. I will let Dietmar and Paolo > comment further > > > > on it. > > > > I think this approach is a really good approach. > > > > > > What I wanted to look into was to use the JIT to > generate code that > > > > would end up in a library, basically reusing the JIT, > but turning on all > > > > the optimizations for this. > > > > > > This approach would also avoid much code duplication. > > > > This approach is what MS did. This approach sucks. > > You just won't get good performance that way. > > Sure, but I also has some advantages. For example it works with > exceptions and garbage collection. I have no idea how we can > include GC > support with the gcc approach. > A conservative garbage collector, like the Boehm collector can work with gcc code if the code is "GC-safe", i.e. it always keeps pointers to the beginning or interior of all live objects. An example of non-gc safe code is: a[i - 5] = 0; When confronted with such code an optimizing compiler might decide to transform it to something like (a-5)[i], which means there are no pointers left pointing to a, so it will be garbage collected. A relevant paper is here: http://www.hpl.hp.com/personal/Hans_Boehm/gc/papers/pldi96.ps.gz Unfortunately, based on a web search on google about 'gcc gc-safe', it looks like the code generated by gcc is not always gc-safe. It looks like the projects which use Boehm-GC like to live dangerously... It might be possible to generated GC safe code based on the ideas of the above paper. Of course, the gcc approach does not work at all with non-conservative collectors, since these like to know which registers/ memory locations contain pointers. As a final remark, I throught (and still thinking about) writing a GCC front end for IL similar to gcj. My biggest problem with this approach is that I would like to target the MONO runtime, and reuse MONO code in the front end. In contrast, gcj is self contained: it includes its own runtime library (libgcj) and targets that. bye Zoltan bye Zoltan > - Dietmar > > > > From jmallett@FreeBSD.ORG Thu Aug 1 12:51:01 2002 From: jmallett@FreeBSD.ORG (Juli Mallett) Date: Thu, 1 Aug 2002 04:51:01 -0700 Subject: [Mono-list] [PATCH] System.Text.RegularExpressions won't DTRT if you re-use patterns In-Reply-To: <20020801102214.85354.qmail@web13807.mail.yahoo.com>; from dihlewis@yahoo.co.uk on Thu, Aug 01, 2002 at 11:22:14AM +0100 References: <20020801102214.85354.qmail@web13807.mail.yahoo.com> Message-ID: <20020801045101.A79990@FreeBSD.org> * De: Dan Lewis [ Data: 2002-08-01 ] [ Subjecte: Re: [Mono-list] [PATCH] System.Text.RegularExpressions won't DTRT if you re-use patterns ] > Hi Juli! > > Nice catch - I hadn't thought about that. Eh, it just happened to come up in the hello world I was writing :) > Your patch does indeed solve the problem. However the parser is now > being called for each new expression, whether it is in the cache or not. > Perhaps a better long term solution would be to cache a structure in the > lookup table. There were a lot of more elegant solutions I could come up with, however to say I ran into that literally my first day writing C# would be no great hyperbole. It is a greater expense now, yes. > At the moment, FactoryCache maps (pattern, options) => (factory). It > could be altered to map (pattern, options) => (factory, mapping, > group_count), so that the Regex constructor could pull these details out > too, and save both parse and compile time. group_count logically should be stored with the pattern yes, is there anything else which maybe should be, too? I wasn't very familiar with this factory system, and so I was very hesitant to dig around and try to fix it in this manner, especially as I did not know how right that was. If you could do this, that'd be great, or I could give it a go later. Thanks much! juli. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org From jarek@atm.com.pl Thu Aug 1 13:19:10 2002 From: jarek@atm.com.pl (Jaroslaw Kowalski) Date: Thu, 1 Aug 2002 14:19:10 +0200 Subject: [Mono-list] OT: C in mono Message-ID: <012c01c23955$a4cbac90$7020160a@atmlabi> Hi all! Is there any reason why mono is developed entirely using C? Why not C++? Quick look at mono/mono/metadata/ directory shows that you guys are actually very good at emulating object oriented concepts using C, which are more naturally expressible using C++ syntax (classes, methods, member variables, virtual functions). Of course you don't have to use all of C++ language constructs, but you could benefit from using some of them. IMHO when you write in C, the number of potential problems resulting from the language itself is much higher than in C++. How do you deal with it? I assume there must be some sort of C coding style that you're all following. I don't mean indentation style, but rather a common way to express higher level constructs like classes, virtual functions, exceptions, allocating and freeing memory, namespaces. Where can I download such a guide? I'm not a GNU/Linux guy (yet? ;-) but I've heard that gcc is not so good ad handling c++ code. I've also heard that it's not as portable as in C mode. Are there any more reasons why you avoid c++? Jarek From miguel@ximian.com Thu Aug 1 13:49:04 2002 From: miguel@ximian.com (Miguel de Icaza) Date: 01 Aug 2002 08:49:04 -0400 Subject: [Mono-list] Announce: A .NET assembly -> native code generation tool (ala ngen for MONO) In-Reply-To: <1028181338.4760.11.camel@tequila> References: <214ABAB6BF4DC24EAD9AB1C7461DA6A101F302@buebe002.NOE.Nokia.com> <1027829025.3825.308.camel@erandi.boston.ximian.com> <1027932403.30838.60.camel@tequila> <20020801023959.GA30080@ceres.cs.mu.oz.au> <1028181338.4760.11.camel@tequila> Message-ID: <1028206144.21163.129.camel@erandi.boston.ximian.com> Hello! > Sure, but I also has some advantages. For example it works with > exceptions and garbage collection. I have no idea how we can include GC > support with the gcc approach. I thought of another optimization that can be done best with the JIT (or copying large parts of the JIT to the gcc-based ngen): arrays bounds check elimination. Anyways, wanted to share this because I could not sleep last night ;-) Miguel. From miguel@ximian.com Thu Aug 1 13:52:38 2002 From: miguel@ximian.com (Miguel de Icaza) Date: 01 Aug 2002 08:52:38 -0400 Subject: [Mono-list] Combining Virtuoso and Mono In-Reply-To: <20020801111705.GK22977@debian.org> References: <87ado8t31s.fsf@purple.uknet.private> <20020801111705.GK22977@debian.org> Message-ID: <1028206358.21167.133.camel@erandi.boston.ximian.com> Hello! > As Miguel points out a possibility is to write a wrapper that mimics the > ms hosting API, though their API is really orrible and I really want a > clean interface for embedding mono. Yes, I agree completely, I just wanted to present another "contribution" case. Because various people have asked to have the same API to port their applications easily to Mono. Miguel From miguel@ximian.com Thu Aug 1 14:00:25 2002 From: miguel@ximian.com (Miguel de Icaza) Date: 01 Aug 2002 09:00:25 -0400 Subject: [Mono-list] OT: C in mono In-Reply-To: <012c01c23955$a4cbac90$7020160a@atmlabi> References: <012c01c23955$a4cbac90$7020160a@atmlabi> Message-ID: <1028206824.21167.138.camel@erandi.boston.ximian.com> > I assume there must be some sort of C coding style that you're all > following. I don't mean indentation style, but rather a common way to > express higher level constructs like classes, virtual functions, exceptions, > allocating and freeing memory, namespaces. Where can I download such a > guide? The Mono runtime has to lay things out in a precise manner, so depending on the C++ compiler to do this is not going to give you much. > I'm not a GNU/Linux guy (yet? ;-) but I've heard that gcc is not so good ad > handling c++ code. Actually, it is one of the most compliant C++ compilers > I've also heard that it's not as portable as in C mode. Are there any more > reasons why you avoid c++? C++ has different versions of it. Depending on your vendor, you will get different features out of the language (for instance, the compliance test will show you that the offerings differ wildly). Mozilla/Netscape has a document on features you are not supposed to use from C++ if you want to remain portable across systems. Miguel. From serge@wildwestsoftware.com Thu Aug 1 14:39:26 2002 From: serge@wildwestsoftware.com (Serge) Date: Thu, 1 Aug 2002 16:39:26 +0300 Subject: [Mono-list] existing managed C++-libraries for Mono and whatswith csgl? References: <1028059957.1553.34.camel@melchior.magi> <1028152037.21167.32.camel@erandi.boston.ximian.com> Message-ID: <002501c23960$df9f5500$334e8ac3@mainmachine> Hello, >> For fun, run ildasm on the resulting executable of the first one. One >> of the symbols (IIRC) should be _mainCRT (or something similar), which > > I have seen this. This little piece of code can always be emulated, > because it is just the bootstrap piece of code. I don't think it's a good idea to try to emulate this stuff. First, it's possible to get rid of CRT startup code using appropriate compiler/linker options (resulting binary will be pure IL). Next, to emulate you would need to find managed entry point (in the simplest case, assuming CRT startup is the only native code in the binary), I have no idea how to do this. I would simply reject binaries with embedded native code. Sergey ----- Original Message ----- From: "Miguel de Icaza" To: "Jonathan Pryor" Cc: "Freddy BL" ; "Mono List" Sent: Thursday, August 01, 2002 12:47 AM Subject: Re: [Mono-list] existing managed C++-libraries for Mono and whatswith csgl? > > > For fun, run ildasm on the resulting executable of the first one. One > > of the symbols (IIRC) should be _mainCRT (or something similar), which > > looks like it calls into the MSVC native libraries. > > I have seen this. This little piece of code can always be emulated, > because it is just the bootstrap piece of code. > > Miguel > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > From lupus@ximian.com Thu Aug 1 14:48:54 2002 From: lupus@ximian.com (Paolo Molaro) Date: Thu, 1 Aug 2002 15:48:54 +0200 Subject: [Mono-list] OT: C in mono In-Reply-To: <012c01c23955$a4cbac90$7020160a@atmlabi> References: <012c01c23955$a4cbac90$7020160a@atmlabi> Message-ID: <20020801134854.GO22977@debian.org> On 08/01/02 Jaroslaw Kowalski wrote: > I assume there must be some sort of C coding style that you're all > following. I don't mean indentation style, but rather a common way to > express higher level constructs like classes, virtual functions, exceptions, > allocating and freeing memory, namespaces. Where can I download such a > guide? Most of that kind of coding style derives from the "common wisdom" of people that worked on (or read the code of) the linux kernel and the glib/gtk/gnome libraries. Some bits about it have been written, mostly in some mailing-list post, but there is no guide, AFAIK. lupus -- ----------------------------------------------------------------- lupus@debian.org debian/rules lupus@ximian.com Monkeys do it better From fjh@cs.mu.oz.au Thu Aug 1 14:54:43 2002 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Thu, 1 Aug 2002 23:54:43 +1000 Subject: [Mono-list] Announce: A .NET assembly -> native code generationtool (ala ngen for MONO) In-Reply-To: <214ABAB6BF4DC24EAD9AB1C7461DA6A1045108@buebe002.NOE.Nokia.com> References: <214ABAB6BF4DC24EAD9AB1C7461DA6A1045108@buebe002.NOE.Nokia.com> Message-ID: <20020801135443.GA14418@ceres.cs.mu.oz.au> On 01-Aug-2002, Zoltan.2.Varga@nokia.com wrote: > > From: Dietmar Maurer > > Sure, but I also has some advantages. For example it works with > > exceptions and garbage collection. I have no idea how we can > > include GC support with the gcc approach. > > A conservative garbage collector, like the Boehm collector can work with gcc code if the code is "GC-safe", i.e. it always > keeps pointers to the beginning or interior of all live objects. An example of non-gc safe code is: > a[i - 5] = 0; That code is GC-safe. The problem is just that an optimizing compiler might transform it to something which is not GC-safe. > When confronted with such code an optimizing compiler might decide to transform it to something like (a-5)[i], which means > there are no pointers left pointing to a, so it will be garbage collected. Right. But in practice this does not seem to be a significant problem. Hardware failure seems to be a more common source of errors. If you can produce a test case for which GCC generates non-GC-safe object code, I will produce a patch for GCC which adds a compiler option to generate GC-safe code, and handles that test case correctly. -- Fergus Henderson | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From dietmar@ximian.com Thu Aug 1 15:32:53 2002 From: dietmar@ximian.com (Dietmar Maurer) Date: 01 Aug 2002 16:32:53 +0200 Subject: [Mono-list] Announce: A .NET assembly -> native code generationtool (ala ngen for MONO) In-Reply-To: <214ABAB6BF4DC24EAD9AB1C7461DA6A1045108@buebe002.NOE.Nokia.com> References: <214ABAB6BF4DC24EAD9AB1C7461DA6A1045108@buebe002.NOE.Nokia.com> Message-ID: <1028212373.4740.22.camel@tequila> On Thu, 2002-08-01 at 13:42, Zoltan.2.Varga@nokia.com wrote: > A conservative garbage collector, like the Boehm collector can work with gcc code if the code is "GC-safe", i.e. it always > keeps pointers to the beginning or interior of all live objects. An example of non-gc safe code is: > a[i - 5] = 0; > > When confronted with such code an optimizing compiler might decide to transform it to something like (a-5)[i], which means > there are no pointers left pointing to a, so it will be garbage collected. A relevant paper is here: > > http://www.hpl.hp.com/personal/Hans_Boehm/gc/papers/pldi96.ps.gz > > Unfortunately, based on a web search on google about 'gcc gc-safe', it looks like the code generated by gcc is not always > gc-safe. It looks like the projects which use Boehm-GC like to live dangerously... > It might be possible to generated GC safe code based on the ideas of the above paper. > > Of course, the gcc approach does not work at all with non-conservative collectors, since these like to know which registers/ > memory locations contain pointers. We consider the Boehm GC only as temporary solution, so our final ngen solution must be able to work with non-conservative collectors. - Dietmar From ravi@ximian.com Thu Aug 1 15:40:17 2002 From: ravi@ximian.com (Ravi Pratap M) Date: 01 Aug 2002 09:40:17 -0500 Subject: [Mono-list] OT: C in mono In-Reply-To: <20020801134854.GO22977@debian.org> References: <012c01c23955$a4cbac90$7020160a@atmlabi> <20020801134854.GO22977@debian.org> Message-ID: <1028212818.1624.51.camel@raj.cs.wustl.edu> On Thu, 2002-08-01 at 08:48, Paolo Molaro wrote: > On 08/01/02 Jaroslaw Kowalski wrote: > > I assume there must be some sort of C coding style that you're all > > following. I don't mean indentation style, but rather a common way to > > express higher level constructs like classes, virtual functions, exceptions, > > allocating and freeing memory, namespaces. Where can I download such a > > guide? > > Most of that kind of coding style derives from the "common wisdom" of > people that worked on (or read the code of) the linux kernel and the > glib/gtk/gnome libraries. > Some bits about it have been written, mostly in some mailing-list post, > but there is no guide, AFAIK. How about the GNOME Programming Guidelines ? It is pretty much what we use but adapted to C# :-) Take a look at mcs's coding style to see what we prefer. Regards, Ravi From dick@ximian.com Thu Aug 1 16:19:23 2002 From: dick@ximian.com (Dick Porter) Date: 01 Aug 2002 16:19:23 +0100 Subject: [Mono-list] OT: C in mono In-Reply-To: <1028206824.21167.138.camel@erandi.boston.ximian.com> References: <012c01c23955$a4cbac90$7020160a@atmlabi> <1028206824.21167.138.camel@erandi.boston.ximian.com> Message-ID: <1028215163.4245.137.camel@hagbard.apathetic.discordia.org.uk> On Thu, 2002-08-01 at 14:00, Miguel de Icaza wrote: > Mozilla/Netscape has a document on features you are not supposed to use > from C++ if you want to remain portable across systems. And what you end up with is remarkably close to ANSI C :) - Dick From michael@ximian.com Thu Aug 1 16:50:10 2002 From: michael@ximian.com (Michael Meeks) Date: 01 Aug 2002 16:50:10 +0100 Subject: [Mono-list] OT: C in mono In-Reply-To: <012c01c23955$a4cbac90$7020160a@atmlabi> References: <012c01c23955$a4cbac90$7020160a@atmlabi> Message-ID: <1028217011.8135.79.camel@michael.home> Hi Jaroslaw, On Thu, 2002-08-01 at 13:19, Jaroslaw Kowalski wrote: > I've also heard that it's not as portable as in C mode. Are there any > more reasons why you avoid c++? You mention some good reasons; for some other reasons why only experts should use C++ read: "Enough rope to shoot yourself in the foot" Holub, McGraw-Hill - an interesting, and useful read: Pages 86-94 "C related rules" - 9pgs Pages 96-178 "Rules for C++ programming" - 83pgs Regards, Michael. -- mmeeks@gnu.org <><, Pseudo Engineer, itinerant idiot From Terry.Wilson@pgnmail.com Thu Aug 1 16:44:10 2002 From: Terry.Wilson@pgnmail.com (Wilson, Terry) Date: Thu, 1 Aug 2002 11:44:10 -0400 Subject: [Mono-list] ASP.NET Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C23972.47874EA0 Content-Type: text/plain For the ASP.NET port, what will be the web server? Apache? Thanks, Terry T. Wilson Application Architect - Dev. Svcs. > Progress Energy > 411 Fayetteville St. Mall (OHS 4A1) > Raleigh, NC. 27602 > (919)546-7466 terry.wilson@pgnmail.com ------_=_NextPart_001_01C23972.47874EA0 Content-Type: text/html ASP.NET

For the ASP.NET port, what will be the web server? Apache?

Thanks,
Terry T. Wilson
Application Architect - Dev. Svcs.
Progress Energy
411 Fayetteville St. Mall (OHS 4A1)
Raleigh, NC. 27602
(919)546-7466
terry.wilson@pgnmail.com


------_=_NextPart_001_01C23972.47874EA0-- From jarek@atm.com.pl Thu Aug 1 17:20:54 2002 From: jarek@atm.com.pl (Jaroslaw Kowalski) Date: Thu, 1 Aug 2002 18:20:54 +0200 Subject: [Mono-list] OT: C in mono References: <012c01c23955$a4cbac90$7020160a@atmlabi> <20020801134854.GO22977@debian.org> <1028212818.1624.51.camel@raj.cs.wustl.edu> Message-ID: <000b01c23977$6931ad70$7020160a@atmlabi> Thanks. That's what I've been looking for. Jarek ----- Original Message ----- From: "Ravi Pratap M" To: "Paolo Molaro" Cc: "Mono List" Sent: Thursday, August 01, 2002 4:40 PM Subject: Re: [Mono-list] OT: C in mono > On Thu, 2002-08-01 at 08:48, Paolo Molaro wrote: > > On 08/01/02 Jaroslaw Kowalski wrote: > > > I assume there must be some sort of C coding style that you're all > > > following. I don't mean indentation style, but rather a common way to > > > express higher level constructs like classes, virtual functions, exceptions, > > > allocating and freeing memory, namespaces. Where can I download such a > > > guide? > > > > Most of that kind of coding style derives from the "common wisdom" of > > people that worked on (or read the code of) the linux kernel and the > > glib/gtk/gnome libraries. > > Some bits about it have been written, mostly in some mailing-list post, > > but there is no guide, AFAIK. > > How about the GNOME Programming Guidelines ? It is pretty much what we > use but adapted to C# :-) Take a look at mcs's coding style to see what > we prefer. > > > > Regards, > > Ravi > > > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > From thaynes@openlinksw.com (Tim Haynes) Thu Aug 1 17:18:24 2002 From: thaynes@openlinksw.com (Tim Haynes) (Tim Haynes) Date: Thu, 01 Aug 2002 17:18:24 +0100 Subject: [Mono-list] Re: Combining Virtuoso and Mono In-Reply-To: <87ado8t31s.fsf@purple.uknet.private> (Tim Haynes's message of "Wed, 31 Jul 2002 14:55:27 +0100") References: <87ado8t31s.fsf@purple.uknet.private> Message-ID: <87ofcmft7z.fsf@purple.uknet.private> I wrote: > OpenLink Software is interested in hosting the Mono run time inside its > Virtuoso universal server. We are working on providing CLR hosting inside > our server under Windows and true to our cross platform focus wish to offer > similar capabilities on other platforms. [snip] > Specifically, we would appreciate either a pointer to existing > documentation or assistance with the following points: Just a quick note to thank all those who've responded so far, in such detail. I've passed your suggestions back to our developers for consideration, and look forward to the inevitable progress :) Thanks again, ~Tim -- Product Development Consultant OpenLink Software Tel: +44 (0) 20 8681 7701 Web: Universal Data Access & Data Integration Technology Providers From fjh@cs.mu.oz.au Thu Aug 1 16:47:05 2002 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Fri, 2 Aug 2002 01:47:05 +1000 Subject: [Mono-list] Announce: A .NET assembly -> native code generationtool (ala ngen for MONO) In-Reply-To: <1028212373.4740.22.camel@tequila>; from dietmar@ximian.com on Thu, Aug 01, 2002 at 04:32:53PM +0200 References: <214ABAB6BF4DC24EAD9AB1C7461DA6A1045108@buebe002.NOE.Nokia.com> <1028212373.4740.22.camel@tequila> Message-ID: <20020802014704.A28132@hg.cs.mu.oz.au> On 01-Aug-2002, Dietmar Maurer wrote: > We consider the Boehm GC only as temporary solution, so our final ngen > solution must be able to work with non-conservative collectors. For one possible approach to accurate collection while compiling to C, see my recent paper at ISMM'02 [1], which describes how to keep track of all pointers on the C stack by linking them into a "shadow stack". However, note that this approach has a fairly significant overhead, due to pointers not being stored in registers. (The results for toy benchmarks in the benchmarks section of this paper are not representative of the likely results for real programs with larger working sets and higher register pressure.) So the overheads might very well outweigh any gains from using GCC's better optimization. In the very long run, I would like to see proper support for accurate GC in GCC, but of course that is a very very difficult task. [1] Fergus Henderson, "Accurate garbage collection in an uncooperative environment". In Proceedings of the 2002 International Symposium on Memory Management, Berlin, Germany, June 2002, pages 150-156. -- Fergus Henderson | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From rodrigo@ximian.com Thu Aug 1 17:59:26 2002 From: rodrigo@ximian.com (Rodrigo Moya) Date: 01 Aug 2002 18:59:26 +0200 Subject: [Mono-list] OT: C in mono In-Reply-To: <012c01c23955$a4cbac90$7020160a@atmlabi> References: <012c01c23955$a4cbac90$7020160a@atmlabi> Message-ID: <1028221166.23750.3.camel@azkoyen.gnome-db.org> On Thu, 2002-08-01 at 14:19, Jaroslaw Kowalski wrote: > I assume there must be some sort of C coding style that you're all > following. I don't mean indentation style, but rather a common way to > express higher level constructs like classes, virtual functions, exceptions, > allocating and freeing memory, namespaces. Where can I download such a > guide? > I suppose you're talking about the GLib object system, which you can read about in http://www.gtk.org and http://developer.gnome.org cheers -- Rodrigo Moya From martin@gnome.org Thu Aug 1 18:03:21 2002 From: martin@gnome.org (Martin Baulig) Date: 01 Aug 2002 19:03:21 +0200 Subject: [Mono-list] MCS now has control flow analysis Message-ID: <86lm7q4ili.fsf@einstein.home-of-linux.org> Hi guys, the last few days I implemented control flow analysis in MCS. This means that MCS will now be able to detect `out' parameters which are not assigned before control leaves the current method or local variables being accessed before they're initialized. If there are any problems with this (ie. you can still access a local before it's assigned or return without all `out' parameters being assigned), just let me know (a simple test case is very appreciated in this case) and I'll fix it. -- Martin Baulig martin@gnome.org From rafaelteixeirabr@hotmail.com Thu Aug 1 18:07:15 2002 From: rafaelteixeirabr@hotmail.com (A Rafael D Teixeira) Date: Thu, 01 Aug 2002 14:07:15 -0300 Subject: [Mono-list] MCS now has control flow analysis Message-ID: Downright stupendous, thanks Happy semantics Rafael Teixeira Brazilian Polymath _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From rafaelteixeirabr@hotmail.com Thu Aug 1 18:22:00 2002 From: rafaelteixeirabr@hotmail.com (A Rafael D Teixeira) Date: Thu, 01 Aug 2002 14:22:00 -0300 Subject: [Mono-list] MCS now has control flow analysis Message-ID: And I forgot to say that MonoBASIC inherits it all, thanks again Rafael Teixeira Brazilian Polymath _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From rafaelteixeirabr@hotmail.com Thu Aug 1 18:29:34 2002 From: rafaelteixeirabr@hotmail.com (A Rafael D Teixeira) Date: Thu, 01 Aug 2002 14:29:34 -0300 Subject: [Mono-list] ASP.NET Message-ID: >For the ASP.NET port, what will be the web server? Apache? Gonzalo et al. are finishing the server-independent part. (the big one) Some people are trying to make a mod_mono for Apache, but the same can be accomplished for nearly any web server that has some integration API. Care to contribute one for Zeus or IIS? Obviously you can also use CGI, but that won't cut the muster on performance, specially for statefull sessions. Blazing bits to you, Rafael Teixeira Brazilian Polymath _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From piersh@friskit.com Thu Aug 1 20:42:53 2002 From: piersh@friskit.com (Piers Haken) Date: Thu, 1 Aug 2002 12:42:53 -0700 Subject: [Mono-list] OT: C in mono Message-ID: <9891913C5BFE87429D71E37F08210CB9081E71@zeus.sfhq.friskit.com> I have to say that I find it ironic that half the project is developed in C# where OO concepts like abstraction, inheritance & aggregation are explicit and even encouraged in the syntax of the language; and the other half is in C where they're hidden in the semantics of the code. I can't stand to look at modern C code (like the mono runtime, or the Linux kernel) any more because every time I do I see these concepts being shoehorned into a language that was never designed to accommodate them. Structs and sets of functions with weird prefixes (due to the flat namespace) that take pointers to those structs just shouting out to become classes and methods. Tables of function pointers (with their obtuse syntax) crying out to become virtual functions. Hoards of different linked lists, hash tables (all taking (void*)) just begging to be put out of their misery and replaced with shiny new, type safe, inlinable STL code, and the macros, oh the macros. It's like purgatory for a C++ guy. But, you know, as long as it gets the job done, what the hell... Piers. > -----Original Message----- > From: Jaroslaw Kowalski [mailto:jarek@atm.com.pl] > Sent: Thursday, August 01, 2002 5:19 AM > To: mono-list@ximian.com > Subject: [Mono-list] OT: C in mono > > > Hi all! > > Is there any reason why mono is developed entirely using C? > Why not C++? > > Quick look at mono/mono/metadata/ directory shows that you > guys are actually very good at emulating object oriented > concepts using C, which are more naturally expressible using > C++ syntax (classes, methods, member variables, virtual > functions). Of course you don't have to use all of C++ > language constructs, but you could benefit from using some of them. > > IMHO when you write in C, the number of potential problems > resulting from the language itself is much higher than in > C++. How do you deal with it? > > I assume there must be some sort of C coding style that > you're all following. I don't mean indentation style, but > rather a common way to express higher level constructs like > classes, virtual functions, exceptions, allocating and > freeing memory, namespaces. Where can I download such a guide? > > I'm not a GNU/Linux guy (yet? ;-) but I've heard that gcc is > not so good ad handling c++ code. I've also heard that it's > not as portable as in C mode. Are there any more reasons why > you avoid c++? > > Jarek > > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > From piersh@friskit.com Thu Aug 1 21:44:48 2002 From: piersh@friskit.com (Piers Haken) Date: Thu, 1 Aug 2002 13:44:48 -0700 Subject: [Mono-list] ASP.NET Message-ID: <9891913C5BFE87429D71E37F08210CB9183918@zeus.sfhq.friskit.com> good question, I have another related one: how much of the ASP.NET infrastructure will be implemented? will we be able to use the cassini sample (from the ASP web matrix, and without the winforms stuff) to host ASP on mono? Piers. -----Original Message----- From: Wilson, Terry [mailto:Terry.Wilson@pgnmail.com] Sent: Thursday, August 01, 2002 8:44 AM To: 'mono-list@ximian.com' Subject: [Mono-list] ASP.NET For the ASP.NET port, what will be the web server? Apache? Thanks, Terry T. Wilson Application Architect - Dev. Svcs. Progress Energy 411 Fayetteville St. Mall (OHS 4A1) Raleigh, NC. 27602 (919)546-7466 terry.wilson@pgnmail.com From jmallett@FreeBSD.ORG Thu Aug 1 22:10:15 2002 From: jmallett@FreeBSD.ORG (Juli Mallett) Date: Thu, 1 Aug 2002 14:10:15 -0700 Subject: [Mono-list] [PATCH] System.Text.RegularExpressions won't DTRT if you re-use patterns In-Reply-To: <20020801045101.A79990@FreeBSD.org>; from jmallett@freebsd.org on Thu, Aug 01, 2002 at 04:51:01AM -0700 References: <20020801102214.85354.qmail@web13807.mail.yahoo.com> <20020801045101.A79990@FreeBSD.org> Message-ID: <20020801141015.A59318@FreeBSD.org> * De: Juli Mallett [ Data: 2002-08-01 ] [ Subjecte: Re: [Mono-list] [PATCH] System.Text.RegularExpressions won't DTRT if you re-use patterns ] After much pain and suffering, I came up with this: http://toxic.magnesium.net/~flata/dump/Regex-factorycache-groupcount.diff It's essentially what I wanted to do in the first place, except I actually managed to figure out where it was possible to do it. Thanks, juli. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org From miguel@ximian.com Fri Aug 2 06:13:01 2002 From: miguel@ximian.com (Miguel de Icaza) Date: 02 Aug 2002 01:13:01 -0400 Subject: [Mono-list] SharpZipLib and NCvsLib compiles under mono. In-Reply-To: <1028151532.2532.125.camel@pitr.bagfors.nu> References: <1028151532.2532.125.camel@pitr.bagfors.nu> Message-ID: <1028265181.21166.264.camel@erandi.boston.ximian.com> Hello Erik, > Still. It's VERY close to working. You guys have done an incredible > job. I hope to have #Develop running some time in the future (maybe > using gtk# instead of winforms) Thanks a lot for trying things out with the mcs compiler, and thanks for the bug reports. Would you be able to help us track down the generated code problem? Mark helped us track down a few elusive bugs in MCS with vorbis# in the past as well. Miguel. From miguel@ximian.com Fri Aug 2 06:19:31 2002 From: miguel@ximian.com (Miguel de Icaza) Date: 02 Aug 2002 01:19:31 -0400 Subject: [Mono-list] ASP.NET In-Reply-To: <9891913C5BFE87429D71E37F08210CB9183918@zeus.sfhq.friskit.com> References: <9891913C5BFE87429D71E37F08210CB9183918@zeus.sfhq.friskit.com> Message-ID: <1028265571.21166.272.camel@erandi.boston.ximian.com> Hello, > good question, I have another related one: how much of the ASP.NET > infrastructure will be implemented? will we be able to use the cassini > sample (from the ASP web matrix, and without the winforms stuff) to host > ASP on mono? Piers, I do not know exactly what Cassini is, but if it is the embedded Web Server in WebMatrix, it should work. Embedding ASP.NET in a .NET application is very simple. Currently XSP rolls its own system, because the complete implementation required a lot more work, that felt under the domain of Patrik's work. We have been talking to Patrik to get his HttpRuntime code integrated (who is hacking on these things on his vacation). The other side of the problem is being done by Gonzalo who is shuffling the XSP code into the System.Web assembly in the proper classes. So the good news is that the various programs that embed ASP.NET should just work when we are done. Miguel. From miguel@ximian.com Fri Aug 2 06:20:51 2002 From: miguel@ximian.com (Miguel de Icaza) Date: 02 Aug 2002 01:20:51 -0400 Subject: [Mono-list] MCS now has control flow analysis In-Reply-To: <86lm7q4ili.fsf@einstein.home-of-linux.org> References: <86lm7q4ili.fsf@einstein.home-of-linux.org> Message-ID: <1028265650.21166.277.camel@erandi.boston.ximian.com> Hello, > This means that MCS will now be able to detect `out' parameters which > are not assigned before control leaves the current method or local > variables being accessed before they're initialized. Btw, this fixes several problems that people had with MCS. We are now a more conformant compiler ;-) Miguel From miguel@ximian.com Fri Aug 2 06:25:10 2002 From: miguel@ximian.com (Miguel de Icaza) Date: 02 Aug 2002 01:25:10 -0400 Subject: [Mono-list] OT: C in mono In-Reply-To: <9891913C5BFE87429D71E37F08210CB9081E71@zeus.sfhq.friskit.com> References: <9891913C5BFE87429D71E37F08210CB9081E71@zeus.sfhq.friskit.com> Message-ID: <1028265909.21166.287.camel@erandi.boston.ximian.com> Hello Piers, > I have to say that I find it ironic that half the project is developed > in C# where OO concepts like abstraction, inheritance & aggregation are > explicit and even encouraged in the syntax of the language; and the > other half is in C where they're hidden in the semantics of the code. Well, also notice that C++ does not directly support interfaces, so a precise control over the object layout is required. You can not just depend on the object layout from the C++ compiler to be right. To make things worse, there is no standard ABI for the layout of an object vtable across platforms or across compilers, so even if we used something like C++, we would still have to handle all of the object management code with a special custom developed idiom to deal with this. [ Personal note: The other thing that makes C code nice, is the inner desire of a programmer to write code as simple and as clean as the published ATT coding style. Some of those guys manage to create great things with tiny amounts of code ] Miguel. From piersh@friskit.com Fri Aug 2 07:53:39 2002 From: piersh@friskit.com (Piers Haken) Date: Thu, 1 Aug 2002 23:53:39 -0700 Subject: [Mono-list] ASP.NET Message-ID: <9891913C5BFE87429D71E37F08210CB9183919@zeus.sfhq.friskit.com> great! i wonder if that includes IIS ;-) (only joking) piers. -----Original Message----- From: Miguel de Icaza [mailto:miguel@ximian.com] Sent: Thursday, August 01, 2002 10:20 PM To: Piers Haken Cc: Wilson, Terry; mono-list@ximian.com Subject: RE: [Mono-list] ASP.NET Hello, > good question, I have another related one: how much of the ASP.NET > infrastructure will be implemented? will we be able to use the cassini > sample (from the ASP web matrix, and without the winforms stuff) to host > ASP on mono? Piers, I do not know exactly what Cassini is, but if it is the embedded Web Server in WebMatrix, it should work. Embedding ASP.NET in a .NET application is very simple. Currently XSP rolls its own system, because the complete implementation required a lot more work, that felt under the domain of Patrik's work. We have been talking to Patrik to get his HttpRuntime code integrated (who is hacking on these things on his vacation). The other side of the problem is being done by Gonzalo who is shuffling the XSP code into the System.Web assembly in the proper classes. So the good news is that the various programs that embed ASP.NET should just work when we are done. Miguel. From erik@bagfors.nu Fri Aug 2 08:28:53 2002 From: erik@bagfors.nu (Erik Bagfors) Date: 02 Aug 2002 09:28:53 +0200 Subject: [Mono-list] SharpZipLib and NCvsLib compiles under mono. In-Reply-To: <1028265181.21166.264.camel@erandi.boston.ximian.com> References: <1028151532.2532.125.camel@pitr.bagfors.nu> <1028265181.21166.264.camel@erandi.boston.ximian.com> Message-ID: <1028273335.2286.4.camel@detrius.ardendo.se> On Fri, 2002-08-02 at 07:13, Miguel de Icaza wrote: > Hello Erik, > > > > Still. It's VERY close to working. You guys have done an incredible > > job. I hope to have #Develop running some time in the future (maybe > > using gtk# instead of winforms) > > Thanks a lot for trying things out with the mcs compiler, and thanks for > the bug reports. Would you be able to help us track down the generated > code problem? I'd love to try. Unfortunately my time is very limited. But I'll give it a go this weekend. > Mark helped us track down a few elusive bugs in MCS with vorbis# in the > past as well. I saw that one of the bugs is fixed!! Great work! /Erik -- Erik Bågfors | erik@bagfors.nu Supporter of free software | GSM +46 733 279 273 fingerprint: 6666 A85B 95D3 D26B 296B 6C60 4F32 2C0B 693D 6E32 From sbardsley@rlwinc.com Fri Aug 2 16:54:31 2002 From: sbardsley@rlwinc.com (Stephen Bardsley) Date: Fri, 2 Aug 2002 11:54:31 -0400 Subject: [Mono-list] compiling mcs -- jit.c assertion Message-ID: Greetings: I am having trouble compiling mcs. Following is the error being reported: make[2]: Entering directory `/home/sbardsley/Projects/Mono/mcs/class/corlib' MONO_PATH= mono ../../mcs/mcs.exe --target library --noconfig -o ../lib/corlib.dll --unsafe --nostdlib @.response ** ERROR **: file jit.c: line 1441 (mono_analyze_stack): assertion failed: (sbb->outdepth == (sp - stack)) aborting... ------- I am using the freshest sources checked out of CVS for mono and mcs. The mono module compiles with no problem. Is this a known issue or am I doing something wrong? Thanks for your help. Steve _____________________ Stephen Bardsley RLW Inc. Malta, NY From crichton@gimp.org Fri Aug 2 18:32:22 2002 From: crichton@gimp.org (Mark Crichton) Date: Fri, 2 Aug 2002 13:32:22 -0400 Subject: [Mono-list] GL for Unix or "existing managed C++-librar..." Message-ID: <20020802173222.GA4354@odo.ecs.umass.edu> --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Miguel asked me to forward this to the list. This was about a discussion for getting OpenGL working on Linux and other Unicies. Mark ----- Forwarded message from Mark Crichton ----- From: Mark Crichton To: Miguel de Icaza Subject: Re: [Mono-list] existing managed C++-libraries for Mono and whats = with csgl? Date: Tue, 30 Jul 2002 12:56:37 -0400 Message-ID: <20020730165636.GA23571@odo.ecs.umass.edu> User-Agent: Mutt/1.3.27i * Miguel de Icaza (miguel@ximian.com) [020730 01:59]: > I have not looked at CSGL recently, but Mark had been looking at doing a > full binding using C#. Mark mentioned that he wanted to bind not only > the regular OpenGL stuff, but also the higher level libraries. It's a little more than that. The problem coes down to two things. First, the CSGL stuff focuses on the wgl side of things. In OpenGL, we have the "base" OpenGL, which does much of the heavy lifting, and a little add-on library that taks to a native windowing system. For Windows, it's wgl, and on x, it's glX. The interfaces are, of course, completely different. Most people don't have to deal with wgl/glX since most people try to use glut... The other is that IMHO, CSGL is inadequate for GL on modern systems. The code only really supports OpenGL, and none of the extensions. However, most modern hardware, namely nVidia GeForce hardware, needs extensions to do any of the work that most games/graphics programmers use in modern software. The prime example is vertex shaders (which are slated for OpenGL 2.0...but it's Not Here Yet). So what I've been doing is taking the gl, glu, and glut headers, and trying to autogenerate DllImport stubs for C# I think, for the most part, they should, in theory, work. However, I never tested them at all, since the code generator was pretty incomplete. The method for generating the bindings is a near-copy of the Gtk# bindings, since I just borrowed the scripts and hacked the code generator. However, I haven't had much time to play with it recently. If anyone wants to play with what I have so far (which is "almost at the point of working"), I'll be happy to send it along. > The DLLs are probably not a problem, because we have a remapping > mechanism in Mono. It should JustWork. The only issue I see is in some of the extensions. The ATI GL libraries might not have glBindProgramNV... This could be solved by either the client app Doing The Right GL Thing (querying for extensions and not using those that are not available), or some glue code. Take care, Mark Crichton ----- End forwarded message ----- --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj1KwiUACgkQOfj2Ja/u/oDP/gCgs7L2FgW+woEya5lO5II/gjoe ruoAoLDKPxFPdw3gfQoJBO2aPl00Xhio =6+pA -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From duncan@ximian.com Fri Aug 2 19:05:42 2002 From: duncan@ximian.com (Duncan Mak) Date: 03 Aug 2002 02:05:42 +0800 Subject: [Mono-list] Mono talk in Hong Kong Message-ID: <1028311542.4706.16.camel@localhost.localdomain> Hey guys, I'll be giving a talk on Mono at the HKLUG LinuxTalk event on August 10th. Details are listed here: http://linux.org.hk/org/event/200208-talk/ -- Duncan Mak From steve@oakmoon.net Fri Aug 2 17:41:26 2002 From: steve@oakmoon.net (Steven Downs) Date: 02 Aug 2002 09:41:26 -0700 Subject: [Mono-list] compiling mcs -- jit.c assertion In-Reply-To: References: Message-ID: <1028306492.30612.12.camel@trinity.oakmoon.net> --=-PYludlqoi+hvuL1Btkib Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I have been seeing this as well for the past week. Prior to the 29th I was able to compile everything fine. I have removed all the source dirs and checked everything out fresh as well. I am on a standard RH 7.3 using a self-compiled gcc 3.1 (incidentally I went back to the RH standard gcc 2.96 and got the same problem). As a side note: the mcs.exe created during the mono compile happens to work if it is copied over the mcs.exe in the mcs/ directory after it has been compiled--I just don't know if this is creating a really compliant set of classes (XSP works for me which is what I have been testing though). Steve On Fri, 2002-08-02 at 08:54, Stephen Bardsley wrote: > Greetings: >=20 > I am having trouble compiling mcs. Following is the error > being reported: >=20 > make[2]: Entering directory `/home/sbardsley/Projects/Mono/mcs/class/corl= ib' > MONO_PATH=3D mono ../../mcs/mcs.exe --target library --noconfig -o > ../lib/corlib.dll --unsafe --nostdlib @.response >=20 > ** ERROR **: file jit.c: line 1441 (mono_analyze_stack): assertion failed= : (sbb->outdepth > =3D=3D (sp - stack)) > aborting... >=20 > ------- >=20 > I am using the freshest sources checked out of CVS for mono and mcs. > The mono module compiles with no problem. >=20 > Is this a known issue or am I doing something wrong? >=20 > Thanks for your help. >=20 >=20 > Steve > _____________________ > Stephen Bardsley > RLW Inc. > Malta, NY >=20 >=20 > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list --=-PYludlqoi+hvuL1Btkib Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9SrY2btau00RJq7MRAuDMAKCEALmb5jD7bB3cb3e2SCybsufKuACffNJv 9Q8Ckb2aDdhO7yYTnZeP0Zo= =J/JM -----END PGP SIGNATURE----- --=-PYludlqoi+hvuL1Btkib-- From yuanfenkuo@students.wisc.edu Fri Aug 2 22:13:35 2002 From: yuanfenkuo@students.wisc.edu (YUAN-FEN KUO) Date: Fri, 02 Aug 2002 16:13:35 -0500 Subject: [Mono-list] removing delegate Message-ID: <28b09f2899a9.2899a928b09f@wiscmail.wisc.edu> It seems that type mismatching isn't caught when removing a delegate from a sequence of delegates. I am just wondering if this were done to match the Spec's saying that "impossible removal is benign." thank you Eric From jarek@atm.com.pl Sat Aug 3 12:09:28 2002 From: jarek@atm.com.pl (Jaroslaw Kowalski) Date: Sat, 3 Aug 2002 13:09:28 +0200 Subject: [Mono-list] Determining the full name of the file Message-ID: <000d01c23ade$3c9d7ce0$9b02a8c0@ewelak> Hi! I want to hack a bit on ".config" files, but I need an robust method to get the full file path given a (possibly relative) file name. I came up with the following idea: If the file is absolute (starts with a slash on Unix, slash, backslash, drive letter or double backslash on Windows) - just normalize it. If the file is relative - concatenate the result of getcwd() + "/" + file name and normalize the result. By normalization I mean optimizing away /../, /./ and converting multiple (back)slashes into one. Before I stard coding I wanted to ask you, if you know about any good (not realpath() as it isn't safe) library function to do this? Also, I don't want to resolve symlinks as realpath() does. Jarek From stodden@in.tum.de Sat Aug 3 14:07:01 2002 From: stodden@in.tum.de (Daniel Stodden) Date: 03 Aug 2002 15:07:01 +0200 Subject: [Mono-list] removing delegate In-Reply-To: <28b09f2899a9.2899a928b09f@wiscmail.wisc.edu> References: <28b09f2899a9.2899a928b09f@wiscmail.wisc.edu> Message-ID: <1028380021.14145.3518.camel@bitch> On Fri, 2002-08-02 at 23:13, YUAN-FEN KUO wrote: > It seems that type mismatching isn't caught when removing a delegate from a > sequence of delegates. > I am just wondering if this were done to match the Spec's saying that > "impossible removal is benign." hi. if you spot any differences between mono and mscli, it always helps if you attach simple demo. regarding the type checks: you mean throwing ArgumentExceptions during Remove in the same matter Combine does? uhm. actually i don't see msdn docs mentioning exceptions in either case. could be combine is wrong as well. [i can't find the quote you mentioned. where did you find that?] regards, dns -- ___________________________________________________________________________ mailto:stodden@in.tum.de From gonzalo@ximian.com Sat Aug 3 15:29:22 2002 From: gonzalo@ximian.com (Gonzalo Paniagua Javier) Date: 03 Aug 2002 16:29:22 +0200 Subject: [Mono-list] Determining the full name of the file In-Reply-To: <000d01c23ade$3c9d7ce0$9b02a8c0@ewelak> References: <000d01c23ade$3c9d7ce0$9b02a8c0@ewelak> Message-ID: <1028384963.536.4.camel@lalo2.micasa> El sáb, 03-08-2002 a las 13:09, Jaroslaw Kowalski escribió: > Before I stard coding I wanted to ask you, if you know about any good (not > realpath() as it isn't safe) library function to do this? Also, I don't want > to resolve symlinks as realpath() does. Path.GetFullPath (...)? - Gonzalo From jarek@atm.com.pl Sat Aug 3 16:39:02 2002 From: jarek@atm.com.pl (Jaroslaw Kowalski) Date: Sat, 3 Aug 2002 17:39:02 +0200 Subject: [Mono-list] Determining the full name of the file References: <000d01c23ade$3c9d7ce0$9b02a8c0@ewelak> <1028384963.536.4.camel@lalo2.micasa> Message-ID: <000701c23b03$e53a7770$9b02a8c0@ewelak> What about path normalization (removing "..", ".", "//") ? Path.GetFullPath() doesn't seem to support it. As soon as I'll have it working robustly with C I'll prepare a patch for GetFullPath() in C#. Jarek ----- Original Message ----- From: "Gonzalo Paniagua Javier" To: "mono-list" Sent: Saturday, August 03, 2002 4:29 PM Subject: Re: [Mono-list] Determining the full name of the file El sáb, 03-08-2002 a las 13:09, Jaroslaw Kowalski escribió: > Before I stard coding I wanted to ask you, if you know about any good (not > realpath() as it isn't safe) library function to do this? Also, I don't want > to resolve symlinks as realpath() does. Path.GetFullPath (...)? - Gonzalo _______________________________________________ Mono-list maillist - Mono-list@ximian.com http://lists.ximian.com/mailman/listinfo/mono-list From fdelfino@napoli.consorzio-cini.it Sat Aug 3 17:55:13 2002 From: fdelfino@napoli.consorzio-cini.it (Francesco FD. Delfino) Date: Sat, 3 Aug 2002 18:55:13 +0200 Subject: [Mono-list] Bug in method System.Threading.ThreadPool.QueueUserWorkItem Message-ID: <9BA46654EA1EFD4D8D8EDA3A2F664972A2B0@alcor.napoli.consorzio-cini.it> Hi, This simple piece of code demostrate that some problems are in this method (or at least that some classes this method uses are not thread safe/need some fixes): --- CUT HERE --- using System; namespace ConsoleApplication2 { /// /// Summary description for Class1. /// class Class1 { /// /// The main entry point for the application. /// [STAThread] static void Main(string[] args) { System.Threading.ThreadPool.QueueUserWorkItem (new System.Threading.WaitCallback(MyFunction)); } static void MyFunction(object o) { Console.Write("hello world!"); } } --- END CUT HERE --- Using **MINT** the output is the following, both on cygwin and linux: (process:2640): ** WARNING **: unhandled exception System.IndexOutOfRangeException: "Array index is out of range" #0: 0x00051 stelem.ref in System.Collections.ArrayList::Add ([00C02DC0] ) #1: 0x00075 callvirt in System.Threading.ThreadPool::CheckIfStartThread () #2: 0x00001 call in System.Threading.ThreadPool::AddItem ([0022F4E8] ) #3: 0x0001b call in System.Threading.ThreadPool::QueueUserWorkItemInternal ([00C03C60] [00000000] ) #4: 0x00007 callvirt in System.Threading.ThreadPool::QueueUserWorkItem ([00C03C60] [00000000] ) #5: 0x00002 call in System.Threading.ThreadPool::QueueUserWorkItemInternal ([00C03C60] ) #6: 0x00006 callvirt in System.Threading.ThreadPool::QueueUserWorkItem ([00C03C60] ) #7: 0x0000c call in ConsoleApplication2.Class1::Main ([00C06F60] ) Using **MONO** just the first line appears, then the process seems to hang for a while and then the call stack is printed. Commenting the ArrayList::Add method in the CheckIfStartThread method allows to bypass the problem, but then each QueueUserWorkItem call would create a new thread. Hope this helps. Regards, Francesco From mono@oakmoon.net Sat Aug 3 18:07:51 2002 From: mono@oakmoon.net (Steven Downs) Date: 03 Aug 2002 10:07:51 -0700 Subject: [Mono-list] compiling mcs -- jit.c assertion In-Reply-To: <1028306492.30612.12.camel@trinity.oakmoon.net> References: <1028306492.30612.12.camel@trinity.oakmoon.net> Message-ID: <1028394479.30672.24.camel@trinity.oakmoon.net> Would anyone be willing to comment on the differences and ramifications of using the mcs.exe created by the mono src tree vs. the mcs.exe created in the mcs src tree? I am still unable to compile mcs unless I skip the mcs compiler steps and copy the mcs.exe from the mono src tree (IOW, I am compiling the class library using the mcs.exe created by the mono source tree). The error I am getting is below: make[2]: Entering directory `/home/sdowns/src/mono/mcs/class/corlib' touch library-deps.stamp MONO_PATH= mono ../../mcs/mcs.exe --target library --noconfig -o ../lib/corlib.dll --unsafe --nostdlib @.response ** ERROR **: file jit.c: line 1441 (mono_analyze_stack): assertion failed: (sbb->outdepth == (sp - stack)) aborting... make[2]: *** [../lib/corlib.dll] Aborted Steve On Fri, 2002-08-02 at 09:41, Steven Downs wrote: > I have been seeing this as well for the past week. Prior to the 29th I > was able to compile everything fine. I have removed all the source dirs > and checked everything out fresh as well. > > I am on a standard RH 7.3 using a self-compiled gcc 3.1 (incidentally I > went back to the RH standard gcc 2.96 and got the same problem). > > As a side note: the mcs.exe created during the mono compile happens to > work if it is copied over the mcs.exe in the mcs/ directory after it has > been compiled--I just don't know if this is creating a really compliant > set of classes (XSP works for me which is what I have been testing > though). > > Steve > > On Fri, 2002-08-02 at 08:54, Stephen Bardsley wrote: > > Greetings: > > > > I am having trouble compiling mcs. Following is the error > > being reported: > > > > make[2]: Entering directory `/home/sbardsley/Projects/Mono/mcs/class/corlib' > > MONO_PATH= mono ../../mcs/mcs.exe --target library --noconfig -o > > ../lib/corlib.dll --unsafe --nostdlib @.response > > > > ** ERROR **: file jit.c: line 1441 (mono_analyze_stack): assertion failed: (sbb->outdepth > > == (sp - stack)) > > aborting... > > > > ------- > > > > I am using the freshest sources checked out of CVS for mono and mcs. > > The mono module compiles with no problem. > > > > Is this a known issue or am I doing something wrong? > > > > Thanks for your help. > > > > > > Steve > > _____________________ > > Stephen Bardsley > > RLW Inc. > > Malta, NY > > > > > > _______________________________________________ > > Mono-list maillist - Mono-list@ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-list > From fdelfino@napoli.consorzio-cini.it Sun Aug 4 11:45:26 2002 From: fdelfino@napoli.consorzio-cini.it (Francesco FD. Delfino) Date: Sun, 4 Aug 2002 12:45:26 +0200 Subject: [Mono-list] Bug in property System.Xml.XmlTextReader.Depth Message-ID: <9BA46654EA1EFD4D8D8EDA3A2F664972A2B2@alcor.napoli.consorzio-cini.it> Hi, Just found another bug, which actually prevents using lower level xmltextreader api. The bogus property is System.Xml.XmlTextReader.Depth I just hacked the code of this property to print out the "real" value (the property actually return 0 if the underlying attribute value 'depth' is less then zero) It seems that when a closing tag is parsed, the depth variable is decremented 3 times (instead of once). At the end of the email, you will find the c# code and the .xml file used as test. Regards, Francesco --- MS.NET OUTPUT --- 0 - 1 - 1 - 1 - 1 - 1 - 1 - --- END MS.NET OUTPUT --- --- MINT OUTPUT --- RealDepth 0 0 - RealDepth 1 1 - RealDepth 1 1 - RealDepth -2 0 - RealDepth -5 0 - RealDepth -8 0 - RealDepth -11 0 - --- END MINT OUTPUT --- --- CUT HERE: c# function --- public static void Parse() { System.Xml.XmlReader textReader = new System.Xml.XmlTextReader("c:\\test.xml"); while (textReader.Read()) { switch (textReader.NodeType) { case XmlNodeType.Element: Console.Write("<{0}", textReader.Name); bool isempty = textReader.IsEmptyElement; // set the element's attributes. while (textReader.MoveToNextAttribute ()) Console.Write(" {0}='{1}'",textReader.Name, textReader.Value); if (isempty) Console.WriteLine("/>"); else Console.WriteLine(">"); textReader.MoveToElement (); break; case XmlNodeType.Text: Console.Write(textReader.Value); break; case XmlNodeType.CDATA: Console.Write("", textReader.Value); break; case XmlNodeType.ProcessingInstruction: Console.Write("", textReader.Name, textReader.Value); break; case XmlNodeType.Comment: Console.Write("", textReader.Value); break; case XmlNodeType.XmlDeclaration: Console.Write(""); break; case XmlNodeType.Document: break; case XmlNodeType.DocumentType: Console.Write("", textReader.Name); break; } } } --- END: c# function --- --- CUT HERE: save as c:\test.xml --- > > > --- END: test.xml --- From stodden@cs.tum.edu Sun Aug 4 01:20:54 2002 From: stodden@cs.tum.edu (Daniel Stodden) Date: 04 Aug 2002 02:20:54 +0200 Subject: [Mono-list] removing delegate In-Reply-To: <2987f229c8a8.29c8a82987f2@wiscmail.wisc.edu> References: <2987f229c8a8.29c8a82987f2@wiscmail.wisc.edu> Message-ID: <1028420455.14149.3545.camel@bitch> On Sun, 2002-08-04 at 01:44, YUAN-FEN KUO wrote: [cc'd to mono-dev] > I think the follwoing piece of code will make my question clear: > > > delegate void delA(); > delegate void delB(); > > class main{ > static void Main(){ > delA food; > delA aoo = new delA(aa); > delB boo = new delB(aa); > delA coo = new delA(aa); > > //legal combine > food += aoo; > food(); > > //combine wrong type > //food += boo; //throws exception as expected during runtime, though I > wonder why not compile time > //food(); > > //revomve wrong type > food -= boo; //does not throw any exceptions though type > mismathched?? > food(); > > //legal remove > //"Attempting to remove a delegate from an empty list (or to remove a > non-existent delegate from a non-empty list) is not an error" is said in the last > paragraph of Secion 15.3 > //"Impossible Removal is benign" was used in their sample code in > Sec. 15.3 as well. > food -= coo; > food(); > > } > > static void aa(){System.Console.WriteLine("method aa");} > > } just tried it. this is indeed helpful. first, there is a bug in mcs. removing the wrong type (food-=boo) should not be allowed by the compiler. second, no mscli does not throw on food-=boo. it never does as i pointed out. but what's _really_ interesting here is that (given an actual assembly as written above) food -= boo actually suceeds, leaving you with a null ref. running mono, the second food() gets you a second call to aa(). running mscli, the second food() already bails out on null. i'll have to look into this. you may file a bug for the mcs gang in the mean time if you want to [if there isn't one already]. thanks a lot, i hate you ;), daniel > > > It seems that type mismatching isn't caught when removing a > > delegate from a > > > sequence of delegates. > > > I am just wondering if this were done to match the Spec's saying > > that > > > "impossible removal is benign." -- ___________________________________________________________________________ mailto:stodden@in.tum.de From will@digitalelite.com Sun Aug 4 16:50:20 2002 From: will@digitalelite.com (William Wise) Date: Sun, 4 Aug 2002 11:50:20 -0400 Subject: [Mono-list] Generics support? In-Reply-To: <1028420455.14149.3545.camel@bitch> Message-ID: <003b01c23bce$a36b5fa0$4c00a8c0@think2k> Has anyone thought of building support for generics into mono? I know they're not in Java or .NET (yet) so it would be interesting if Mono could beat them to the punch. Doing so could also generate good publicity in the hardcore developer community and receive mention in DDJ and other programming rags...just a thought. Will From mbravenb@students.cs.uu.nl Sun Aug 4 17:16:25 2002 From: mbravenb@students.cs.uu.nl (Martin Bravenboer) Date: Sun, 04 Aug 2002 18:16:25 +0200 Subject: [Mono-list] Generics support? References: <003b01c23bce$a36b5fa0$4c00a8c0@think2k> Message-ID: <3D4D5359.7020703@students.cs.uu.nl> Hey, > Has anyone thought of building support for generics into mono? I know > they're not in Java or .NET (yet) Sun offers an early access compiler for JSR 14: Adding generics to the Java language. I've been using this compiler for more than a year now. Of course GJ has also been around for quite some time. There are a lot of publications on the design and implementation of generics for .NET and C#, but I'm not aware of any downloadable CLR that supports them. You can find some resources on generics in Java and .NET over here: http://www.mbravenboer.org/dotnet_resources.xhtml http://www.mbravenboer.org/java_resources.xhtml Cheers, Martin Bravenboer From Lonnie@Physics.Wayne.edu Sun Aug 4 20:35:37 2002 From: Lonnie@Physics.Wayne.edu (Lonnie Cumberland) Date: Sun, 4 Aug 2002 12:35:37 -0700 Subject: [Mono-list] MONO status Message-ID: <003c01c23bee$1c288cf0$7edcd98d@octet> This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C23BB3.6FAB0960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, I have been looking at a site that shows how to use C# but I think that = it was mainly written for the MS .NET version. http://www.csharphelp.com/mainarchive.html I was wondering if MONO is compatible with the same .cs files as the MS = .NET? Actually, I am running the Windows version of MONO and like it a lot. Cheers, Lonnie ------=_NextPart_000_0039_01C23BB3.6FAB0960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All,
 
I have been looking at a site that = shows how to use=20 C# but I think that it was mainly written for the MS .NET = version.
 
http://www.csharphelp= .com/mainarchive.html
 
I was wondering if MONO is compatible = with the same=20 .cs files as the MS .NET?
 
Actually, I am running the Windows = version of MONO=20 and like it a lot.
 
Cheers,
Lonnie
 
 
------=_NextPart_000_0039_01C23BB3.6FAB0960-- From sma@3plus4.de Sun Aug 4 19:19:49 2002 From: sma@3plus4.de (Stefan Matthias Aust) Date: Sun, 04 Aug 2002 20:19:49 +0200 Subject: [Mono-list] Generics support? References: <003b01c23bce$a36b5fa0$4c00a8c0@think2k> Message-ID: <3D4D7045.1010808@3plus4.de> William Wise wrote: > Has anyone thought of building support for generics into mono? I know > they're not in Java or .NET (yet) so it would be interesting if Mono could > beat them to the punch. Indeed, it would be cool to play around generics in C#. IIRC, the C# generics proposal is modelled after GJ (which is based on a lot of type research done by Gilad Bracha, for example Strongtalk, a statically typed Smalltalk) and is build upon the ILX, an extended IL instruction set specially suited for all kinds of functional languages. I was searching for ILX and found this link -> http://research.microsoft.com/projects/ilx/fsharp.htm Unfortunately, this page if one of those which aren't correctly displayed by Mozilla (probably Front Page 5.0's fault). It about a new research language for .NET, F#, a mixture of OCaml, an object oriented functional programming language based on ML, and that parts of C# and other .NET languages that is required to interface the .NET framework. The ML type system has parameterized types which fullfill the same role as generic types in Java/C#. I might prefer using a language like F# over C#. Don't know yet. So please support ILX (I don't know wether this needs a new runtime) for mono :-) bye -- Stefan Matthias Aust // www.3plus4software.de // Inter Deum Et Diabolum Semper Musica Est From mkestner@speakeasy.net Sun Aug 4 21:51:01 2002 From: mkestner@speakeasy.net (Mike Kestner) Date: 04 Aug 2002 15:51:01 -0500 Subject: [Mono-list] gtk-sharp-0.3 released Message-ID: <1028494261.19856.149.camel@localhost.localdomain> Announcing release 0.3 of Gtk#, codenamed "Bread Pudding with Vanilla Sauce." Binaries and source tarballs are available for download at your convenience: http://sourceforge.net/project/showfiles.php?group_id=40240 About Gtk#: Gtk# is C# language binding for the Gtk+ Graphical User Interface toolkit. Well, that's understating it a bit. It's really a set of classes in IL assemblies which can theoretically be accessed by any .Net compatible language. To this date, Gtk# has been seen in the wild under the control of C# and LOGO code. People are now starting to do significant things with Gtk#, but it is still largely unproven and not recommended for production work. Changes since 0.2: - Better GInterface support (rachel) - Preliminary Docs: docs are not distributed, but can be accessed from the Gtk# homepage (rachel) - Dialog, Paned, ColorSelectionDialog, and FileSelection enhancements and customizations. (duncan) - Test samples: Duncan has been systematically exercising the binding, finding holes, and reporting bugs. Check out his work in sample/test. - DBClient sample app for Gtk# based database access. (Gonzalo and Duncan) - Enum support for GValues (rachel) - Ctor collision resolutions (rachel) - Binding of the GtkHTML widget (mkestner) - Binding of libgnome, libgnomeui, and libgnomecanvas (rachel) - GnomeHelloWorld sample (rachel) - Null parameter support (rachel) - Typed event handlers with EventArgs subclasses for compile time typesafe signal parameter access. (mkestner) - Default constructor customization support and ScrolledWindow customizations. (Radek) - Opaque structure support in the parser: (mkestner) - static method parsing and generation: (mkestner) - structure marshaling support: (rachel) - Gdk Drawable binding (rachel) - Prefer property accessor methods instead of GObject properties.(mkestner) Contact: Discussion of Gtk# occurs at gtk-sharp-list@ximian.com. Bug reports should be directed to bugzilla.ximian.com module gtk#. From fjh@cs.mu.OZ.AU Sun Aug 4 22:01:39 2002 From: fjh@cs.mu.OZ.AU (Fergus Henderson) Date: Mon, 5 Aug 2002 07:01:39 +1000 Subject: [Mono-list] Generics support? In-Reply-To: <3D4D7045.1010808@3plus4.de>; from sma@3plus4.de on Sun, Aug 04, 2002 at 08:19:49PM +0200 References: <003b01c23bce$a36b5fa0$4c00a8c0@think2k> <3D4D7045.1010808@3plus4.de> Message-ID: <20020805070139.A440467@murlibobo.cs.mu.OZ.AU> On 04-Aug-2002, Stefan Matthias Aust wrote: > I might prefer using a language like F# over C#. Don't know yet. So > please support ILX (I don't know wether this needs a new runtime) for > mono :-) Supporting ILX does not require a new runtime. Don Syme has written an ILX to IL translator. See . Supporting ILX *efficiently* may however require a new runtime. But probably there are a lot of other efficiency issues to worry about first. -- Fergus Henderson | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. From manyoso@yahoo.com Mon Aug 5 07:45:20 2002 From: manyoso@yahoo.com (Adam Treat) Date: Mon, 5 Aug 2002 02:45:20 -0400 Subject: [Mono-list] Qt# 0.4 has been released Message-ID: <200208050245.20518.manyoso@yahoo.com> August 5th, 2002 Qt# 0.4 - A cross-platform GUI toolkit for Mono and Portable.Net [1], has been released. Download for source, binaries, tutorials and documentation: http://sourceforge.net/project/showfiles.php?group_id=48999 Information and screenshots: http://qtcsharp.sourceforge.net Debian apt source: deb http://chemlab.org/~nick/debian unstable release deb-src http://chemlab.org/~nick/debian unstable release We've been hard at work over the last several months and now we're finally ready to bring you the latest release of Qt# codenamed "Purgative... Eewwww!" * Preliminary support for Qt# on Microsoft.Net (manyoso) * CreateDelegate and multiple custom slots (manyoso) * Object tracking and determinstic destruction of unmanaged resources (n1ko) * Support for events and localized Event Handling (manyoso) * A nice set of tutorials that guide the developer in the differences between Qt/C++ and Qt# (marcusU) * Debianized packages of qtcsharp and libqtc (n1ko) * Better QString <-> string handling (n1ko/marcusU) * Generated initial API docs courtesy of Portable.NET's documentation tools (manyoso) * Added Mandlebrot, a fractal viewer/generator to the samples section (marcusU) * Some fixes to the enum/constant mapping between Qt/C++ <-> Qt# (marcusU) * Numerous bug fixes and bug reports (mostly marcusU) * Better handling of the multiple inheritance issues with interfaces. See QPaintDevice in particular ;-) (manyoso) This release would not have been possible without the contributions of so many: Marcus Urban, Nick Zigarovich, Paolo Molaro, Dietmar Maurer, Mike Kestner, Rachel Hestilow, Miguel and the rest of the Mono/Ximian team, kind folks of DotGNU and PNet and most gratefully my wife Lisa for putting up with all the time I spend hunched over my computer coding furiously (not really, I mostly just screw around ;-) [1] Qt# has also been know to work with another CLR... Microsoft's .Net :-) From bios-bob@ti.com Mon Aug 5 04:48:54 2002 From: bios-bob@ti.com (bob frankel) Date: Sun, 4 Aug 2002 20:48:54 -0700 Subject: [Mono-list] status of JANET Message-ID: <000001c23c33$0916c100$6401a8c0@cnsba0783908> i've followed the link to JANET (a open-source C# implementation of JavaScript) at your site, only to find that this sourceforge project hasn't had an update in over a year!!! any idea what's going on here. or better, do you know of anyone else working on an implementation of ECMA-262 (the official standard) that will work in a .NET environment. in short, microsoft's jscript.net is just what i want as a language; i just need implementations that run on linux/unix platforms as well!!! bob frankel chief software strategist texas instruments From spvdamme@vtk2.rug.ac.be Sun Aug 4 21:42:38 2002 From: spvdamme@vtk2.rug.ac.be (Stijn "Adhemar" Vandamme) Date: Sun, 4 Aug 2002 22:42:38 +0200 (CEST) Subject: [Mono-list] Reply: Generics support? Message-ID: Hello, The site http://research.microsoft.com/projects/clrgen/ has already (since May 2001) a paper on generics in C# and .NET . http://research.microsoft.com/projects/clrgen/generics.pdf The Design and Implementation of Generics for the .NET Common Language Runtime The site says: "The standard question asked is "will it be in the final release of the current version C# and VS.NET", and the standard response is "no, but it may be in a later version". However the C# team and community are very willing to receive further feedback on generics." IMHO, the problem with Mono including generics in C# is that Microsoft probably will implement them in a future version of .Net so that there is an incompatibility (either a subtle or a very big one) with Mono. Adhemar. From harnold@imn.htwk-leipzig.de Mon Aug 5 11:39:51 2002 From: harnold@imn.htwk-leipzig.de (Holger Arnold) Date: Mon, 5 Aug 2002 12:39:51 +0200 Subject: [Mono-list] Are constants accessible via reflection? Message-ID: <200208051038.g75AcD324383@trna.ximian.com> Hello, for a research project I'm developing a compiler that targets the CLI. This compiler, which is developed partly in C# using Mono, has to store additional semantic information in the compiled PE files. The information will be stored either in the Constant table (0x0B), or in the data section of the PE file, referenced through the FieldRVA table (0x1D). The questions I have are, (i) are there any real differences (advantages/disadvantages) between storing this data in the Constants table or in the data section, and (ii) does anyone know if data stored this way is accessible via the standard System.Reflection mechanism, or if I have to use a more low-level metadata library? There should be a way to access such data via System.Reflection, as at least constants can easily be generated via the SetConstant() method of the System.Reflection.Emit.FieldBuilder class, but I'm unable to find out how. Can anyone help? Holger Arnold From david@novembar.com Mon Aug 5 13:55:57 2002 From: david@novembar.com (david@novembar.com) Date: Mon, 5 Aug 2002 14:55:57 +0200 Subject: [Mono-list] mcs can't build a file larger than 65536 bytes Message-ID: <1028552157.3d4e75dd404f1@webmail.novembar.com> mcs --fatal --target exe -o mcs.exe assign.cs attribute.cs driver.cs cs-parser.cs cs-tokenizer.cs tree.cs location.cs cfold.cs class.cs codegen.cs const.cs constant.cs decl.cs delegate.cs enum.cs ecore.cs expression.cs genericparser.cs interface.cs literal.cs modifiers.cs namespace.cs parameter.cs pending.cs report.cs rootcontext.cs statement.cs support.cs typemanager.cs /pub/gnome2/install/bin/mcs: line 2: 9956 Superado el límite de tamaño de fichero /pub/gnome2/install/bin/mono /pub/gnome2/install/bin/mcs.exe "$@" make[1]: *** [mcs.exe] Error 153 make[1]: Saliendo directorio `/pub/gnome2/source/mcs-0.13/mcs' make: *** [all] Error 1 The error is the same, so i think mono/mcs can't build a file larger than 65536. Anybody knows what happens? Thanks for your help, david From lupus@ximian.com Mon Aug 5 14:19:06 2002 From: lupus@ximian.com (Paolo Molaro) Date: Mon, 5 Aug 2002 15:19:06 +0200 Subject: [Mono-list] Are constants accessible via reflection? In-Reply-To: <200208051038.g75AcD324383@trna.ximian.com> References: <200208051038.g75AcD324383@trna.ximian.com> Message-ID: <20020805131906.GT22977@debian.org> On 08/05/02 Holger Arnold wrote: > for a research project I'm developing a compiler that targets the CLI. This > compiler, which is developed partly in C# using Mono, has to store additional > semantic information in the compiled PE files. The information will be stored > either in the Constant table (0x0B), or in the data section of the PE file, > referenced through the FieldRVA table (0x1D). You could also use custom attributes. > The questions I have are, (i) are there any real differences > (advantages/disadvantages) between storing this data in the Constants table > or in the data section, and (ii) does anyone know if data stored this way is The constant table can hold only simple types, while you can set an arbitrary blob of data in the FieldRVA table. > accessible via the standard System.Reflection mechanism, or if I have to use > a more low-level metadata library? field.GetValue() should work. See also how the C# compiler handles array initialization like: int[] array = {0, 1, 2, 3, 4, 5, 6}; > There should be a way to access such data via System.Reflection, as at least > constants can easily be generated via the SetConstant() method of the > System.Reflection.Emit.FieldBuilder class, but I'm unable to find out how. There is also SetRVAData(). lupus -- ----------------------------------------------------------------- lupus@debian.org debian/rules lupus@ximian.com Monkeys do it better From david@novembar.com Mon Aug 5 14:08:19 2002 From: david@novembar.com (david@novembar.com) Date: Mon, 5 Aug 2002 15:08:19 +0200 Subject: [Mono-list] mcs can't build a file larger than 65536 bytes Message-ID: <1028552899.3d4e78c3e1711@webmail.novembar.com> Hi, I'm trying to compile gtk# on Mandrake linux 8.1 with kernel-2.4.18.8.1mdk-1-3mdk. When compiling mcs-0.13, after install mono-0.13, i get this error: make -f makefile.gnu for i in jay mcs class nunit nunit/src/NUnitConsole ; do \ (cd $i; make -f makefile.gnu all) || exit 1; \ done make[1]: Cambiando a directorio `/pub/gnome2/source/mcs-0.13/jay' make -f makefile linux make[2]: Cambiando a directorio `/pub/gnome2/source/mcs-0.13/jay' cc -c -o closure.o closure.c cc -c -o error.o error.c cc -c -o lalr.o lalr.c cc -c -o lr0.o lr0.c cc -c -o main.o main.c cc -c -o mkpar.o mkpar.c cc -c -o output.o output.c cc -c -o reader.o reader.c cc -c -o symtab.o symtab.c cc -c -o verbose.o verbose.c cc -c -o warshall.o warshall.c cc -o jay closure.o error.o lalr.o lr0.o main.o mkpar.o output.o reader.o symtab.o verbose.o warshall.o make[2]: Saliendo directorio `/pub/gnome2/source/mcs-0.13/jay' make[1]: Saliendo directorio `/pub/gnome2/source/mcs-0.13/jay' make[1]: Cambiando a directorio `/pub/gnome2/source/mcs-0.13/mcs' ../jay/jay -ctv < ../jay/skeleton.cs cs-parser.jay > cs-parser.cs ../jay/jay: 2 rules never reduced ../jay/jay: 29 shift/reduce conflicts, 1 reduce/reduce conflict. mcs --fatal --target exe -o mcs.exe assign.cs attribute.cs driver.cs cs-parser.cs cs-tokenizer.cs tree.cs location.cs cfold.cs class.cs codegen.cs const.cs constant.cs decl.cs delegate.cs enum.cs ecore.cs expression.cs genericparser.cs interface.cs literal.cs modifiers.cs namespace.cs parameter.cs pending.cs report.cs rootcontext.cs statement.cs support.cs typemanager.cs /pub/gnome2/install/bin/mcs: line 2: 10544 File size limit exceeded /pub/gnome2/install/bin/mono /pub/gnome2/install/bin/mcs.exe "$@" make[1]: *** [mcs.exe] Error 153 make[1]: Saliendo directorio `/pub/gnome2/source/mcs-0.13/mcs' make: *** [all] Error 1 mcs.exe has a size of 65536. If i try to compile gtk# i get the same error in generator/codegen.exe I think mono/mcs can't build a file larger than 65536. Anybody knows what happens? Thanks for your help, david From martin@gnome.org Mon Aug 5 16:07:02 2002 From: martin@gnome.org (Martin Baulig) Date: 05 Aug 2002 17:07:02 +0200 Subject: [Mono-list] removing delegate In-Reply-To: <1028420455.14149.3545.camel@bitch> References: <2987f229c8a8.29c8a82987f2@wiscmail.wisc.edu> <1028420455.14149.3545.camel@bitch> Message-ID: <86bs8hny3t.fsf@einstein.home-of-linux.org> Daniel Stodden writes: > first, there is a bug in mcs. removing the wrong type (food-=boo) should > not be allowed by the compiler. Ok, this mcs bug is now fixed. -- Martin Baulig martin@gnome.org From steve@snewman.net Mon Aug 5 16:19:36 2002 From: steve@snewman.net (Steve Newman) Date: Mon, 5 Aug 2002 08:19:36 -0700 Subject: [Mono-list] Re: status of JANET In-Reply-To: <200208051319.g75DJR303355@trna.ximian.com> References: <200208051319.g75DJR303355@trna.ximian.com> Message-ID: >From: "bob frankel" >To: >Date: Sun, 4 Aug 2002 20:48:54 -0700 >Subject: [Mono-list] status of JANET > >i've followed the link to JANET (a open-source C# implementation of >JavaScript) at your site, only to find that this sourceforge project hasn't >had an update in over a year!!! any idea what's going on here. or better, >do you know of anyone else working on an implementation of ECMA-262 (the >official standard) that will work in a .NET environment. JANET was my project. There are two reasons the SourceForge project is so out of date: 1. When I began the project, there was essentially no outside interest. I worked on it for a while, and got pretty far (see below). However, eventually I set it aside and moved on to other things. So no work has been done in quite a while. There has been a little discussion of JavaScript on this list recently, maybe something will get started again. I don't have time to continue leading the project, but would be happy to help someone else picking it up. 2. Frankly, I found SourceForge so baffling that I was never able to successfully upload source, and had to go through an embarassingly convoluted process even to update the web site. So SourceForge is out of date even with respect to the stalled project. The current project status is as follows: I have a working compiler that handles most of the ECMAScript 3 language, and have implemented most of the core object model. There is a test file, about 500 lines of JavaScript, that exercises more or less all of the implemented functionality. The current implementation compiles JavaScript to C# source code, but the code generator is well isolated behind a set of interfaces, and it should be easy to add direct-to-CIL support. I have not yet tried to implement any of the jscript.net extensions, partly because (at the time) I couldn't find a specification for this language -- just some tutorials and sample code. If anyone knows of a rigorous specification for jscript.net, I'd love to hear about it. -- Steve Newman steve@snewman.net From steve@snewman.net Mon Aug 5 16:19:36 2002 From: steve@snewman.net (Steve Newman) Date: Mon, 5 Aug 2002 08:19:36 -0700 Subject: [Mono-list] Re: status of JANET In-Reply-To: <200208051319.g75DJR303355@trna.ximian.com> References: <200208051319.g75DJR303355@trna.ximian.com> Message-ID: >From: "bob frankel" >To: >Date: Sun, 4 Aug 2002 20:48:54 -0700 >Subject: [Mono-list] status of JANET > >i've followed the link to JANET (a open-source C# implementation of >JavaScript) at your site, only to find that this sourceforge project hasn't >had an update in over a year!!! any idea what's going on here. or better, >do you know of anyone else working on an implementation of ECMA-262 (the >official standard) that will work in a .NET environment. JANET was my project. There are two reasons the SourceForge project is so out of date: 1. When I began the project, there was essentially no outside interest. I worked on it for a while, and got pretty far (see below). However, eventually I set it aside and moved on to other things. So no work has been done in quite a while. There has been a little discussion of JavaScript on this list recently, maybe something will get started again. I don't have time to continue leading the project, but would be happy to help someone else picking it up. 2. Frankly, I found SourceForge so baffling that I was never able to successfully upload source, and had to go through an embarassingly convoluted process even to update the web site. So SourceForge is out of date even with respect to the stalled project. The current project status is as follows: I have a working compiler that handles most of the ECMAScript 3 language, and have implemented most of the core object model. There is a test file, about 500 lines of JavaScript, that exercises more or less all of the implemented functionality. The current implementation compiles JavaScript to C# source code, but the code generator is well isolated behind a set of interfaces, and it should be easy to add direct-to-CIL support. I have not yet tried to implement any of the jscript.net extensions, partly because (at the time) I couldn't find a specification for this language -- just some tutorials and sample code. If anyone knows of a rigorous specification for jscript.net, I'd love to hear about it. -- Steve Newman steve@snewman.net From miguel@ximian.com Mon Aug 5 18:24:51 2002 From: miguel@ximian.com (Miguel de Icaza) Date: 05 Aug 2002 13:24:51 -0400 Subject: [Mono-list] mcs can't build a file larger than 65536 bytes In-Reply-To: <1028552899.3d4e78c3e1711@webmail.novembar.com> References: <1028552899.3d4e78c3e1711@webmail.novembar.com> Message-ID: <1028568291.23531.115.camel@erandi.boston.ximian.com> > mcs.exe has a size of 65536. If i try to compile gtk# i get the same error in > generator/codegen.exe > > I think mono/mcs can't build a file larger than 65536. That seems to be a limitation in your shell. Miguel From will@digitalelite.com Mon Aug 5 18:24:31 2002 From: will@digitalelite.com (William Wise) Date: Mon, 5 Aug 2002 13:24:31 -0400 Subject: [Mono-list] Eclipse as C# sourceforge client - was: status of JANET In-Reply-To: Message-ID: <000601c23ca4$f6ef0d80$4c00a8c0@think2k> eclipse from eclipse.org does a GREAT job of making connection to a sourceforge cvs repository brain-dead easy. It's even got secure shell built into the client. There's a project to allow eclipse to work with C# files under windows at http://www.improve-technologies.com/alpha/esharp/ The only problem getting this to work on Linux is that mcs appears to take different command line parameters relative to MS's csc. A little help with this project would allow them to work with mono and provide developers with a pretty sharp (pun intended) development environment that connects easily to sourceforge. Either that or create a compatability mode for command line parameters that mimics csc. Whaddaya think? Will -----Original Message----- From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]On Behalf Of Steve Newman Sent: Monday, August 05, 2002 11:20 AM To: mono-list@ximian.com Cc: mono-list@ximian.com Subject: [Mono-list] Re: status of JANET >From: "bob frankel" >To: >Date: Sun, 4 Aug 2002 20:48:54 -0700 >Subject: [Mono-list] status of JANET > >i've followed the link to JANET (a open-source C# implementation of >JavaScript) at your site, only to find that this sourceforge project hasn't >had an update in over a year!!! any idea what's going on here. or better, >do you know of anyone else working on an implementation of ECMA-262 (the >official standard) that will work in a .NET environment. JANET was my project. There are two reasons the SourceForge project is so out of date: 1. When I began the project, there was essentially no outside interest. I worked on it for a while, and got pretty far (see below). However, eventually I set it aside and moved on to other things. So no work has been done in quite a while. There has been a little discussion of JavaScript on this list recently, maybe something will get started again. I don't have time to continue leading the project, but would be happy to help someone else picking it up. 2. Frankly, I found SourceForge so baffling that I was never able to successfully upload source, and had to go through an embarassingly convoluted process even to update the web site. So SourceForge is out of date even with respect to the stalled project. The current project status is as follows: I have a working compiler that handles most of the ECMAScript 3 language, and have implemented most of the core object model. There is a test file, about 500 lines of JavaScript, that exercises more or less all of the implemented functionality. The current implementation compiles JavaScript to C# source code, but the code generator is well isolated behind a set of interfaces, and it should be easy to add direct-to-CIL support. I have not yet tried to implement any of the jscript.net extensions, partly because (at the time) I couldn't find a specification for this language -- just some tutorials and sample code. If anyone knows of a rigorous specification for jscript.net, I'd love to hear about it. -- Steve Newman steve@snewman.net _______________________________________________ Mono-list maillist - Mono-list@ximian.com http://lists.ximian.com/mailman/listinfo/mono-list From miguel@ximian.com Mon Aug 5 19:20:40 2002 From: miguel@ximian.com (Miguel de Icaza) Date: 05 Aug 2002 14:20:40 -0400 Subject: [Mono-list] Eclipse as C# sourceforge client - was: status of JANET In-Reply-To: <000601c23ca4$f6ef0d80$4c00a8c0@think2k> References: <000601c23ca4$f6ef0d80$4c00a8c0@think2k> Message-ID: <1028571640.23538.132.camel@erandi.boston.ximian.com> > The only problem getting this to work on Linux is that mcs appears to take > different command line parameters relative to MS's csc. A little help with > this project would allow them to work with mono and provide developers with > a pretty sharp (pun intended) development environment that connects easily > to sourceforge. Either that or create a compatability mode for command line > parameters that mimics csc. As of a few weeks ago, MCS takes the same arguments as CSC. The man page and on-line help were only recently updated to reflect this though. Notice that CSC and MCS both accept /option and -option. We document the later to people to use the most unique version of the option. Miguel From christophw@alphasierrapapa.com Mon Aug 5 19:22:26 2002 From: christophw@alphasierrapapa.com (Christoph Wille) Date: Mon, 05 Aug 2002 20:22:26 +0200 Subject: [Mono-list] SharpZipLib and NCvsLib compiles under mono. In-Reply-To: <1028151532.2532.125.camel@pitr.bagfors.nu> Message-ID: <5.1.0.14.2.20020805201852.03a9a818@mail.alphasierrapapa.com> At 11:38 PM 7/31/2002 +0200, you wrote: >Just wanted you all to know that both SharpZipLib and NCvsLib (from >SharpDevelop fame) compiles under mono/mcs. I had to do some small >changes in SharpZipLib to get around bugs #28189 and #28407. But that's >not rocket science :). I also had to change NCvsLib to use SharpZipLib >instead of NZipLib (the old name of SharpZipLib, NCvsLib still used that >old name, I guess I could have gotten cvs-code instead of zip-files) We have released new versions of #ziplib and #cvslib today: http://www.icsharpcode.net/OpenSource/SharpZipLib/ http://www.icsharpcode.net/OpenSource/SharpCvsLib/ Namespaces (and project names) are now streamlined across all of our projects, and of course #cvslib now works with the latest version of #ziplib without a hitch. If someone wants to help with #cvslib, welcome aboard! Chris From miguel@ximian.com Mon Aug 5 19:23:26 2002 From: miguel@ximian.com (Miguel de Icaza) Date: 05 Aug 2002 14:23:26 -0400 Subject: [Mono-list] Reply: Generics support? In-Reply-To: References: Message-ID: <1028571805.23538.134.camel@erandi.boston.ximian.com> > IMHO, the problem with Mono including generics in C# is that Microsoft > probably will implement them in a future version of .Net so that there is > an incompatibility (either a subtle or a very big one) with Mono. When they become part of the standard, we might look into this. Not while it is on a research stage, and might still change. Miguel From jaime@geneura.ugr.es Mon Aug 5 19:32:02 2002 From: jaime@geneura.ugr.es (=?iso-8859-1?q?Jaime=20Anguiano=20Olarra?=) Date: Mon, 5 Aug 2002 20:32:02 +0200 (CEST) Subject: [Mono-list] Mono Beginners HOWTO for Windows Message-ID: <20020805183202.24388.qmail@web40308.mail.yahoo.com> --0-1462768487-1028572322=:23493 Content-Type: multipart/alternative; boundary="0-121206253-1028572322=:23493" --0-121206253-1028572322=:23493 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all!, I have made a little HOWTO for helping people to setup or build Mono on Windows. It works fine for me and I hope this will help others to get it done. It is attached. Thanks to Álvaro that made some corrections and the tarball. Cheers, Jaime. Btw. I'll be out for a week so I'll try to put the files in the CVS tonight (GTM+1) before I go. --------------------------------- Yahoo! Messenger Nueva versión: Webcam, voz, y mucho más ¡Gratis! --0-121206253-1028572322=:23493 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi all!,

I have made a little HOWTO for helping people to setup or build Mono on Windows. It works fine for me and I hope this will help others to get it done. It is attached. Thanks to Álvaro that made some corrections and the tarball.

Cheers,

Jaime.

Btw. I'll be out for a week so I'll try to put the files in the CVS tonight (GTM+1) before I go.

Yahoo! Messenger
Nueva versión: Webcam, voz, y mucho más ¡Gratis! --0-121206253-1028572322=:23493-- --0-1462768487-1028572322=:23493 Content-Type: application/x-gzip-compressed; name="mono-beginning-windows.tgz" Content-Transfer-Encoding: base64 Content-Description: mono-beginning-windows.tgz Content-Disposition: attachment; filename="mono-beginning-windows.tgz" H4sIAFjZTj0AA+w8aXMaSZb+6voVOShmbEejAoQOtywpGgGScCPQArLHMTvh KKoSyFYdTB1Cmo7+7/vey8w6OD1td8/sbhNhAUXly5fvvspe4Af7Yz4Vvi/8 6f5C+E6wiCovvuWrWj2snhwdwXu1dnJUzb/r1wu44aB+dHR4eHD4olqrH51U X7Cjb4rFhlcSxVbI2AvLjrbet+v3/6Uvbz3/4Y0/mbPYc7/BHtVatXp8eLiB /7WT4+ODJf4fHZ0cv2DVb7D3ztf/c/6f/anVb44+3bXZzei2y+7uL7udJivt Vyof681KpTVqyR8OzWqNjULLj0QsAt9yK5V2r3RhnOGvxsXZTbvRgrdRZ9Rt Gxe3IFXskqSKhxG76X8c9dkkCNlHKV8sieD6WUXdfnbbHjWMXuO2fV66bvfa g8aoPygZzX5v1O6Nzku3gZO4wKVWYF8GwYPEaBg/uzyacR6zDwAMkGI18+R4 /J1Rujjrdno/GoN297zUa/91VDJoo/MS6/jAbtcFUWeIY8m4GbSvzktCXrbw aCT1AKKijnTZb30ymt3GcHhessJY2C4vGZfXzX63Pzgv7V3RC3aAfeCrlOmS gQior/jrB/X97WG1+vawZDSWfr84a3U+6F0ag1Gn2W0vXaUj3DWu6fpNTV+O RYwIXZxpAjbavYPSF3MAAAG0enrAJJ4F4RI4wPfivSU8zhr+NBEWQO4DO0Lr rNIwkFD1IqbWZCJcQcRcOoPlOCGPIrx6t3rtJ9zjhyn3eRJaZjINTQ4Y3uEW CCN924FuDch/cYMHZzc8jrn3rfGcmTMJ9wcrsR9cy3dMyzb9f67DNV0+T8aO FSOnDqrVg/3q27PLwYVckds45I8zEcVB+Ix7jxqXoB4fO63RzXkJjOifQfD6 g1Yb5K5Kvw/wzw1K03XvvNRtX4Gof1DfRv07VKHu8K4B3+p4/6VxMeCPgnTl Rm5zVrlEZAEI/h2kQFtFoNm6qlmDG1vr7lEH268ebbqDoHCHjZ9P2fuGumvL tgX0r0QYxSzkLrciXlhbkYRKiZ791bwbR3Fo2fGyntRLyCHFBvj3l71a/d1L NppxNg0slwUTFgM/mBPYicf9mMHnOGCgBA5ncx7MXQ43hEEyncE7ZxGPkzmu ssi8GEy/JqHl8UUQPjDhw49aCcfBkwlaalugjSwKvBSoJ6azmC0s2BL2+wmc FIt5FGcASb8tNhYxA/lDbSYE7MCbC5eHZcZju8w6bGY9AjQL0I0XAXOA6cK3 UeKjMgt8nsMQbANCIMBoHOCbFcM97jPhIQ8OxnYecrUL8FH4Vih4RDiAXQAA 4SpI2IfNgkUGZpwI15E7TcLAo5uaH4YEZR4GY2sMm9qBH4dinMQ5JGEt3gv3 /MRtODmc5JG7zyZrW/aMPQBVkfiE/cyirUJuOYoyIajvPPAdMP4ZxDmY9BU2 m0i4YM6BwG5APxesJlsI1yVaWMwXNmcZOGsOuCEuCtNJyJGxk3hhhZyBALgo /AxjjhidUBJpV2QaL1MxXGv0BgXx1k6h3yTThS64NZIqPgLycUS6CRSE00RK x+l3/FMzGWiB9nw60NsTQG/wiBcdfHcSkhJlOeXSVn6nmrkBDMiY7aIlR7vc Sr8UINH6g/Xr7ZA7IkY725SfWIVOQrIQoM9aBlRfD2jCuTO27Ac0Hepjfm2F jlKRp4ILRXSW4wEkSyF02EyZgyXKLIHaC8axJTDaBqB9/XkVJkHaitQeGMJn dXUVQVA7LbZlkkW8G3TweXWX+tZdZlboZLtcou6meyRA7jSmWAV8uB39MAR+ AswRWNAxBnNBgFqxjUt5VMOEkhbNoIH8yryt3KkXuJMHsTe2ImHjEfEddJTP V45UL3CksBrUh4dgHGMS/E72bRsuB5uxcfg4mU6lmLT053X4bMQI6B2jwbeR xsP0y3bybiLwXqfbiLzPduBwKWtzsMBI7k6XNaKIe9JmO3wVxcNNID3L/zy3 phzxu7V8Rp+3oZeHhI7C5V6k2X+nvi/vf5RbYwfz5xBdq17U1BfI93TBmPsR 38ywowK7itD2phMHQV737tkVmv2W8iYk8V8Gewf0fYz67gbtxi2EO6vnLJrU detrsL5xdwcpXuOy0+2MPrFGr8Va7atOrzPq9HvDdUDrO4AeANAP7cFlY9S5 Zc3+3adO73odnMMdcDDGU8tZp8f+677Rg5zn0zpQm3kqQWHGcttvda7goBvP dbwDyBHhc3sJtAGMIE2+v4VsdC2okx2gjglUt9tuEjasf7Ud3tsd8E6Qj9fX g/Y1HY997IxugGat9l0b/vRG7GN/8ONayN/vgPwWzfGg0Rt2CfI6ELXqDhjf I4z24LbT2wxjl6RTEnd1P7oftNmg/aEz1HQb3XSGDAS43RuuVYHaTh1AJbiB cDQOVNgMkZ/STgpZn4MkNHQouNEcrfu8HJ1FYCJrxXQ9vaTTEBl1YUxWjLso MdcpCflagWE2g7DUh4gyCSHuFB7kCpmJoTAWIunA89DgWJCsg0EFuJB9QP4D kJOQG6+b3c4bhuZbTATE8JCQtJu3DYxJfQdcPavXQb06MeYSHGPdeAZxbnMv zS3QVBpgfR8hCSKU+BOEmZHAqHMO/h1o6CFxHQ6xeTAnywpmH2NjV9iEakTJ hYExMblNOFRIUSvtdivsMMCgmZm99sg0iumZpgVkG2wCsVM0487+vqDczEpT A/B0EKPL8EQhIiP7BtxlQCaQuHGZ5WMSwhOSjomYJqG84lnPtM0YMoGIRR6E JzP8BBJiUA4APySYz8YqkaEECITJT55YrtaSP7nJeoBOCDdCwAORmeGp81Bi iC6by8yLNgDkQFJhP519wTmTlKQU7uDnKQSRBn8CKgru24qMIt7fX8wEJCMi wlRwESSQfUQQSEAmWYbNAA1IRTzMgEAJABQyLVim92g5AcZwHrK9mISNsB+r OlNZ5oHCo9QLop8Il1gkOS6EQsaj4AuZHnvAOQ8y7DwHykyiu3pyeTRCAI8m aQbXKWV2+BTcLYms5UYod5ENyQLIJv1MWhGAbmdAgAkfOdHLjiWxrQlIISWL RIfCkQGHV5jvUURNJGJcEKODiYFZNREvOjWW8rd+18DC6nmJ9L3bydEU8xkQ Eo7gsjxXJ410Oi3IwpfHiGYWJKQgVKheJpYojAUfRwKWYapL94BCWjIXV1wm VZNKgIBn6nyv0nwKvr3SDK8QihvxXIS414oSk2oDkoi0yQqgKv1uDtZHLnPq InFzajRJXNwHWQ7w0AqDfmPJhyJxKdO0i3EDWDzDsW3I+Kd/MlaqaGhkD8ju Hqxc0nY3l6bKXDafqsI6QpwZvYC5whoLV8TPaUHDVon1an3IBnOI1sK2+Tzm jmncp4UZHy+BIvInC7VB8kn4yE5lf2J