class library

<= /DIV>

Just a random thought...

John
=

Get more from the Web. FREE = MSN Explorer download : http://explor= er.msn.com

------=_NextPart_001_0000_01C1086A.7C2A3120-- From martin.coxall@itouch.co.uk Mon Jul 9 16:32:25 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Mon, 9 Jul 2001 16:32:25 +0100 Subject: [Mono-list] Re: Welcome To "Mono-list"! In-Reply-To: References: Message-ID: <0107091632253G.03999@gypsumfantastic.uk.itouchnet.net> > Here's a thought: Microsoft is doing this whole "JUMP to .NET" thing, > which is basically a way to convert Java code to C#. From what little > experience I've had with C#, it looks in many ways *very* similar to Java. > So why -can't- a .NET implementation of Java be viable? > > Just a random thought... Simple answer: It can. Better answer: Since C# is a slightly better language that Java, and C# properly conforms to the CLS, whereas Java corresponds to the JLS, perhaps a j2cs translator would be better? I imagine it would be trivial(ish) to implement. --- Martin --- "Where laughing and smiling are not allowed" From trd@cs.mu.OZ.AU Mon Jul 9 16:43:02 2001 From: trd@cs.mu.OZ.AU (Tyson Dowd) Date: Tue, 10 Jul 2001 01:43:02 +1000 Subject: [Mono-list] Re: Welcome To "Mono-list"! In-Reply-To: <0107091632253G.03999@gypsumfantastic.uk.itouchnet.net>; from martin.coxall@itouch.co.uk on Mon, Jul 09, 2001 at 04:32:25PM +0100 References: <0107091632253G.03999@gypsumfantastic.uk.itouchnet.net> Message-ID: <20010710014302.A32038@cs.mu.oz.au> On 09-Jul-2001, Martin Coxall wrote: > > Here's a thought: Microsoft is doing this whole "JUMP to .NET" thing, > > which is basically a way to convert Java code to C#. From what little > > experience I've had with C#, it looks in many ways *very* similar to Java. > > So why -can't- a .NET implementation of Java be viable? > > > > Just a random thought... > > Simple answer: It can. > > Better answer: Since C# is a slightly better language that Java, and C# > properly conforms to the CLS, whereas Java corresponds to the JLS, perhaps a > j2cs translator would be better? > > I imagine it would be trivial(ish) to implement. There are few technical obstacles, but you should be careful about the legal obstacles because Sun has been known to sue people. JUMP is not just Java -> C#. IIRC it also does JVM bytecode to CIL and Java to IL bytecode. -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. trd@cs.mu.oz.au # http://www.cs.mu.oz.au/~trd # From martin.coxall@itouch.co.uk Mon Jul 9 16:49:09 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Mon, 9 Jul 2001 16:49:09 +0100 Subject: [Mono-list] Re: Welcome To "Mono-list"! In-Reply-To: <20010710014302.A32038@cs.mu.oz.au> References: <0107091632253G.03999@gypsumfantastic.uk.itouchnet.net> <20010710014302.A32038@cs.mu.oz.au> Message-ID: <0107091649093I.03999@gypsumfantastic.uk.itouchnet.net> > JUMP is not just Java -> C#. IIRC it also does JVM bytecode to CIL and > Java to IL bytecode. Yeah, but here in the world of free software, we're always going to have access to the source, so a java -> c# translator and a c# compiler are all we need. From my political perspective, if we don't have the source, we shouldn't be trying to translate it to Mono anyway. In any case, the last thing we want is a screaming RMS hovering over us with his rod of justice. --- Martin --- "Where laughing and smiling are not allowed" From trd@cs.mu.OZ.AU Mon Jul 9 17:08:06 2001 From: trd@cs.mu.OZ.AU (Tyson Dowd) Date: Tue, 10 Jul 2001 02:08:06 +1000 Subject: [Mono-list] Re: Welcome To "Mono-list"! In-Reply-To: <0107091649093I.03999@gypsumfantastic.uk.itouchnet.net>; from martin.coxall@itouch.co.uk on Mon, Jul 09, 2001 at 04:49:09PM +0100 References: <0107091632253G.03999@gypsumfantastic.uk.itouchnet.net> <20010710014302.A32038@cs.mu.oz.au> <0107091649093I.03999@gypsumfantastic.uk.itouchnet.net> Message-ID: <20010710020806.A7313@cs.mu.oz.au> On 09-Jul-2001, Martin Coxall wrote: > > > JUMP is not just Java -> C#. IIRC it also does JVM bytecode to CIL and > > Java to IL bytecode. > > Yeah, but here in the world of free software, we're always going to have > access to the source, so a java -> c# translator and a c# compiler are all we > need. Depends what you are doing. For most stuff you are right. But for some cases... Source access will be unlikely in mobile code scenarios. Source access is impossible in dynamic code generation scenarios (.NET uses dynamic code gen a fair bit, but I'm not sure whether people do this very often with Java). And finally, many languages and tools which target the JVM generate bytecodes directly. You will have to write a source->source translator for each one of them. So I think this is why JUMP offers multiple paths, and if you were really keen you could provide similar ones. > >From my political perspective, if we don't have the source, we shouldn't be > trying to translate it to Mono anyway. Politics don't necessarily come into it, sometimes technical issues mean you don't get the source. Tyson. From martin.coxall@itouch.co.uk Mon Jul 9 17:11:15 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Mon, 9 Jul 2001 17:11:15 +0100 Subject: [Mono-list] Re: Welcome To "Mono-list"! In-Reply-To: <20010710020806.A7313@cs.mu.oz.au> References: <0107091649093I.03999@gypsumfantastic.uk.itouchnet.net> <20010710020806.A7313@cs.mu.oz.au> Message-ID: <0107091711153L.03999@gypsumfantastic.uk.itouchnet.net> > Politics don't necessarily come into it, sometimes technical issues mean > you don't get the source. Fair point. But ultimately we are talking about a Java2IL only? Microsoft have said repeatedly that the CLI *can* support multiple languages, but how many *does* it? How many languages is it worth us supporting? I would argue that C# and java should be the only two for the time being. --- Martin --- "Where laughing and smiling are not allowed" From paddy.robinson-griffin@timeoutdoors.com Mon Jul 9 17:38:29 2001 From: paddy.robinson-griffin@timeoutdoors.com (Paddy Robinson-Griffin) Date: Mon, 9 Jul 2001 17:38:29 +0100 Subject: [Mono-list] Good on you Message-ID: <55A6DE12E530D411B9990050DA1669A009D257@TODREA1S001> Sorry, I can't help out with the dev of this, but I just want to let you know that as one of the Microsoft faithful, I'm pleased we'll all be one big happy development family and kill the horrid XvsMoft divide. Good on you for the mature approach (how un-slashdot-ish!) :-) From martin.coxall@itouch.co.uk Mon Jul 9 17:30:12 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Mon, 9 Jul 2001 17:30:12 +0100 Subject: [Mono-list] Good on you In-Reply-To: <55A6DE12E530D411B9990050DA1669A009D257@TODREA1S001> References: <55A6DE12E530D411B9990050DA1669A009D257@TODREA1S001> Message-ID: <0107091730123M.03999@gypsumfantastic.uk.itouchnet.net> > Sorry, I can't help out with the dev of this, but I just want to let you > know that as one of the Microsoft faithful, I'm pleased we'll all be one > big happy development family and kill the horrid XvsMoft divide. Good on > you for the mature approach (how un-slashdot-ish!) > > :-) The Register describes it as "cheeky". I see it a necessary. Monocultures are a bad thing in general, and HailStorm is a monoculture in the very worst sense. With project Mono, we can ensure there is always an alternative, and get a damn fine development platform out of it at the same time. My guess is, we'll be perfectly happy to cow ork, for as long as microsoft plays nice. How long that will be, only time will tell. --- Martin --- "Where laughing and smiling are not allowed" From peter@razorsoft.com Mon Jul 9 18:50:46 2001 From: peter@razorsoft.com (Peter Drayton) Date: Mon, 9 Jul 2001 10:50:46 -0700 Subject: [Mono-list] Looking at Microsoft implementation? Message-ID: <003101c1089f$af367ad0$1601a8c0@razorsoft.com> On the Mono web site it says: "If you have looked at Microsoft's implementation of .NET or their shared source code, you will not be able to contribute to Mono" Does "Microsoft's implementation of .NET" mean MS's actual source for .NET, or does merely ILDasm'ing mscorlib exclude someone from working on Mono? -Peter http://staff.develop.com/peterd From rubys@us.ibm.com Mon Jul 9 19:33:50 2001 From: rubys@us.ibm.com (Sam Ruby) Date: Mon, 9 Jul 2001 14:33:50 -0400 Subject: [Mono-list] Re: Welcome To "Mono-list"! Message-ID: Martin Coxall wrote: > > How many languages is it worth us supporting? I would argue that C# > and java should be the only two for the time being. The three "first tier" languages supported by the Microsoft implemenation are C#, VB, and JavaScript. - Sam Ruby From Bob_Salita@SoftworksLtd.com Mon Jul 9 21:38:36 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Mon, 09 Jul 2001 15:38:36 -0500 Subject: [Mono-list] FAQ additions Message-ID: Here are some questions gleamed from actual postings. Some are emotional, some are factual, some are difficult business questions. Convince us to help the Mono project by answering these questions: Will Mono enable running of MS Office on Linux? Otherwise its a waste. Don't existing OSS offer capabilities equivalent to .Net? Why should we direct such considerable resources to such a marginal and risky project? Aren't these resources better directed elsewhere? Isn't .Net vaporware? Is the real purpose of Mono to counterpunch MS? Isn't Mono important only because .Net will be popular? Isn't Ximian already overburdened and underfunded? How can you compete with MS minions and billions? I thought Ximian redefined itself as a service provider, not a developer? Didn't plan A already fail? Can't MS thwart Mono by creating technical or IP roadblocks? Is MS trying to bash Linux by offering .Net on BSD? Isn't it a divide and conquer gambit? Is it really about licensing terms? Why are RedHat, IBM and others refusing to directly support Mono with funding and public commitments? What do they know but won't say? Isn't Mono a foil in negotiating .Net licensing for Linux? Won't Mono run afoul of intellectual property rights? What are the alternatives to Mono? MS is releasing shared source on FreeBSD. Isn't it better to convert to FreeBSD rather than fight the .Net battle? Isn't the gain in open vs. shared source too small for the major effort? If Mono succeeds, who are the winners and losers? What level of performance can be expected? What if Mono can't achieve that level of performance? Do we really know if .Net achieves an acceptable performance level? Isn't Sun's controlling attitude responsible for MS need for .Net? I've read the reasons for Ximian'sneed for .Net. They seem really lame? This is a MS play. They'll win no matter what. What is ORP and why is it being considered for a VM? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From tom7ca@yahoo.com Mon Jul 9 21:42:46 2001 From: tom7ca@yahoo.com (Tom) Date: Mon, 9 Jul 2001 13:42:46 -0700 (PDT) Subject: [Mono-list] Mono JIT Message-ID: <20010709204246.23975.qmail@web11907.mail.yahoo.com> Hi, I read the description of the Mono project with interest. I wanted to make a suggestion about the JIT: almost all JITs appear to be written in C or another low-level language. Why that is, I can't quite fathom. I hope you'll take a look at OpenJIT (www.openjit.org), which implements a Java JIT in Java. I think an analogous approach might be suitable for CLR as well. In fact, if you get the OpenJIT folks to release their codebase under the LGPL, you might be able to use it (or an automatic translation into C#) as a starting point. I think such an approach would make retargetting the Mono JIT potentially much easier. Incidentally, a similar argument could be made about writing the Mono VM interpreter in C#. There is actually more precedent for writing the virtual machine for a language in the language itself than for the JIT. One particularly nice example is the Squeak Smalltalk VM that's implemented in Squeak Smalltalk. Cheers, Thomas. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From handor@peaseassociates.com Mon Jul 9 21:49:35 2001 From: handor@peaseassociates.com (Dominic Pease) Date: Mon, 9 Jul 2001 15:49:35 -0500 Subject: [Mono-list] Clarification on Windowing and P/Invoke Message-ID: The Runtime section of the site suggests that PInvoke will be supported, but the Classes section says, 'The only drawback is that support for PInvoke of Win32 code won't be available.' Does this just mean that you can't run Win32 code on Linux (duh) or what? Clarification would be appreciated! As for windowing: Will the HWND (etc.) functionality of the System.Windows.* libraries be supported? If not, how can we expect compatibility with GUI apps? Thanks for the info. I'm excited about the project. -DBP From bob@thestuff.net Mon Jul 9 22:14:36 2001 From: bob@thestuff.net (Bob Smith) Date: 09 Jul 2001 15:14:36 -0600 Subject: [Mono-list] Contributing In-Reply-To: References: Message-ID: <994713286.31271.6.camel@5of9.h.thestuff.net> Hello, I'd like to contribute to Mono project. I'm a decent C programmer but probably not good enough to do corba bindings or anything that complex. But, I could do alot of the gruntwork on the class libs like the math classes. What needs to be done, and what can I do? Thanks, Bob From miguel@ximian.com Mon Jul 9 22:49:01 2001 From: miguel@ximian.com (Miguel de Icaza) Date: Mon, 9 Jul 2001 17:49:01 -0400 Subject: [Mono-list] Test Message-ID: <200107092149.RAA06556@erandi.helixcode.com> Testing if this works From casey@sarahandcasey.com Mon Jul 9 23:09:43 2001 From: casey@sarahandcasey.com (Casey Cady) Date: Mon, 9 Jul 2001 15:09:43 -0700 Subject: [Mono-list] Mono contributions Message-ID: <200107092210.SAA15947@trna.ximian.com> I'd be interested in contributing to Mono, probably in the JIT or GC area. By way of full disclosure, up until a year and a half ago, I was working on the Visual C++ compiler for Alpha (which was cancelled). But since I wasn't working on anything to do with C# or .Net, and it was a relatively long time ago, I don't see any conflicts there. Thanks Casey From flaub@dev.virtuoso.com Mon Jul 9 23:23:50 2001 From: flaub@dev.virtuoso.com (Frank Laub) Date: Mon, 9 Jul 2001 15:23:50 -0700 Subject: [Mono-list] Mono contributions Message-ID: <405B970EDF7A804FBC97EAFBDAB2769D016BE9@MAIL.virtuoso.com> Greetings! I'm interested in contributing to the Mono project. I'd be interested in working on the C# compiler. I'm also interested in working with the System.Net classes. Sounds like a very interesting project! Thanks Frank From me@ryanmarsh.com Mon Jul 9 21:32:15 2001 From: me@ryanmarsh.com (Ryan Marsh) Date: 09 Jul 2001 15:32:15 -0500 Subject: [Mono-list] Questions Message-ID: <994710735.2874.1.camel@cocoon.butterflysoft.org> I apologize if I am a johnny-come-lately. If the war has already been fought, please just share the out come with me. Firstly, I laud Miguel's efforts and his bravery in embracing a positive thing out of Redmond. Many of us could not resist the flames if we ever publicly supported anything MS did right. Nor could we survive if criticising the "Unix way" of doing something. Gnome is alot of work. It has taken many (donated) man hours of work to get the code to it's current place. Making dedications to large architectural changes or improvments must be made with prudence. If we decide to do 'X', will we ever get there (remember mozilla)? I think adopting a standard such as the CLI is a very wise decision. I have one fear. It would be niave to think that if we as a community started to 'best' Microsoft (imagine that the Linux implementation is better) that they would not do everything in their power to 'extend' interfaces and essentially do what Microsoft does best. Essentially we don't want to wind up like Samba, going from best to worst (no offence guys it's not your fault). Even if it does become an ECMA standard, what assurances do we have that Microsoft won't engineer subtle differences that make it difficult to write portable code, or to add small incompatible features that we will always be running to catchup with? How do we know we won't get, excuse the expression, 0wNz0r3d? In the interest of jogging your memory: Anyone who has been a Java developer for more than 3 years remembers using the MS jvm and how their extensions to Java were only the tip of the iceberg. The real problem was the many basic functions existing in the Sun standard that were used differently, not implemented, or were not reliable in the MS version. This forced developers to use code in a manner that was not portable. This is a much more subtle problem but it is much more dangerous. Let's remember that this is not simply a protocol to be implemented, it is an entire environment (much more complex). What assurances do we have that Microsoft will play well when we show their customers how much better a platform Linux is? Regards, -ryan The three great virtues of programming are laziness, impatience, and hubris, but bigotry makes the open-source world go round. From miguel@ximian.com Mon Jul 9 23:37:25 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 09 Jul 2001 18:37:25 -0400 Subject: [Mono-list] On porting to C# Message-ID: Hello guys, Sam brings up an interesting point: why port existing software from Java to C#? Given that the CLR is supposed to be language neutral, it makes sense to make sure that Java byte codes can be executed in the CLR. The only issue I see is that Java programs will expect a set of class libraries to be available for them to use, and this might not be the case for the CLR. What approach do you suggest we should use Sam? Miguel. From wesley@felter.org Tue Jul 10 00:05:48 2001 From: wesley@felter.org (Wesley Felter) Date: Mon, 9 Jul 2001 18:05:48 -0500 (CDT) Subject: [Mono-list] On porting to C# In-Reply-To: Message-ID: On 9 Jul 2001, Miguel de Icaza wrote: > Sam brings up an interesting point: why port existing software from > Java to C#? Given that the CLR is supposed to be language neutral, it > makes sense to make sure that Java byte codes can be executed in the > CLR. > > The only issue I see is that Java programs will expect a set of > class libraries to be available for them to use, and this might not be > the case for the CLR. What approach do you suggest we should use Sam? Classpath sounds like it would mostly fit the bill here. Wesley Felter - wesley@felter.org - http://felter.org/wesley/ From casey@sarahandcasey.com Mon Jul 9 23:52:48 2001 From: casey@sarahandcasey.com (Casey Cady) Date: Mon, 9 Jul 2001 15:52:48 -0700 Subject: [Mono-list] On porting to C# In-Reply-To: Message-ID: <200107092253.SAA19539@trna.ximian.com> Hmm, I'd probably emphasize Java *language* compatibility as opposed to byte code compatibility. I've not looked at Java's byte codes in quite some time, but I believe that MS had a fundamentally different mindset when developing MSIL, which was that MSIL was never to be interpreted, only JITed. This might make compatibility on the MSIL/Byte Code level a bit tricky due to the philosophical differences. Besides, it's probably much easier just to throw together a Java compiler that uses the CodeDOM and Reflection.Emit stuff as an MSIL puker than it is to write a Byte code converter, which, IMHO, misses the point of the CLR. Thanks Casey On Monday, July 9, 2001, at 03:37 PM, Miguel de Icaza wrote: > > Hello guys, > > Sam brings up an interesting point: why port existing software from > Java to C#? Given that the CLR is supposed to be language neutral, it > makes sense to make sure that Java byte codes can be executed in the > CLR. > > The only issue I see is that Java programs will expect a set of > class libraries to be available for them to use, and this might not be > the case for the CLR. What approach do you suggest we should use Sam? > > Miguel. > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > From miguel@ximian.com Mon Jul 9 23:53:57 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 09 Jul 2001 18:53:57 -0400 Subject: [Mono-list] Answering questions. Message-ID: Bob Salita posted a few questions on the list, I have answered here, and added them to our FAQ: Here are the questions: ## > Will Mono enable running of MS Office on Linux? Otherwise its a > waste. No, Mono is not a mechanism to run existing Windows applications on Linux. Look at Wine for this kind of technology. I see Mono as an upgrade on the development platform, an exciting addition to the developer toolkit. The goal of Mono is to bring this technology to non-Windows platforms (although we hope Mono will also run on Windows, for debugging and comparative purposes). ## > Q: How can you expect Mono to compete with Microsoft, wont this > require an effort too large? > > A: You are right. Mono will never become a reality without the help > of other contributors. Ximian is a small company that can not > finish Mono alone. We will be working with members of the > community to deliver the product. ## Q: What about Intel's research JIT framework, ORP? A: At this time, we are investigating whether we can use elements of ORP for Mono. ORP is a research JIT engine that has a clear defined API that splits the JIT from the GC system and the actual byte code implementation. It is a research product. ## Q: How can you expect Mono to compete with Microsoft, wont this require an effort too large? A: You are right. Mono will never become a reality without the help of other contributors. Ximian is a small company that can not finish Mono alone. We will be working with members of the community to deliver the product. Miguel. From miguel@ximian.com Mon Jul 9 23:58:16 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 09 Jul 2001 18:58:16 -0400 Subject: [Mono-list] On porting to C# In-Reply-To: Casey Cady's message of "Mon, 9 Jul 2001 15:52:48 -0700" References: <200107092253.SAA19539@trna.ximian.com> Message-ID: > Besides, it's probably much easier just to throw together a Java > compiler that uses the CodeDOM and Reflection.Emit stuff as an MSIL > puker than it is to write a Byte code converter, which, IMHO, misses the > point of the CLR. CodeDOM is sadly a badly designed piece of code. It is not really useful for a compiler, it is mostly a tool for creating C# source code, but the tree later gets passed on to an external C# compiler. Reflection.Emit on the other hand is really nice Miguel. From miguel@ximian.com Tue Jul 10 00:21:04 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 09 Jul 2001 19:21:04 -0400 Subject: [Mono-list] Mono JIT Message-ID: OpenJIT looks really interesting, but it assumes that you have an existing Java implementation to run it on. Currently we have no JIT available on non-Windows systems. Miguel. From stefan.arentz@soze.com Tue Jul 10 00:19:35 2001 From: stefan.arentz@soze.com (Stefan Arentz) Date: Tue, 10 Jul 2001 01:19:35 +0200 Subject: [Mono-list] Mono without too many GNOME dependencies Message-ID: <20010710011935.A2689@keyser.soze.com> I'm interested in working on Mono for Mac OS X, but I'm a bit afraid that there will be many many dependencies on existing GNOME libraries. Is it possible to make the Mono core (CLI) pretty much self supporting without too many dependencies? Stefan From miguel@ximian.com Tue Jul 10 00:25:08 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 09 Jul 2001 19:25:08 -0400 Subject: [Mono-list] PInvoke clarification Message-ID: > The Runtime section of the site suggests that PInvoke will be supported, but > the Classes section says, `The only drawback is that support for PInvoke of > Win32 code wont be available'. Does this just mean that you can't run Win32 > code on Linux (duh) or what? Yes, that is what this means. We need to support PInvoke for example to write our own interfaces to the existing libraries (ie, libc open()). But if you copy an executable from Windows that uses PInvoke on a Win32 call, we wont be able to make that call. On HWND: we will support handles, but those handles will be mapped to whatever abstraction makes sense for us. If you try to "work around" System.Windows.Forms and talk to Win32 through PInvoke, you would find two surprises: 1. We dont support Win32 PInvoke calls (we might at some point with Wine. Careful: at *some distant* point). 2. The HWND is not a Windows handle, but something that just makes sense to the backing implementation of System.Windows.Forms. Miguel. From miguel@ximian.com Tue Jul 10 00:30:40 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 09 Jul 2001 19:30:40 -0400 Subject: [Mono-list] Contributing to the classes. Message-ID: (Paolo look at the end) There are a number of people who are interested in contributing to the class libraries in Mono. Here is how we can organize this work: 1. Pick a class that you want to implement. 2. Post to the list `I am implementing XXX, and I estimate it will take YYY days' (please, try to have a good estimate). 3. We will keep track of this (actually, we need a volunteer to keep track of this). 4. If YYY days pass and we do not hear from you, we will "release" the class to other contributors and assume you got too busy to implement it. 5. I will put up a web page with the "ownerships" of the various classes that are being worked on so people can track it 6. If you finish your class, post it to the list, or mail me your implementation and I will put it up. (Paolo, do you think we can use a version of your script to keep track of this?) Miguel. From miguel@ximian.com Tue Jul 10 00:34:30 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 09 Jul 2001 19:34:30 -0400 Subject: [Mono-list] Mono contributions Message-ID: Hello, Hey Casey, currently here is how the plan looks like: * Dick Porter is currently researching the GC system, please get in touch with him, so we can discuss the issues involved (dick@ximian.com). * We are trying to build a few things before we do the JIT (my excuse for not jumping into the JIT): * A disassembler (to make sure we understand all the metadata correctly). * An interpreter: so we can at least have a simple to debug CLI that can be used to test code. * The actual JIT. Do you have any suggestions about the GC or the JIT? Miguel. From miguel@ximian.com Tue Jul 10 00:41:40 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 09 Jul 2001 19:41:40 -0400 Subject: [Mono-list] Archive of Mono-Hackers Message-ID: Hello guys, Some of you that wanted to contribute might want to look at the archives that we had for the `mono hackers', there are a few guidelines for coding things like System.Net (I know because Frank mentioned that): http://mail.ximian.com/archives/public/mono-hackers-list Miguel. From miguel@ximian.com Tue Jul 10 00:46:23 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 09 Jul 2001 19:46:23 -0400 Subject: [Mono-list] Mono without too many GNOME dependencies In-Reply-To: Stefan Arentz's message of "Tue, 10 Jul 2001 01:19:35 +0200" References: <20010710011935.A2689@keyser.soze.com> Message-ID: > I'm interested in working on Mono for Mac OS X, but I'm a bit afraid > that there will be many many dependencies on existing GNOME > libraries. I agree with your sentiment, and I am glad to see someone from the Mac OS X hackers in the list. I have been secretly wishing that someone would be interested! I think that the GNOME bits (Gtk+ for the toolkit and libart for the Drawing2D namespace) make sense on X environments, or in embedded environments (GtkFb), but for other platforms like MacOS X, we should just use the native Cocoa > Is it possible to make the Mono core (CLI) pretty much self supporting > without too many dependencies? Yes. The only dependency we have right now is the `glib', which is just a collection of useful C routines (hashtables, lists, memory allocation, string functions). No dependencies on GNOME whatsoever. Miguel. From nelson@monkey.org Tue Jul 10 00:52:26 2001 From: nelson@monkey.org (Nelson Minar) Date: Mon, 9 Jul 2001 16:52:26 -0700 (PDT) Subject: [Mono-list] Mono contributions In-Reply-To: References: Message-ID: <15178.17338.145015.748713@syrah.nelson.monkey.org> Mono is the most exciting thing I've seen all year! Thanks, Ximian! > * We are trying to build a few things before we do the JIT > * An interpreter I'd love to have an interpreter - JITs are often superfluous, at least for the JVM. If folks are interested in this topic, this article is interesting: http://www2.fit.qut.edu.au/CompSci/PLAS//ComponentPascal/VirtualMachines.ps It makes the case that the details of typing in the CLR make an interpreter much more difficult than in the JVM. Also has some suggestions about how to work around it. nelson@monkey.org . . . . . . . . http://www.media.mit.edu/~nelson/ From stefan.arentz@soze.com Tue Jul 10 01:00:32 2001 From: stefan.arentz@soze.com (Stefan Arentz) Date: Tue, 10 Jul 2001 02:00:32 +0200 Subject: [Mono-list] Mono without too many GNOME dependencies In-Reply-To: ; from miguel@ximian.com on Mon, Jul 09, 2001 at 07:46:23PM -0400 References: <20010710011935.A2689@keyser.soze.com> Message-ID: <20010710020032.A3077@keyser.soze.com> On Mon, Jul 09, 2001 at 07:46:23PM -0400, Miguel de Icaza wrote: > > > I'm interested in working on Mono for Mac OS X, but I'm a bit afraid > > that there will be many many dependencies on existing GNOME > > libraries. > > I agree with your sentiment, and I am glad to see someone from the Mac > OS X hackers in the list. I have been secretly wishing that someone > would be interested! Good. What kind of plan do you suggest for an 'alternative' platform? Keep up-to-date with the current sources, or do a port when things are stable? (I have no idea if I can commit time, but I wil certainly stay around) > > Is it possible to make the Mono core (CLI) pretty much self supporting > > without too many dependencies? > > Yes. The only dependency we have right now is the `glib', which is > just a collection of useful C routines (hashtables, lists, memory > allocation, string functions). > > No dependencies on GNOME whatsoever. Sounds good! glib has already been ported to Darwin/OS X so that will not be a problem. Stefan From Bob_Salita@SoftworksLtd.com Tue Jul 10 01:05:50 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Mon, 09 Jul 2001 19:05:50 -0500 Subject: [Mono-list] On porting to C# Message-ID: Wouldn't you also need to implement a way to expose Java objects for other languages to use? Unless Java is a first class CLR language, things may quickly become too problematic. >Miguel wrote: > Sam brings up an interesting point: why port existing software from >Java to C#? Given that the CLR is supposed to be language neutral, it >makes sense to make sure that Java byte codes can be executed in the >CLR. > > The only issue I see is that Java programs will expect a set of >class libraries to be available for them to use, and this might not be >the case for the CLR. What approach do you suggest we should use Sam? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From casey@sarahandcasey.com Tue Jul 10 01:06:22 2001 From: casey@sarahandcasey.com (Casey Cady) Date: Mon, 9 Jul 2001 17:06:22 -0700 Subject: [Mono-list] On porting to C# In-Reply-To: Message-ID: <200107100007.UAA26528@trna.ximian.com> Substitute "badly designed" with "immature" and I'll completely agree with you. :) I see potential in the CodeDOM namespace but currently it needs a big fat flashing red warning saying "I cheat!!!". (For those that don't know about the CodeDOM namespace, it allows you to programatically represent source code. You can then dump the CodeDOM to a source file, or compile it to MSIL. The huge catch is that Microsoft's implementation of the CodeDOM compiler simply spits out c# code and compiles it externally with the plain old compiler.) Thanks Casey On Monday, July 9, 2001, at 03:58 PM, Miguel de Icaza wrote: > >> Besides, it's probably much easier just to throw together a Java >> compiler that uses the CodeDOM and Reflection.Emit stuff as an MSIL >> puker than it is to write a Byte code converter, which, IMHO, misses >> the >> point of the CLR. > > CodeDOM is sadly a badly designed piece of code. It is not really > useful for a compiler, it is mostly a tool for creating C# source > code, but the tree later gets passed on to an external C# compiler. > > Reflection.Emit on the other hand is really nice > > Miguel. > From rodrigo@ximian.com Tue Jul 10 01:12:31 2001 From: rodrigo@ximian.com (Rodrigo Moya) Date: 10 Jul 2001 02:12:31 +0200 Subject: [Mono-list] ADO.NET and GNOME-DB Message-ID: <994723954.9344.17.camel@zubiri> Hi! I've just been said about an article, by Brian Jepson, in which there is a comparison between ADO.NET and GNOME-DB, which may be of interest it's at http://www.oreillynet.com/pub/a/dotnet/2001/07/09/mono.html cheers -- Rodrigo Moya - http://www.gnome-db.org/ - http://www.ximian.com/ From Bob_Salita@SoftworksLtd.com Tue Jul 10 01:21:28 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Mon, 09 Jul 2001 19:21:28 -0500 Subject: [Mono-list] Answering questions. Message-ID: >Miguel wrote: >Bob Salita posted a few questions on the list, I have answered here, >and added them to our FAQ: I'm sorry to be in the taskmaster role. You've only answered a few of the questions and there are many really important questions remaining to be answered. I believe I speak for other developers and angels in requesting upfront full disclosure and challenges to your thinking. Can we get answers to the remaining questions? Bob. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From fejj@ximian.com Tue Jul 10 01:45:38 2001 From: fejj@ximian.com (Jeffrey Stedfast) Date: 09 Jul 2001 20:45:38 -0400 Subject: [Mono-list] I'll be implementing System.String Message-ID: <994725938.13274.10.camel@tazmanian-devil.helixcode.com> Miguel told me to announce that I'll be working on hacking System.String just so that no one duplicates this effort. Jeff From miguel@ximian.com Tue Jul 10 01:57:51 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 09 Jul 2001 20:57:51 -0400 Subject: [Mono-list] Answering questions. In-Reply-To: "Bob Salita"'s message of "Mon, 09 Jul 2001 19:21:28 -0500" References: Message-ID: > I'm sorry to be in the taskmaster role. You've only answered a few of the > questions and there are many really important questions remaining to be > answered. I believe I speak for other developers and angels in requesting > upfront full disclosure and challenges to your thinking. Can we get answers > to the remaining questions? There were about 30 questions, and I found many of them unrelated to Mono. Can you point out the ones that you find particularly troublesome? I do want to get back to code, you know ;-). Miguel. From peter@razorsoft.com Tue Jul 10 02:33:37 2001 From: peter@razorsoft.com (Peter Drayton) Date: Mon, 9 Jul 2001 18:33:37 -0700 Subject: [Mono-list] Re: Welcome To "Mono-list"! In-Reply-To: <0107091711153L.03999@gypsumfantastic.uk.itouchnet.net> Message-ID: <002601c108e0$5956c5c0$6ea6accf@razorsoft.com> > How many languages is it worth us supporting? I would argue that C# and > java should be the only two for the time being. If the point of this project is an alternate implementation of the CLI, why on earth worry about Java yet? It's not in the CLI specs and there's no .NET code written in Java yet outside of research labs :-). IMHO the focus should be laser-sharp, on building a high-quality C# compiler and CLI implementation (and here I *specifically* mean the VES & 250-odd CLI classes, not the 3800+ that are in .NET and *not* in the CLI). More classes and other language compilers/porting tools are a natural once the core is in place, but let's walk before we run, for heavens sake! --Peter http://staff.develop.com/peterd From jbarn@httcb.net Tue Jul 10 03:01:06 2001 From: jbarn@httcb.net (John Barnette) Date: Mon, 9 Jul 2001 20:01:06 -0600 Subject: [Mono-list] C# coding standards for Mono Message-ID: Hey kids, Has anybody taken a stab at a C# coding standard for Mono classes? I'm thinking something along the lines of Sun's Java Coding Conventions (http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html) ~ j. From rubys@us.ibm.com Tue Jul 10 02:54:24 2001 From: rubys@us.ibm.com (Sam Ruby) Date: Mon, 9 Jul 2001 21:54:24 -0400 Subject: [Mono-list] On porting to C# Message-ID: Miguel de Izaca wrote: > > Sam brings up an interesting point: why port existing software from > Java to C#? Given that the CLR is supposed to be language neutral, it > makes sense to make sure that Java byte codes can be executed in the > CLR. Directly supporting Java byte codes? That surprises me. In that case, it is not exactly the same CLR as ECMA is standardizing or Microsoft is implementing. > The only issue I see is that Java programs will expect a set of > class libraries to be available for them to use, and this might not be > the case for the CLR. What approach do you suggest we should use Sam? The Microsoft implementation of PInvoke supports COM Interop. It would be nice if the Mono implementation supported CORBA Interop and/or Java Interop. - Sam Ruby From peter@razorsoft.com Tue Jul 10 03:16:04 2001 From: peter@razorsoft.com (Peter Drayton) Date: Mon, 9 Jul 2001 19:16:04 -0700 Subject: [Mono-list] ReplyTo in headers Message-ID: <002c01c108e6$50fad280$6ea6accf@razorsoft.com> Could the list admin please set up the list so there's a Reply-To in the header, pointing at mono-list@ximian.com? It's quite annoying to default to emailing the poster directly, rather than the list at large. Thanks! --Peter http://staff.develop.com/peterd From peter@razorsoft.com Tue Jul 10 03:16:04 2001 From: peter@razorsoft.com (Peter Drayton) Date: Mon, 9 Jul 2001 19:16:04 -0700 Subject: [Mono-list] On porting to C# In-Reply-To: Message-ID: <002d01c108e6$52f7b3f0$6ea6accf@razorsoft.com> I certainly hope that any attempt to compile Java source into MSIL opcodes would result in normal CTS metadata with normal IL opcodes, possibly with one or more supporting libraries. This should give you interop no worse than, say, VB.NET<->C#, right? --Peter http://staff.develop.com/peterd > -----Original Message----- > From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com] On > Behalf Of Bob Salita > Sent: Monday, July 09, 2001 5:06 PM > To: mono-list@ximian.com > Subject: Re: [Mono-list] On porting to C# > > Wouldn't you also need to implement a way to expose Java objects for other > languages to use? Unless Java is a first class CLR language, things may > quickly become too problematic. > > >Miguel wrote: > > Sam brings up an interesting point: why port existing software from > >Java to C#? Given that the CLR is supposed to be language neutral, it > >makes sense to make sure that Java byte codes can be executed in the > >CLR. > > > > The only issue I see is that Java programs will expect a set of > >class libraries to be available for them to use, and this might not be > >the case for the CLR. What approach do you suggest we should use Sam? > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list From peter@razorsoft.com Tue Jul 10 03:16:04 2001 From: peter@razorsoft.com (Peter Drayton) Date: Mon, 9 Jul 2001 19:16:04 -0700 Subject: [Mono-list] Mono contributions In-Reply-To: <15178.17338.145015.748713@syrah.nelson.monkey.org> Message-ID: <002e01c108e6$5a246740$6ea6accf@razorsoft.com> +1. I'm with Nelson on this - interpreters have all sorts of nice characteristics IMO, in that they are easier to write, easier to read, and easier to port. I think these are important characteristics for a bootstrap like this, where you want the core system to materialize and stabilize fast enough to retain community interest, and to also be approachable. IMO a well-designed VES should be able to combine JITted and interpreted code, too, and change the mix over time (ie. reJIT code if access patterns change, or pitch JITted functions and go back to interpreting if memory is tight). Are these currently goals for Mono? Is there a list somewhere of the design goals for the Mono VES? --Peter http://staff.develop.com/peterd > -----Original Message----- > From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com] On > Behalf Of Nelson Minar > Sent: Monday, July 09, 2001 4:52 PM > To: mono-list@ximian.com > Subject: Re: [Mono-list] Mono contributions > > Mono is the most exciting thing I've seen all year! Thanks, Ximian! > > > * We are trying to build a few things before we do the JIT > > * An interpreter > > I'd love to have an interpreter - JITs are often superfluous, at least > for the JVM. If folks are interested in this topic, this article is > interesting: > > http://www2.fit.qut.edu.au/CompSci/PLAS//ComponentPascal/VirtualMachines .p > s > > It makes the case that the details of typing in the CLR make an > interpreter much more difficult than in the JVM. Also has some > suggestions about how to work around it. > > nelson@monkey.org > . . . . . . . . http://www.media.mit.edu/~nelson/ > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list From peter@razorsoft.com Tue Jul 10 03:16:04 2001 From: peter@razorsoft.com (Peter Drayton) Date: Mon, 9 Jul 2001 19:16:04 -0700 Subject: [Mono-list] Re: Welcome To "Mono-list"! In-Reply-To: <0107091632253G.03999@gypsumfantastic.uk.itouchnet.net> Message-ID: <003001c108e6$6214b8b0$6ea6accf@razorsoft.com> > Better answer: Since C# is a slightly better language that Java, and C# > properly conforms to the CLS, whereas Java corresponds to the JLS, perhaps > a j2cs translator would be better? FYI, the CLS is the Common Language Specification, which isn't really anything to so with C#. Rather, the CLS is a subset of the Common Type System (CTS). The CTS is the set of rules for defining and using types, and the CLS subsets these rules to make it easier to allow languages to interoperate. It's true that C# can produce CLS-compliant types (although it can also produce types that are not CLS-compliant). However, from the context of your email it looked like you were referring to the C# language specification, not the CLS. --Peter http://staff.develop.com/peterd From jbarn@httcb.net Tue Jul 10 03:23:49 2001 From: jbarn@httcb.net (John Barnette) Date: Mon, 9 Jul 2001 20:23:49 -0600 Subject: [Mono-list] Inconsistent namespaces || I am really dumb Message-ID: Looking through the current set of classes, I notice that, for example, mcs/class/corlib/System.CodeDom/CodeArrayCreateExpression.cs contains: namespace System.CodeDOM { ... } while mcs/class/corlib/System.Collections/IDictionary.cs contains: namespace MCS.System.Collections { ... } Is this an unintentional inconsistency, or am I missing something? ~ j. From peter@razorsoft.com Tue Jul 10 03:20:23 2001 From: peter@razorsoft.com (Peter Drayton) Date: Mon, 9 Jul 2001 19:20:23 -0700 Subject: [Mono-list] C# coding standards for Mono In-Reply-To: Message-ID: <003101c108e6$e15a5b20$6ea6accf@razorsoft.com> Following the Microsoft recommendations in the Framework SDK might be a good idea - they seem pretty well thought out, and the code is going to look and feel familiar to other .NET programmers. --Peter http://staff.develop.com/peterd > -----Original Message----- > From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com] On > Behalf Of John Barnette > Sent: Monday, July 09, 2001 7:01 PM > To: mono-list@ximian.com > Subject: [Mono-list] C# coding standards for Mono > > Hey kids, > > Has anybody taken a stab at a C# coding standard for Mono classes? I'm > thinking something along the lines of Sun's Java Coding Conventions > (http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html) > > > ~ j. > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list From peter@razorsoft.com Tue Jul 10 03:32:58 2001 From: peter@razorsoft.com (Peter Drayton) Date: Mon, 9 Jul 2001 19:32:58 -0700 Subject: [Mono-list] C# coding standards for Mono In-Reply-To: Message-ID: <003501c108e8$a35472a0$6ea6accf@razorsoft.com> Darn mailing list - I think John meant to mail the list... :-) It's in the help system under .NET Framework SDK->.NET Framework Developer Specifications->.NET Framework Design Guidelines. In particular check out the "Naming Guidelines" section, though the entire set of design guidelines is also good reading. --Peter http://staff.develop.com/peterd > -----Original Message----- > From: John Barnette [mailto:jbarn@httcb.net] > Sent: Monday, July 09, 2001 7:32 PM > To: Peter Drayton > Subject: RE: [Mono-list] C# coding standards for Mono > > Oh, excellent. Could you tell me where in the SDK I might find 'em? I > searched through the help, but I'm still getting a grasp on the Microsoft > help system. ;-) > > > ~ j. > > > -----Original Message----- > From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]On > Behalf Of Peter Drayton > Sent: Monday, July 09, 2001 8:20 PM > To: mono-list@ximian.com > Subject: RE: [Mono-list] C# coding standards for Mono > > > Following the Microsoft recommendations in the Framework SDK might be a > good idea - they seem pretty well thought out, and the code is going to > look and feel familiar to other .NET programmers. > > --Peter > http://staff.develop.com/peterd > > > > -----Original Message----- > > From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com] > On > > Behalf Of John Barnette > > Sent: Monday, July 09, 2001 7:01 PM > > To: mono-list@ximian.com > > Subject: [Mono-list] C# coding standards for Mono > > > > Hey kids, > > > > Has anybody taken a stab at a C# coding standard for Mono classes? > I'm > > thinking something along the lines of Sun's Java Coding Conventions > > (http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html) > > > > > > ~ j. > > > > > > _______________________________________________ > > Mono-list maillist - Mono-list@ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-list > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list From jbarn@httcb.net Tue Jul 10 03:42:11 2001 From: jbarn@httcb.net (John Barnette) Date: Mon, 9 Jul 2001 20:42:11 -0600 Subject: [Mono-list] C# coding standards for Mono In-Reply-To: <003501c108e8$a35472a0$6ea6accf@razorsoft.com> Message-ID: > -----Original Message----- > From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]On > Behalf Of Peter Drayton > Sent: Monday, July 09, 2001 8:33 PM > To: mono-list@ximian.com > Subject: RE: [Mono-list] C# coding standards for Mono > > > Darn mailing list - I think John meant to mail the list... :-) D'oh. Silly mailman default settings. Thanks for the pointer. > It's in the help system under .NET Framework SDK->.NET Framework > Developer Specifications->.NET Framework Design Guidelines. In > particular check out the "Naming Guidelines" section, though the entire > set of design guidelines is also good reading. ~ j. > > Oh, excellent. Could you tell me where in the SDK I might find 'em? > I > > searched through the help, but I'm still getting a grasp on the > Microsoft > > help system. ;-) > > > > > > ~ j. > > > > > > -----Original Message----- > > From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]On > > Behalf Of Peter Drayton > > Sent: Monday, July 09, 2001 8:20 PM > > To: mono-list@ximian.com > > Subject: RE: [Mono-list] C# coding standards for Mono > > > > > > Following the Microsoft recommendations in the Framework SDK might be > a > > good idea - they seem pretty well thought out, and the code is going > to > > look and feel familiar to other .NET programmers. > > > > --Peter > > http://staff.develop.com/peterd > > > > > > > -----Original Message----- > > > From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com] > > On > > > Behalf Of John Barnette > > > Sent: Monday, July 09, 2001 7:01 PM > > > To: mono-list@ximian.com > > > Subject: [Mono-list] C# coding standards for Mono > > > > > > Hey kids, > > > > > > Has anybody taken a stab at a C# coding standard for Mono classes? > > I'm > > > thinking something along the lines of Sun's Java Coding Conventions > > > (http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html) > > > > > > > > > ~ j. > > > > > > > > > _______________________________________________ > > > Mono-list maillist - Mono-list@ximian.com > > > http://lists.ximian.com/mailman/listinfo/mono-list > > > > > > _______________________________________________ > > Mono-list maillist - Mono-list@ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-list > > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > From scott@stonecobra.com Tue Jul 10 03:40:14 2001 From: scott@stonecobra.com (Scott Sanders) Date: Mon, 9 Jul 2001 19:40:14 -0700 Subject: [Mono-list] What's a java coder to do? Message-ID: <01fb01c108e9$a5e73600$0d01a8c0@empoweredintelligence.com> I am a java coder (Delphi and Python as well ;-), and I would like to get involved. I am interested in learning C#, and learning it while contributing to Mono would be good for me and possibly Mono. Is there any work involved which would be at a C# code level? Thanks Scott Sanders From elacin12@world-online.no Tue Jul 10 03:46:20 2001 From: elacin12@world-online.no (=?ISO-8859-1?Q?=D8yvind?= Berg) Date: Tue, 10 Jul 2001 04:46:20 +0200 Subject: [Mono-list] Hello world and .net newbie question References: Message-ID: <3B4A6C7C.7080304@world-online.no> First, a big Hullo to all on this list, this is my first post! Then, my question: I am a (mainly) C/C++ programmer that really would like to contribute to this project. The problem, though, is that I have no experience with and doesn't really know much about anything related to .net (glanced a bit at C#, tho). I though the whole mess was nothing too great, probably because it was something innovative (gasp!) from MS, but after the recent Free Software initiatives (dotGNU and off course, mono) I got more interested... So, do anyone have any links to places where I can read more about this? how it works and so on? Something which gives poor ppl like me some kind of overview ;-) Hmm... better put those links on your web-page, because else I'd guess the same question would repeat itself a few thousand times a day the following days/months/years ;-) ( I did look at the Resource page, but to starting with a look at those .net class libraries and the likes didn't make sense just yet, bear over with me!) And... I have access to (but never tested) visual studio.net beta1, but the web page states that "If you have looked at Microsoft's implementation of .NET or their shared source code, you may not be able to contribute to Mono." err.. what do you think about that.. I'll keep my not-yet-dirty-hands off that cd, right? ;-) -- MVH / Greets, �yvind Berg ~ �laC|n [ elacin@c2i.net || elacin12@world-online.no ] [ icq#:123433 || ElaCin@EFNet ] From fjh@cs.mu.oz.au Tue Jul 10 04:21:20 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Tue, 10 Jul 2001 13:21:20 +1000 Subject: [Mono-list] Re: Welcome To "Mono-list"! Message-ID: <20010710132120.A31316@murlibobo.cs.mu.OZ.AU> Martin Coxall martin.coxall@itouch.co.uk writes: > How many languages is it worth us supporting? I would argue that C# and java > should be the only two for the time being. If you're only going to support two languages, please make one of them be IL. -- 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 Bob_Salita@SoftworksLtd.com Tue Jul 10 04:29:11 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Mon, 09 Jul 2001 22:29:11 -0500 Subject: [Mono-list] FAQ additions - resubmitted v2.0 Message-ID: [v2.0: Ordered list by relevance and significance per Miguels request. Bob] Here are some questions gleamed from actual postings on other forums. They do not necessarily reflect my opinion. Some are provocative, some are emotional, some are technical, some are difficult business questions. Convince us to help the Mono project by answering these questions. I've listed the questions in order of importance: 1. Why should we direct such considerable resources to such a marginal and risky project? Aren't these precious resources better directed elsewhere? 2. Can't MS thwart Mono by creating technical or intellectual property roadblocks? 3. Don't existing open source projects offer capabilities equivalent to .Net? Can't we use them instead of mono? 4. What are the commercial alternatives to Mono? 5. Why are RedHat, IBM and others refusing to directly support Mono with funding and public commitments? What do they know but won't say? 6. What level of performance can be expected? What if Mono can't achieve that level of performance? 7. MS is releasing shared source on FreeBSD. Isn't it better to convert to FreeBSD rather than fight the .Net battle? Isn't the gain in open vs. shared source too small for such a major effort? 8. Isn't Mono a foil in negotiating .Net licensing for Linux? Won't mono project be dropped if .Net for Linux is licensed? 9. Isn't Ximian already overburdened and under funded? How can you compete with MS minions and billions? 10. I thought Ximian redefined itself as a service provider, not a developer? Didn't plan A already fail? 11. Is the real purpose of Mono to counterpunch MS? 12. Isn't Mono important only because .Net will be popular? 13. Is MS trying to bash Linux by offering .Net on BSD? Isn't it a divide and conquer gambit? Is it really about licensing terms? 14. Do we really know if .Net achieves an acceptable performance level? 15. Isn't Sun's controlling attitude responsible for MS need for .Net? 16. If Mono succeeds, who are the winners and losers? 17. This is a MS play. They'll win no matter what. 18. What is ORP and why is it being considered for a VM? 19. Isn't .Net vaporware? 20. If mono succeeds, won't MS quit sharing source? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From fjh@cs.mu.oz.au Tue Jul 10 04:49:43 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Tue, 10 Jul 2001 13:49:43 +1000 Subject: [Mono-list] Questions Message-ID: <20010710134943.A9143@murlibobo.cs.mu.OZ.AU> Ryan Marsh me@ryanmarsh.com wrote: > > Even if it does become an ECMA standard, what assurances do we have that > Microsoft won't engineer subtle differences that make it difficult to > write portable code, or to add small incompatible features that we will > always be running to catchup with? Absolutely none. -- 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 Tue Jul 10 05:07:03 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Tue, 10 Jul 2001 14:07:03 +1000 Subject: [Mono-list] Mono JIT Message-ID: <20010710140703.B9143@murlibobo.cs.mu.OZ.AU> Miguel de Icaza miguel@ximian.com wrote: > OpenJIT looks really interesting, but it assumes that you have an > existing Java implementation to run it on. Currently we have no JIT > available on non-Windows systems. What would be the technical obstacle to compiling OpenJit with gcj (the Java front-end for GCC, which is included in GCC 3.0)? However, even if the technical issues could be resolved, there seems to be a more serious problem --- licensing. The OpenJit licence only permits non-commercial use: | 5. Any use of the source code or the binary in a commercial product, | whether may it be the origial [sic] representation or in some modified | form, is not permitted without specific prior written permission. Anyway personally I'm not sure that using a high-level language is the best choice for a JIT. There are definitely a lot of advantages for maintainability, but JIT compilation time is very important, and it may be harder to optimize that if you're writing in a higher-level language. So C may be a better choice. -- 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 peter@razorsoft.com Tue Jul 10 05:37:12 2001 From: peter@razorsoft.com (Peter Drayton) Date: Mon, 9 Jul 2001 21:37:12 -0700 Subject: [Mono-list] Re: Welcome To "Mono-list"! In-Reply-To: <0107091711153L.03999@gypsumfantastic.uk.itouchnet.net> Message-ID: <000201c108f9$ff7e9810$257baccf@razorsoft.com> > Microsoft have said repeatedly that the CLI *can* support multiple > languages, but how many *does* it? Lots. Microsoft themselves ship production compilers for Managed C++, VB.NET, C#, JScript.NET and MSIL. The Framework SDK also include demo source for compilers that target massively sub-setted Lisp, a C variant called SMC, and a Tiny C-like language. Third parties are/have produced compilers for Perl, Python, Cobol, Eiffel#, Scheme, Haskell, Mondrian, Mercury, Component Pascal, you name it... There's a list here (watch for wraps): http://www.gotdotnet.com/resourcecenter/resource_center.aspx?classificat ion=Language%20Vendors --Peter http://staff.develop.com/peterd From saurik@saurik.com Tue Jul 10 06:29:00 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Tue, 10 Jul 2001 00:29:00 -0500 Subject: [Mono-list] Re: Looking at Microsoft implementation? Message-ID: <005801c10901$3a351860$d1cd1d18@cruiser> This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C108D7.50AC6230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I hadn't read noticed that, good to see it pointed out. About the = "shared source" mention, at this point that's kind of anal... from what = I've seen in the interviews that have been done so far (seeing that = noone has this license yet), "Shared Source" will _specifically_ allow = for people to read the source code and take what they learn for other = implementations (yes, including those under "potentially viral = licenses"). Being "the decompiler guy", I'm also interested in the later point about = ILDasm, as while I haven't actually 'read' any code I have 'looked at' a = ton and have closely examined the IL of a few functions that had strange = overlapping switch statements in System.Net.DLL (which, considering I = hate System.Net.DLL with a vengeance, I haven't ever considered a = problem). * goes back to reorganizing his code * Sincerely, Jay Freeman (saurik) saurik@saurik.com Original Message (evil lack of mbox compatible archive...): On the Mono web site it says: "If you have looked at Microsoft's implementation of .NET or their shared source code, you will not be able to contribute to Mono" Does "Microsoft's implementation of .NET" mean MS's actual source for .NET, or does merely ILDasm'ing mscorlib exclude someone from working on Mono? -Peter http://staff.develop.com/peterd ------=_NextPart_000_0055_01C108D7.50AC6230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I hadn't read noticed that, good to see = it pointed=20 out. About the "shared source" mention, at this point that's = kind of=20 anal... from what I've seen in the interviews that have been done = so far=20 (seeing that noone has this license yet), "Shared Source" will = _specifically_=20 allow for people to read the source code and take what they learn for = other=20 implementations (yes, including those under "potentially viral=20 licenses").

Being "the decompiler guy", I'm also = interested in=20 the later point about ILDasm, as while I haven't actually = 'read' any code I=20 have 'looked at' a ton and have closely examined the IL of a few = functions that=20 had strange overlapping switch statements in System.Net.DLL (which, = considering=20 I hate System.Net.DLL with a vengeance, I haven't ever considered a=20 problem).

* goes back to reorganizing his code = *

Sincerely,

Jay Freeman (saurik)

saurik@saurik.com

Original Message (evil lack of mbox=20 compatible archive...):

On the Mono web site it says: "If you = have looked=20 at Microsoft's
implementation of .NET or their shared source code, = you will=20 not be able
to contribute to Mono"

Does "Microsoft's implementation of = .NET" mean MS's=20 actual source for
.NET, or does merely ILDasm'ing mscorlib exclude = someone=20 from working on
Mono?

-Peter
http://staff.develop.com/peterd<= /A>

------=_NextPart_000_0055_01C108D7.50AC6230-- From clabitan@juno.com Tue Jul 10 06:35:57 2001 From: clabitan@juno.com (Cesar M Labitan) Date: Tue, 10 Jul 2001 00:35:57 -0500 Subject: [Mono-list] research.microsoft.com Message-ID: <20010710.003559.-313755.0.clabitan@juno.com> See research.microsoft.com for more insight and ideas. From mcmillen@cs.umn.edu Tue Jul 10 06:52:49 2001 From: mcmillen@cs.umn.edu (Colin P McMillen) Date: Tue, 10 Jul 2001 00:52:49 -0500 Subject: [Mono-list] Okay, so ya got me interested. Message-ID: <20010710005249.B24785@cicero.cs.umn.edu> I've not really been keeping abreast of the developments of the .NET system, but the recent FAQ on ximian.com has me interested. I'm willing to help with the project in whatever way I can, but am not entirely sure what I'd be qualified to work on. I can certainly do documentation, and "small duties in the project that need to be addressed", and I'm interested in CORBA interoperability as well. I'm guessing I'll need to be reading some docs and possibly buying a book on C# before I get into any real coding though. Any ideas, anyone? -- Colin McMillen mcmillen@cs.umn.edu Research Assistant, University of Minnesota Distributed Robotics Lab From jason@injektilo.org Tue Jul 10 06:59:06 2001 From: jason@injektilo.org (Jason Diamond) Date: Mon, 9 Jul 2001 22:59:06 -0700 Subject: [Mono-list] System.Xml Message-ID: Hi. Since I recently implemented most of a pull-based XML parser in Java using System.Xml.XmlReader as a model, I would certainly love to offer to do the same for a pure C# version. It could easily be developed in a Windows environment until the necessary classes from System.IO and System.Net were implemented for Mono at which point it would be ready to compile and run. Has anybody started work on this yet? Jason Diamond http://injektilo.org/ From hinoue@cs.unm.edu Tue Jul 10 07:00:28 2001 From: hinoue@cs.unm.edu (Hajime Inoue) Date: Tue, 10 Jul 2001 00:00:28 -0600 (MDT) Subject: [Mono-list] FAQ additions - resubmitted v2.0 In-Reply-To: Message-ID: On Mon, 9 Jul 2001, Bob Salita wrote: > Here are some questions gleamed from actual postings on other > forums. I can answer a couple of the technical questions: > 6. What level of performance can be expected? What if Mono can't achieve > that level of performance? Nothing here is an unknown. The technology is similar to Java and will have similar performance characteristics. > 18. What is ORP and why is it being considered for a VM? ORP is short for Open Runtime Platform. It's purpose is for VM research but is also a fairly complete Java VM running on the GNU classpath libraries. It is well written and runs fast. See: http://orp.sourceforge.net/ or http://www.intel.com/research/mrl/orp/ -Jim From jbarn@httcb.net Tue Jul 10 07:08:41 2001 From: jbarn@httcb.net (John Barnette) Date: Tue, 10 Jul 2001 00:08:41 -0600 Subject: [Mono-list] System.Collections.Hashtable Message-ID: I've started mucking around with what's necessary to implement System.Collections.Hashtable. Anybody else playing with this? ~ j. From fjh@cs.mu.oz.au Tue Jul 10 07:11:21 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Tue, 10 Jul 2001 16:11:21 +1000 Subject: [Mono-list] FAQ additions - resubmitted v2.0 In-Reply-To: References: Message-ID: <20010710161121.A14820@hg.cs.mu.oz.au> On 09-Jul-2001, Bob Salita wrote: > 1. Why should we direct such considerable resources to such a marginal and > risky project? Aren't these precious resources better directed elsewhere? Good question. > 2. Can't MS thwart Mono by creating technical or intellectual property > roadblocks? That depends to some extent on what the aim of Mono is. If the aim is to make something that is supposed to be compatible with ".NET", then almost certainly yes. If the aim is just to develop an implementation of the ECMA specs, rather than aiming for broader compatibility, then probably not. Which of these is the aim? > 3. Don't existing open source projects offer capabilities equivalent to > .Net? Can't we use them instead of mono? I don't know of any open source projects that provide capabilities equivalent to the .Net framework. The JVM provides many similar capabilities, but it is not as good for multi-language interoperability; getting decent performance for non-Java-like languages is very hard. BTW, please use precise language -- say "the .Net framework", not ".Net", if that is what you mean. Questions about ".Net"'s capabilities are pretty meaningless since ".Net" is a meaningless marketing brand name for a bunch of quite different technologies. > 5. Why are RedHat, IBM and others refusing to directly support Mono with > funding and public commitments? What do they know but won't say? Supporting Mono would help MS, by increasing acceptance of .Net; why would RH & IBM want to do that? See also 1. -- 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 adriano@satec.es Tue Jul 10 07:35:40 2001 From: adriano@satec.es (Adriano Galano) Date: Tue, 10 Jul 2001 08:35:40 +0200 Subject: [Mono-list] Open Fire :-) References: <00a501c1087c$9d6121c0$48f8513e@agalano> <0107091506383F.03999@gypsumfantastic.uk.itouchnet.net> Message-ID: <00f601c1090a$89934ea0$48f8513e@agalano> > On Monday 09 July 2001 2:39 pm, Adriano Galano wrote: > > Hi: > > > > Well are you saying at > > > > http://www.ximian.com/mono/ideas.html that propose JXTA. I don't wan't a > > flamewar but ... > > > > why not Freenet (http://freenet.sourceforge.net)? > Hi! > The two aren't really comparable are they? JXTA is an infrastructure for > creating P2P systems. Freenet is a distributed, anonymous, intelligent > temporary storage and distribution mechanism. > Is marvellous that the marketing could do ;-) What JXTA is a infraestructure and Freenet one mechanism? What is the difference in your opinion between infraestructure and mechanism? Let's see: http://www.openp2p.com/pub/a/p2p/2001/05/02/jxta_trouble.html If you want more information about the "mechanism" look at: http://sourceforge.net/projects/eof/ I don't know but maybe apt-get over freenet is something that sounds good! (or maybe rpm, Mr. Tiemman?) > JXTA's classes could be ported to Mono, and Freenet could be easily ported to > c# (I assume, it's Java). The two would not interfere with each other at all. > Yes, everything is possible to be ported to MONO but not all was sugested in the ideas section ;-) 0 -Bryam From saurik@saurik.com Tue Jul 10 08:07:49 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Tue, 10 Jul 2001 02:07:49 -0500 Subject: [Mono-list] Open Fire :-) References: <00a501c1087c$9d6121c0$48f8513e@agalano> <0107091506383F.03999@gypsumfantastic.uk.itouchnet.net> <00f601c1090a$89934ea0$48f8513e@agalano> Message-ID: <008501c1090f$08534980$d1cd1d18@cruiser> I've been doing quite a bit of research about this over the last few weeks, and feel safe in saying that they really _aren't_ comparible and _are_ on different levels. Freenet is about having an anonymous system for sending files around. It doesn't maintain any connections. Each node keeps a list of other nodes and a hash of a key that has been known to come from that node. It tries to find files by asking people who have been known to produce files that have keys that hash to something similar to the key being looked for. There is no way of searching, files are transfered along the hops taken to find the path (so no one knows where the file was originally so you couldn't use this as a fast way to take out the people with the file). JXTA is an architecture for first connecting a network of users and then doing host and service discovery. That's all it itself is designed to do. If you wanted to write an application like Freenet, it could be written over JXTA, but as the network topology itself doesn't change, you wouldn't gain some of the interesting aspects of Freenet. OK, so far all I have really said is "JXTA is _just_ this and Freenet does _this_ faster". It's important to realize that _just_ doing something important is a good thing, and that there is a lot more to the world than _this_ :-). An example: if you are trying to do file sharing a la Napster, something like Gnutella blows Freenet so far away that it isn't even funny. First off, Gnutella can search, which is very important. Secondly, Gnutella's standard implementation doesn't have the added overhead of transferring files between many users who may be in disparate locations just to get a file from someone who may be downstairs, instead it only returns a URL to find the file at, at which point the user downloads it directly from the other party. Third, Gnutella doesn't see a need to protect users from what they are storing on their own system, and doesn't make a differentiation between "files this user has on his computer and uses" and "files that are being stored here by the network that other people can download from him, carefully encrypted enough to make it annoying for him to know what terrible things he is donating storage to", and thereby ends up with a much larger region of storage (as many users share hundreds of megabytes of MP3s and other files to the network, something they are unlikely to do if it is just an encrypted blob that they have no idea what is in). Once again, those "limitations" in file sharing lead to advantages in anonymous file storage, but I think we can cut to the point here: JXTA is a framework that provides an architecture for writing P2P applications easily. Also, as the initial main implementation is Java, nodes that don't have an application or a service can easily (and securely) transfer the code from a repository or from each other and run it without having to worry much about security (hence a synergy with .NET). OK, right now their implementation sucks (so much so _I_ am at least avoiding it :-), hehe), but their abstractions seem sound and as a better system is worked into it, improvements will be seen in all applications. I read that same article you have there (first, as, like likely was true of you, my initial reasons for researching JXTA were to prove to myself that it wasn't something that needed to be looked at much), and after doing more research am surprised at how misleading it is. To me, an implementation of Freenet would be quite worthless in .NET, all you really need is one implementation. It isn't good for much else than it is currently being used for (a statement the recent group who ported some online games to work on Freenet will almost assuradly agree to, accourding to their web page they only did it because they were bored and thought it would be freaky), and if you try to make it do things that other applications are good at you could quickly violate it's core principals (which is seeable if you read enough of the content on their website, and see the decisions they have had to make in the past to guarantee anonymity of users). However, an implementation of JXTA for .NET would be very useful, and would do a lot to push forward P2P by making such applications both "easy to develop" and "easy to develop in any language". Any work that is done on this should be done closely with the jxta.org people, as they are still working on coming forward with the drafts and such. (BTW, I'd be happy to work with such an effort.) Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "Adriano Galano" To: "Martin Coxall" ; "Fiery Death" Cc: "Fiery Death" Sent: Tuesday, July 10, 2001 1:35 AM Subject: Re: [Mono-list] Open Fire :-) > ... > > Is marvellous that the marketing could do ;-) > What JXTA is a infraestructure and Freenet one mechanism? What is the > difference in your opinion between infraestructure and mechanism? > Let's see: http://www.openp2p.com/pub/a/p2p/2001/05/02/jxta_trouble.html > > If you want more information about the "mechanism" look at: > http://sourceforge.net/projects/eof/ > > I don't know but maybe apt-get over freenet is something that sounds good! > (or maybe rpm, Mr. Tiemman?) > ... > > Yes, everything is possible to be ported to MONO but not all was sugested in > the ideas section ;-) > > 0 > > -Bryam From simon@cs.uoregon.edu Tue Jul 10 08:59:21 2001 From: simon@cs.uoregon.edu (Simon Per Soren Kagedal) Date: Tue, 10 Jul 2001 00:59:21 -0700 Subject: [Mono-list] FAQ additions - resubmitted v2.0 In-Reply-To: ; from bsalita@hotmail.com on Mon, Jul 09, 2001 at 10:29:11PM -0500 References: Message-ID: <20010710005921.A6055@ix.cs.uoregon.edu> bored enough to try and answer some of these questions... > 1. Why should we direct such considerable resources to such a marginal and > risky project? Aren't these precious resources better directed elsewhere? Because it is * interesting (lots of fun technology) * important (we do want to stop MS monopoly) * standardized (ECMA) and most importantly, * useful (even if all compatibility fails, we will still have a cool platform) > 2. Can't MS thwart Mono by creating technical or intellectual property > roadblocks? No, nothing can stop Mono from doing what it currently aspires to do (CLR, C# compiler, class library) > 3. Don't existing open source projects offer capabilities equivalent to > .Net? Can't we use them instead of mono? No. Similary maybe (which, though? java hardly even qualifies), but definately not equivalent. > 5. Why are RedHat, IBM and others refusing to directly support Mono with > funding and public commitments? What do they know but won't say? Ask RedHat, IBM and others. > 7. MS is releasing shared source on FreeBSD. Isn't it better to convert to > FreeBSD rather than fight the .Net battle? Isn't the gain in open vs. shared > source too small for such a major effort? Absolutely not. http://www.gnu.org/philosophy/ > > 8. Isn't Mono a foil in negotiating .Net licensing for Linux? Won't mono > project be dropped if .Net for Linux is licensed? No, unless another free software implementation of the .NET development framework comes along, Mono will live on. (that's my guess..) > 11. Is the real purpose of Mono to counterpunch MS? > 12. Isn't Mono important only because .Net will be popular? Dude, look at http://www.ximian.com/mono/faq.html, question 9. Don't suggest new FAQs that are already answered in the FAQ just because you don't believe the answer. > 13. Is MS trying to bash Linux by offering .Net on BSD? Isn't it a divide > and conquer gambit? Is it really about licensing terms? Ask MS. > 14. Do we really know if .Net achieves an acceptable performance level? pretty much yeah. > 15. Isn't Sun's controlling attitude responsible for MS need for .Net? Partially, yes, I guess... but what does this has to do with Mono??? > 16. If Mono succeeds, who are the winners and losers? We will all be winners. > 17. This is a MS play. They'll win no matter what. That's not a question. > 19. Isn't .Net vaporware? What are you talking about? .NET as the framework Mono is trying to implement? No, go look at the ECMA specs. Microsofts implementation? No, look at VS.NET beta 2. > 20. If mono succeeds, won't MS quit sharing source? 1. Ask MS. 2. We don't care. Shared Source is not free software. Simon. From martin.coxall@itouch.co.uk Tue Jul 10 10:03:25 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Tue, 10 Jul 2001 10:03:25 +0100 Subject: [Mono-list] Looking at Microsoft implementation? In-Reply-To: <003101c1089f$af367ad0$1601a8c0@razorsoft.com> References: <003101c1089f$af367ad0$1601a8c0@razorsoft.com> Message-ID: <01071010032501.01523@gypsumfantastic.uk.itouchnet.net> > Does "Microsoft's implementation of .NET" mean MS's actual source for > .NET, or does merely ILDasm'ing mscorlib exclude someone from working on > Mono? MS' shared source license is incompatible with the GPL, it not being a valid free software license. Thus, if you have seen MS's code, you are unable legally to contribute to this project. --- Martin --- "Where laughing and smiling are not allowed" From rsriram@noida.hcltech.com Tue Jul 10 10:28:44 2001 From: rsriram@noida.hcltech.com (Sriram Rajamanuri) Date: Tue, 10 Jul 2001 14:58:44 +0530 Subject: [Mono-list] How to compile MCS Message-ID: <05f401c10922$b6e65150$e9fea0cc@noida.hcltech.com> This is a multi-part message in MIME format. ------=_NextPart_000_05F1_01C10950.D05CC960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I am sorta newbie out here. I have downloaded the latest sources as well = as the CVS snapshots .I wish to kno what r the executables so far as = mcs, jay and mono are concerned. Its quite confusing goi thru all the = directories and executing just the make files. I am quite new to the concept of .NET too Help is earnestly solicited Thx in advance S ------=_NextPart_000_05F1_01C10950.D05CC960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I am sorta newbie out here. I have = downloaded the=20 latest sources as well as the CVS snapshots .I wish to kno what r the=20 executables so far as mcs, jay and mono are concerned. Its quite = confusing=20 goi thru all the directories and executing just the make=20 files.

I am quite new to the concept of .NET=20 too

Help is earnestly = solicited

Thx in advance

------=_NextPart_000_05F1_01C10950.D05CC960-- From martin.coxall@itouch.co.uk Tue Jul 10 10:23:29 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Tue, 10 Jul 2001 10:23:29 +0100 Subject: [Mono-list] Questions In-Reply-To: <994710735.2874.1.camel@cocoon.butterflysoft.org> References: <994710735.2874.1.camel@cocoon.butterflysoft.org> Message-ID: <01071010232902.01523@gypsumfantastic.uk.itouchnet.net> > Even if it does become an ECMA standard, what assurances do we have that > Microsoft won't engineer subtle differences that make it difficult to > write portable code, or to add small incompatible features that we will > always be running to catchup with? How do we know we won't get, excuse > the expression, 0wNz0r3d? We have to get Miguel de Icaza or some of his Ximian/FSF colleagues on the ECMA committe responsible for standardisation- to make sure they don't slip any changes is that could harm Mono. As the register put it, this is an absolute minimum requirement. --- Martin --- "Where laughing and smiling are not allowed" From saurik@saurik.com Tue Jul 10 10:36:34 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Tue, 10 Jul 2001 04:36:34 -0500 Subject: [Mono-list] Re: FAQ additions - Once again, but much shorter... Message-ID: <00d201c10923$cf930a30$d1cd1d18@cruiser> This is a multi-part message in MIME format. ------=_NextPart_000_00CF_01C108F9.E611CE10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK, apparently my last e-mail got sent to a moderator because it was = >40k (specifically 67k). While I'd still like it to hit the list as is = (i.e., I'd prefer if the moderator doesn't can it because of this = message so that it gets into the main archive, but it's quite ok if he = does), I'd also like to see it hit the list today, so here is a URL = where you can find the same text: = http://lists.saurik.net/message.xsp?id=3D177 . The URL is lynx = friendly, and you can safely ignore the cookie if you hate cookies. The = e-mail _is_ quite long, and in some places (such as question #2), = gratuitously so. - Jay ------=_NextPart_000_00CF_01C108F9.E611CE10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

OK, apparently my last e-mail got sent = to a=20 moderator because it was >40k (specifically 67k). While I'd = still like=20 it to hit the list as is (i.e., I'd prefer if the moderator doesn't can = it=20 because of this message so that it gets into the main archive, but it's = quite ok=20 if he does), I'd also like to see it hit the list today, so here is a = URL where=20 you can find the same text: http://lists.saurik= .net/message.xsp?id=3D177 . =20 The URL is lynx friendly, and you can safely ignore the cookie if you = hate=20 cookies. The e-mail _is_ quite long, and in some places (such as = question=20 #2), gratuitously so.

- Jay

------=_NextPart_000_00CF_01C108F9.E611CE10-- From martin.coxall@itouch.co.uk Tue Jul 10 10:38:16 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Tue, 10 Jul 2001 10:38:16 +0100 Subject: [Mono-list] System.Xml In-Reply-To: References: Message-ID: <01071010381603.01523@gypsumfantastic.uk.itouchnet.net> > Since I recently implemented most of a pull-based XML parser in Java using > System.Xml.XmlReader as a model, I would certainly love to offer to do the > same for a pure C# version. In that respect, I imagine the best bet would be to port Apache's best-of-breed Xalan/Xerces parser to c#, as it is written in Java and available under the (GPL-compatible) Apache license, this would be technically and legally possible. --- Martin --- "Where laughing and smiling are not allowed" From saurik@saurik.com Tue Jul 10 10:43:51 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Tue, 10 Jul 2001 04:43:51 -0500 Subject: [Mono-list] FAQ additions - One (crazy?) guy responds... Message-ID: <00e701c10924$d4ac2a50$d1cd1d18@cruiser> OK, seeing my last post actually get through the system made it obvious to me what happened, I sent it as an HTML e-mail and the system doesn't strip out the HTML in the HTML e-mail (as I have gotten to the point of expecting it to except on the lists dominated by windows people). I've made sure that I don't send HTML to the list any more by telling my client that mono-list only receives plain text, sorry about that. If the moderator could kill the really large one, that would be handy. -------- Seeing as I am sick of coding for the night, and got intrigued by some of these questions, I thought I might answer them. No one likely cares, but if you are interested, go ahead and read on. I'm also not that afraid of being yelled at, so I'm likely to answer some questions than casual list readers would, and more bluntly than Ximian would feel confortable with. I'm also a Windows developer, have been working with .NET for a year now since the initial pre-beta release, have written a C# decompiler for the first Beta of the technology, and feel confortable saying that I know more about the technical aspects of this technology than many of the open source Unix developers who are likely on this list. I removed the questions that have to do with politics that I don't really understand (specifically Red Hat and some of the internal operations of Ximian) as I don't really have a good comment on them. To the people on my net-tech mailing list, I cross posted this there as I thought some of you might be interested and might not yet be on the mono-list (if you aren't, you might want to look into getting on it: http://www.ximian.com/mono/ ). 1. Why should we direct such considerable resources to such a marginal and risky project? Aren't these precious resources better directed elsewhere? I left this one for last, and I don't have the strength to answer it. Even thinking about it gives me a headache :-). Besides, I don't really have anything good to say for this one. 2. Can't MS thwart Mono by creating technical or intellectual property roadblocks? This is really determined by what your success metric for Mono is. They've already released a lot of their IP to the ECMA. As for technical roadblocks, yes, they would (trivially, not even leaving specs) be able to keep their own products from running on Mono. I don't think anyone really expects to be compatible there, anyway, so let's cut to the chase: what if they do something to fork the developer community. This is what they seem to have attempted with Java (although I don't know if we can directly fault them for a bad implementation of libraries and a want to have better COM interop), and they managed quite nicely before Sun shut them down. This _is_ a large issue, and if anyone claims otherwise, says anything about how specifications will be everyone's ally, they haven't thought through the problem of "who requires users to follow specs" much. In some ways it is the same thing that Netscape used originally to gain browser superiority (adding background color to tables and other such things were Netscape extensions, Netscape didn't care much about standards until they were on the butt end of these issues) and then that Microsoft used to take it away from them: add a few features that make your version easier that can't easily be implemented in someone else's version without breaking it and you have them. It all comes back to a rather fundamental principal: some things are not easy to port. Back when the PDC bits came out and it didn't look like cross-platform was all that much to think about (the way to look at it was "it simply isn't going to happen"), I started looking at the System.Net classes. I had been working on a COM networking abstraction for a _long_ time (long enough to be fooled by early reports that COM+ was going to be an entirely different development experience that I lost a few months of development to waiting for it to happen, and then not being able to figure out if it happened yet or not), thinking through how streams should be supported, coming up with a way that end-users would be able to customize applications written using the streams system... I had quite a bit of stuff on paper. This had all started because I had run into major, fundamental problems with MS's Winsock control, and couldn't find a replacement that worked the way I wanted it to. I had constructed a few initial releases of the socket component and released it to people online as a preview, and reports were very positive. This wasn't something I was doing for a day job, so work was going slowly on this project. Then I hear about MS's .NET, and how it was going to be a very, very redesigned set of classes that would revamp VB (the rest didn't click yet). The first thing I did was take a look at the socket libraries. First off, they didn't do very well. Really, as far as I'm concerned, it was a step _backwards_. I wanted to have events from the socket ripple forward through different streams to fire events on the other end, now we weren't even going to have a good event-oriented base for recieving network events at all. I put together the more technical issues together and sent them in an e-mail to the DOTNET mailing list: http://discuss.develop.com/archives/wa.exe?A2=ind0009B&L=DOTNET&P=R11720 :, and got contacted by a MS representative (partly because I expressed interest in a job with them, then to talk about aspects that might be improved in the library). Apparently the main reason they went this way was for later cross-platform support. If they went the Winsock 2 way, later implementation on Unix would be almost impossible (Unix's sockets haven't advanced much in... well, they haven't). If Microsoft wants to fork off an incompatible suite of .NET applications and related developers, all they need to do is start implenting forking points such as this. Winsock 2 support in the framework would rather quickly cause Unix framework developers massive headaches (it could be done, but it would take a long time and it would require a good amount of overhead to simulate some of the abstractions at a higher level) and split off a number of network developers if architected to make development much easier. System.Windows.Forms is already rather highly adapted to their GUI (as this was never considered an important piece to port using), but it could be made more so. The general idea is: find some low-level glue that maps to something in the OS and, rather than either mapping it to the Unix compatible APIs that Microsoft has been dragging around with them for years now or building a general abstraction that would make it easy to port to other OSs later, map it to the Windows specific APIs that handle that feature instead. To me, the most important thing for Mono to do is to just implement the standards, and maybe even then extend it _themselves_ to better take advantage of Unix with a System.X.Forms or System.GTK.Forms or whatever anyone wants to call it. This would promote the usage of the standards, and also generate people who want to write applications for _just_ Unix using .NET rather than being forced into most simple of the levels of abstraction that exist in the core. As for this goal, Microsoft doesn't have much power over it. It _is_ important to realize that MS's implementation isn't even going to be up to spec for V1. One such example (as was mentioned on the DOTNET mailing list recently) is the 1024 byte limitation of class names and the such. These small (limiting!) incompatibilities, if not noticed soon and pointed out strongly, could cause future issues. In this way, by starting now, Mono is doing something important. However, Rhys (the owner of Southern Storm, Ltd., mentioned in question 18) has been working on this for a _while_ now (started at the end of last year using the PDC bits, although put most of the work on hold until Beta 1 was out) as well and already initial implementations of such tools, thereby lowering the importance of the Mono project for this purpose. I have also been spending time implementing metadata libraries that are compatible with MS's interfaces to make things easier to port (as well as to feel more confident that future changes to lower-level formats aren't going to cause problems with the higher-level interfaces). 3. Don't existing open source projects offer capabilities equivalent to .Net? Can't we use them instead of mono? Surprisingly (?), no. Most open source efforts at runtimes have been implementations of JVMs or specialized VMs for other languages (such as the Smalltalk VM that was mentioned earlier on this list). All this has done is furthered the split between language camps. There is a good amount of code out there written in Perl that I currently can't easily use from a C++ application, and a ton of C code that I can't easily use from a shell script. The only people in the open-source world who have put any effort into integrating the development arenas has been the GNOME project (which includes Ximian). The idea there was that, by using CORBA to abstract object representation, people could write code in one language and easily use it in another. The problem with this is that CORBA does this by providing very high level abstractions of data types that need to be martialled down to whatever you are working with. Also, there aren't many good, open source (or even just $0) ORBs (which are what broker the data type conversion) available. CORBA simply wasn't designed to be what GNOME was trying to use it as: a response to Microsoft's COM. CORBA was designed as a networking protocol (where the overhead of the network will assuradly surpass any overhead from martialling), and was starting to get in the way despite the efforts of the GNOME group (especially one developer whom I believe I remember being named "Michael") to slim it down to the bare essentials. Another project to look at is Intel's ORP (about which I will cover more in your question #18). 4. What are the commercial alternatives to Mono? In as much as the attempt to allow for developers to utilize programming languages together efficiently, pretty much just Microsoft's implementation of .NET. There have been a number of smaller scale attempts to allow for VMs to take over, but they were all concentrating on a very small target market segment. The main one that I know of is Omni..something.. that, interestingly enough, was bought by Microsoft :-). 6. What level of performance can be expected? What if Mono can't achieve that level of performance? The expectation is that you should be able to get near native performance. Various Java VMs in the past have shown that, when done right, this isn't that far out there, as has Microsoft's Beta versions of .NET (which should only get faster as they near release and start lessening the debug code). If Mono can't achieve this level of performance it will be quite a loss to the open source development community (as they will not be able to feel confortable writing all of their code for this architecture), but it won't neccessarily cause _too_ much harm to Mono itself. 7. MS is releasing shared source on FreeBSD. Isn't it better to convert to FreeBSD rather than fight the .Net battle? Isn't the gain in open vs. shared source too small for such a major effort? I, at least, _am_ switching to FreeBSD. There is something important that needs to be pointed out here, however. It doesn't seem obvious yet (to me, at least) whether the "shared source" implementation will be available for usage on production systems for corporate purposes. In interviews that have been conducted with the implementation team, it has been mentioned that the "shared source" implementation will not be for academic usage only and not for corporations' usage. The way it has been worded has reminded me of applications like Netscape (other examples aren't coming to me now for some reason, but I come across them all the time... some anti-virus packages for instance) that could be used at home but not in a corporate environment. This clause may just apply to the usage of the source code itself, however; thereby making it so that the code can't be used in a corporate project and sold. What makes me second guess that interpretation is how eerily similar that is to GPL (where you can use the code for anything as long as you don't try to use it in a closed source project), with only a few extra limiting cases (companies in a business like Red Hat's thereby ending up in a squidgy middle ground). 8. Isn't Mono a foil in negotiating .Net licensing for Linux? Won't mono project be dropped if .Net for Linux is licensed? This is likely not to be the case. It is important to understand that, in the standard "cathedral" vs. "bazaar" comparison of closed vs. open source, "free software" (which GNU advocates, and is also the stand Ximian is behind) is best brought up as a "protest" or a "crusade". It isn't enough that someone writes software, or even that they release the code for it. If it isn't under a truly open license that preserves the freedom of the code, or at least capable of being converted into a totally open license that preserves the freedom of the code, then the work isn't done. Now, Ximian might get a lot less interesting from Ximian programmers if it isn't far along before Mono exists on Linux, but it definitely won't get "dropped" by the entire community. 11. Is the real purpose of Mono to counterpunch MS? I would say "no". While there are many reasons to adopt a frameowork like .NET (some of which I've already touched on), I would claim that the "real" purpose of Mono is to save GNOME. GNOME made a lot of promises initially. While they have come up with a great desktop environment, many of these promises haven't been made good on, and don't look like they will if they continue the direction they are going in. A few weeks ago a few Red Hat engineers made some rather low-voiced announcements (partially prompted by a website that claims that a talk will be given about it in Auguest, a fact which the engineers responsible claim was a mistake...) about a new architecture called Hub that would allow for speedy in-process components to be built (no more overhead than a virtual function call, the same overhead that COM has), yet still allow for some aspects of cross-language ability (much like COM). Whether it is just going to be COM with a few modifications, or whether the entire project will now be scrapped is anyone's guess. 12. Isn't Mono important only because .Net will be popular? Well, right now *nux doesn't really have anything that compares well. Java _could_ have taken this spot, but Sun is overly sensitive about their technology and isn't going to make the modifications required to allow for great things in .NET to boost them as well. A big reason for this is that it would invalidate their existing byte code, the consistency of which they consider tantemount to their success: how can they convince people that Java should run on everything if they keep changing the design and no one can keep up? They were even advocating getting it running on hardware for a while (which, unlike .NET, it has some hope in accomplishing). If a new binary format came out later that was required to access new features, their empire might crumble. It's a pitty, too. Had they marketted themselves slightly differently they might have been able to be stronger at this point. 13. Is MS trying to bash Linux by offering .Net on BSD? Isn't it a divide and conquer gambit? Is it really about licensing terms? While I want to agree with the "divide and conquer statement", I really do feel Microsoft's pain when it comes to the GPL. There is an important point to make here: A while back I was contacted by a Microsoft engineer about my decompiler who was offering me support with it (I ended up asking him to help me with some potential legal problems I was having with another Microsoft employee as a result of working on Unix ports and ended up losing contact with him, so none of this ended up working out, but...). One of the things he was asking was if I could change the license from GPL to LGPL which would give them more "room" to help. On one hand, there is the possibility that this is a decree from higher-ups that GPL shouldn't be gotten near with a 10,000-foot pole. Another is that they actually wanted to incorporate my decompiler or some of its code generation routines (which I've been working on improving) into Visual Studio and wanted it to be easier to accomplish. A third interpretation (one that I find very likely) is that they simply didn't want to have any legal problems themselves. If, at some later point, they accidentally use my code (no matter how small or trivial) or some idea of it that ends up producing very similar algorithms (as this is uncharted legal water), they may accidentally throw all of their code under GPL. At least with commercial code they could be sued and put under a restraining order, at worst have to remove the code and pay damanges, as they would have violated some license term that states "don't use this code". In the case of the GPL code, there is no legal rubberband to snap back on them, they have now released something under GPL and are violating license to _not_ release the code. This is not an acceptable risk for any closed-source company to take. As for me, all code I release for my decompiler and such from now on (as I haven't gotten any code from anyone else yet and still have all of the copyright) will be under a modified BSD license. 14. Do we really know if .Net achieves an acceptable performance level? Yes, we do. It exists, and it works very, very well. 15. Isn't Sun's controlling attitude responsible for MS need for .Net? Initially, yes. The history of C# and .NET can be seen back many years now. I actually have a book sitting next to me copyright 1997 ("Active Template Library: A Developer's Guide") that has an appendix that goes into many of the issues relating to .NET. It then goes on to show a snippit of code that looks as eerily simple as MC++ that is apparently how it will be handled "with COM+ support". There is also overwhelming (and obvious) evidence that C# is in fact COOL, a language that MS was working on as an alternative to Java to solve their problems. The "COR" designation (COM Object Runtime) can be traced back to at least 1999 in header files shipped with the Microsoft Platform SDK (specifically, IMAGE_DIRECTORY_ENTRY_COR_DESCRIPTOR comes to mind). MS may very well have attempted to adapt Java to serve their purposes rather than creating .NET, but the result would have been just as incompatible with Java and therefor just as much a separate entity as .NET is. 16. If Mono succeeds, who are the winners and losers? This is a quite difficult question to answer. One thing to point out is that Microsoft's motives aren't very clear. To make a blanket statement like "developers do", or "everybody does" is quite naieve. You have to look at everything that is being done as a cohesive unit, and see how it interconnections... Complexity Theory relates as much to Microsoft as it does to any other group of people. I started answering this question after answering question #17, so there will be a small amount of overlap, and then you should just read that one for the rest. It looks like MS's strategy right now is one of a magician. This is something that even some media sources are starting to pick up on. They are making loud noise in one arena to make it seem like everyone should be looking there, while quitely taking control over something entirely different. One big aspect to this specific trick is that it doesn't matter where software is running as components become services. Just because you have a Unix web server doesn't mean you aren't still using MS's authentication technologies. If people don't look more closely at this aspect of Microsoft's strategy all could be lost but for the want of one battle. If you haven't been payin attention to what Microsoft is doing, and have been sitting around working in your Unix desktop environments with your Unix applications and feel content with your software, I urge you to look at where Microsoft is taking the 90% of the population who don't even understand what Unix is. Hotmail is being integrated with Outlook Express, MSN Messenger is being integrated into Office, and Passport is being integrated into everything, including the OS. When everyone has a Passport, it is going to be much easier to start sliding websites over to this architecture. 17. This is a MS play. They'll win no matter what. Not really question, I guess I can answer this with: "true"? The bigger question is: what is MS's play? My guess is that they want to control the services. Open source operating systems won't matter much once the hardware becomes closed, a move that is already in the works. This is all really a shell game to keep people from paying attention to the important moves that MS is making: A) Microsoft has been hard at work in the area of content protection. One of these efforts is in signed drivers. Originally signed drivers were a way to allow users to know that such-and-such a driver was actually written to play well with other drivers (something hardware manufacturers are terrible at if left to their own devices). The way this would happen is the driver would be sent to Microsoft or one of their affiliates to be verified. Lately, more and more requirements have been tacked on. An example: to have a signed audio driver, you must provide a mechanism to deactivate digital outputs when copyrighted audio is played. The same concept goes for DVD's, you can't have non-encrypted digital outputs (such as current LCD panels) or non-macrovision encoded TV outputs active while playing copyrighted DVDs. Having this support in the driver, of course, isn't enough, the software must tell these devices to deactivate. Microsoft Media Player is one such software application. If you attempt to play copyrighted music to a non-signed driver with the newest versions, it simply won't play. Same goes for DVD's through both Microsoft's current software (as well as a few other popular brands, such as Intervideo). OK, so you just don't use Microsoft's software, right? You build your own OS, and you use your own tools. Nope, not going to help. Just try to support the encrypted channels that exist in the next line of LCD panels that are coming next year if you can't license the encryption technology to include with your OS. Even worse, some companies are looking into adding this technology to rather standard hardware such as hard drives. As mentioned on Slashdot a few months ago, IBM finally decided against adding content protection (can't store copyrighted files, and won't talk with drivers that don't support telling it about copyrighted files) to its IDE drives; unfortunately this was only because Pheonix came forward with plans to add similar technology to the BIOS itself, something much more fundamental to an OSs execution than a new series of hard drives. B) Microsoft seems to be more about the services. One of the failed companies I have been a part of over the last year and half was one designed to compete with Microsoft's Passport by being a more powerful system that would be available on more platforms (with the connector bits being open source so it could be ported into everything rapidly, we're selling a service here, not a 50k piece of software) called Data Universal. Part of it was to securely store user data in the databases, giving end-users more fine grained control over who has access to what data, even later being able to use this to slowly force websites to understand that someone's name isn't even a required element of their data in most cases (long term, interesting goal). This is the same kind of goal as HailStorm. I have spent long enough thinking about this to know about the power of this technology. If you don't believe what it can do if done right, watch the episode "Please Press One" of the television show "Sliders". A short synopsis can be found here ( http://greene.xtn.net/~lucast/sliders/season5/please/episode.html ), and yes, our company _was_ based on theirs :). We simply felt we could do it in such a way as to not end up as bad (besides, the point was to start a company, and they seemed to be rather successful... right?... right?!?). I also urge you to read http://www.thestandard.com/article/0,1902,27685,00.html , "Microsoft Could Hold Passport to Net", a recent article from "The Standard". 18. What is ORP and why is it being considered for a VM? ORP is a project that has been put together by the Microprocessor Research Laboritory at Intel. Part of the reason it is being looked into is because I have been telling Miguel about it for many months now (although it would have been run across anyway, as it was brought up on the mono-hackers list if you read through the entries for last month by a developer who hadn't heard of it before and was likely just combing for related projects), initially due to a project I was trying to get support for (failed at this) to write a Unix implementation of .NET based on it, hopefully with Intel's support. If anyone is interested in reading it for kicks, the best initial project write-up can be found here in my mailing list archives: http://lists.saurik.net/message.xsp?id=62 . The e-mail is in response to one sent to a mailing list for another of the earlier projects that was started by a company in Australia named Southern Storm, Ltd. Their project can be found here: http://www.southern-storm.com.au/portable_net.html . Something to point out is that ORP isn't really a "JVM" (as someone else who just responded to this question said), Intel doesn't call it that, and I wish other people would stop as well (as it makes people think that it is _just_ Java technology). ORP is a VM, "initially" designed to support Java byte codes, that has a clear seperation between runtime, JIT, and GC. The idea is to allow for research to be done on better JITs and GCs without requiring a new runtime to be written (which severely taints any performance data). Because of this architecture, ORP is ideal for writing a cross-platform JIT, or for slowly improving a GC over time as newer methods come into existance. Intel is already considering support of the CLI, as indicated in a recent presentation at Java Grande 2001 (you can get the slides from this presentation from the files section of their sourceforge project at http://www.sourceforge.net/projects/orp/ ). So far they have a codebase licensed under a BSD-type license that runs under both Linux and Windows (using Visual Studio, not requiring cygwin or some other porting layer), and have a JIT for IA32. Working with Intel has an added benefit of giving credibility to the project, both in the eyes of end users but, more importantly, to corporations looking to use .NET technology in their infrastructure (who take more note of this kind of thing than your average techie). This involvement has, in the past, been incredabely effective, as is seen by Sun's involvement in some of the Apache XML technologies and IBM's support of Linux in general. 19. Isn't .Net vaporware? No, it currently exists. I'm running it right now and am working on building a few applications using it. Hell, I've already written a decompiler for it :). 20. If mono succeeds, won't MS quit sharing source? Is that really a big deal? If we everyone already has the source they need, then if Microsoft stops sharing it there isn't any big loss. From Bob_Salita@SoftworksLtd.com Tue Jul 10 10:52:59 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Tue, 10 Jul 2001 04:52:59 -0500 Subject: [Mono-list] Looking at Microsoft implementation? Message-ID: >Martin wrote: > > Does "Microsoft's implementation of .NET" mean MS's actual source for > > .NET, or does merely ILDasm'ing mscorlib exclude someone from working on > > Mono? > >MS' shared source license is incompatible with the GPL, it not being a >valid >free software license. Thus, if you have seen MS's code, you are unable >legally to contribute to this project. Does the MS shared source license really prohibit this? Anyone have a pointer to the shared source license? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From martin.coxall@itouch.co.uk Tue Jul 10 10:55:58 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Tue, 10 Jul 2001 10:55:58 +0100 Subject: [Mono-list] Looking at Microsoft implementation? In-Reply-To: References: Message-ID: <01071010555805.01523@gypsumfantastic.uk.itouchnet.net> > Does the MS shared source license really prohibit this? No, but the GPL does. --- Martin --- "Where laughing and smiling are not allowed" From Bob_Salita@SoftworksLtd.com Tue Jul 10 11:02:07 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Tue, 10 Jul 2001 05:02:07 -0500 Subject: [Mono-list] Questions Message-ID: >Martin wrote: >We have to get Miguel de Icaza or some of his Ximian/FSF colleagues on the >ECMA committe responsible for standardisation- to make sure they don't slip >any changes is that could harm Mono. I'm less concerned about something being slipped into the standard and more afraid of something being slipped into the code after the standard. The former is an implementation detail, the later is proprietary. I would think the goal of an open source advocate at ECMA would be to encourage as much detailed standardization as possible. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From Bob_Salita@SoftworksLtd.com Tue Jul 10 11:32:03 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Tue, 10 Jul 2001 05:32:03 -0500 Subject: [Mono-list] Looking at Microsoft implementation? Message-ID: >Martin wrote: > > Does the MS shared source license really prohibit this? > >No, but the GPL does. Are you saying the GPL prohibits someone from looking at proprietary source code and then working on a clone open source project? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From worleys@hotmail.com Tue Jul 10 14:33:41 2001 From: worleys@hotmail.com (Scott Worley) Date: Tue, 10 Jul 2001 06:33:41 -0700 Subject: [Mono-list] Mono Message-ID: ------=_NextPart_001_0000_01C1090A.4265B810 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys, =20 Nice to see another effort out there spreading the .NET gospel to other p= latforms, I am an Author, and will soon have a book on ASP.NET on the she= lves, and am interested in helping you out a little on the documentation = side, I have registered withyou mailing list, and will be tracking your p= rogress, good luck in the project, I hope that this open source project r= uns the full distance, since .NET badly needs other platform support. Respect & Honour Scott Worley "Author of INSIDE ASP.NET, Newriders Publishing"Get more from the Web. F= REE MSN Explorer download : http://explorer.msn.com ------=_NextPart_001_0000_01C1090A.4265B810 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi guys,

Nice to see another effort out there spreading t= he .NET gospel to other platforms, I am an Author, and will soon have a b= ook on ASP.NET on the shelves, and am interested in helping you out a lit= tle on the documentation side, I have registered withyou mailing list, an= d will be tracking your progress, good luck in the project, I hope that t= his open source project runs the full distance, since .NET badly needs ot= her platform support.

Respect & Honour

Scott Worley=

"Author of INSIDE ASP.NET, Newriders Publishing"

&= nbsp;

Get more from the Web. FREE= MSN Explorer download : http://explo= rer.msn.com

------=_NextPart_001_0000_01C1090A.4265B810-- From tseng_mike@yahoo.com Tue Jul 10 12:02:42 2001 From: tseng_mike@yahoo.com (Mikw Lee) Date: Tue, 10 Jul 2001 21:02:42 +1000 Subject: [Mono-list] Portable.NET References: <200107100944.FAA31761@trna.ximian.com> Message-ID: <3B4AE0D2.16D92C34@yahoo.com> Is there any relationship between Mono and Portable.NET? They seem to have some work that overlaps. Mike _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From martin.coxall@itouch.co.uk Tue Jul 10 12:09:04 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Tue, 10 Jul 2001 12:09:04 +0100 Subject: [Mono-list] Portable.NET In-Reply-To: <3B4AE0D2.16D92C34@yahoo.com> References: <200107100944.FAA31761@trna.ximian.com> <3B4AE0D2.16D92C34@yahoo.com> Message-ID: <0107101209040A.01523@gypsumfantastic.uk.itouchnet.net> > Is there any relationship between Mono and Portable.NET? They seem to > have some work that overlaps. Indeed. Project Mono, portable.net and dotGNU all overlap. It would be better if we all stopped stepping on each other's toes, then together provide a complete range of responses to .NET --- Martin --- "Where laughing and smiling are not allowed" From poole@troilus.org Tue Jul 10 12:19:17 2001 From: poole@troilus.org (Michael Poole) Date: 10 Jul 2001 07:19:17 -0400 Subject: [Mono-list] ReplyTo in headers In-Reply-To: <002c01c108e6$50fad280$6ea6accf@razorsoft.com> References: <002c01c108e6$50fad280$6ea6accf@razorsoft.com> Message-ID: <873d859glm.fsf@cj46222-a.reston1.va.home.com> "Peter Drayton" writes: > Could the list admin please set up the list so there's a Reply-To in the > header, pointing at mono-list@ximian.com? It's quite annoying to default > to emailing the poster directly, rather than the list at large. Thanks! Please don't! http://www.unicom.com/pw/reply-to-harmful.html lists a number of reasons it's bad for a mailing list to set (or change) Reply-To. I actually like being able to reply directly to the poster and getting copies of replies to my mail. For those who don't want to get copies of replies, I've seen people put "Please reply to mailing lists, not me" in their sigs. -- Michael From rubys@us.ibm.com Tue Jul 10 12:10:04 2001 From: rubys@us.ibm.com (Sam Ruby) Date: Tue, 10 Jul 2001 07:10:04 -0400 Subject: [Mono-list] System.Xml Message-ID: Martin Coxall wrote: > > In that respect, I imagine the best bet would be to port Apache's > best-of-breed Xalan/Xerces parser to c#, as it is written in Java and > available under the (GPL-compatible) Apache license, this would be > technically and legally possible. Several comments: 1) Instead of rewriting everything from Java to C# (JXTA was mentioned previously, now Xalan/Xerces), why not write a Java2IL compiler once and be done with it? 2) It is not clear that the Apache License is GPL-compatible. That being said, the current Apache license is a BSD license without the advertising clause (see http://www.ximian.com/mono/faq.html, question 13). 3) The Xerces parser's API does not match Microsoft's one. Pull, SAX, and DOM are fundamentally different. There is an internal, and largely undocumented pull parser API inside of Xerces. - Sam Ruby, Apache Member Member, Apache XML Project Management Committee From weiqigao@networkusa.net Tue Jul 10 12:30:05 2001 From: weiqigao@networkusa.net (Weiqi Gao) Date: 10 Jul 2001 06:30:05 -0500 Subject: [Mono-list] ReplyTo in headers In-Reply-To: <873d859glm.fsf@cj46222-a.reston1.va.home.com> References: <002c01c108e6$50fad280$6ea6accf@razorsoft.com> <873d859glm.fsf@cj46222-a.reston1.va.home.com> Message-ID: <994764607.1259.1.camel@gao-2001.stlouis.mo.us> On 10 Jul 2001 07:19:17 -0400, Michael Poole wrote: > "Peter Drayton" writes: > > > Could the list admin please set up the list so there's a Reply-To in the > > header, pointing at mono-list@ximian.com? It's quite annoying to default > > to emailing the poster directly, rather than the list at large. Thanks! > > Please don't! http://www.unicom.com/pw/reply-to-harmful.html lists a > number of reasons it's bad for a mailing list to set (or change) > Reply-To. I actually like being able to reply directly to the poster > and getting copies of replies to my mail. For those who don't want to > get copies of replies, I've seen people put "Please reply to mailing > lists, not me" in their sigs. Get into the habit of using "Reply to all" feature of the mailer. That way the reply goes to both the list and the sender. I just experienced an 12 hour ordeal on a list with "Reply-To:" set to the list. Everyone received hundreds of messages of the type "I'm out of the office till next Tuesday." -- Weiqi Gao weiqigao@networkusa.net From martin.coxall@itouch.co.uk Tue Jul 10 12:33:18 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Tue, 10 Jul 2001 12:33:18 +0100 Subject: [Mono-list] System.Xml In-Reply-To: References: Message-ID: <0107101233180E.01523@gypsumfantastic.uk.itouchnet.net> > 1) Instead of rewriting everything from Java to C# (JXTA was mentioned > previously, now Xalan/Xerces), why not write a Java2IL compiler once and be > done with it? Can we legally use MS JUMP to do this? If we used it to convert Xerces to c#, would the original Apache license be intact? --- Martin --- "Where laughing and smiling are not allowed" From Bob_Salita@SoftworksLtd.com Tue Jul 10 13:04:09 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Tue, 10 Jul 2001 07:04:09 -0500 Subject: [Mono-list] Perplexed and intrigued by ECMA licensing of .Net Message-ID: I'm perplexed and intrigued by the issue of licensing and standardization. In particular the licensing of MS .Net technologies to ECMA. Is it correct that ECMA has not been granted any license for MS .Net technologies? What licensing covers ECMA's current;y published work (working group stuff)? Is it true that ECMA doesn't know what licensing will be granted to ECMA for distribution of the ECMA .Net standard? On the other hand, I understand MS wouldn't want to license their highly valued .Net technologies until a final standard is approved. This way MS maintains leverage over the standards process. MS will only grant a license if they like the final document. This must be a common scenario in standards making. Seems like potential for considerable intrigue. MS wants, and can, largely control the standardization process. Other members want to get as much IP as possible, with least onerous terms, using as much leverage as they can muster. At the very end of the process, everyone holds their breath as the final licensing terms are negotiated (or dictated), then granted to ECMA. Is this how it works? Seems sort of entertaining. So this would explain why Red Hat, IBM and others are not fully commited to supporting mono. They can't deploy a strategy until licensing is granted. Any related public comments or actions must be carefully chosen. Meanwhile, all they can do is lobby for most favorable terms. So this would be a critical time for open source advocates to use their leverage to get favorable terms. Perhaps terms are a more important priority than the IP content of the standard. Bob. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From trd@cs.mu.OZ.AU Tue Jul 10 13:11:54 2001 From: trd@cs.mu.OZ.AU (Tyson Dowd) Date: Tue, 10 Jul 2001 22:11:54 +1000 Subject: [Mono-list] Re: Welcome To "Mono-list"! In-Reply-To: ; from rubys@us.ibm.com on Mon, Jul 09, 2001 at 02:33:50PM -0400 References: Message-ID: <20010710221154.A6293@cs.mu.oz.au> On 09-Jul-2001, Sam Ruby wrote: > Martin Coxall wrote: > > > > How many languages is it worth us supporting? I would argue that C# > > and java should be the only two for the time being. > > The three "first tier" languages supported by the Microsoft implemenation > are C#, VB, and JavaScript. I personally run Mercury on .NET almost every day. If you implement the instruction set and the runtime engine, the langauges run automatically. There is very little extra work required to get extra languages working even if you just implement the minimum that is required for C#. -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. trd@cs.mu.oz.au # http://www.cs.mu.oz.au/~trd # From angryjohn69@hotmail.com Tue Jul 10 13:15:42 2001 From: angryjohn69@hotmail.com (John Hicks) Date: Tue, 10 Jul 2001 08:15:42 -0400 Subject: [Mono-list] contributing to mono Message-ID: ------=_NextPart_001_0000_01C10918.82D951F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'd certainly be interested in contributing to Mono in any way that I can= , especially when it comes to coding, but I'm not sure where my skill-set would fit in at t= his point. I've been an exclusive server-side Java guy for the past 2+ years, but I've been pl= aying with C# for a =20 couple of months now, so I can say that I'm comfortable with working with= it. =20 I'd be more than happy to help out with a project that somebody has start= ed, especially =20 in the area of System.xml. Thanks, JohnGet more from the Web. FREE MSN Explorer download : http://explorer.= msn.com ------=_NextPart_001_0000_01C10918.82D951F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I'd certainly = be interested in contributing to Mono in any way that I can, especially w= hen

it comes to coding, but I'm not sure where my skill-set wo= uld fit in at this point. I've been

an exclusive server-= side Java guy for the past 2+ years, but I've been playing with C# for a =

couple of months now, so I can say that I'm comfortable with = working with it.

I'd be more than happ= y to help out with a project that somebody has started, especially

in the area of System.xml.

Thanks,

John

Get more from= the Web. FREE MSN Explorer download : http://explorer.msn.com

------=_NextPart_001_0000_01C10918.82D951F0-- From trd@cs.mu.OZ.AU Tue Jul 10 13:20:13 2001 From: trd@cs.mu.OZ.AU (Tyson Dowd) Date: Tue, 10 Jul 2001 22:20:13 +1000 Subject: [Mono-list] On porting to C# In-Reply-To: <200107100007.UAA26528@trna.ximian.com>; from casey@sarahandcasey.com on Mon, Jul 09, 2001 at 05:06:22PM -0700 References: <200107100007.UAA26528@trna.ximian.com> Message-ID: <20010710222013.B6293@cs.mu.oz.au> CodeDOM can be implemented in other languages too. The fact that is spits out source code is no big deal -- it has to compile the code somehow, and because CodeDOM allow snippets or verbatim code to be inserted, running the compiler is a relatively easy way to achieve this. There are implementations in several other languages around. It helps enormously if your language is C# though. And the closer you are to C# the easier it is. But I believe it is poorly designed. The idea is a good one, but the design is terrible. On 09-Jul-2001, Casey Cady wrote: > Substitute "badly designed" with "immature" and > I'll completely agree with you. :) I see potential in the > CodeDOM namespace but currently it needs a big fat flashing > red warning saying "I cheat!!!". > > (For those that don't know about the CodeDOM namespace, it > allows you to programatically represent source code. You can then > dump the CodeDOM to a source file, or compile it to MSIL. The huge > catch is that Microsoft's implementation of the CodeDOM compiler > simply spits out c# code and compiles it externally with the plain old > compiler.) > > Thanks > Casey > > On Monday, July 9, 2001, at 03:58 PM, Miguel de Icaza wrote: > > > > >> Besides, it's probably much easier just to throw together a Java > >> compiler that uses the CodeDOM and Reflection.Emit stuff as an MSIL > >> puker than it is to write a Byte code converter, which, IMHO, misses > >> the > >> point of the CLR. > > > > CodeDOM is sadly a badly designed piece of code. It is not really > > useful for a compiler, it is mostly a tool for creating C# source > > code, but the tree later gets passed on to an external C# compiler. > > > > Reflection.Emit on the other hand is really nice > > > > Miguel. > > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list -- Tyson Dowd # # Surreal humour isn't everyone's cup of fur. trd@cs.mu.oz.au # http://www.cs.mu.oz.au/~trd # From pit@sssup.it Tue Jul 10 15:00:29 2001 From: pit@sssup.it (Emanuele Ruffaldi) Date: Tue, 10 Jul 2001 16:00:29 +0200 Subject: [Mono-list] just starting to play Message-ID: <000001c10948$addd2090$4a53cdc1@sssup.it> Hi, just playing with your latest snapshor 8/7/01: I have Beta 2 and compiler doesn't go Just al little difference in driver.cs line 113 a = Assembly.LoadFrom (full_path); instead of a = Assembly.Load (full_path); I hope to follow and help your work following months Emanuele Ruffaldi From iain@ximian.com Tue Jul 10 16:35:14 2001 From: iain@ximian.com (iain) Date: 10 Jul 2001 11:35:14 -0400 Subject: [Mono-list] System.Collections.Queue Message-ID: <994779314.974.1.camel@anti-slavery> I've started work on this class (actually, I'm almost finished it, I just need to test it properly), just in case anyone else was thinking about doing it. iain From lupus@ximian.com Tue Jul 10 16:36:19 2001 From: lupus@ximian.com (Paolo Molaro) Date: Tue, 10 Jul 2001 17:36:19 +0200 Subject: [Mono-list] Contributing to the classes. In-Reply-To: References: Message-ID: <20010710173619.B19004@lettere.unipd.it> On 07/09/01 Miguel de Icaza wrote: > There are a number of people who are interested in contributing to the > class libraries in Mono. [...] > (Paolo, do you think we can use a version of your script to keep track > of this?) Yes. I will put the XML description file for this on cvs shortly. lupus -- ----------------------------------------------------------------- lupus@debian.org debian/rules lupus@ximian.com Monkeys do it better From sebastien.lambla@6sens.com Tue Jul 10 16:39:20 2001 From: sebastien.lambla@6sens.com (Sebastien Lambla) Date: Tue, 10 Jul 2001 17:39:20 +0200 Subject: [Mono-list] About the System namespace In-Reply-To: <994779314.974.1.camel@anti-slavery> Message-ID: Hello all, as far as I understand, some classes will be built on top of existing components. For other classes completely written on top of C# and the framework, wouldn't it be better to have them published in another namespace on windows systems so as to provide an open source equivalent to the System namespace, such as FreeSystem? Sebastien Lambla From pablob@manes.netverk.com.ar Tue Jul 10 13:42:59 2001 From: pablob@manes.netverk.com.ar (Pablo Baena) Date: Tue, 10 Jul 2001 12:42:59 +0000 Subject: [Mono-list] Bonobo/Corba and mono Message-ID: <3B4AF853.5060107@manes.netverk.com.ar> Hi! I have a question. I've been following Gnome since the early beginnings, and I never understood (nor did I put much effort to) which part of Bonobo or Corba take account in making Gnome components, but they (combined or not) finally do that. Now it seems that mono will replace it. I've been reading that Gnome 2.0 is thought to be using Bonobo exhaustively. What will happen now?? In Gnome 4.0 everything will be replaced by mono? As a side note, I really think this will be good for Ximian and Linux in general. We know that this stuff, like it or not, will be adopted by the market and thus, having a good implementation for our OSes will make them more popular. From linuxgeek@yahoo.com Tue Jul 10 17:59:04 2001 From: linuxgeek@yahoo.com (Eric Harlow) Date: Tue, 10 Jul 2001 09:59:04 -0700 (PDT) Subject: [Mono-list] Organizational questions Message-ID: <20010710165904.41115.qmail@web14006.mail.yahoo.com> Are you going to have a dedicated person to manage the .NET framework project? Part-time or full-time - but someone who's not doing a lot of development so they can focus on moving the project along? Is there going to be a site (more than the current status pages) where we can see the status of various items and find small bite-sized projects that are available? (Which class libraries need writing, for example.) -Eric __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From bob@thestuff.net Tue Jul 10 18:18:53 2001 From: bob@thestuff.net (Bob Smith) Date: 10 Jul 2001 11:18:53 -0600 Subject: [Mono-list] Math class Message-ID: <994785626.32741.7.camel@5of9.h.thestuff.net> Hello, I'd like to do the Math class if no one is working on it. Bob From fejj@ximian.com Tue Jul 10 18:43:18 2001 From: fejj@ximian.com (Jeffrey Stedfast) Date: 10 Jul 2001 13:43:18 -0400 Subject: [Mono-list] Bonobo/Corba and mono In-Reply-To: <3B4AF853.5060107@manes.netverk.com.ar> References: <3B4AF853.5060107@manes.netverk.com.ar> Message-ID: <994786998.16166.9.camel@tazmanian-devil.helixcode.com> Mono isn't a component system, so it won't be replacing Bonobo. Jeff On 10 Jul 2001 12:42:59 +0000, Pablo Baena wrote: > Hi! I have a question. I've been following Gnome since the early > beginnings, and I never understood (nor did I put much effort to) which > part of Bonobo or Corba take account in making Gnome components, but > they (combined or not) finally do that. Now it seems that mono will > replace it. > > I've been reading that Gnome 2.0 is thought to be using Bonobo > exhaustively. What will happen now?? In Gnome 4.0 everything will be > replaced by mono? > > As a side note, I really think this will be good for Ximian and Linux in > general. We know that this stuff, like it or not, will be adopted by the > market and thus, having a good implementation for our OSes will make > them more popular. > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list From John.Huss@AGG.com Tue Jul 10 18:52:24 2001 From: John.Huss@AGG.com (Huss, John J.) Date: Tue, 10 Jul 2001 13:52:24 -0400 Subject: [Mono-list] class library Message-ID: <20506E72B708AF4BA8CEE4484F7D417BF335F5@atlex02.agg.local> 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_01C10969.1334D490 Content-Type: text/plain; charset="iso-8859-1" Hey, I want to get involved with developing Mono. What sort of jobs are there that need to be done that are doable by someone who has some c++ experience but no c#? where does one learn c#? ------_=_NextPart_001_01C10969.1334D490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable class library

Hey, I want to get involved with = developing Mono.
What sort of jobs are there that need = to be done that are doable by someone who has some c++ experience but = no c#?
where does one learn c#?

------_=_NextPart_001_01C10969.1334D490-- From saurik@saurik.com Tue Jul 10 18:59:37 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Tue, 10 Jul 2001 12:59:37 -0500 Subject: [Mono-list] Bonobo/Corba and mono References: <3B4AF853.5060107@manes.netverk.com.ar> <994786998.16166.9.camel@tazmanian-devil.helixcode.com> Message-ID: <015401c1096a$168dce20$d1cd1d18@cruiser> Umm... I hate to have to correct someone from _Ximian_ of all places, but Mono had _better_ be a component system... really, that's about 90% of what the .NET infrastructure is about: a framework for writing components in various languages that can be used from the other languages, all running over a VM with a garbage collector. That's what the specs cover, not some magical platform for selling software as a service (although a sufficiently network-oriented VM such as .NET that comes with a number of useful components definitely helps this a ton). Microsoft is currently pushing this as the long-term replacement to writing COM objects and "ActiveX" components (which are just COM objects that implement a number of special interfaces) on Windows. This work is _directly_ comparable with Bonobo, just as it is _directly_ comparable with COM. * is now afraid... very afraid... * Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "Jeffrey Stedfast" To: "Pablo Baena" Cc: Sent: Tuesday, July 10, 2001 12:43 PM Subject: Re: [Mono-list] Bonobo/Corba and mono > Mono isn't a component system, so it won't be replacing Bonobo. > > Jeff From Mike Labosh" I have been a Microsoft Pawn for many years. I have been writing code since about 1979 and I have lately seen the need for change. I am well versed in MS technologies and even considered writing a VB compiler and COM implementation for linux. Too bad I don't know assembler and could actually pull it off. In any case, I would like to be involved in this project any way I can. Peace and happy computing, Mike Labosh, MCT, MCSD "Escriba coda ergo sum." -- vbSensei From handor@peaseassociates.com Tue Jul 10 19:18:33 2001 From: handor@peaseassociates.com (Dominic Pease) Date: Tue, 10 Jul 2001 13:18:33 -0500 Subject: [Mono-list] Bonobo/Corba and mono In-Reply-To: <015401c1096a$168dce20$d1cd1d18@cruiser> Message-ID: Yeah, agreed. I don't really know what people think the .Net framework really is unless it's a grand component and integration tool. You guys do understand this, right? I mean, I'd hate to watch this project progress without a firm understanding of exactly what they're working on. -Dominic -----Original Message----- From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]On Behalf Of Jay Freeman (saurik) Sent: Tuesday, July 10, 2001 1:00 PM To: mono-list Subject: Re: [Mono-list] Bonobo/Corba and mono Umm... I hate to have to correct someone from _Ximian_ of all places, but Mono had _better_ be a component system... really, that's about 90% of what the .NET infrastructure is about: a framework for writing components in various languages that can be used from the other languages, all running over a VM with a garbage collector. That's what the specs cover, not some magical platform for selling software as a service (although a sufficiently network-oriented VM such as .NET that comes with a number of useful components definitely helps this a ton). Microsoft is currently pushing this as the long-term replacement to writing COM objects and "ActiveX" components (which are just COM objects that implement a number of special interfaces) on Windows. This work is _directly_ comparable with Bonobo, just as it is _directly_ comparable with COM. * is now afraid... very afraid... * Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "Jeffrey Stedfast" To: "Pablo Baena" Cc: Sent: Tuesday, July 10, 2001 12:43 PM Subject: Re: [Mono-list] Bonobo/Corba and mono > Mono isn't a component system, so it won't be replacing Bonobo. > > Jeff _______________________________________________ Mono-list maillist - Mono-list@ximian.com http://lists.ximian.com/mailman/listinfo/mono-list From bob@thestuff.net Tue Jul 10 19:33:55 2001 From: bob@thestuff.net (Bob Smith) Date: 10 Jul 2001 12:33:55 -0600 Subject: [Mono-list] I want to get in on this. In-Reply-To: References: Message-ID: <994790045.456.10.camel@5of9.h.thestuff.net> I dont speak for everyone, but I'd love to see a vb compiler for mono. There is a tun of vb programmers/code out there that could be harnased for gnome programming if vb was available. You wouldnt need to know asembly to do it. The C# compiler is writen in C#. On 10 Jul 2001 14:19:58 -0400, Mike Labosh wrote: > I have been a Microsoft Pawn for many years. I have been writing code since > about 1979 and I have lately seen the need for change. I am well versed in > MS technologies and even considered writing a VB compiler and COM > implementation for linux. Too bad I don't know assembler and could actually > pull it off. > > In any case, I would like to be involved in this project any way I can. > > Peace and happy computing, > > Mike Labosh, MCT, MCSD > "Escriba coda ergo sum." -- vbSensei > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > From rodrigo@ximian.com Tue Jul 10 19:31:18 2001 From: rodrigo@ximian.com (Rodrigo Moya) Date: 10 Jul 2001 20:31:18 +0200 Subject: [Mono-list] I want to get in on this. In-Reply-To: <994790045.456.10.camel@5of9.h.thestuff.net> References: <994790045.456.10.camel@5of9.h.thestuff.net> Message-ID: <994789884.25107.10.camel@zubiri> On 10 Jul 2001 12:33:55 -0600, Bob Smith wrote: > I dont speak for everyone, but I'd love to see a vb compiler for mono. > There is a tun of vb programmers/code out there that could be harnased > for gnome programming if vb was available. You wouldnt need to know > asembly to do it. The C# compiler is writen in C#. > there is already a project towards a VB interpreter: GNOME Basic at http://www.gnome.org/projects/gb. I don't know the exact state of the project, but it's being used in Gnumeric (I think), so it might be quite advanced. I guess Mono support could be added to it. cheers -- Rodrigo Moya - http://www.gnome-db.org/ - http://www.ximian.com/ From zedlwski@Princeton.EDU Tue Jul 10 19:32:20 2001 From: zedlwski@Princeton.EDU (John Zedlewski) Date: Tue, 10 Jul 2001 14:32:20 -0400 Subject: [Mono-list] Gcc front-end? In-Reply-To: <200107101817.OAA28032@trna.ximian.com> Message-ID: <000b01c1096e$a7afe6a0$1699b48c@cp102230a> Hi folks, On the roadmap, it seems to imply that y'all are working on a completely new "JIT" compiler for the CLI. I'm curious about why this is a better plan than writing a Gcc front-end for CLI bytecode. As soon as a Linux x86 "JIT" comes out, somebody's going to complain about the lack of optimizations, somebody else will bitch about not having a Linux Alpha port, and ten more users will want ports to Solaris and IA-64. At least, that's been my experience with OSS projects in the past ;) Some old posts from the Mercury folks implied that they were able to do the Mercury->gcc interface in under 8,000 LOC. Also, am I correct in believing that CLI is designed for more of an Ahead-Of-Time compiler with local caching of native code? That's what all the MS marketing-speak seemed to imply (no interepreter or mixed-mode). Thanks! --JRZ From zedlwski@Princeton.EDU Tue Jul 10 19:35:49 2001 From: zedlwski@Princeton.EDU (John Zedlewski) Date: Tue, 10 Jul 2001 14:35:49 -0400 Subject: [Mono-list] x86 JIT In-Reply-To: <200107101817.OAA28032@trna.ximian.com> Message-ID: <000c01c1096f$23e89730$1699b48c@cp102230a> Oh, sorry I forgot to put this in my last message. If you really are interested in focusing on Linux x86, rather than using a gcc backend, I would HIGHLY recommend a look at Intel's Open Research Platform (ORP) JIT for Java. It's clean, well-designed, and basically under an Apache-style license: http://www.intel.com/research/mrl/orp/. Very nice code, several different garbage collectors, etc. --JRZ From iain@ximian.com Tue Jul 10 19:41:49 2001 From: iain@ximian.com (iain) Date: 10 Jul 2001 14:41:49 -0400 Subject: [Mono-list] class library In-Reply-To: <20506E72B708AF4BA8CEE4484F7D417BF335F5@atlex02.agg.local> References: <20506E72B708AF4BA8CEE4484F7D417BF335F5@atlex02.agg.local> Message-ID: <994790510.2462.13.camel@anti-slavery> On 10 Jul 2001 13:52:24 -0400, Huss, John J. wrote: > Hey, I want to get involved with developing Mono. > What sort of jobs are there that need to be done that are doable by someone > who has some c++ experience but no c#? > where does one learn c#? The book that most (all?) of the Ximian people used is called C# Essentials from O'Reilly. It's not bad. There's also a fairly comprehensive SDK on the MSDN site somewhere. There's a link to it from the mono website. iain From bob@thestuff.net Tue Jul 10 19:48:26 2001 From: bob@thestuff.net (Bob Smith) Date: 10 Jul 2001 12:48:26 -0600 Subject: [Mono-list] I want to get in on this. In-Reply-To: <994789884.25107.10.camel@zubiri> References: <994790045.456.10.camel@5of9.h.thestuff.net> <994789884.25107.10.camel@zubiri> Message-ID: <994790915.32733.11.camel@5of9.h.thestuff.net> As far as I know, Gnome Basic is an interpriter only, and I would think it would be difficult to addapt to generate CLI code. I may be mistaken. I'm curious about what the Gnome Basic GURU's have to say about Gnome Basic for Mono. On 10 Jul 2001 20:31:18 +0200, Rodrigo Moya wrote: > On 10 Jul 2001 12:33:55 -0600, Bob Smith wrote: > > I dont speak for everyone, but I'd love to see a vb compiler for mono. > > There is a tun of vb programmers/code out there that could be harnased > > for gnome programming if vb was available. You wouldnt need to know > > asembly to do it. The C# compiler is writen in C#. > > > there is already a project towards a VB interpreter: GNOME Basic at > http://www.gnome.org/projects/gb. I don't know the exact state of the > project, but it's being used in Gnumeric (I think), so it might be quite > advanced. > > I guess Mono support could be added to it. > > cheers > > -- > Rodrigo Moya - > http://www.gnome-db.org/ - http://www.ximian.com/ > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > From iain@ximian.com Tue Jul 10 19:43:47 2001 From: iain@ximian.com (iain) Date: 10 Jul 2001 14:43:47 -0400 Subject: [Mono-list] class library In-Reply-To: <20506E72B708AF4BA8CEE4484F7D417BF335F5@atlex02.agg.local> References: <20506E72B708AF4BA8CEE4484F7D417BF335F5@atlex02.agg.local> Message-ID: <994790628.2452.17.camel@anti-slavery> On 10 Jul 2001 13:52:24 -0400, Huss, John J. wrote: > Hey, I want to get involved with developing Mono. > What sort of jobs are there that need to be done that are doable by someone > who has some c++ experience but no c#? > where does one learn c#? From michaellambert@bellsouth.net Tue Jul 10 19:54:08 2001 From: michaellambert@bellsouth.net (Michael Lambert) Date: Tue, 10 Jul 2001 14:54:08 -0400 Subject: [Mono-list] Perplexed and intrigued by ECMA licensing of .Net In-Reply-To: <200107101817.OAA28038@trna.ximian.com> Message-ID: > Reply-To: Bob_Salita@SoftworksLtd.com > From: "Bob Salita" > To: mono-list@ximian.com > Date: Tue, 10 Jul 2001 07:04:09 -0500 > Subject: [Mono-list] Perplexed and intrigued by ECMA licensing of .Net > > Is it correct that ECMA has not been granted any license for MS .Net > technologies? What licensing covers ECMA's current;y published > work (working > group stuff)? Is it true that ECMA doesn't know what licensing will be > granted to ECMA for distribution of the ECMA .Net standard? > > Bob. > I would agree that if this thing is going to work that this would need to be sorted out in advance. Is there someone knowledgeable about the ECMA on the list who could comment on this? If this is the case then perhaps a few authors should shed some light on Microsoft's approach to the standards process. On another note... A .Net assembly can be signed so simply replacing the MS System assembly with a FreeSystem assembly could be destined to fail before it starts. If the loader checks the sign key as part of loading and the key is not MS's key then your dead. MS is already incorporating this technology in the XP version of Windows. This means that the Mono effort could require a total rewrite/parallel implementation. Would our best bet be to just take an open source java implementation and get that to run on top of the Mono infrastructure? Focus on system, collection, sockets, files, etc... the basics. Michael From bob@thestuff.net Tue Jul 10 20:25:33 2001 From: bob@thestuff.net (Bob Smith) Date: 10 Jul 2001 13:25:33 -0600 Subject: [Mono-list] binding Message-ID: <994793143.32741.13.camel@5of9.h.thestuff.net> I'm looking at implementing the Math class and I was wondering would it be better to implement it from scratch in C#, or bind it to standard C math functions. Each way is just as portable as the other, both I think will be just about the same performance, the C binding requires less work, and the C# way would probably be cleaner. What is the general consensus about binding vs codeing when it comes to making use of standard C libs? Bob From saurik@saurik.com Tue Jul 10 20:16:58 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Tue, 10 Jul 2001 14:16:58 -0500 Subject: [Mono-list] Gcc front-end? References: <000b01c1096e$a7afe6a0$1699b48c@cp102230a> Message-ID: <000e01c10974$e48b8650$d1cd1d18@cruiser> John: Yes. Speaking about Microsoft's implementation: While it caches compiled code in memory (obviously), it will not (for version 1 at least, future support has been indicated) cache the code it compiles during execution onto disk between executions. It does not do any interpretation or mixed-mode execution (the byte codes weren't designed to make this easy, anyway). There is also a "pre-JIT" compiler that can be executed either manually or from an installation program to compile the code during installation, sign it (to verify that evil code wasn't plopped in its place), and cache it away. The question I have about what you are saying is: if you do this, is there going to be a good way to get gcc to execute on in-memory sets of byte codes (as we just downloaded them from whatever site into memory, or maybe someone used Reflection.Emit to compile on-the-fly into memory) to output an in-memory binary (for purposes of actual execution)? From what I've seen of GCC it looks like god-forsaken, hacked-together, monolithic technology that only kicks ass at what it does because everyone uses it and keeps it up to date with all of the latest hacks. The inability to quickly seperate out its components for reuse actually seems to be a _feature_ accourding to what I've heard from Miguel in conversations recently (having to do with being able to... convince... companies to release their source code, as to get their product working it needed to actually _become_ gcc rather than just _using_ gcc for a single purpose, such as a back-end compiler). While I really would love to see a gcc front-end, I don't see how this deals well with the JIT question. Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "John Zedlewski" To: Sent: Tuesday, July 10, 2001 1:32 PM Subject: [Mono-list] Gcc front-end? > Hi folks, > On the roadmap, it seems to imply that y'all are working on a > completely new "JIT" compiler for the CLI. I'm curious about why this > is a better plan than writing a Gcc front-end for CLI bytecode. As soon > as a Linux x86 "JIT" comes out, somebody's going to complain about the > lack of optimizations, somebody else will bitch about not having a Linux > Alpha port, and ten more users will want ports to Solaris and IA-64. At > least, that's been my experience with OSS projects in the past ;) Some > old posts from the Mercury folks implied that they were able to do the > Mercury->gcc interface in under 8,000 LOC. > > Also, am I correct in believing that CLI is designed for more of an > Ahead-Of-Time compiler with local caching of native code? That's what > all the MS marketing-speak seemed to imply (no interepreter or > mixed-mode). > > Thanks! > --JRZ From stefan.arentz@soze.com Tue Jul 10 20:28:30 2001 From: stefan.arentz@soze.com (Stefan Arentz) Date: Tue, 10 Jul 2001 21:28:30 +0200 Subject: [Mono-list] Perplexed and intrigued by ECMA licensing of .Net In-Reply-To: ; from michaellambert@bellsouth.net on Tue, Jul 10, 2001 at 02:54:08PM -0400 References: <200107101817.OAA28038@trna.ximian.com> Message-ID: <20010710212830.A14359@keyser.soze.com> On Tue, Jul 10, 2001 at 02:54:08PM -0400, Michael Lambert wrote: ... > I would agree that if this thing is going to work that this would need to be > sorted out in advance. Is there someone knowledgeable about the ECMA on the > list who could comment on this? If this is the case then perhaps a few > authors should shed some light on Microsoft's approach to the standards > process. > > On another note... A .Net assembly can be signed so simply replacing the MS > System assembly with a FreeSystem assembly could be destined to fail before > it starts. If the loader checks the sign key as part of loading and the key > is not MS's key then your dead. MS is already incorporating this technology > in the XP version of Windows. This means that the Mono effort could require > a total rewrite/parallel implementation. I'm not completely familiar with the .net framework (yet!), but ... Why would it fail. We write the loader, so we can check the signature and make sure compatibility is ok. There might be a problem with importing certificates with Microsoft's signature though. > Would our best bet be to just take an open source java implementation and > get that to run on top of the Mono infrastructure? Focus on system, > collection, sockets, files, etc... the basics. You're not the first to suggest Java. The goal however is to implement the CLI and do it from scratch :-) Inheriting some Java implementation brings up a lot of unwanted issues .. license, code maintenance, etc. Stefan From rodrigo@ximian.com Tue Jul 10 20:56:51 2001 From: rodrigo@ximian.com (Rodrigo Moya) Date: 10 Jul 2001 21:56:51 +0200 Subject: [Mono-list] I want to get in on this. In-Reply-To: <994790915.32733.11.camel@5of9.h.thestuff.net> References: <994790045.456.10.camel@5of9.h.thestuff.net> <994789884.25107.10.camel@zubiri> <994790915.32733.11.camel@5of9.h.thestuff.net> Message-ID: <994795015.815.16.camel@zubiri> On 10 Jul 2001 12:48:26 -0600, Bob Smith wrote: > As far as I know, Gnome Basic is an interpriter only, and I would think > it would be difficult to addapt to generate CLI code. I may be mistaken. > I'm curious about what the Gnome Basic GURU's have to say about Gnome > Basic for Mono. > well, but I mean, the parser (and other stuff) from GNOME Basic can be reused. That's what I meant. cheers -- Rodrigo Moya - http://www.gnome-db.org/ - http://www.ximian.com/ From saurik@saurik.com Tue Jul 10 21:02:12 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Tue, 10 Jul 2001 15:02:12 -0500 Subject: [Mono-list] Mailing list randomly dropping messages? Message-ID: <004201c1097b$367306e0$d1cd1d18@cruiser> OK, is this happening to anyone else? I started correlating what is in the archives with what I'm actually getting, and it isn't looking good. I got tipped off by having not recieved back one off the messages I just sent, but it is apparently in the archive. In the last few hours, I haven't gotten: x86 JIT by John Zedlewski (which I really would have liked to as it is about ORP, which I am advocating) binding by Bob Smith class libray by iain I checked, and these messages didn't even hit my SMTP server (so it isn't some case of server-side mail organization gone awry). Sincerely, Jay Freeman (saurik) saurik@saurik.com From trd@cs.mu.oz.au Tue Jul 10 21:07:52 2001 From: trd@cs.mu.oz.au (Tyson Dowd) Date: Tue, 10 Jul 2001 22:07:52 +0200 Subject: [Mono-list] Gcc front-end? In-Reply-To: <000b01c1096e$a7afe6a0$1699b48c@cp102230a> Message-ID: <20010710220752.A397@cs.mu.oz.au> On 10-Jul-2001, John Zedlewski wrote: > Hi folks, > On the roadmap, it seems to imply that y'all are working on a > completely new "JIT" compiler for the CLI. I'm curious about why this > is a better plan than writing a Gcc front-end for CLI bytecode. As soon > as a Linux x86 "JIT" comes out, somebody's going to complain about the > lack of optimizations, somebody else will bitch about not having a Linux > Alpha port, and ten more users will want ports to Solaris and IA-64. At > least, that's been my experience with OSS projects in the past ;) Some > old posts from the Mercury folks implied that they were able to do the > Mercury->gcc interface in under 8,000 LOC. The Mercury->gcc interface was a pretty easy binding because all the hard work of translating Mercury to an intermediate form that was basically compatible with gcc's internal data structures had already been done. All that was left was handling the impedence mismatches between the two structures. (I'm probably over-simplifying a bit). If you are going to have a JIT, gcc is not going to be fast enough -- it wasn't designed for it. It certainly wasn't designed to be a compilation server kind of application (which is what a JIT compiler is like). For instance, gcc has trouble with compiling multiple files at once (this is one of the problems with the Mercury->gcc binding, you can't easily wipe clean the gcc data structures in process, you are expected to start a new process instead). If you are saying forget JITting the code and just generate native code from CIL, then it will probably work, but you lose runtime verifiability, code mobility and all the other nice things that an architecture neutral bytecode gives you. > Also, am I correct in believing that CLI is designed for more of an > Ahead-Of-Time compiler with local caching of native code? That's what > all the MS marketing-speak seemed to imply (no interepreter or > mixed-mode). No interpreter, everything is either - jitted as required (at class load time I expect) - jitted as installed Microsoft probably had an interpreter once for bootstrapping purposes, but they aren't releasing one now. I believe native code is cached during a single session (but not between reboots) -- others think it isn't the case, but it seems to be that way to me. I'm not sure if there is any documentation on what actually happens. Tyson. From saurik@saurik.com Tue Jul 10 21:17:30 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Tue, 10 Jul 2001 15:17:30 -0500 Subject: [Mono-list] Re: x86 JIT Message-ID: <004e01c1097d$59b28c00$d1cd1d18@cruiser> John: I totally agree with this. I've been advocating this for months now :-). - Back in March on my net-tech mailing list (which Miguel was a member of), cross-posted to the Portable.NET mailing list: ( original message about it: ) http://lists.saurik.net/message.xsp?id=62 . - In recent conversations with Miguel when he was working on the release documentation last week where I outlined all of the reasons I could think of why it wouldn't be a good idea and why those reasons don't actually apply (as no one has been giving me any good reasons other than wanting to write it themselves for whatever reason). - On Slashdot: http://slashdot.org/comments.pl?sid=01/07/05/205203&cid=217 on one of the Mono related articles. Sincerely, Jay Freeman (saurik) saurik@saurik.com Original message (never got recieved, though... copied out of archive): Oh, sorry I forgot to put this in my last message. If you really are interested in focusing on Linux x86, rather than using a gcc backend, I would HIGHLY recommend a look at Intel's Open Research Platform (ORP) JIT for Java. It's clean, well-designed, and basically under an Apache-style license: http://www.intel.com/research/mrl/orp/. Very nice code, several different garbage collectors, etc. --JRZ From Bob_Salita@SoftworksLtd.com Tue Jul 10 21:49:30 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Tue, 10 Jul 2001 15:49:30 -0500 Subject: [Mono-list] Re: x86 JIT Message-ID: Jay, >I totally agree with this. What is it that you totally agree with? Nothing from the original post is quoted, nor can I find the original message. Also this link to slashdot seems dead: >- On Slashdot: http://slashdot.org/comments.plsid=01/07/05/205203&cid=217 >on one of the Mono related articles. BTW, thanks for answering the FAQ questions that I submitted. Your learned opinion has been awesome and valuable. You obviously spent considerable time in composing answers. Your efforts are much appreciated! Bob. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From michaellambert@bellsouth.net Tue Jul 10 22:00:32 2001 From: michaellambert@bellsouth.net (Michael Lambert) Date: Tue, 10 Jul 2001 17:00:32 -0400 Subject: [Mono-list] Perplexed and intrigued by ECMA licensing of .Net In-Reply-To: <20010710212830.A14359@keyser.soze.com> Message-ID: > > Why would it fail. We write the loader, so we can check the signature and > make sure compatibility is ok. There might be a problem with importing > certificates with Microsoft's signature though. > Good point. Following that train of thought to its conclusion then, unlike jars our assembly images potentially would not run on other non-Mono CLI compliant implementations? Background: "A reference to an assembly (see Section 6.3) captures some of this information at compile time. At runtime, the information contained in the assembly reference can be combined with the information from the manifest of the assembly located at runtime to ensure that the same private key was used to create both the assembly seen when the reference was created (compile time) and when it is resolved (runtime)." Issue: "A conforming implementation of the CLI need not perform this validation, but it is permitted to do so, and it may refuse to load an assembly for which the validation fails. A conforming implementation of the CLI may also refuse to permit access to an assembly unless the assembly reference contains either the public key or the public key token. A conforming implementation of the CLI shall make the same access decision independent of whether a public key or a token is used." > > Would our best bet be to just take an open source java > implementation and > > get that to run on top of the Mono infrastructure? Focus on system, > > collection, sockets, files, etc... the basics. > > You're not the first to suggest Java. The goal however is to implement > the CLI and do it from scratch :-) Inheriting some Java implementation > brings up a lot of unwanted issues .. license, code maintenance, etc. > > Stefan > Sorry for the confusion. At some point the Mono implementation will diverge from the MS one. Mono would be unable to support certain class libraries as they are heavily reliant on Windows (DirectX, Windows GDI+, etc). This means that some of Mono's class library structure would be different. I imagine the hope is that the runtime, compilers, il etc.. would all be compliant. I was asking where the dividing line should be? For example, should Mono's sockets class look more like Microsoft's or Java's? From stefan.arentz@soze.com Tue Jul 10 21:48:47 2001 From: stefan.arentz@soze.com (Stefan Arentz) Date: Tue, 10 Jul 2001 22:48:47 +0200 Subject: [Mono-list] binding In-Reply-To: <994793143.32741.13.camel@5of9.h.thestuff.net>; from bob@thestuff.net on Tue, Jul 10, 2001 at 01:25:33PM -0600 References: <994793143.32741.13.camel@5of9.h.thestuff.net> Message-ID: <20010710224847.A15076@keyser.soze.com> On Tue, Jul 10, 2001 at 01:25:33PM -0600, Bob Smith wrote: > I'm looking at implementing the Math class and I was wondering would it > be better to implement it from scratch in C#, or bind it to standard C > math functions. Each way is just as portable as the other, both I think > will be just about the same performance, the C binding requires less > work, and the C# way would probably be cleaner. What is the general > consensus about binding vs codeing when it comes to making use of > standard C libs? Compiled C code has dependencies to support libraries. Bytecode can be run immediately on any platform. If speed is a problem, it's probably possible to do both a bytecode and native version, and let the runtime decide which one to use? Stefan From stefan.arentz@soze.com Tue Jul 10 21:54:06 2001 From: stefan.arentz@soze.com (Stefan Arentz) Date: Tue, 10 Jul 2001 22:54:06 +0200 Subject: [Mono-list] Perplexed and intrigued by ECMA licensing of .Net In-Reply-To: ; from michaellambert@bellsouth.net on Tue, Jul 10, 2001 at 05:00:32PM -0400 References: <20010710212830.A14359@keyser.soze.com> Message-ID: <20010710225405.B15076@keyser.soze.com> > Sorry for the confusion. At some point the Mono implementation will diverge > from the MS one. Mono would be unable to support certain class libraries as > they are heavily reliant on Windows (DirectX, Windows GDI+, etc). This > means that some of Mono's class library structure would be different. I > imagine the hope is that the runtime, compilers, il etc.. would all be > compliant. I was asking where the dividing line should be? For example, > should Mono's sockets class look more like Microsoft's or Java's? Aren't objects like that part of the standard runtime that we are trying to duplicate? Stefan From saurik@saurik.com Tue Jul 10 21:59:37 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Tue, 10 Jul 2001 15:59:37 -0500 Subject: [Mono-list] Re: x86 JIT References: Message-ID: <006a01c10983$3bbf67d0$d1cd1d18@cruiser> Bob: Take a look at the bottom of the e-mail, it has "Original message:" there, below which is the original message. I've been having problems getting a few posts (they finally came in over the last 10 minutes all bunched together), so I couldn't reply to the original message and was working off the archives. I still haven't gotten this message yet, however (ok, correctly, it JUST came in as I am about to hit the send button on this message). Just in case, here, again, was the original message from John Zedlewski: Oh, sorry I forgot to put this in my last message. If you really are interested in focusing on Linux x86, rather than using a gcc backend, I would HIGHLY recommend a look at Intel's Open Research Platform (ORP) JIT for Java. It's clean, well-designed, and basically under an Apache-style license: http://www.intel.com/research/mrl/orp/. Very nice code, several different garbage collectors, etc. --JRZ Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "Bob Salita" To: Sent: Tuesday, July 10, 2001 3:49 PM Subject: Re: [Mono-list] Re: x86 JIT > Jay, > > >I totally agree with this. > > What is it that you totally agree with? Nothing from the original post is > quoted, nor can I find the original message. > > Also this link to slashdot seems dead: > >- On Slashdot: http://slashdot.org/comments.plsid=01/07/05/205203&cid=217 > >on one of the Mono related articles. > > BTW, thanks for answering the FAQ questions that I submitted. Your learned > opinion has been awesome and valuable. You obviously spent considerable time > in composing answers. Your efforts are much appreciated! > > Bob. From Bob_Salita@SoftworksLtd.com Tue Jul 10 22:04:21 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Tue, 10 Jul 2001 16:04:21 -0500 Subject: [Mono-list] binding Message-ID: My instincts say C is the best choice. C libraries are mature, fast, portable, reusable, omnipresent. >I'm looking at implementing the Math class and I was wondering would it >be better to implement it from scratch in C#, or bind it to standard C >math functions. Each way is just as portable as the other, both I think >will be just about the same performance, the C binding requires less >work, and the C# way would probably be cleaner. What is the general >consensus about binding vs codeing when it comes to making use of >standard C libs? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From saurik@saurik.com Tue Jul 10 22:12:23 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Tue, 10 Jul 2001 16:12:23 -0500 Subject: [Mono-list] Re: x86 JIT References: Message-ID: <008d01c10985$04752150$d1cd1d18@cruiser> Bob: DOH, should have replied to this along with the last message, didn't notice the "link seems dead" part. Not really all that important, but in case you are interested (a phrase that is rapidly becoming my battle cry, hehe): I tried it myself, and yes, it gets a 404, but if I first go to my user profile and click the same link there it works. Oh well, you can go to the article at http://slashdot.org/article.pl?sid=01/07/05/205203 and then search for "work with Intel" on the page. If _that_ link doesn't work, you can go to the main slashdot page, search for ".net open source competition" with the search blank at the bottom and choose the article entitled ".NET has Open Source Competition". Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "Bob Salita" To: Sent: Tuesday, July 10, 2001 3:49 PM Subject: Re: [Mono-list] Re: x86 JIT ... > > Also this link to slashdot seems dead: > >- On Slashdot: http://slashdot.org/comments.plsid=01/07/05/205203&cid=217 > >on one of the Mono related articles. > ... > > Bob. From michaellambert@bellsouth.net Tue Jul 10 22:21:05 2001 From: michaellambert@bellsouth.net (Michael Lambert) Date: Tue, 10 Jul 2001 17:21:05 -0400 Subject: [Mono-list] RE: Mono-list digest, Vol 1 #6 - 20 msgs In-Reply-To: <200107102059.QAA22492@trna.ximian.com> Message-ID: > > From: Bob Smith > Subject: [Mono-list] binding > > I'm looking at implementing the Math class and I was wondering would it > be better to implement it from scratch in C#, or bind it to standard C > math functions. Each way is just as portable as the other, both I think > will be just about the same performance, the C binding requires less > work, and the C# way would probably be cleaner. What is the general > consensus about binding vs codeing when it comes to making use of > standard C libs? > > Bob > Bind it to standard C (My vote). Michael From lupus@ximian.com Tue Jul 10 22:14:47 2001 From: lupus@ximian.com (Paolo Molaro) Date: Tue, 10 Jul 2001 23:14:47 +0200 Subject: [Mono-list] binding In-Reply-To: <994793143.32741.13.camel@5of9.h.thestuff.net> References: <994793143.32741.13.camel@5of9.h.thestuff.net> Message-ID: <20010710231446.E19004@lettere.unipd.it> On 07/10/01 Bob Smith wrote: > I'm looking at implementing the Math class and I was wondering would it > be better to implement it from scratch in C#, or bind it to standard C > math functions. Each way is just as portable as the other, both I think > will be just about the same performance, the C binding requires less > work, and the C# way would probably be cleaner. What is the general > consensus about binding vs codeing when it comes to making use of > standard C libs? I think implementing them in C# right now would be better because it could help test the interpreter (it may be awhile before support for calling external libraries is added). There is always time for switching to the optimized version, IMHO. lupus -- ----------------------------------------------------------------- lupus@debian.org debian/rules lupus@ximian.com Monkeys do it better From jp@demonseed.net Tue Jul 10 22:29:42 2001 From: jp@demonseed.net (jason petrone) Date: Tue, 10 Jul 2001 17:29:42 -0400 Subject: [Mono-list] Re: x86 JIT In-Reply-To: <006a01c10983$3bbf67d0$d1cd1d18@cruiser>; from saurik@saurik.com on Tue, Jul 10, 2001 at 03:59:37PM -0500 References: <006a01c10983$3bbf67d0$d1cd1d18@cruiser> Message-ID: <20010710172942.B10708@demonseed.net> Also it might be worth examining GNU Lightning(http://www.gnu.org/software/lightning/) and the NJ Machine Code Toolkit(http://www.eecs.harvard.edu/~nr/toolkit/) jason From sebastien.lambla@6sens.com Wed Jul 11 07:25:05 2001 From: sebastien.lambla@6sens.com (Sebastien Lambla) Date: Tue, 10 Jul 2001 23:25:05 -0700 Subject: [Mono-list] binding In-Reply-To: <20010710224847.A15076@keyser.soze.com> Message-ID: I think we should concentrate on having all possible classes built on C#, mainly because when the library writing is complete, it will be easier to port a very small number of OS dependant classes to new platforms and have most of the classes running out of the box. On the other hand, on a per-os basis, it would be great to have optimized classes for a specific platform, but when and only when pure C# classes exists. What do you think? Sebastien Lambla -----Original Message----- From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]On Behalf Of Stefan Arentz Sent: mardi 10 juillet 2001 13:49 To: Bob Smith Cc: mono-list@ximian.com Subject: Re: [Mono-list] binding On Tue, Jul 10, 2001 at 01:25:33PM -0600, Bob Smith wrote: > I'm looking at implementing the Math class and I was wondering would it > be better to implement it from scratch in C#, or bind it to standard C > math functions. Each way is just as portable as the other, both I think > will be just about the same performance, the C binding requires less > work, and the C# way would probably be cleaner. What is the general > consensus about binding vs codeing when it comes to making use of > standard C libs? Compiled C code has dependencies to support libraries. Bytecode can be run immediately on any platform. If speed is a problem, it's probably possible to do both a bytecode and native version, and let the runtime decide which one to use? Stefan _______________________________________________ Mono-list maillist - Mono-list@ximian.com http://lists.ximian.com/mailman/listinfo/mono-list From stefan.arentz@soze.com Tue Jul 10 22:21:10 2001 From: stefan.arentz@soze.com (Stefan Arentz) Date: Tue, 10 Jul 2001 23:21:10 +0200 Subject: [Mono-list] RE: Mono-list digest, Vol 1 #6 - 20 msgs In-Reply-To: ; from michaellambert@bellsouth.net on Tue, Jul 10, 2001 at 05:21:05PM -0400 References: <200107102059.QAA22492@trna.ximian.com> Message-ID: <20010710232109.A15397@keyser.soze.com> On Tue, Jul 10, 2001 at 05:21:05PM -0400, Michael Lambert wrote: > > > > From: Bob Smith > > Subject: [Mono-list] binding > > > > I'm looking at implementing the Math class and I was wondering would it > > be better to implement it from scratch in C#, or bind it to standard C > > math functions. Each way is just as portable as the other, both I think > > will be just about the same performance, the C binding requires less > > work, and the C# way would probably be cleaner. What is the general > > consensus about binding vs codeing when it comes to making use of > > standard C libs? > > > > Bob > > > > Bind it to standard C (My vote). That defeats one of the great features of an interpreted (jit-compiled) system; portability. Stefan From zedlwski@Princeton.EDU Tue Jul 10 23:17:35 2001 From: zedlwski@Princeton.EDU (John Zedlewski) Date: Tue, 10 Jul 2001 18:17:35 -0400 Subject: [Mono-list] gcc front-end and portability In-Reply-To: <200107102059.QAA22487@trna.ximian.com> Message-ID: <000401c1098e$1f868480$1699b48c@cp102230a> >If you are saying forget JITting the code and just generate native code >from CIL, then it will probably work, but you lose runtime >verifiability, code mobility and all the other nice things that an >architecture neutral bytecode gives you. Tyson, Hmm... I don't see why you lose that by generating native code from CIL, if you do it on the client machine. You can verify and compile everything at install-time, no? That way we only incur the overhead of compiling once. I definitely agree, though, that the gcc backend will be too slow for Java-style JIT-ing, but I really don't see an advantage to the JIT model at all. Most of the new research JVMs have moved over to a 2-JIT model, where you have one super-fast, but non-optimizing compiler and another slower, optimizing one for frequently-used methods. IBM's Jalapeno (http://www.research.ibm.com/jalapeno/publication.html) does this, as does Intel's ORP (http://www.intel.com/research/mrl/orp/). It might be possible to use gcc for optimization, but a non-optimizing, custom compiler for fast compilation on a handful of popular platforms. I just want to emphasize that it's really, really, really, really hard to build a good, cross-platform optimizing JIT from scratch. In the 5-6 years that Java has been around, no open source or academic project has managed to do it (Sable, OpenJIT, and LaTTe are all machine-specific and they typically lose to the Sun, MS, and IBM JVMs by a factor of 2 in benchmarks). I really don't se a reason to believe that Mono-CLI will do better unless it starts from a strong foundation. But, hey, maybe I'm just too much of a cynic. --JRZ From bob@leary.csoft.net Tue Jul 10 23:23:07 2001 From: bob@leary.csoft.net (bob@leary.csoft.net) Date: Tue, 10 Jul 2001 18:23:07 -0400 (EDT) Subject: [Mono-list] binding In-Reply-To: <20010710224847.A15076@keyser.soze.com> Message-ID: Well, the standard C functions are portable enough to any C supporting platform (alot more platforms then C# at the moment) and the C standard math lib is alot better tested as well. So, it should be just as portable. The question is, Do we want the class libs we are writing to be able to run outside of mono, so that they run on Microsofts .NET (they already have those libs, so it seems alittle silly) and other .NETalikes? If we do, then we shouldnt bind anything and use pure C#. On Tue, 10 Jul 2001, Stefan Arentz wrote: > On Tue, Jul 10, 2001 at 01:25:33PM -0600, Bob Smith wrote: > > I'm looking at implementing the Math class and I was wondering would it > > be better to implement it from scratch in C#, or bind it to standard C > > math functions. Each way is just as portable as the other, both I think > > will be just about the same performance, the C binding requires less > > work, and the C# way would probably be cleaner. What is the general > > consensus about binding vs codeing when it comes to making use of > > standard C libs? > > Compiled C code has dependencies to support libraries. Bytecode can be > run immediately on any platform. > > If speed is a problem, it's probably possible to do both a bytecode > and native version, and let the runtime decide which one to use? > > Stefan > > From bob@leary.csoft.net Tue Jul 10 23:40:48 2001 From: bob@leary.csoft.net (bob@leary.csoft.net) Date: Tue, 10 Jul 2001 18:40:48 -0400 (EDT) Subject: [Mono-list] Enterence In-Reply-To: Message-ID: Is it planed to be able to call a C# method from standard C? I'm considering takeing a stab at a ASP.NET implementation once things start to get useable, and I'm wandering if that would be posible. Bob From eric.b.lemings@lmco.com Tue Jul 10 23:55:11 2001 From: eric.b.lemings@lmco.com (Eric Lemings) Date: Tue, 10 Jul 2001 16:55:11 -0600 Subject: [Mono-list] Features and advantages of .NET and Mono? Message-ID: <3B4B87CF.2BAFA1C0@lmco.com> Hello all, Please note, I'm not subscribed to this list so a carbon-copied reply would be appreciated. This whole .NET thing and the Mono project are so new that there are too many questions and not enough answers. The Mono FAQ danced around one that I have. What are the advantages and features of .NET that are so important to warrant the creation of the Mono project? Thanks, Eric. From michaellambert@bellsouth.net Wed Jul 11 00:01:09 2001 From: michaellambert@bellsouth.net (Michael Lambert) Date: Tue, 10 Jul 2001 19:01:09 -0400 Subject: [Mono-list] RE: Mono-list digest, Vol 1 #6 - 20 msgs In-Reply-To: <20010710232109.A15397@keyser.soze.com> Message-ID: > -----Original Message----- > From: Stefan Arentz [mailto:stefan.arentz@soze.com] > > > From: Bob Smith > > > Subject: [Mono-list] binding > > > > > > I'm looking at implementing the Math class and I was wondering would it > > > be better to implement it from scratch in C#, or bind it to standard C > > > math functions. Each way is just as portable as the other, both I think > > > will be just about the same performance, the C binding requires less > > > work, and the C# way would probably be cleaner. What is the general > > > consensus about binding vs codeing when it comes to making use of > > > standard C libs? > > > > > Bind it to standard C (My vote). > > That defeats one of the great features of an interpreted (jit-compiled) > system; portability. > Obviously, functions like System.Math.Min can be done in IL. Unfortunately, not everything will be. Take this example from .Net from System.Math .method public hidebysig static float64 Cos(float64 d) cil managed internalcall { } // end of method Math::Cos Now load up MSVCR70.DLL in the Dependency Walker and look at ordinal 61 (0x03D): _CIcos My vote was for the standard C libraries in this case. Feel free to post your alternative. Michael From miguel@ximian.com Tue Jul 10 23:51:13 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 18:51:13 -0400 Subject: [Mono-list] On porting to C# In-Reply-To: "Sam Ruby"'s message of "Mon, 9 Jul 2001 21:54:24 -0400" References: Message-ID: > The Microsoft implementation of PInvoke supports COM Interop. It would be > nice if the Mono implementation supported CORBA Interop and/or Java > Interop. The CORBA bits might be implemented without even using PInvoke though. From miguel@ximian.com Tue Jul 10 23:52:27 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 18:52:27 -0400 Subject: [Mono-list] ReplyTo in headers In-Reply-To: "Peter Drayton"'s message of "Mon, 9 Jul 2001 19:16:04 -0700" References: <002c01c108e6$50fad280$6ea6accf@razorsoft.com> Message-ID: > Could the list admin please set up the list so there's a Reply-To in the > header, pointing at mono-list@ximian.com? It's quite annoying to default > to emailing the poster directly, rather than the list at large. Thanks! The Reply-To header has a number of problems. Please read: http://www.unicom.com/pw/reply-to-harmful.html Miguel. From bob@thestuff.net Tue Jul 10 23:57:01 2001 From: bob@thestuff.net (Bob Smith) Date: Tue, 10 Jul 2001 18:57:01 -0400 (EDT) Subject: [Mono-list] Features and advantages of .NET and Mono? In-Reply-To: <3B4B87CF.2BAFA1C0@lmco.com> Message-ID: The one big one that got me hooked is the ability for any language to use code from any other language. This will stop the code duplication. EX: odbc for C/C++, jdbc for java, perls database api, python's db api, etc. This should greatly accelerate development times, especially on the Open Source front, since we wont have to reinvent the wheel for every single language we want to use. Write a class once, and use it everywhere. On Tue, 10 Jul 2001, Eric Lemings wrote: > Hello all, > > Please note, I'm not subscribed to this list so a carbon-copied reply > would be appreciated. > > This whole .NET thing and the Mono project are so new that there are too > many questions and not enough answers. The Mono FAQ danced around one > that I have. > > What are the advantages and features of .NET that are so important to > warrant the creation of the Mono project? > > Thanks, > Eric. > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > From miguel@ximian.com Tue Jul 10 23:53:43 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 18:53:43 -0400 Subject: [Mono-list] Inconsistent namespaces || I am really dumb In-Reply-To: "John Barnette"'s message of "Mon, 9 Jul 2001 20:23:49 -0600" References: Message-ID: > mcs/class/corlib/System.Collections/IDictionary.cs > contains: namespace MCS.System.Collections { ... } > > Is this an unintentional inconsistency, or am I missing something? This is a bug. Will fix it soon. From david@pipco.freeserve.co.uk Wed Jul 11 01:03:05 2001 From: david@pipco.freeserve.co.uk (David Gardner) Date: Wed, 11 Jul 2001 00:03:05 GMT Subject: [Mono-list] binding In-Reply-To: References: Message-ID: <20010711.30500@imaginarie.localdomain> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 7/11/01, 7:25:05 AM, "Sebastien Lambla" wrote regarding RE: [Mono-list] binding: > I think we should concentrate on having all possible classes built on C#, > mainly because when the library writing is complete, it will be easier to > port a very small number of OS dependant classes to new platforms and have > most of the classes running out of the box. > On the other hand, on a per-os basis, it would be great to have optimized > classes for a specific platform, but when and only when pure C# classes > exists. > What do you think? I would have thought a math class isn't that hard to write, so do both a C# version and a C-library version. It will give a good indication of how much performance is lost by the interpreter. Dave From bob@thestuff.net Wed Jul 11 00:00:23 2001 From: bob@thestuff.net (Bob Smith) Date: Tue, 10 Jul 2001 19:00:23 -0400 (EDT) Subject: [Mono-list] RE: Mono-list digest, Vol 1 #6 - 20 msgs In-Reply-To: Message-ID: I'm leaning towards doing it as a C binding as well. On a side note, anyone know where I can get VS.NET beta without paying Microsoft an arm and a leg for their MSDN subscription? On Tue, 10 Jul 2001, Michael Lambert wrote: > > > > -----Original Message----- > > From: Stefan Arentz [mailto:stefan.arentz@soze.com] > > > > From: Bob Smith > > > > Subject: [Mono-list] binding > > > > > > > > I'm looking at implementing the Math class and I was wondering would > it > > > > be better to implement it from scratch in C#, or bind it to standard C > > > > math functions. Each way is just as portable as the other, both I > think > > > > will be just about the same performance, the C binding requires less > > > > work, and the C# way would probably be cleaner. What is the general > > > > consensus about binding vs codeing when it comes to making use of > > > > standard C libs? > > > > > > > Bind it to standard C (My vote). > > > > That defeats one of the great features of an interpreted (jit-compiled) > > system; portability. > > > > Obviously, functions like System.Math.Min can be done in IL. Unfortunately, > not everything will be. Take this example from .Net from System.Math > > .method public hidebysig static float64 Cos(float64 d) cil managed > internalcall > { > } // end of method Math::Cos > > Now load up MSVCR70.DLL in the Dependency Walker and look at ordinal 61 > (0x03D): _CIcos > > My vote was for the standard C libraries in this case. Feel free to post > your alternative. > > Michael > > > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > From eric.b.lemings@lmco.com Wed Jul 11 00:05:55 2001 From: eric.b.lemings@lmco.com (Eric Lemings) Date: Tue, 10 Jul 2001 17:05:55 -0600 Subject: [Mono-list] Re: Features and advantages of .NET and Mono? References: <3B4B87CF.2BAFA1C0@lmco.com> Message-ID: <3B4B8A53.539404ED@lmco.com> More questions: What makes C# a better language than Java? (I'm not fluent in either one but they look virtually the same to me. Not to mention, neither one is an ISO standardized language and probably won't be for at least 5 years from now.) And how is .NET different from the CORBA platform? Does .NET overlap with CORBA or does it have an entirely different purpose? Thanks, Eric. From eric.b.lemings@lmco.com Wed Jul 11 00:05:50 2001 From: eric.b.lemings@lmco.com (Eric Lemings) Date: Tue, 10 Jul 2001 17:05:50 -0600 Subject: [Mono-list] Features and advantages of .NET and Mono? References: Message-ID: <3B4B8A4E.8EF5AC44@lmco.com> Bob Smith wrote: > The one big one that got me hooked is the ability for any language to use > code from any other language. This will stop the code duplication. EX: > odbc for C/C++, jdbc for java, perls database api, python's db api, etc. > This should greatly accelerate development times, especially on the Open > Source front, since we wont have to reinvent the wheel for every single > language we want to use. Write a class once, and use it everywhere. Isn't that the whole purpose of CORBA? Eric. From bob@thestuff.net Wed Jul 11 00:03:42 2001 From: bob@thestuff.net (Bob Smith) Date: Tue, 10 Jul 2001 19:03:42 -0400 (EDT) Subject: [Mono-list] Features and advantages of .NET and Mono? In-Reply-To: <3B4B8A4E.8EF5AC44@lmco.com> Message-ID: Yes, but CORBA falls down in that the languages are almost imposible to get inprocess, so there can be significant overhead involved. Plus, you have to deal with IDL and skels/stubs. Everything's automatic and inprocess with Mono. On Tue, 10 Jul 2001, Eric Lemings wrote: > Bob Smith wrote: > > > The one big one that got me hooked is the ability for any language to use > > code from any other language. This will stop the code duplication. EX: > > odbc for C/C++, jdbc for java, perls database api, python's db api, etc. > > This should greatly accelerate development times, especially on the Open > > Source front, since we wont have to reinvent the wheel for every single > > language we want to use. Write a class once, and use it everywhere. > > Isn't that the whole purpose of CORBA? > > Eric. > > > From miguel@ximian.com Wed Jul 11 00:00:15 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 19:00:15 -0400 Subject: [Mono-list] FAQ additions - resubmitted v2.0 In-Reply-To: Hajime Inoue's message of "Tue, 10 Jul 2001 00:00:28 -0600 (MDT)" References: Message-ID: > 6. What level of performance can be expected? What if Mono can't achieve > that level of performance? Q: How fast will be Mono? A: We can not predict the future, but a conservative estimate is that it would be at least `as fast as other JIT engines'. Now, wishfully thinking I hope that we will ship various JITs with Mono just like Microsoft has done. A fast JITer when maximum performance is not needed, but fast load times are important; And an optimizing JITer that would be slower at generating code but produce more optimal output. The CIL has some advantages over the Java byte code: it is really an intermediate representation and there are a number of restrictions on how you can emit CIL code that simplify creating better JIT engines. For example, on the CIL the stack is not really an abstraction available for the code generator to use at will: it is just a way of creating a postfix representation of the parsed tree. At any given call point or return point, the contents of the stack are expected to contain the same object types independently of how the instructions was reached. From bob@thestuff.net Wed Jul 11 00:05:33 2001 From: bob@thestuff.net (Bob Smith) Date: Tue, 10 Jul 2001 19:05:33 -0400 (EDT) Subject: [Mono-list] Re: Features and advantages of .NET and Mono? In-Reply-To: <3B4B8A53.539404ED@lmco.com> Message-ID: C# and Java as a language are about the same. The difference lies in the backend. C# will allow other languages to be easily combined with it. Java wont (ok, there are a few exceptions, but not neerly on the scale I'm talking about) On Tue, 10 Jul 2001, Eric Lemings wrote: > More questions: > > What makes C# a better language than Java? (I'm not fluent in either one > but they look virtually the same to me. Not to mention, neither one is an > ISO standardized language and probably won't be for at least 5 years from > now.) > > And how is .NET different from the CORBA platform? Does .NET overlap with > CORBA or does it have an entirely different purpose? > > Thanks, > Eric. > > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > From scott@stonecobra.com Wed Jul 11 00:05:13 2001 From: scott@stonecobra.com (Scott Sanders) Date: Tue, 10 Jul 2001 16:05:13 -0700 Subject: [Mono-list] RE: Mono-list digest, Vol 1 #6 - 20 msgs References: Message-ID: <008501c10994$c9f39c40$050e10ac@mobileum.com> > On a side note, anyone know where I can get VS.NET beta without paying > Microsoft an arm and a leg for their MSDN subscription? You can go to: http://msdn.microsoft.com/vstudio/nextgen/beta.asp and click on the CD or DVD orders, and then they only charge shipping ($15 or so). Note that the MSDN links are the first ones on the page, so make sure you look down the page. They are supposed to start shipping July 16. Scott Sanders From eric.b.lemings@lmco.com Wed Jul 11 00:12:47 2001 From: eric.b.lemings@lmco.com (Eric Lemings) Date: Tue, 10 Jul 2001 17:12:47 -0600 Subject: [Mono-list] Features and advantages of .NET and Mono? References: Message-ID: <3B4B8BEF.A765658A@lmco.com> Bob Smith wrote: > Yes, but CORBA falls down in that the languages are almost imposible to > get inprocess, so there can be significant overhead involved. Plus, you > have to deal with IDL and skels/stubs. Everything's automatic and > inprocess with Mono. I assume you're referring to CORBA v2. Does that apply to CORBA v3 also? Eric. From bob@thestuff.net Wed Jul 11 00:11:33 2001 From: bob@thestuff.net (Bob Smith) Date: Tue, 10 Jul 2001 19:11:33 -0400 (EDT) Subject: [Mono-list] RE: Mono-list digest, Vol 1 #6 - 20 msgs In-Reply-To: <008501c10994$c9f39c40$050e10ac@mobileum.com> Message-ID: Is there any way to direct download it? I have a dsl connection so I can download/burn if posible. On Tue, 10 Jul 2001, Scott Sanders wrote: > > On a side note, anyone know where I can get VS.NET beta without paying > > Microsoft an arm and a leg for their MSDN subscription? > > You can go to: http://msdn.microsoft.com/vstudio/nextgen/beta.asp and click > on the CD or DVD orders, and then they only charge shipping ($15 or so). > Note that the MSDN links are the first ones on the page, so make sure you > look down the page. > > They are supposed to start shipping July 16. > > Scott Sanders > > > From david@pipco.freeserve.co.uk Wed Jul 11 01:16:03 2001 From: david@pipco.freeserve.co.uk (David Gardner) Date: Wed, 11 Jul 2001 00:16:03 GMT Subject: [Mono-list] Organizational questions In-Reply-To: <20010710165904.41115.qmail@web14006.mail.yahoo.com> References: <20010710165904.41115.qmail@web14006.mail.yahoo.com> Message-ID: <20010711.160300@imaginarie.localdomain> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 7/10/01, 5:59:04 PM, Eric Harlow wrote regarding [Mono-list] Organizational questions: > Are you going to have a dedicated person to manage the > .NET framework project? Part-time or full-time - but > someone who's not doing a lot of development so they > can focus on moving the project along? > Is there going to be a site (more than the current > status pages) where we can see the status of various > items and find small bite-sized projects that are > available? (Which class libraries need writing, for > example.) > -Eric Hey... if there's a job on offer, I'm currently unemployed... :-) Dave From scott@stonecobra.com Wed Jul 11 00:13:19 2001 From: scott@stonecobra.com (Scott Sanders) Date: Tue, 10 Jul 2001 16:13:19 -0700 Subject: [Mono-list] RE: Mono-list digest, Vol 1 #6 - 20 msgs References: Message-ID: <00a301c10995$eb6f6dd0$050e10ac@mobileum.com> I am under the assumption that they are charging the money to disallow the downloading. I spent yesterday and today looking for a place to download, but only found the SDK available, or VS.NET available if you are an MSDN Universal Subscriber (which I am not :(). Scott > Is there any way to direct download it? I have a dsl connection so I can > download/burn if posible. > > On Tue, 10 Jul 2001, Scott Sanders wrote: > > > > On a side note, anyone know where I can get VS.NET beta without paying > > > Microsoft an arm and a leg for their MSDN subscription? > > > > You can go to: http://msdn.microsoft.com/vstudio/nextgen/beta.asp and click > > on the CD or DVD orders, and then they only charge shipping ($15 or so). > > Note that the MSDN links are the first ones on the page, so make sure you > > look down the page. > > > > They are supposed to start shipping July 16. > > > > Scott Sanders From miguel@ximian.com Wed Jul 11 00:14:33 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 19:14:33 -0400 Subject: [Mono-list] FAQ additions - resubmitted v2.0 In-Reply-To: "Bob Salita"'s message of "Mon, 09 Jul 2001 22:29:11 -0500" References: Message-ID: > 1. Why should we direct such considerable resources to such a marginal and > risky project? Aren't these precious resources better directed elsewhere? I belive that it is a better platform for building applications (my personal interest is creating better desktop applications, but others might want to build web services). Ximian has decided to invest resources on this particular project. And we would like to have others join us. Read the `Rationale' document for more information about our reasons. > 2. Can't MS thwart Mono by creating technical or intellectual property > roadblocks? Maybe. But it does not seem to be the case so far. > 3. Don't existing open source projects offer capabilities equivalent to > .Net? Can't we use them instead of mono? Yes. You are free to use those. We are interested in the CLI because it will allow us to create a common runtime for multiple languages to target, it makes multiple languages share a class library, threading engine and garbage collection system. We have been dealing with these issues for some time in the GNOME project, and we wanted to provide solutions to problems we see every day. The CLI and associated technologies do solve various problems we see for the future growth of Linux on the desktop. > 5. Why are RedHat, IBM and others refusing to directly support Mono with > funding and public commitments? What do they know but won't say? I can not speak for them. But you can always ask them. > 7. MS is releasing shared source on FreeBSD. Isn't it better to convert to > FreeBSD rather than fight the .Net battle? Isn't the gain in open vs. shared > source too small for such a major effort? Shared Source does not give the freedoms that Free Software/Open Source gives. Please read the gnu web site. > 8. Isn't Mono a foil in negotiating .Net licensing for Linux? Won't mono > project be dropped if .Net for Linux is licensed? If .NET for Linux is licensed under an Free Softwre/Open Source license, then we might as well just use that version. Until then, we are buliding this. > 9. Isn't Ximian already overburdened and under funded? How can you compete > with MS minions and billions? We can not compete alone. That is why this is a Free Software/Open Source effort. > 10. I thought Ximian redefined itself as a service provider, not a > developer? Didn't plan A already fail? It seems you know more about Ximian than I do. > 11. Is the real purpose of Mono to counterpunch MS? Read `Rationale'. This is not about punches, it is about improving the free software development platform. > 12. Isn't Mono important only because .Net will be popular? Different people have different motivations. That might be one. > 13. Is MS trying to bash Linux by offering .Net on BSD? Isn't it a divide > and conquer gambit? Is it really about licensing terms? I think they are trying to do divide and conquer. The licensing issue is irrelevant in my opinion. > 14. Do we really know if .Net achieves an acceptable performance > level? Go do some benchmarks, and come back to us. I will now just focus on technical questions. Miguel. From bob@thestuff.net Wed Jul 11 00:18:12 2001 From: bob@thestuff.net (Bob Smith) Date: Tue, 10 Jul 2001 19:18:12 -0400 (EDT) Subject: [Mono-list] RE: Mono-list digest, Vol 1 #6 - 20 msgs In-Reply-To: <00a301c10995$eb6f6dd0$050e10ac@mobileum.com> Message-ID: Ok. Thanks. On Tue, 10 Jul 2001, Scott Sanders wrote: > I am under the assumption that they are charging the money to disallow the > downloading. I spent yesterday and today looking for a place to download, > but only found the SDK available, or VS.NET available if you are an MSDN > Universal Subscriber (which I am not :(). > > Scott > > > > Is there any way to direct download it? I have a dsl connection so I can > > download/burn if posible. > > > > On Tue, 10 Jul 2001, Scott Sanders wrote: > > > > > > On a side note, anyone know where I can get VS.NET beta without paying > > > > Microsoft an arm and a leg for their MSDN subscription? > > > > > > You can go to: http://msdn.microsoft.com/vstudio/nextgen/beta.asp and > click > > > on the CD or DVD orders, and then they only charge shipping ($15 or so). > > > Note that the MSDN links are the first ones on the page, so make sure > you > > > look down the page. > > > > > > They are supposed to start shipping July 16. > > > > > > Scott Sanders > > > > From miguel@ximian.com Wed Jul 11 00:16:20 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 19:16:20 -0400 Subject: [Mono-list] Okay, so ya got me interested. In-Reply-To: Colin P McMillen's message of "Tue, 10 Jul 2001 00:52:49 -0500" References: <20010710005249.B24785@cicero.cs.umn.edu> Message-ID: > I can certainly do documentation, and "small duties in the project that > need to be addressed", and I'm interested in CORBA interoperability as well. > I'm guessing I'll need to be reading some docs and possibly buying a book > on C# before I get into any real coding though. > > Any ideas, anyone? Documenting existing classes and writing the sample code to use them seem like a great way of helping if you want to help with documentation. Miguel. From miguel@ximian.com Wed Jul 11 00:19:10 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 19:19:10 -0400 Subject: [Mono-list] System.Xml In-Reply-To: "Sam Ruby"'s message of "Tue, 10 Jul 2001 07:10:04 -0400" References: Message-ID: > 1) Instead of rewriting everything from Java to C# (JXTA was mentioned > previously, now Xalan/Xerces), why not write a Java2IL compiler once and be > done with it? I think we want sources to the implementation. A Java2IL might not have all the features we want: * Full compatibility with the .NET API. Properties, Attributes dropped We need that to be fully compatible with .NET * Inline documentation. Java2IL might be a useful toolkit addition for those who want to port code to the CIL platform, but for the .NET classes, I think that we might have to have our own implemetnation (if reusing/porting is what it takes, thats fine with me) > 2) It is not clear that the Apache License is GPL-compatible. That being > said, the current Apache license is a BSD license without the advertising > clause (see http://www.ximian.com/mono/faq.html, question 13). It would be compatible in this case. From miguel@ximian.com Wed Jul 11 00:21:57 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 19:21:57 -0400 Subject: [Mono-list] How to compile MCS In-Reply-To: "Sriram Rajamanuri"'s message of "Tue, 10 Jul 2001 14:58:44 +0530" References: <05f401c10922$b6e65150$e9fea0cc@noida.hcltech.com> Message-ID: > I am sorta newbie out here. I have downloaded the latest sources as well = > as the CVS snapshots .I wish to kno what r the executables so far as = > mcs, jay and mono are concerned. Its quite confusing goi thru all the = > directories and executing just the make files. > > I am quite new to the concept of .NET too The information on the Web site should describe this (www.go-mono.net/c-sharp.html). Basically: 1. On Linux: Type cd mcs/mcs make parser 2. On Windows (once you have generated the parser, copy it over, or use a shared SMB share) cd mcs/mcs make Miguel. From miguel@ximian.com Wed Jul 11 00:27:19 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 19:27:19 -0400 Subject: [Mono-list] Organizational questions In-Reply-To: Eric Harlow's message of "Tue, 10 Jul 2001 09:59:04 -0700 (PDT)" References: <20010710165904.41115.qmail@web14006.mail.yahoo.com> Message-ID: > Are you going to have a dedicated person to manage the > .NET framework project? Part-time or full-time - but > someone who's not doing a lot of development so they > can focus on moving the project along? I would love to have volunteers that make sure that things move along in various parts of the project. I am the manager for the Ximian team that will be working on Mono, so we will be maintaining at least a roadmap of the things we consider to be on the critical path and that we will be actively working on. Other areas (class libraries at this point, and more when we know more about those) should greatly benefit from a volunteer. > Is there going to be a site (more than the current > status pages) where we can see the status of various > items and find small bite-sized projects that are > available? (Which class libraries need writing, for > example.) We will be doing this. Paolo already has a script, but we need to start testing and building the libraries (they currently dont build) (since the script uses System.Reflection to track the status of our implementation) Other important tasks are for me to stop going to meetings (I am booked all week on talking to potential partners about Mono) and to get things on SourceForge this week. Miguel. From miguel@ximian.com Wed Jul 11 00:27:51 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 19:27:51 -0400 Subject: [Mono-list] Math class In-Reply-To: Bob Smith's message of "10 Jul 2001 11:18:53 -0600" References: <994785626.32741.7.camel@5of9.h.thestuff.net> Message-ID: > I'd like to do the Math class if no one is working on it. I suggest you start with a single class at a time and post your `request' ownership to the list From miguel@ximian.com Wed Jul 11 00:28:50 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 19:28:50 -0400 Subject: [Mono-list] I want to get in on this. In-Reply-To: Rodrigo Moya's message of "10 Jul 2001 20:31:18 +0200" References: <994790045.456.10.camel@5of9.h.thestuff.net> <994789884.25107.10.camel@zubiri> Message-ID: > there is already a project towards a VB interpreter: GNOME Basic at > http://www.gnome.org/projects/gb. I don't know the exact state of the > project, but it's being used in Gnumeric (I think), so it might be quite > advanced. > > I guess Mono support could be added to it. This interpreter is written in C. These days I tend to believe that System.Reflection.Emit is the best idea ever. So I would encourage people to like, use C# to write new languages. From miguel@ximian.com Wed Jul 11 00:47:44 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 19:47:44 -0400 Subject: [Mono-list] Gcc front-end? In-Reply-To: "John Zedlewski"'s message of "Tue, 10 Jul 2001 14:32:20 -0400" References: <000b01c1096e$a7afe6a0$1699b48c@cp102230a> Message-ID: (btw, I have updated the faq) > On the roadmap, it seems to imply that y'all are working on a > completely new "JIT" compiler for the CLI. I'm curious about why this > is a better plan than writing a Gcc front-end for CLI bytecode. Actually, the CIL lends itself to pretty good optimization. I have been reading some papers that Paolo pointed me to on JIT code generation and it not only looks like a lot of fun, but I also feel more confident that we can outperform JITs like Kaffe. > As soon > as a Linux x86 "JIT" comes out, somebody's going to complain about the > lack of optimizations, somebody else will bitch about not having a Linux > Alpha port, and ten more users will want ports to Solaris and IA-64. Well, that is not only an extremely fun task (I would love to do them all myself, but it might not be in our time line), but this is precisely where Open Source development shines: ports ;-) > At least, that's been my experience with OSS projects in the past ;) > Some old posts from the Mercury folks implied that they were able to > do the Mercury->gcc interface in under 8,000 LOC. I would love if someone wants to write a C#->gcc front-end and a CIL backend to GCC. Ximian on the other hand is taking the easy road: nice and simple C# compiler, and JIT engine. If I had more resources at my disposal, I would look into more projects. But I want to focus on a concrete and deliverable set of tools. > Also, am I correct in believing that CLI is designed for more of an > Ahead-Of-Time compiler with local caching of native code? That's what > all the MS marketing-speak seemed to imply (no interepreter or > mixed-mode). You can do either one of them. Miguel. From Bob_Salita@SoftworksLtd.com Wed Jul 11 00:51:26 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Tue, 10 Jul 2001 18:51:26 -0500 Subject: [Mono-list] Novel Proposal for Mono Compiler Implementations Message-ID: Novel may be too strong a word but certainly a shift in thinking about compiler implementation is accurate. I propose a different kind of compiler design for Mono. One that gives significantly more utility to the compiler, and a compelling distinction between Mono and Microsoft's compiler implementations. One that is ideally suited to the open source philosophy. State of the Art Having spent quite a few years thinking about compilers and virtual machine technology, it occurred to me that our view of compilers is obsolete. Current compilers read source code and emit machine code, or bytecodes. This is the traditional monolithic approach. The Problem When new execution environments are invented, such as in .Net, Java VM or AMD's SledgeHammer, monolithic compilers are difficult to adapt. This is because the compiler's emitter has a fixed target, either IL or bytecodes or native code. This is too inflexible. The Solution Instead, compilers should NOT emit IL, bytecodes, or even native code. They should emit NOTHING. Their task is to merely translate source code into information rich parsetrees. Once the parsetrees are built, the compiler's work is done. Next a user selectable emitter traverses the parsetrees (sort of like traversing XML DOM structures). The emitter outputs any of a multitude of targets. The targets could be IL, bytecodes, native code, XML, obfuscated code, lint messages, documentation, or even other languages (e.g. VB6 compiler builds a parsetree, emitter outputs C#). The benefits are obvious. Combinations of compiler and emitters still produce traditional code. Nothing changes there. The compiler becomes much simpler to write and the emitters are even simpler. First year programmers will be able to write emitters that effectively generate code for whole new architectures. Emitter technology would be highly reusable between disparate compiler implementations or languages. Call it Open Compiler Technology. Contrast this solution to our current discussions about the vexing problem of adapting gcc to .Net. Or the discussions about how to take existing useful Java applications and them in Mono. Open Compiler Technology makes these discussions moot because the solution and implementation method are obvious. I propose that Open Compiler Technology be the architecture of compilers used in Mono, furthermore we should demand this style of compiler architecture from all our compiler vendors. The benefits of an Open Compiler are unlike any that we have experienced. Bob. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From Imaginarie Wed Jul 11 02:02:15 2001 From: Imaginarie (Imaginarie) Date: Wed, 11 Jul 2001 01:02:15 GMT Subject: [Mono-list] A 'use case' Message-ID: <20010711.1021500@imaginarie.localdomain> Here is a hypothetical situation that I thought up whilst trying to get a mental image of where Mono and .GNU (maybe portable.net too) might be used in the future. My imaginary company produces brochures and catalogues. In order to take advantage of some government scheme, we have a large number of stay-at-home mums in employment who do their work at home on a company-supplied computer, and communicate their work via the internet. For economic reasons we are using Linux 3.0 on Gnome 2.2 (including Evolution 0.436-pre27 beta 4) All the documents, both the source text given to us by companies and the documents we produce, are stored on a SAN and a Linux server at the head office. The employees work on these documents live via the internet, in particular two or more off-site employees can be working on the same document simultaneously, say a couple editing text, whilst one does layout and formatting and another does graphics. Now think about the following points, and consider which technologies (Mono, .gnu, bonobo, portable.net, etc.) have responsibility, and where the technologies need to communicate amongst themselves. * How do the workers authenticate? * How is the communication over the internet encrypted? * How will the software on the user's machine be kept up to date? * How is responsibility balanced between the user's machine and the server? * Where is the split in responsibility between mono and bonobo on the client? * How will the technologies manage the 'simultaneous editing' scenario? * How can the workers keep going when the network goes down? * Can you think of anything else? I thought that this particular situation could be a good model for both how these technologies could be utilised and what future working practices might be. Dave From miguel@ximian.com Wed Jul 11 00:55:54 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 19:55:54 -0400 Subject: [Mono-list] binding In-Reply-To: Bob Smith's message of "10 Jul 2001 13:25:33 -0600" References: <994793143.32741.13.camel@5of9.h.thestuff.net> Message-ID: > I'm looking at implementing the Math class and I was wondering would it > be better to implement it from scratch in C#, or bind it to standard C > math functions. Each way is just as portable as the other, both I think > will be just about the same performance, the C binding requires less > work, and the C# way would probably be cleaner. What is the general > consensus about binding vs codeing when it comes to making use of > standard C libs? I would just bind the existing C code if possible (for Decimal, you might need to link with the GNU Multi Precission library). From miguel@ximian.com Wed Jul 11 00:59:39 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 19:59:39 -0400 Subject: [Mono-list] RE: Mono-list digest, Vol 1 #6 - 20 msgs In-Reply-To: Stefan Arentz's message of "Tue, 10 Jul 2001 23:21:10 +0200" References: <200107102059.QAA22492@trna.ximian.com> <20010710232109.A15397@keyser.soze.com> Message-ID: > > Bind it to standard C (My vote). > > That defeats one of the great features of an interpreted (jit-compiled) > system; portability. Not really. And also, we will be doing a lot of binding, and there is no reason why we should just reimplement the math stuff when it is already there: tested, debugged, and functional. So using `PInvoke' to call functions in the standard math library is great, because it is a mechanism that we will support right from the start. From miguel@ximian.com Wed Jul 11 01:03:05 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 20:03:05 -0400 Subject: [Mono-list] gcc front-end and portability In-Reply-To: "John Zedlewski"'s message of "Tue, 10 Jul 2001 18:17:35 -0400" References: <000401c1098e$1f868480$1699b48c@cp102230a> Message-ID: > I just want to emphasize that it's really, really, really, really hard > to build a good, cross-platform optimizing JIT from scratch. In the 5-6 > years that Java has been around, no open source or academic project has > managed to do it (Sable, OpenJIT, and LaTTe are all machine-specific and > they typically lose to the Sun, MS, and IBM JVMs by a factor of 2 in > benchmarks). I really don't se a reason to believe that Mono-CLI will do > better unless it starts from a strong foundation. But, hey, maybe I'm > just too much of a cynic. I have been doing some intense learning on the subject, and the differentce really is that to write a JIT for Java you have to either do some really good work on the bytecode analysis to prove that it will not do anything strange (which most small projects wont be able to do, hence them being slow) or you just to `macro expansion' of opcodes. The CIL is different from Java Byte Codes in that regard: there are various assumptions that can be made on the input stream that are just not possible to do with java (the state of the stack at invocation and return points, and the type safety of the stack) that come into play. Please read the links on the `Runtime' web page, I have updated them with some really interesting links from Paolo (great article on the guy who did LCC) From miguel@ximian.com Wed Jul 11 01:03:57 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 10 Jul 2001 20:03:57 -0400 Subject: [Mono-list] Enterence In-Reply-To: 's message of "Tue, 10 Jul 2001 18:40:48 -0400 (EDT)" References: Message-ID: > Is it planed to be able to call a C# method from standard C? I'm > considering takeing a stab at a ASP.NET implementation once things start > to get useable, and I'm wandering if that would be posible. It is something that the runtime has to provide for us (GNOME developers will need it). We need to define the object layout and ABI before. From david@pipco.freeserve.co.uk Wed Jul 11 02:15:36 2001 From: david@pipco.freeserve.co.uk (David Gardner) Date: Wed, 11 Jul 2001 01:15:36 GMT Subject: [Mono-list] Novel Proposal for Mono Compiler Implementations In-Reply-To: References: Message-ID: <20010711.1153600@imaginarie.localdomain> On 7/11/01, 12:51:26 AM, "Bob Salita" wrote regarding [Mono-list] Novel Proposal for Mono Compiler Implementations: > Instead, compilers should NOT emit IL, bytecodes, or even native code. They > should emit NOTHING. Sorry, but I spilt my tea everywhere at the thought of a compiler that emitted nothing but a sequence of NOP! > I propose that Open Compiler Technology be the architecture of compilers > used in Mono, furthermore we should demand this style of compiler > architecture from all our compiler vendors. The benefits of an Open Compiler > are unlike any that we have experienced. I like this idea. Maybe it's slightly too radical, but the best ideas are. Would you envisage that it would be faster to write a compiler according to the 'parsetree + emitter' scheme as opposed to the 'monolith' scheme? It's worth further discussion. Dave From jbarn@httcb.net Wed Jul 11 01:25:08 2001 From: jbarn@httcb.net (John Barnette) Date: Tue, 10 Jul 2001 18:25:08 -0600 Subject: [Mono-list] Novel Proposal for Mono Compiler Implementations In-Reply-To: <20010711.1153600@imaginarie.localdomain> Message-ID: > > Instead, compilers should NOT emit IL, bytecodes, or even native code. > They > > should emit NOTHING. > > I like this idea. Maybe it's slightly too radical, but the best ideas > are. Would you envisage that it would be faster to write a compiler > according to the 'parsetree + emitter' scheme as opposed to the > 'monolith' scheme? It's worth further discussion. Irrespective of development speed, it would certainly allow a much more clear separation of responsibilities and areas of interest. I, for one, detest writing parsers, but am quite interested in bytecode generation and language translation. This scheme would allow people like me to contribute in an undiminished fashion. ~ j. From flaub@dev.virtuoso.com Wed Jul 11 01:20:45 2001 From: flaub@dev.virtuoso.com (Frank Laub) Date: Tue, 10 Jul 2001 17:20:45 -0700 Subject: [Mono-list] Novel Proposal for Mono Compiler Implementations Message-ID: <405B970EDF7A804FBC97EAFBDAB2769D016BEA@MAIL.virtuoso.com> You know, I've thought about this very thing. I've specifically thought about what kind of emitters you could have. Here are some revalations I had when this is the sort of paradigm is used to develop software: - Source Control Currently, source control works (most commonly) by dealing with files. Imagine if code was never in a source format, but if it was always stored as a parsetree. An editor for that code would be much like a 'viewer' into that parsetree. Any language could be used to view someone else's work. (i.e. I write a class in VB, another developer modifies that class in C#, another developer debugs that code in a C++ flavor). Languages won't truly matter when it comes to implementing software. - Code Reviews I'm thinking that the above will make this process easier. - Non-Imperative Centric Views Instead of emitting code into IL or bytecodes or opcodes, how about emitting it as, say database recordsets (organizations can have true code repositories, not just shared files of source code), or say the output is some graphical representation. We're now coming closer to the idea of editing code visually, not just faking it by using tools that generate source code. The thing I keep thinking is this isn't really a major departure from current compiler technology, just an evolution of it. By seperating the phases of a compiler and keeping those pieces truly independent, all sorts of possiblities come out. AND, the biggest side-effect of this that I can see is, it makes writing a compiler easier. Monolithic software is a thing of the past, let's setup the tools (compilers) for which we build software to also be componentized (which is exactly why I'm so interested in .NET). I guess these ideas might be sort of out there, but can anyone else see where I'm headed? Frank -----Original Message----- From: Bob Salita [mailto:bsalita@hotmail.com] Sent: Tuesday, July 10, 2001 4:51 PM To: mono-list@ximian.com Subject: [Mono-list] Novel Proposal for Mono Compiler Implementations Novel may be too strong a word but certainly a shift in thinking about compiler implementation is accurate. I propose a different kind of compiler design for Mono. One that gives significantly more utility to the compiler, and a compelling distinction between Mono and Microsoft's compiler implementations. One that is ideally suited to the open source philosophy. State of the Art Having spent quite a few years thinking about compilers and virtual machine technology, it occurred to me that our view of compilers is obsolete. Current compilers read source code and emit machine code, or bytecodes. This is the traditional monolithic approach. The Problem When new execution environments are invented, such as in .Net, Java VM or AMD's SledgeHammer, monolithic compilers are difficult to adapt. This is because the compiler's emitter has a fixed target, either IL or bytecodes or native code. This is too inflexible. The Solution Instead, compilers should NOT emit IL, bytecodes, or even native code. They should emit NOTHING. Their task is to merely translate source code into information rich parsetrees. Once the parsetrees are built, the compiler's work is done. Next a user selectable emitter traverses the parsetrees (sort of like traversing XML DOM structures). The emitter outputs any of a multitude of targets. The targets could be IL, bytecodes, native code, XML, obfuscated code, lint messages, documentation, or even other languages (e.g. VB6 compiler builds a parsetree, emitter outputs C#). The benefits are obvious. Combinations of compiler and emitters still produce traditional code. Nothing changes there. The compiler becomes much simpler to write and the emitters are even simpler. First year programmers will be able to write emitters that effectively generate code for whole new architectures. Emitter technology would be highly reusable between disparate compiler implementations or languages. Call it Open Compiler Technology. Contrast this solution to our current discussions about the vexing problem of adapting gcc to .Net. Or the discussions about how to take existing useful Java applications and them in Mono. Open Compiler Technology makes these discussions moot because the solution and implementation method are obvious. I propose that Open Compiler Technology be the architecture of compilers used in Mono, furthermore we should demand this style of compiler architecture from all our compiler vendors. The benefits of an Open Compiler are unlike any that we have experienced. Bob. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com _______________________________________________ Mono-list maillist - Mono-list@ximian.com http://lists.ximian.com/mailman/listinfo/mono-list From wesley@felter.org Wed Jul 11 01:35:24 2001 From: wesley@felter.org (Wesley Felter) Date: Tue, 10 Jul 2001 19:35:24 -0500 (CDT) Subject: [Mono-list] Novel Proposal for Mono Compiler Implementations In-Reply-To: <20010711.1153600@imaginarie.localdomain> Message-ID: On Wed, 11 Jul 2001, David Gardner wrote: > are. Would you envisage that it would be faster to write a compiler > according to the 'parsetree + emitter' scheme as opposed to the > 'monolith' scheme? It's worth further discussion. That's how most compilers are already written. The difference is that the stages cannot be run separately, either to discourage proprietary tools (GCC) or to protect "trade secrets" (most proprietary compilers). SGI's Pro64 compiler stores an intermediate representation in .o files and the linker does the rest of the compilation so that it can do IPA. And speaking of interprocedural analysis, for those who are proposing install-time compilation: Should Mono compile each assembly separately? In that case you couldn't inline across assemblies, but a JIT could. Wesley Felter - wesley@felter.org - http://felter.org/wesley/ From jks6b@cs.virginia.edu Wed Jul 11 01:23:21 2001 From: jks6b@cs.virginia.edu (James Kevin Scott) Date: Tue, 10 Jul 2001 20:23:21 -0400 Subject: [Mono-list] A comment on published research and IP Message-ID: <200107110023.UAA20726@ares.cs.Virginia.EDU> I've noticed links to a few research publications on the Ximian mono web pages. Some of you may already be aware of this, but I think that it bears saying anyway. The fact that an algorithm or idea is published in a peer-reviewed scientific publication DOES NOT mean that the algorithm or idea is unencumbered by patents. The mono developers should be particularly careful when considering using ideas presented in research papers published by authors from industry. It is often the case that industrial research labs require researchers to file patent applications before they are allowed to disclose their ideas in scientific publications. Nowadays it is not that uncommon for university researchers to file for patents on their ideas before publishing them. This is not to say that you shouldn't incorporate ideas from the research community into mono. Just don't assume that those ideas are always going to be "free" for you to use. -Kevin -- Kevin Scott PhD Student, Dept. of Computer Science kscott@cs.virginia.edu University of Virginia http://www.cs.virginia.edu/~jks6b +1 804 982 2391 (work) From rweather@zip.com.au Wed Jul 11 02:39:05 2001 From: rweather@zip.com.au (Rhys Weatherley) Date: Wed, 11 Jul 2001 11:39:05 +1000 Subject: [Mono-list] Novel Proposal for Mono Compiler Implementations References: Message-ID: <3B4BAE39.6125F006@zip.com.au> Bob Salita wrote: > The Solution [....] Essentially, you want to create an UNCOL (Universal Compiler- Oriented Language). UNCOL's have been the holy grail of compiler research since the 1950's. They always flounder because at some point you have to introduce language-specific or emitter-specific behaviour to make the system work. Speaking from my own experience writing IL and JVM backend's for Portable.NET's C# compiler, it really isn't all that easy. The front-end has to pick a representation for the program's type system so that it has somewhere to put the information in the parse tree. But since IL and JVM differ in how they handle types in the engine, you have a problem: which type system do you use? IL's? JVM's? Something else? I eventually just said "to hell with it", and used the IL representation as-is with a converter for JVM. The point is that you have to make implementation choices very early in the process, but those choices destroy the UNCOL and all of its benefits immediately. Cheers, Rhys. Portable.NET: http://www.southern-storm.com.au/portable_net.html From saurik@saurik.com Wed Jul 11 02:37:33 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Tue, 10 Jul 2001 20:37:33 -0500 Subject: [Mono-list] Buying VS.NET (was: Mono-list digest, Vol 1 #6 - 20 msgs) References: <008501c10994$c9f39c40$050e10ac@mobileum.com> Message-ID: <00dc01c109aa$0f7a2d00$d1cd1d18@cruiser> To make the point, this isn't true. All of my orders have long shipped (and arrived, and have been installed). That was there from before they knew the dates and they never updated it. Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "Scott Sanders" To: "Bob Smith" ; "Michael Lambert" Cc: "Stefan Arentz" ; Sent: Tuesday, July 10, 2001 6:05 PM Subject: Re: [Mono-list] RE: Mono-list digest, Vol 1 #6 - 20 msgs ... > > They are supposed to start shipping July 16. > > Scott Sanders From zedlwski@Princeton.EDU Wed Jul 11 02:39:47 2001 From: zedlwski@Princeton.EDU (John Zedlewski) Date: Tue, 10 Jul 2001 21:39:47 -0400 Subject: [Mono-list] RE: Compilers emitting parsetrees In-Reply-To: <200107110021.UAA17364@trna.ximian.com> Message-ID: <000001c109aa$5e571460$1699b48c@cp102230a> Bob Salita mentioned the possibility of a "compiler" that simply emits a parse tree and leaves all the code generation to a separate process, so I thought I'd send over some links relative to that discussion. Modularization is, of course, very important in a compiler, but I think we shouldn't estimate the extent to which others have tried this. - GCC's internal tree representation is unwieldy, but it's also quite powerful. See: http://www.ncsa.uiuc.edu/~wendling/tree.html for a great introduction to the structures involved. The back-end technically runs in the same process as the front-end, but it does simply walk this tree and emit code. If you're looking for a human-readable form of this tree, try: http://sourceforge.net/projects/introspector/. - JavaML is also a nice, human-readable format. It works at a higher level, so it's much more easily readable by people. See: http://www.cs.washington.edu/homes/gjb/JavaML/ - SUIF is a compiler framework designed for really, really intense optimizations with total separation of front-end and back-end. It's incredibly comprehensive, and it includes a whole toolkit for writing new compiler passes. These passes aren't necessarily just a language front-end or processor back-end, they can fit into the middle and do crazy optimizations or transformations. Because it tries to be so comprehensive, though, SUIF gets really complicated. See: http://suif.stanford.edu/. - In the end, there's really not much difference between the "information rich parsetrees" and the IL itself. After all, nobody said back-ends needed to operate on trees, and the IL satisfied the criteria of being language-independent and platform independent. --JRZ From david@pipco.freeserve.co.uk Wed Jul 11 03:44:33 2001 From: david@pipco.freeserve.co.uk (David Gardner) Date: Wed, 11 Jul 2001 02:44:33 GMT Subject: [Mono-list] Novel Proposal for Mono Compiler Implementation In-Reply-To: <405B970EDF7A804FBC97EAFBDAB2769D016BEA@MAIL.virtuoso.com> References: <405B970EDF7A804FBC97EAFBDAB2769D016BEA@MAIL.virtuoso.com> Message-ID: <20010711.2443300@imaginarie.localdomain> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 7/11/01, 1:20:45 AM, "Frank Laub" wrote regarding RE: [Mono-list] Novel Proposal for Mono Compiler Implementation: > You know, I've thought about this very thing. I've specifically thought > about what kind of emitters you could have. Here are some revalations I > had when this is the sort of paradigm is used to develop software: > - Source Control > Currently, source control works (most commonly) by dealing with files. > Imagine if code was never in a source format, but if it was always > stored as a parsetree. An editor for that code would be much like a > 'viewer' into that parsetree. Any language could be used to view > someone else's work. (i.e. I write a class in VB, another developer > modifies that class in C#, another developer debugs that code in a C++ > flavor). Languages won't truly matter when it comes to implementing > software. Surely there has to be some reasonable limit to this. I can't quite imagine writing code in C++ and reading it in Prolog and LISP :) Also, how would you deal with preconditions/postconditions/invariants written in Eiffel? More generally, how do you deal with any feature in one language not present in another (eg single/multiple inheritance, early/late binding, contracts/no contracts, strongly/weakly typed, functional/imperative) > - Code Reviews > I'm thinking that the above will make this process easier. > - Non-Imperative Centric Views > Instead of emitting code into IL or bytecodes or opcodes, how about > emitting it as, say database recordsets (organizations can have true > code repositories, not just shared files of source code), or say the > output is some graphical representation. We're now coming closer to the > idea of editing code visually, not just faking it by using tools that > generate source code. Now the graphical view idea really does sound good. I've always wanted to use software components like electronic components, ie like drawing a schematic diagram. I would imagine it would be easier for a non-programmer to make a custom application using this schematic/graphic approach, rather than edit source code. > The thing I keep thinking is this isn't really a major departure from > current compiler technology, just an evolution of it. By seperating the > phases of a compiler and keeping those pieces truly independent, all > sorts of possiblities come out. AND, the biggest side-effect of this > that I can see is, it makes writing a compiler easier. Monolithic > software is a thing of the past, let's setup the tools (compilers) for > which we build software to also be componentized (which is exactly why > I'm so interested in .NET). I think it's an excellent idea to solve a problem by dividing it into two pieces, each less than half the size of the original problem! Dave From saurik@saurik.com Wed Jul 11 02:49:41 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Tue, 10 Jul 2001 20:49:41 -0500 Subject: [Mono-list] Novel Proposal for Mono Compiler Implementations References: <405B970EDF7A804FBC97EAFBDAB2769D016BEA@MAIL.virtuoso.com> Message-ID: <00f901c109ab$c1194180$d1cd1d18@cruiser> I do, and I've been working on it with my decompiler technology. For a while I thought what I wanted was to have an intermediate XML representation, but then I decided that it wasn't the best way to do it and are going back to an object tree representation. Many of these similar ideas have already been talked about on the DOTNET mailing list, both due to the work I was doing on my decompiler (which should support, still working on the core so C# only for now, multiple languages; will make sure to have a few ready for my talk at the end of this month when I release the next version). One of the end goals of my decompiler has always been a more powerful version of CodeDOM called ILEngineer. Once I had the intermediate representation that gets turned into source code, turning it into a compiled binary didn't seem that hard, so I finally decided on building just what you guys are talking about (*sigh*, I need to find something that no ones interested, maybe I should just buy a damned Mac and work on that, people keep forsaking Mac software so the competition comes later). I never really liked the idea of source control in multiple languages, however, as some things don't express well in some languages and you end up having to go through terrible hoops. Even some of the things you can do in VB.NET don't translate to C# without destroying information along the way to get back to the original version. Research I've been doing includes getting Java to decompile into the same intermediate representation, as well as working out better flow-graph analyzers (something which may be easier now that I have one of the larger decompiler venders willing to help me on the occasional sticky point). Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "Frank Laub" To: ; Sent: Tuesday, July 10, 2001 7:20 PM Subject: RE: [Mono-list] Novel Proposal for Mono Compiler Implementations > You know, I've thought about this very thing. I've specifically thought > about what kind of emitters you could have. Here are some revalations I > had when this is the sort of paradigm is used to develop software: > > - Source Control > Currently, source control works (most commonly) by dealing with files. > Imagine if code was never in a source format, but if it was always > stored as a parsetree. An editor for that code would be much like a > 'viewer' into that parsetree. Any language could be used to view > someone else's work. (i.e. I write a class in VB, another developer > modifies that class in C#, another developer debugs that code in a C++ > flavor). Languages won't truly matter when it comes to implementing > software. > - Code Reviews > I'm thinking that the above will make this process easier. > - Non-Imperative Centric Views > Instead of emitting code into IL or bytecodes or opcodes, how about > emitting it as, say database recordsets (organizations can have true > code repositories, not just shared files of source code), or say the > output is some graphical representation. We're now coming closer to the > idea of editing code visually, not just faking it by using tools that > generate source code. > > The thing I keep thinking is this isn't really a major departure from > current compiler technology, just an evolution of it. By seperating the > phases of a compiler and keeping those pieces truly independent, all > sorts of possiblities come out. AND, the biggest side-effect of this > that I can see is, it makes writing a compiler easier. Monolithic > software is a thing of the past, let's setup the tools (compilers) for > which we build software to also be componentized (which is exactly why > I'm so interested in .NET). > > I guess these ideas might be sort of out there, but can anyone else see > where I'm headed? > > Frank From saurik@saurik.com Wed Jul 11 03:00:53 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Tue, 10 Jul 2001 21:00:53 -0500 Subject: [Mono-list] Novel Proposal for Mono Compiler Implementations References: <405B970EDF7A804FBC97EAFBDAB2769D016BEA@MAIL.virtuoso.com> <00f901c109ab$c1194180$d1cd1d18@cruiser> Message-ID: <012201c109ad$51dacad0$d1cd1d18@cruiser> Doh, forgot to finish that sentence. ... both due to ... and due to the work of some guy in the UK who started a project called "meta code" which started a good discussion on it. Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "Jay Freeman (saurik)" To: "mono-list" Sent: Tuesday, July 10, 2001 8:49 PM Subject: Re: [Mono-list] Novel Proposal for Mono Compiler Implementations ... > > Many of these similar ideas have already been talked about on the DOTNET > mailing list, both due to the work I was doing on my decompiler (which > should support, still working on the core so C# only for now, multiple > languages; will make sure to have a few ready for my talk at the end of this > month when I release the next version). > ... > > Sincerely, > Jay Freeman (saurik) > saurik@saurik.com From pbaena@uol.com.ar Wed Jul 11 01:03:08 2001 From: pbaena@uol.com.ar (Pablo Baena) Date: Wed, 11 Jul 2001 00:03:08 +0000 Subject: [Mono-list] Don't forget the desktop Message-ID: <3B4B97BC.8090400@uol.com.ar> OK, although nobody answered my question about the future of Bonobo, I kept reading the list and I have an idea now. It seems good stuff indeed! I'm just afraid that this project will not leave enough resources for the desktop. I mentioned that I use Gnome from the very beginnings, and been following its development and see it mature, and it is in a good status right now, but it still needs improvement. It isn't usable as Kde 2.x is (I use Gnome 1.4x from debian unstable, maybe redhat's another story), and lacks documentation (I'm starting to program in gnome with C++ and it is really hard to find some information about it, and the API isn't so well documented as the plain C libraries). Esound doesn't work for me, but artsd does, and konqueror is very well integrated with everything. I'm not saying that gnome is worst than Kde, but it needs more work on it. Before anyone mentions it, yes, in the documentation side, being a beginner I think I can help in this field and I'll do it if time permits me. Also I'd love to be more experienced to help in the areas I think need improvement. I just wanted to share my opinion, I'll continue using Gnome in the future and keep learning to develop on it. Ximian has all my trust, I know that you are doing what is best. Just dont forget the desktop, all lusers like me will be grateful. Pablo From jason@injektilo.org Wed Jul 11 04:06:29 2001 From: jason@injektilo.org (Jason Diamond) Date: Tue, 10 Jul 2001 20:06:29 -0700 Subject: [Mono-list] XmlReader Implementation Message-ID: I hope nobody minds but I started working on an initial implementation of XmlTextReader. I have compilable skeletons for both XmlReader and XmlTextReader (along with the other classes and enumerations that they depend on in the System.Xml namespace) and have started implementing a private XmlTokenizer class to help with the parsing. I'd love to collaborate on this with anybody else who's interested. As soon as a CVS repository appears, I can check it in. Thanks, Jason Diamond http://injektilo.org/ From per@bothner.com Wed Jul 11 04:10:28 2001 From: per@bothner.com (Per Bothner) Date: 10 Jul 2001 20:10:28 -0700 Subject: [Mono-list] using lgpl in mono class libraries Message-ID: You may not realize that LGPL'd code is difficult or impossible to use for embedded systems, due to the requirement for being able to re-link the application. Therefore Cygnus has never shipped LGPL'd "target" libraries (code that gets linked with the application so it can run on the target). These libraries, which include libgcc, libstdc++, libgcj, and "newlib" (an ansi C library for embedded system) have used what we call the libgcc copyright, which is GPL with exception: As a special exception, if you link this library with other files to produce an executable, this library does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. Of course any code that depends on Gnome might as well be LGPL. However, you might want to consider a libgcc-style license for "core" (non-GUI) classes. But of course it is up to you. (Stallman has mixed feelings about both LGPL and the libgcc-license.) [I am not on the mono-list, so please cc me on any discussion.] -- --Per Bothner per@bothner.com http://www.bothner.com/per/ From Bob_Salita@SoftworksLtd.com Wed Jul 11 04:07:15 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Tue, 10 Jul 2001 22:07:15 -0500 Subject: [Mono-list] Novel Proposal for Mono Compiler Implementations Message-ID: >David Gardner wrote: >I like this idea. Maybe it's slightly too radical, but the best ideas are. >Would you envisage that it would be faster to write a compiler according to >the 'parsetree + emitter' scheme as opposed to the 'monolith' scheme? It's >worth further discussion. John Barnette is correct. One person project -- no significant time savings. With two or more coders it would be faster because some coders could work on the parser, others could work on emitters and that nasty run-time. The clear separation of tasks would encourage parallelism. The less complex design has all sorts of obvious advantages. Probably easier to debug. Probably easier to enhance. Oh, sorry about the tea. Wesley Felter: Some of your links are dead, can you refind them? Your information is much appreciated. Many compilers have a parser and emitter, only they are monolithic. I'm unaware of any compiler that (attempts to) meets the Open Compiler definition: * The compiler creates a publicly exposed parsetree. * The parsetree is designed to encourage new emitters. * The parsetree is rich with information to support many types of emitters. * The parsetree is designed for easy traversal. * The parsetree is designed for emitters written by non-compiler experts. * Emitters can easily be plugged in. * New emitters are not encumbered with IP restrictions. Frank Laub: Your ideas of possible emitters are dead on. I had not thought of those specific ones. Rhys: UNCOL is not the same animal as my proposal. In my proposal, the compiler is specific to a single language. One language compiler to many emitters. Also, UNCOL's don't follow the above definition. The parsetree is rich enough to emit either IL or Java bytecodes or anything else. >David Gardner wrote: >Surely there has to be some reasonable limit to this. I can't quite >imagine writing code in C++ and reading it in Prolog and LISP :) Yes. This would be quite constrained. In perspective, language translation would be a rarely used benefit of an Open Compiler, although potentially a hugely important one in some situations. Bob. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From marcins@zipworld.com.au Wed Jul 11 04:46:36 2001 From: marcins@zipworld.com.au (Marcin Szczepanski) Date: Wed, 11 Jul 2001 13:46:36 +1000 Subject: [Mono-list] System.Text.StringBuilder Message-ID: <000001c109bc$16a44310$ba4307ca@llama> I'm playing around with implementing the System.Text.StringBuilder class. I noticed someone is already working on String, so this will be useful once that is done. Regards, Marcin Szczepanski marcins@zipworld.com.au From david@pipco.freeserve.co.uk Wed Jul 11 04:50:16 2001 From: david@pipco.freeserve.co.uk (David Gardner) Date: Wed, 11 Jul 2001 03:50:16 GMT Subject: [Mono-list] How similar is Java to C#? Message-ID: <20010711.3501600@imaginarie.localdomain> My reason for asking is: if there is a good common core between the two then we could do the early stages in the shared subset, and hence be able to compile and test under gcc 3.0. This is important to me because all my computers are Microsoft-free, it would mean I could get involved earlier. Dave From marcins@zipworld.com.au Wed Jul 11 05:22:21 2001 From: marcins@zipworld.com.au (Marcin Szczepanski) Date: Wed, 11 Jul 2001 14:22:21 +1000 Subject: [Mono-list] Interpretation of the spec for StringBuilder.. Message-ID: <000101c109c1$1540f040$ba4307ca@llama> Already found something that's a bit weird and I've barely started! This is the description for the StringBuilder.Length property: If the specified length is less than the current length, the StringBuilder is truncated to the specified length. If the specified length is greater than the current length, the Capacity of the current instance is set to the specified length, padding its string value with spaces on the left. The first bit of this is fine, however the second seems a bit confusing. It's saying to put the padding on the left?! So if I have a string "foo" and I do Length = 6 then the string will be: " foo" and not "foo ", which would make more sense. What does everyone else think?? Actually, I'll try the MS implementation and see what it does... Okay, the MS implementation puts the padding on the right, ie. This code: [...] StringBuilder sb = new StringBuilder( "foo" ); Console.WriteLine( ">{0}<", sb.ToString() ); sb.Length = 6; Console.WriteLine( ">{0}<", sb.ToString() ); [...] Gives this result: >foo< >foo < Is this a case of LAMESPEC or am I just misreading the spec?? Either that or they just wrote left where they meant right :) Thanks for your time :) From miguel@ximian.com Wed Jul 11 07:02:20 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 11 Jul 2001 02:02:20 -0400 Subject: [Mono-list] Bonobo/Corba and mono In-Reply-To: Jeffrey Stedfast's message of "10 Jul 2001 13:43:18 -0400" References: <3B4AF853.5060107@manes.netverk.com.ar> <994786998.16166.9.camel@tazmanian-devil.helixcode.com> Message-ID: > Mono isn't a component system, so it won't be replacing Bonobo. Well, I wish it will ;-) At least we will provide hooks when running on Unix to talk to Bonobo. From trd@cs.mu.oz.au Wed Jul 11 07:27:34 2001 From: trd@cs.mu.oz.au (Tyson Dowd) Date: Wed, 11 Jul 2001 08:27:34 +0200 Subject: [Mono-list] gcc front-end and portability In-Reply-To: <000401c1098e$1f868480$1699b48c@cp102230a> Message-ID: <20010711082734.A392@cs.mu.oz.au> Ok, you've convinced me that for an installation time JIT, a GCC backend might not be a bad idea. I'm not 100% sure, but I don't think its a waste of time to investigate it anymore. On 10-Jul-2001, John Zedlewski wrote: > >If you are saying forget JITting the code and just generate native code > >from CIL, then it will probably work, but you lose runtime > >verifiability, code mobility and all the other nice things that an > >architecture neutral bytecode gives you. > > Tyson, > Hmm... I don't see why you lose that by generating native code from > CIL, if you do it on the client machine. You can verify and compile > everything at install-time, no? That way we only incur the overhead of > compiling once. I definitely agree, though, that the gcc backend will > be too slow for Java-style JIT-ing, but I really don't see an advantage > to the JIT model at all. > > Most of the new research JVMs have moved over to a 2-JIT model, where > you have one super-fast, but non-optimizing compiler and another slower, > optimizing one for frequently-used methods. IBM's Jalapeno > (http://www.research.ibm.com/jalapeno/publication.html) does this, as > does Intel's ORP (http://www.intel.com/research/mrl/orp/). It might be > possible to use gcc for optimization, but a non-optimizing, custom > compiler for fast compilation on a handful of popular platforms. > > I just want to emphasize that it's really, really, really, really hard > to build a good, cross-platform optimizing JIT from scratch. In the 5-6 > years that Java has been around, no open source or academic project has > managed to do it (Sable, OpenJIT, and LaTTe are all machine-specific and > they typically lose to the Sun, MS, and IBM JVMs by a factor of 2 in > benchmarks). I really don't se a reason to believe that Mono-CLI will do > better unless it starts from a strong foundation. But, hey, maybe I'm > just too much of a cynic. > > --JRZ > > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list From ravi@che.iitm.ac.in Wed Jul 11 07:47:35 2001 From: ravi@che.iitm.ac.in (Ravi Pratap M) Date: Wed, 11 Jul 2001 12:17:35 +0530 (IST) Subject: [Mono-list] I want to get in on this. In-Reply-To: <994789884.25107.10.camel@zubiri> Message-ID: Hello, On 10 Jul 2001, Rodrigo Moya wrote: > On 10 Jul 2001 12:33:55 -0600, Bob Smith wrote: > > I dont speak for everyone, but I'd love to see a vb compiler for mono. > > There is a tun of vb programmers/code out there that could be harnased > > for gnome programming if vb was available. You wouldnt need to know > > asembly to do it. The C# compiler is writen in C#. > > > there is already a project towards a VB interpreter: GNOME Basic at > http://www.gnome.org/projects/gb. I don't know the exact state of the > project, but it's being used in Gnumeric (I think), so it might be quite > advanced. Gb is precisely what you are looking for :-) The basic core is pretty robust and the parser should be complete with some more effort; it's the GUI parts which are rather embryonic at the moment and are tied to the corresponding GTK+ widgets. > I guess Mono support could be added to it. Indeed. Writing a VB.NET parser should be quite easy given the specs ;-) Regards, Ravi -- "If you're smart, you'll be humble. There always is somebody who hasn't read a book and knows twice as much as you do." -- David Duchovny in Readers' Digest Ravi Pratap M From ravi@che.iitm.ac.in Wed Jul 11 07:48:10 2001 From: ravi@che.iitm.ac.in (Ravi Pratap M) Date: Wed, 11 Jul 2001 12:18:10 +0530 (IST) Subject: [Mono-list] I want to get in on this. In-Reply-To: <994790915.32733.11.camel@5of9.h.thestuff.net> Message-ID: Hi Bob, On 10 Jul 2001, Bob Smith wrote: > it would be difficult to addapt to generate CLI code. I may be mistaken. > I'm curious about what the Gnome Basic GURU's have to say about Gnome > Basic for Mono. Well, currently it is only an interpreter but we believe that the code has been written in a manner which allows generation of CLI code not a monumental task. If it really is, and if warranted, we should be happy to help it become easier :-) But I guess what you really want is just the parser. Regards, Ravi -- "If you're smart, you'll be humble. There always is somebody who hasn't read a book and knows twice as much as you do." -- David Duchovny in Readers' Digest Ravi Pratap M From kamran@halcyonsoft.com Wed Jul 11 07:57:03 2001 From: kamran@halcyonsoft.com (Kamran Zafar) Date: Wed, 11 Jul 2001 11:57:03 +0500 Subject: [Mono-list] Which Language? Message-ID: <3B4BF8BF.B0ACEA65@halcyonsoft.com> Hi Sir, I wanna know that in which language you will be implementing the APIs of the .NET Framework SDK class libraries? (C/C++ , java or any other language). Regards, Kamran kamran@halcyonsoft.com From sebastien.lambla@6sens.com Wed Jul 11 09:25:07 2001 From: sebastien.lambla@6sens.com (sebastien.lambla@6sens.com) Date: Wed, 11 Jul 2001 10:25:07 +0200 Subject: [Mono-list] =?iso-8859-1?Q?RE=A0=3A_=5BMono-list=5D_using_lgpl_in_mono_class_libraries?= Message-ID: <6077DD9569DFBB458C86DAA89858FA5F59C4C3@BT1F6ESBEX05.bt1d2001.w2k.bouyguestelecom.fr> I fully agree with Per on that one. The reason for the mono project is to be able to run .net framework-based apps to run on linux systems without modification, isn't it ? Moreover, if the source code is linked to the .net Microsoft class, when does the Microsoft License and when does the LGPL license apply ? Would all software which "might" be able to run on the Mono classes be covered by the LGPL? Or only when the software is run on Linux? On the latter, it's the user responsability if the Mono framework is to run an application, not the developpers : you can't enforce a license model on all software devs. What do you think guys? Sebastien Lambla -------- Message d'Origine-------- De: Per Bothner Date: 11/07/2001 05:09:35 �: mono-list@ximian.com Cc: per@bothner.com Objet: [Mono-list] using lgpl in mono class libraries You may not realize that LGPL'd code is difficult or impossible to use for embedded systems, due to the requirement for being able to re-link the application. Therefore Cygnus has never shipped LGPL'd "target" libraries (code that gets linked with the application so it can run on the target). These libraries, which include libgcc, libstdc++, libgcj, and "newlib" (an ansi C library for embedded system) have used what we call the libgcc copyright, which is GPL with exception: As a special exception, if you link this library with other files to produce an executable, this library does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. Of course any code that depends on Gnome might as well be LGPL. However, you might want to consider a libgcc-style license for "core" (non-GUI) classes. But of course it is up to you. (Stallman has mixed feelings about both LGPL and the libgcc-license.) [I am not on the mono-list, so please cc me on any discussion.] -- --Per Bothner per@bothner.com http://www.bothner.com/per/ _______________________________________________ Mono-list maillist - Mono-list@ximian.com http://lists.ximian.com/mailman/listinfo/mono-list From monodeveloper@yahoo.com Wed Jul 11 09:37:24 2001 From: monodeveloper@yahoo.com (Mono Dev) Date: Wed, 11 Jul 2001 01:37:24 -0700 (PDT) Subject: [Mono-list] Has anybody been able to compile the code available on the site ? Message-ID: <20010711083724.53094.qmail@web14910.mail.yahoo.com> Hi: Has anybody been able to compile the code available on the site ? I am getting this strange 'Node' class not found problem. I will appreciate any inputs on this. Thanks MD. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From saurik@saurik.com Wed Jul 11 09:47:35 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Wed, 11 Jul 2001 03:47:35 -0500 Subject: [Mono-list] using lgpl in mono class libraries References: <6077DD9569DFBB458C86DAA89858FA5F59C4C3@BT1F6ESBEX05.bt1d2001.w2k.bouyguestelecom.fr> Message-ID: <021d01c109e6$228145f0$d1cd1d18@cruiser> I think I'm missing something fundamental here... LGPL is the "GNU Lesser General Public License". This is different than the GPL, and shouldn't have any nasty issues with linking. It was originally called the "GNU Library General Public License", but Stallman changed the name because he didn't want to encourage people to use it. Why is there any issue in using LGPL? Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: To: Sent: Wednesday, July 11, 2001 3:25 AM Subject: [Mono-list] RE : [Mono-list] using lgpl in mono class libraries > I fully agree with Per on that one. The reason for the mono project is > to be able to run .net framework-based apps to run on linux systems > without modification, isn't it ? > Moreover, if the source code is linked to the .net Microsoft class, when > does the Microsoft License and when does the LGPL license apply ? Would > all software which "might" be able to run on the Mono classes be covered > by the LGPL? Or only when the software is run on Linux? On the latter, > it's the user responsability if the Mono framework is to run an > application, not the developpers : you can't enforce a license model on > all software devs. > > What do you think guys? > > Sebastien Lambla From martin.coxall@itouch.co.uk Wed Jul 11 09:51:06 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Wed, 11 Jul 2001 09:51:06 +0100 Subject: [Mono-list] I want to get in on this. In-Reply-To: <994790045.456.10.camel@5of9.h.thestuff.net> References: <994790045.456.10.camel@5of9.h.thestuff.net> Message-ID: <01071109510601.01136@gypsumfantastic.uk.itouchnet.net> > I dont speak for everyone, but I'd love to see a vb compiler for mono. > There is a tun of vb programmers/code out there that could be harnased > for gnome programming if vb was available. You wouldnt need to know > asembly to do it. The C# compiler is writen in C#. Highly unlikely. VB is not .NET compatible. VB.NET is, however. It is also a *very* different language to VB. However, VB.NET isn't an open standard, so there is no scope there. --- Martin --- "Where laughing and smiling are not allowed" From sebastien.lambla@6sens.com Wed Jul 11 09:50:21 2001 From: sebastien.lambla@6sens.com (Sebastien Lambla) Date: Wed, 11 Jul 2001 10:50:21 +0200 Subject: [Mono-list] Bunch of thoughts Message-ID: Hello all, I have several thoughts about the Mono development: 1. Shouldn't we begin, for the classes, to define which classes NEED bindings on existing libs and which classes should be built on top of it, written in C# ? That would be a great step to begin the development of new classes in "pure" C#? 2. How about a policy on implementing binding to classes who could bind to linux or gnome libs ? Like : Always bind when available. Or Always write a pure C# version and THEN bind if you want. Or If and only if someone opened a tree in the CVS for a C# version, you can take over the binding version of the class. etc. 3. Is the mono project means running .net programs on top of Linux (and thus be able to run most .net programs on Linux if developed under windows seamlessly) or not? That should answer the question "should we prefer compatibility first and think about divergent classes later in a different namespace ?" and prohibit ideas about having two different set of classes, some of them not compatible. 4. Shouldn't we split the mailing list, one on the classes dev, one on the JIT/parsers ? 5. Licensing is definitely an issue for the reasons I mentioned in my "RE : [Mono-list] using lgpl in mono class libraries". Based on the answers, we should be able to develop the classes quite fast. As the mail title is talking about "thoughts", I wanted to let you know who I am and what I can do / want to do, in my group and in the mono project. I'm Sebastien Lambla, you already guessed it. I'm one of the early people involved in the peer2peer space. I'm the founder and current president of the gPulp Consortium, the first European peer2peer standard body (you could say kind of the W3C but for P2P). Enough about me. I, as an individual, would like to get involved in the Mono project, because I really think it would be a tremendous addition to the Linux system as a whole to get "native" support for the tools most people will be using in a not too far future. I am available to work as a dev for pure C# classes (don't know enough of the Linux system to do any bindings). I should add that C# libraries for the DIF protocol and the gPulp Protocol will be published in a few months, which would give a pure C# library to use peer 2 peer technologies in the .net framework. I think this message is already waaaaaaaaay too long. Have a nice day, Sebastien Lambla From martin.coxall@itouch.co.uk Wed Jul 11 09:54:06 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Wed, 11 Jul 2001 09:54:06 +0100 Subject: [Mono-list] I want to get in on this. In-Reply-To: <994795015.815.16.camel@zubiri> References: <994790915.32733.11.camel@5of9.h.thestuff.net> <994795015.815.16.camel@zubiri> Message-ID: <01071109540602.01136@gypsumfantastic.uk.itouchnet.net> > well, but I mean, the parser (and other stuff) from GNOME Basic can be > reused. That's what I meant. I doubt you could. GNOME Basic is a language designed to be 100% syntax-compatible with VB, which is .NET compatible. VB.NET is a very different language, rewritten from scratch. Similarly I suspect, we would have to rewrite a GB.MONO from scratch. --- Martin --- "Where laughing and smiling are not allowed" From martin.coxall@itouch.co.uk Wed Jul 11 09:58:53 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Wed, 11 Jul 2001 09:58:53 +0100 Subject: [Mono-list] RE: Mono-list digest, Vol 1 #6 - 20 msgs In-Reply-To: <20010710232109.A15397@keyser.soze.com> References: <200107102059.QAA22492@trna.ximian.com> <20010710232109.A15397@keyser.soze.com> Message-ID: <01071109585303.01136@gypsumfantastic.uk.itouchnet.net> > That defeats one of the great features of an interpreted (jit-compiled) > system; portability. No, because glibc is highly portable, so that's not a problem. --- Martin --- "Where laughing and smiling are not allowed" From martin.coxall@itouch.co.uk Wed Jul 11 09:47:48 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Wed, 11 Jul 2001 09:47:48 +0100 Subject: [Mono-list] Bonobo/Corba and mono In-Reply-To: <994786998.16166.9.camel@tazmanian-devil.helixcode.com> References: <3B4AF853.5060107@manes.netverk.com.ar> <994786998.16166.9.camel@tazmanian-devil.helixcode.com> Message-ID: <01071109474800.01136@gypsumfantastic.uk.itouchnet.net> > Mono isn't a component system, so it won't be replacing Bonobo. Are you sure? MS intends .NET to replace COM, so why shouldn't it replace Bonobo? It'd certainly be a lot more efficient. --- Martin --- "Where laughing and smiling are not allowed" From sebastien.lambla@6sens.com Wed Jul 11 10:11:35 2001 From: sebastien.lambla@6sens.com (Sebastien Lambla) Date: Wed, 11 Jul 2001 11:11:35 +0200 Subject: [Mono-list] License Addendum In-Reply-To: <01071109474800.01136@gypsumfantastic.uk.itouchnet.net> Message-ID: here are my worries about the LGPL license. If anyone can show me there's no problems, I'll be very happy to use the LGPL license for mono: ------ 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. ------ That means that a software running on top of mono should include in it's license a grant for the users of the application to be able to modify the application, reverse engineering it. That means that most closed-source programs which will run on top of the .net framework could "technically" run on top of mono, but won't "legally" ? ------ For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. ------ That means publishing the source code of the application and the compilers, right? My main problem with the LGPL license is that it only allow the application ran on top of mono not to be modified for distribution, but it seems to me it still requires to publish source code and such? Which will be a conflict for applications which weren't linked "specifically" to the mono library, but just built on top of the framework. Sebastien Lambla From martin.coxall@itouch.co.uk Wed Jul 11 10:31:00 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Wed, 11 Jul 2001 10:31:00 +0100 Subject: [Mono-list] Enterence In-Reply-To: References: Message-ID: <01071110310004.01136@gypsumfantastic.uk.itouchnet.net> > > Is it planed to be able to call a C# method from standard C? I'm > > considering takeing a stab at a ASP.NET implementation once things start > > to get useable, and I'm wandering if that would be posible. What would that involve? An apache mod_asp.NET to act as a bridge to the compiler/CLR? I'd like to take a stab at implementing the Web Forms classes if that were the case: I think that asp.NET is one of the best aspects of the .NET infrastructure, and if we can produce a great software libre implementation, all the better. --- Martin --- "Where laughing and smiling are not allowed" From saurik@saurik.com Wed Jul 11 10:46:30 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Wed, 11 Jul 2001 04:46:30 -0500 Subject: [Mono-list] License Addendum References: Message-ID: <023a01c109ee$5d3d00f0$d1cd1d18@cruiser> OUCH, I never noticed how that clause forced applications linked with LGPL binaries to still be freely redistributable (and in modified form to boot). I totally agree that there are some issues that need to be dealt with here. Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "Sebastien Lambla" To: Sent: Wednesday, July 11, 2001 4:11 AM Subject: [Mono-list] License Addendum > here are my worries about the LGPL license. If anyone can show me there's no > problems, I'll be very happy to use the LGPL license for mono: > > ------ > 6. As an exception to the Sections above, you may also combine or link a > "work that uses the Library" with the Library to produce a work containing > portions of the Library, and distribute that work under terms of your > choice, provided that the terms permit modification of the work for the > customer's own use and reverse engineering for debugging such modifications. > ------ > > That means that a software running on top of mono should include in it's > license a grant for the users of the application to be able to modify the > application, reverse engineering it. That means that most closed-source > programs which will run on top of the .net framework could "technically" run > on top of mono, but won't "legally" ? > > ------ > For an executable, the required form of the "work that uses the Library" > must include any data and utility programs needed for reproducing the > executable from it. > ------ > > That means publishing the source code of the application and the compilers, > right? > > > My main problem with the LGPL license is that it only allow the application > ran on top of mono not to be modified for distribution, but it seems to me > it still requires to publish source code and such? Which will be a conflict > for applications which weren't linked "specifically" to the mono library, > but just built on top of the framework. > > Sebastien Lambla From martin.coxall@itouch.co.uk Wed Jul 11 10:49:16 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Wed, 11 Jul 2001 10:49:16 +0100 Subject: [Mono-list] Bonobo/Corba and mono In-Reply-To: References: <3B4AF853.5060107@manes.netverk.com.ar> <994786998.16166.9.camel@tazmanian-devil.helixcode.com> Message-ID: <01071110491605.01136@gypsumfantastic.uk.itouchnet.net> > > Mono isn't a component system, so it won't be replacing Bonobo. > > Well, I wish it will ;-) > > At least we will provide hooks when running on Unix to talk to Bonobo. I guess we'll just rewrite the COM interop classes to be BONOBO interop? For that matter, why not have DCOP interop as well? Put aside all that KDE/GNOME bickering in the name of peace and harmony. I am sure that Trolltech could also reimplement System.Windows.Forms classes, so that people can choose whether they have Mono use GTK+ or QT. Oh, the harmony. --- Martin --- "Where laughing and smiling are not allowed" From mark.lord@ntlworld.com Wed Jul 11 10:57:50 2001 From: mark.lord@ntlworld.com (Mark Lord) Date: Wed, 11 Jul 2001 10:57:50 +0100 Subject: [Mono-list] BASIC, Compilers and Salutations Message-ID: <015301c109ef$f236dcc0$0100a8c0@red> This is a multi-part message in MIME format. ------=_NextPart_000_0150_01C109F8.53E12D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Firstly, hi all! I have a few comments and a couple of questions (in = that order), but I'll endeavour to keep it short. a) On the subject of Basic, GNOME Basic is a VBScript-a-like to emulate = the Visual Basic for Applications in Excel. VBScript is quite different = from the compiled VB implemented by Visual Basic 6, and that's been = changed quite substantially for VB.NET. I expect that portions of the = GB grammar could be used, but I would think it would be safer to produce = the rest of the code from scratch. b) On the subject of "a novel approach to compilers", I think it was = titled, am I wrong in thinking that System.CodeDom provides a rich = abstract syntax tree which could be the input to a common IL generator? = Looking through the .NET documentation from Visual Studio.NET Beta 2, = Microsoft provides an ICodeCompiler implementation for C# and for = VB.NET, which can produce code from a CodeDom. Is this not very close = to the novel approach? And finally, the questions... 1) I am an experienced C++ programmer, with good Java experience and a = good working knowledge of C#. I have written compilers, parsers and = bytecode interpreters, and I am an experienced x86 assembly language = programmer. What is the best place for me to get involved at this time? = I'm really interested in seeing an open source .NET implementation, and = want to help out in the best way I can. Is my best bet to just choose a = library and start coding? 2) I've not read Microsoft's license thoroughly enough; is it OK to = develop GPL/LGPL code within Visual Studio.NET? I'm thinking about the = recent Microsoft license that restricted the use of "viral license" = tools with their libraries. That's it, sorry about the length of the mail! Mark. ------=_NextPart_000_0150_01C109F8.53E12D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Firstly, hi all! I have a few = comments and a=20 couple of questions (in that order), but I'll endeavour to keep it=20 short.

a) On the subject of Basic, GNOME Basic = is a=20 VBScript-a-like to emulate the Visual Basic for Applications in = Excel. =20 VBScript is quite different from the compiled VB implemented by Visual = Basic 6,=20 and that's been changed quite substantially for VB.NET. I expect = that=20 portions of the GB grammar could be used, but I would think it would be = safer to=20 produce the rest of the code from scratch.

b) On the subject of "a novel approach = to=20 compilers", I think it was titled, am I wrong in thinking that = System.CodeDom=20 provides a rich abstract syntax tree which could be the input to a = common IL=20 generator? Looking through the .NET documentation from Visual = Studio.NET=20 Beta 2, Microsoft provides an ICodeCompiler implementation for C# and = for=20 VB.NET, which can produce code from a CodeDom. Is this not very = close to=20 the novel approach?

And finally, the = questions...

1) I am an experienced C++ programmer, with good Java = experience and a=20 good working knowledge of C#. I have written compilers, parsers = and=20 bytecode interpreters, and I am an experienced x86 assembly language=20 programmer. What is the best place for me to get involved at this=20 time? I'm really interested in seeing an open source .NET = implementation,=20 and want to help out in the best way I can. Is my best bet to just = choose=20 a library and start coding?

2) I've not read Microsoft's license thoroughly enough; is it OK to = develop=20 GPL/LGPL code within Visual Studio.NET? I'm thinking about the = recent=20 Microsoft license that restricted the use of "viral license" tools with = their=20 libraries.

That's it, sorry about the length of the mail!

Mark.

------=_NextPart_000_0150_01C109F8.53E12D10-- From ravi@che.iitm.ac.in Wed Jul 11 10:58:57 2001 From: ravi@che.iitm.ac.in (Ravi Pratap M) Date: Wed, 11 Jul 2001 15:28:57 +0530 (IST) Subject: [Mono-list] I want to get in on this. In-Reply-To: <01071109510601.01136@gypsumfantastic.uk.itouchnet.net> Message-ID: Hi Martin, On Wed, 11 Jul 2001, Martin Coxall wrote: > VB.NET is, however. It is also a *very* different language to VB. However, > VB.NET isn't an open standard, so there is no scope there. Well, there surely is extensive documentation on how VB.NET is different from VB 6.0. MS doesn't plan on leaving all the million VB developers just hanging, does it ? They need to be told how to port their apps ;-) Although it isn't an open standard really, I am pretty sure we can write a complete VB .NET parser :) It just takes effort which we surely will put in ! Regards, Ravi -- "If you're smart, you'll be humble. There always is somebody who hasn't read a book and knows twice as much as you do." -- David Duchovny in Readers' Digest Ravi Pratap M From martin.coxall@itouch.co.uk Wed Jul 11 11:02:04 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Wed, 11 Jul 2001 11:02:04 +0100 Subject: [Mono-list] I want to get in on this. In-Reply-To: References: Message-ID: <01071111020407.01136@gypsumfantastic.uk.itouchnet.net> > Well, there surely is extensive documentation on how VB.NET is > different from VB 6.0. MS doesn't plan on leaving all the million VB > developers just hanging, does it ? They need to be told how to port their > apps ;-) Visual Studio.NET ports it automagically the first time you open a VB6 proj. --- Martin --- "Where laughing and smiling are not allowed" From lupus@ximian.com Wed Jul 11 11:04:14 2001 From: lupus@ximian.com (Paolo Molaro) Date: Wed, 11 Jul 2001 12:04:14 +0200 Subject: [Mono-list] mini VM experiments Message-ID: <20010711120414.A5462@lettere.unipd.it> Miguel asked me to post this one here as well: some results from a prototype VM for CIL. This afternoon I was tired of working on the disassembler finding things not well or wrongly specified, so I started writing a virtual machine for IL to get a grasp on some possible implementation details. I used the recursive fibonacci code as used in the comparisons in http://www.bagley.org/~doug/shootout/bench/fibo/. =cut cut= public class Fib { public static int fib (int n) { if (n < 2) return 1; return fib(n-2)+fib(n-1); } public static int Main () { return fib(25); } } =cut cut= This was compiled with csc and run both in windows and on linux. Note that I hardcoded 25 because we don't have an implementation of the string class for the command line args... I implemented only the code to run this sample, with a couple of limitations: only integer arithmetrics and only one arg in methods (both of these problems are easily solved). No optimizations have been done, apart from a method lookup cache. Ok, now with the surprise: this implementation ran faster than the perl, rep and python implementations, but also faster than the same program executed in windows (bug report for the MS people, if they are listening: the program dumps core with fib(25) and possibly bigger values). Typical runs (fib(25)) in seconds: gcc 0.020 mono 0.330 rep 0.460 mswin 0.780 (used fib(20) run in a cygwin environment) perl 0.980 python 1.260 Some further notes: the mswin number is bad because it's slow to startup, other programs show it's considerably faster than a bare-bones interpreter (and with fib(25) it can be argued it's faster too, since it crashes pretty soon;-). Anyway the ratios with python/perl are mostly the same even with the nested loops program. Another interesting point: using GCC's computed goto feature doesn't result in any performace gain over a switch statement. lupus -- ----------------------------------------------------------------- lupus@debian.org debian/rules lupus@ximian.com Monkeys do it better From ravi@che.iitm.ac.in Wed Jul 11 11:02:31 2001 From: ravi@che.iitm.ac.in (Ravi Pratap M) Date: Wed, 11 Jul 2001 15:32:31 +0530 (IST) Subject: [Mono-list] I want to get in on this. In-Reply-To: <01071109540602.01136@gypsumfantastic.uk.itouchnet.net> Message-ID: Hi there, On Wed, 11 Jul 2001, Martin Coxall wrote: > different language, rewritten from scratch. Similarly I suspect, we would > have to rewrite a GB.MONO from scratch. I am not completely familiar in what ways VB.NET is so radically different from VB 6.0 but I am quite sure, as an author of gb, that the task is not as monumental as it seems :) Rewriting from scratch might be warranted but I wouldn't worry about it so much :-) Could somebody please point me to docs on VB.NET ? Time to start digging into it I guess. Regards, Ravi -- "If you're smart, you'll be humble. There always is somebody who hasn't read a book and knows twice as much as you do." -- David Duchovny in Readers' Digest Ravi Pratap M From Bob_Salita@SoftworksLtd.com Wed Jul 11 11:52:35 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Wed, 11 Jul 2001 05:52:35 -0500 Subject: [Mono-list] BASIC, Compilers and Salutations Message-ID: Mark, You've pushed me to look at CodeDOM. Thank you. From the brief look, I agree it forms the methods for encoding rich parsetrees and traversing. Looks like it could be used to form the implementation details of an Open Compiler. Although I doubt that was the original design goal. The importance is that it provides a standardized and documentated way of implementing the parsetrees. Bob. >Mark Lord wrote: >b) On the subject of "a novel approach to compilers", I think it was >titled, am I wrong in thinking that System.CodeDom provides a rich abstract >syntax tree which could be the input to a common IL generator? Looking >through the .NET documentation from Visual Studio.NET Beta 2, Microsoft >provides an ICodeCompiler implementation for C# and for VB.NET, which can >produce code from a CodeDom. Is this not very close to the novel approach? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From Bob_Salita@SoftworksLtd.com Wed Jul 11 12:07:44 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Wed, 11 Jul 2001 06:07:44 -0500 Subject: [Mono-list] I want to get in on this. Message-ID: Ravi, This links summarizes the differences between VB6 and VB.Net: http://www.mvps.org/vb/index.html?rants/dotnot.htm Please send me a pointer to a document that describes GB syntax. I want to compare GB with VB. I'm having trouble figuring out the technical details of the goals of the GB project. Bob. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From ravi@che.iitm.ac.in Wed Jul 11 12:27:27 2001 From: ravi@che.iitm.ac.in (Ravi Pratap M) Date: Wed, 11 Jul 2001 16:57:27 +0530 (IST) Subject: [Mono-list] I want to get in on this. In-Reply-To: <01071111020407.01136@gypsumfantastic.uk.itouchnet.net> Message-ID: Hi Martin, On Wed, 11 Jul 2001, Martin Coxall wrote: > Visual Studio.NET ports it automagically the first time you open a VB6 > proj. Well, in that case, would it be possible to study the project/source files to see how they have changed ? Or do we have to just wait for the release of some kind of book or authoritative reference ? I think being able to get a complete reference is necessary to build that parse. Regards, Ravi -- "If you're smart, you'll be humble. There always is somebody who hasn't read a book and knows twice as much as you do." -- David Duchovny in Readers' Digest Ravi Pratap M From ravi@che.iitm.ac.in Wed Jul 11 13:06:37 2001 From: ravi@che.iitm.ac.in (Ravi Pratap M) Date: Wed, 11 Jul 2001 17:36:37 +0530 (IST) Subject: [Mono-list] I want to get in on this. In-Reply-To: Message-ID: Hi Bob, On Wed, 11 Jul 2001, Bob Salita wrote: > http://www.mvps.org/vb/index.html?rants/dotnot.htm Thank, I'll look into it right away :-) > Please send me a pointer to a document that describes GB syntax. I want to > compare GB with VB. I'm having trouble figuring out the technical details of > the goals of the GB project. Unfortunately, there is no such document although I was planning to write one soon. Lemme explain what we're upto right now : GB is not yet a full parser, it will be soon. The goals of the GB project is to provide a 100% VB compatible interpreter for the GNOME platform. This means that there will be (are) no differences between the GB language spec and the VB 6.0 language spec :) Although we started off as a project to help gnumeric execute VBA macros, we have since expanded our goals to be a complete VB interpreter. Currently, we are focussing on writing a very solid core and that's why our parser is undergoing a lot of change to become as robust and as close to the VB core as possible. So, if you're interested in seeing the GB grammar file, you can find it in the CVS module 'gb' in gb/grammar.y. It is fairly clean and self explanatory so perhaps you'd like to take a look. I am quite sure that the goals of the GB project are rather flexible and lend themselves to help with the Mono project. Regards, Ravi -- "If you're smart, you'll be humble. There always is somebody who hasn't read a book and knows twice as much as you do." -- David Duchovny in Readers' Digest Ravi Pratap M From sebastien.lambla@6sens.com Wed Jul 11 13:15:30 2001 From: sebastien.lambla@6sens.com (Sebastien Lambla) Date: Wed, 11 Jul 2001 14:15:30 +0200 Subject: [Mono-list] BASIC, Compilers and Salutations Message-ID: Hi Mark, << 2) I've not read Microsoft's license thoroughly enough; is it OK to develop GPL/LGPL code within Visual Studio.NET? I'm thinking about the recent Microsoft license that restricted the use of "viral license" tools with their libraries.>> The main problem in writing components in GPL with any of the Microsoft libraries is that Microsoft is not willing to give source code access to its libraries. Writing a GPL component based on a microsoft library would automatically imply that these libraries are GPL'd, which obviously are not. As such, your component can't be GPL'd. For the OS included libraries, there's a special mention about not having to give the material (aka the source code), but if we respect the GPL logic, they are still to be covered by the GPL. For LGPL, the problem is quite the same, as there's still, as far as I understand it, a "requirement" for source code publishing of the linked modules. Claiming being GPL'd or LGPL'd and using MFCs or by extension the Microsoft Implementation of the .net framework seems not to be doable in a GPL or LGPL environment. Using the tool to create the code is another issue. You can freely use a tool to create an app as long as you don't link to non GPL software. Thus, you can develop a .net application under GPL only if you link to a GPL'd library and not to the microsoft one. Sebastien Lambla From sebastien.lambla@6sens.com Wed Jul 11 13:15:29 2001 From: sebastien.lambla@6sens.com (Sebastien Lambla) Date: Wed, 11 Jul 2001 14:15:29 +0200 Subject: [Mono-list] Bonobo/Corba and mono Message-ID: rewriting the COM interop classes? Why not simply having *another* namespace for BONOBO/Corba/Name-your-favorite-component-model-here and not implement the Microsoft namespace where the COM interop classes seems to be ? Sebastien Lambla -----Message d'origine----- De : mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]De la part de Martin Coxall Envoy� : mercredi 11 juillet 2001 11:49 � : Miguel de Icaza; Jeffrey Stedfast Cc : Pablo Baena; mono-list@ximian.com Objet : Re: [Mono-list] Bonobo/Corba and mono > > Mono isn't a component system, so it won't be replacing Bonobo. > > Well, I wish it will ;-) > > At least we will provide hooks when running on Unix to talk to Bonobo. I guess we'll just rewrite the COM interop classes to be BONOBO interop? For that matter, why not have DCOP interop as well? Put aside all that KDE/GNOME bickering in the name of peace and harmony. I am sure that Trolltech could also reimplement System.Windows.Forms classes, so that people can choose whether they have Mono use GTK+ or QT. Oh, the harmony. --- Martin --- "Where laughing and smiling are not allowed" _______________________________________________ Mono-list maillist - Mono-list@ximian.com http://lists.ximian.com/mailman/listinfo/mono-list From kunle.odutola@virgin.net Wed Jul 11 13:27:03 2001 From: kunle.odutola@virgin.net (Kunle Odutola) Date: Wed, 11 Jul 2001 13:27:03 +0100 Subject: [Mono-list] I want to get in on this. In-Reply-To: <01071109510601.01136@gypsumfantastic.uk.itouchnet.net> Message-ID: > -----Original Message----- > From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]On > Behalf Of Martin Coxall > Sent: 11 July 2001 09:51 > To: Bob Smith; Mike Labosh > Cc: mono-list@ximian.com > Subject: Re: [Mono-list] I want to get in on this. > > > > I dont speak for everyone, but I'd love to see a vb compiler for mono. > > There is a tun of vb programmers/code out there that could be harnased > > for gnome programming if vb was available. You wouldnt need to know > > asembly to do it. The C# compiler is writen in C#. > > Highly unlikely. VB is not .NET compatible. > > VB.NET is, however. It is also a *very* different language to VB. > However, > VB.NET isn't an open standard, so there is no scope there. This is incorrect. The VB.NET language is mostly compatible with VB6's dialect of the VB language. It is possible to produce a VB6.NET and a VB.NET compiler in fact although the vastly different platform API in VB6 might pose some serious problems. Kunle From martin.coxall@itouch.co.uk Wed Jul 11 13:13:03 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Wed, 11 Jul 2001 13:13:03 +0100 Subject: [Mono-list] Bonobo/Corba and mono In-Reply-To: References: Message-ID: <0107111313030H.01136@gypsumfantastic.uk.itouchnet.net> > rewriting the COM interop classes? Why not simply having *another* > namespace for BONOBO/Corba/Name-your-favorite-component-model-here and not > implement the Microsoft namespace where the COM interop classes seems to be > ? Oh, okay. I didn't realise that COM interop was in a Microsoft namespace. Still, if we want to provide a complete, free alternative on windows, sooner or later someone will have to write Mono COM-interop classes. --- Martin --- "Where laughing and smiling are not allowed" From john.backstrand@e-game.com Wed Jul 11 13:25:35 2001 From: john.backstrand@e-game.com (=?iso-8859-1?Q?John_B=E4ckstrand?=) Date: Wed, 11 Jul 2001 14:25:35 +0200 Subject: [Mono-list] BASIC, Compilers and Salutations Message-ID: <4397F7C260EFD311A0AA00508B6B8C3D9098DD@fileserver> how about crtdll.dll and msvcrt.dll? every .exe made with vc++ uses one of these. does this mean that its impossible to do gpl/lgpl work with MS vc++ ? > For LGPL, the problem is quite the same, as there's still, as far as I > understand it, a "requirement" for source code publishing of > the linked > modules. > > Claiming being GPL'd or LGPL'd and using MFCs or by extension > the Microsoft > Implementation of the .net framework seems not to be doable > in a GPL or LGPL > environment. > > Using the tool to create the code is another issue. You can > freely use a > tool to create an app as long as you don't link to non GPL > software. Thus, > you can develop a .net application under GPL only if you link > to a GPL'd > library and not to the microsoft one. John B�ckstrand john.backstrand@e-game.com Programmer, E-game AB http://www.e-game.com Phone (direct) +46 (0)8 429 70 92 From martin.coxall@itouch.co.uk Wed Jul 11 13:33:06 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Wed, 11 Jul 2001 13:33:06 +0100 Subject: [Mono-list] I want to get in on this. In-Reply-To: References: Message-ID: <0107111333060I.01136@gypsumfantastic.uk.itouchnet.net> > This is incorrect. The VB.NET language is mostly compatible with VB6's > dialect of the VB language. It is possible to produce a VB6.NET and a > VB.NET compiler in fact although the vastly different platform API in VB6 > might pose some serious problems. How can they be "mostly compatible" and have "vastly different APIs"? The may be syntactically similar (but by no means the same), but this is only superficial. VB.NET is an entirely new, different language. --- Martin --- "Where laughing and smiling are not allowed" From saurik@saurik.com Wed Jul 11 13:34:18 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Wed, 11 Jul 2001 07:34:18 -0500 Subject: [Mono-list] I want to get in on this. References: Message-ID: <028401c10a05$ce662740$d1cd1d18@cruiser> Ravi: Interesting... yacc... how are you dealing with collapsed Next structures using yacc (as it shouldn't be fundamentally capable of this)? For X = 1 To 10 For Y = 1 To 20 Next Y, X I have been looking into building a VB6 compiler for .NET for a while (as it would be quite useful for legacy code, seeing that the update wizard isn't able to convert all code, yet strange enough to throw into a bank of "arcane" compilers such as BrainFuck for a laugh, which I released a simple .NET compiler for last night), rooting through old compiler and parser mailing lists looking for people who have talked about this before. Some people mentioned you could mess with the trees before it goes into yacc, but the general concenses among the few people who worked for companies that have actually been proven to have accomplished this feat was that you should just go with something more powerful than bison/yacc (I believe someone mentioned that ANTLR's predicates might make it up to the task, but I might have remembered that incorreclty). Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "Ravi Pratap M" To: Cc: Sent: Wednesday, July 11, 2001 7:06 AM Subject: Re: [Mono-list] I want to get in on this. ... > > So, if you're interested in seeing the GB grammar file, you can > find it in the CVS module 'gb' in gb/grammar.y. It is fairly clean and > self explanatory so perhaps you'd like to take a look. > ... > > Regards, > > Ravi > ... > > Ravi Pratap M > From saurik@saurik.com Wed Jul 11 13:34:18 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Wed, 11 Jul 2001 07:34:18 -0500 Subject: [Mono-list] I want to get in on this. References: Message-ID: <028501c10a05$cff504a0$d1cd1d18@cruiser> Ravi: Interesting... yacc... how are you dealing with collapsed Next structures using yacc (as it shouldn't be fundamentally capable of this)? For X = 1 To 10 For Y = 1 To 20 Next Y, X I have been looking into building a VB6 compiler for .NET for a while (as it would be quite useful for legacy code, seeing that the update wizard isn't able to convert all code, yet strange enough to throw into a bank of "arcane" compilers such as BrainFuck for a laugh, which I released a simple .NET compiler for last night), rooting through old compiler and parser mailing lists looking for people who have talked about this before. Some people mentioned you could mess with the trees before it goes into yacc, but the general concenses among the few people who worked for companies that have actually been proven to have accomplished this feat was that you should just go with something more powerful than bison/yacc (I believe someone mentioned that ANTLR's predicates might make it up to the task, but I might have remembered that incorreclty). Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "Ravi Pratap M" To: Cc: Sent: Wednesday, July 11, 2001 7:06 AM Subject: Re: [Mono-list] I want to get in on this. ... > > So, if you're interested in seeing the GB grammar file, you can > find it in the CVS module 'gb' in gb/grammar.y. It is fairly clean and > self explanatory so perhaps you'd like to take a look. > ... > > Regards, > > Ravi > ... > > Ravi Pratap M > From sebastien.lambla@6sens.com Wed Jul 11 13:45:29 2001 From: sebastien.lambla@6sens.com (Sebastien Lambla) Date: Wed, 11 Jul 2001 14:45:29 +0200 Subject: [Mono-list] BASIC, Compilers and Salutations In-Reply-To: <4397F7C260EFD311A0AA00508B6B8C3D9098DD@fileserver> Message-ID: Section 5 of the LGPL: ----- A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License ----- That means that the "Library" would here be your software, and the "work that uses the library" the msvcrt.dll. So as far as I understand it, that means that, "in isolation", these dlls are not to be covered by the LGPL to be used. However: Section 6 of the LGPL: ----- For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable ----- So as long as you don't have the dlls in your software, you don't have to publish anything. What I don't get is if these components are to be LGPL'd. And for me the problem lies here. If you make the assumption that to link anything from an LGPL'd component must be an LGPL'd piece of code, then you definitly can't make GPL software with any Microsoft library or any commercial library. Moreover, that would mean that the simple fact of binding to GPL'd libraries on Linux from the mono framework would mean that it would have to be GPL'd. If I'm missing something here, can someone correct me please? Sebastien Lambla From kunle.odutola@virgin.net Wed Jul 11 14:00:48 2001 From: kunle.odutola@virgin.net (Kunle Odutola) Date: Wed, 11 Jul 2001 14:00:48 +0100 Subject: [Mono-list] I want to get in on this. In-Reply-To: <0107111333060I.01136@gypsumfantastic.uk.itouchnet.net> Message-ID: > -----Original Message----- > From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]On > Behalf Of Martin Coxall > Sent: 11 July 2001 13:33 > To: Kunle Odutola; mono-list@ximian.com > Subject: Re: [Mono-list] I want to get in on this. > > > > This is incorrect. The VB.NET language is mostly compatible with VB6's > > dialect of the VB language. It is possible to produce a VB6.NET and a > > VB.NET compiler in fact although the vastly different platform > API in VB6 > > might pose some serious problems. > > How can they be "mostly compatible" and have "vastly different APIs"? The syntax & semantics of both languages are "mostly compatible". One is an evolution of the other. The platform APIs are different. One was targetted at Win32, the other at the .NET platform. > The may be syntactically similar (but by no means the same), but > this is only > superficial. VB.NET is an entirely new, different language. Not at all. It is just the latest iteration of VB from MS. Kunle From saurik@saurik.com Wed Jul 11 14:02:36 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Wed, 11 Jul 2001 08:02:36 -0500 Subject: [Mono-list] BASIC, Compilers and Salutations References: Message-ID: <02ad01c10a09$c271dcf0$d1cd1d18@cruiser> Sebastien: I don't see where that is a good assumption, you (or was it someone else, forgot) showed last night that it needed to be open-source in some kind, but not neccessarily LGPL (then again, this doesn't help much, hehehe). Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "Sebastien Lambla" To: Sent: Wednesday, July 11, 2001 7:45 AM Subject: RE: [Mono-list] BASIC, Compilers and Salutations ... > problem lies here. If you make the assumption that to link anything from an > LGPL'd component must be an LGPL'd piece of code, then you definitly can't ... > > Sebastien Lambla From kmgreen2@ilstu.edu Wed Jul 11 14:05:42 2001 From: kmgreen2@ilstu.edu (kmgreen2@ilstu.edu) Date: Wed, 11 Jul 2001 08:05:42 -0500 (CDT) Subject: [Mono-list] installation - mono Message-ID: <529888774.994856742753.JavaMail.root@mail.ilstu.edu> hello, as a student i am very interested in the mono project. i just have a few questions. i am working off of a freeBSD box. i downloaded the three tar files from your web site. i am having a little trouble making the files. before you back-hand me and tell me to leave you alone, i was just wondering if you guys know of anywhere to get documentation on such a situation. i know documentation is sparse. i figured i would check with you guys before i spend a couple of hours figuring out for myself. i also haven't worked on any projects like this one before, but i am very interested in it. how can i contribute? thanks, kevin g. From saurik@saurik.com Wed Jul 11 14:09:48 2001 From: saurik@saurik.com (Jay Freeman (saurik)) Date: Wed, 11 Jul 2001 08:09:48 -0500 Subject: [Mono-list] Icky... no... evil... (was: BASIC, Compilers and Salutations) References: <4397F7C260EFD311A0AA00508B6B8C3D9098DD@fileserver> Message-ID: <02b201c10a0a$c3b2f300$d1cd1d18@cruiser> The more I think about it, the more I believe that this license was never designed to support interoperability. If you have GPL source code, and you want to run as even the remotest part of something that isn't GPL, you are simply not supposed to due to philosophical reasons. This means that GPL software for Windows shouldn't really exist, the philosophy here applying as "if you are writing free software, you shouldn't be writing it for non-free operating systems, you shouldn't encourage the non-freedom of it all". I had never really even thought about this issue before in its completeness. I've been reading over the GPL a few times, and I would say "yes, you can't do GPL work with MS VC++". The initial thing that hits me isn't even the runtimes dlls but that runtime code is placed in the actual binary whether you use the DLL form or not for purposes of initializing global variables. This is software in every sense of the word that MS has written and has even included a commercial "just for use when debugging" license to along with VC++, you can step through it and look at it. Everything I know about law has been learned from watching court dramatizations, so I'm no authority, but this is bugging the hell out of me. The problem ends up getting more basic, though. It isn't just crtdll.dll you need to worry about, it is kernel32.dll, and shell32.dll. It isn't just VC++, it's Windows itself. GPL software must link with DLLs and share a memory space with these DLLs that are a part of the OS no matter what compiler they were written using, at some point you get to the level of the OS. (BTW, I just read Sebastian's post, and he brings up this same line in his message for the LGPL, I'm going to leave my mention of it here, though, as I can't figure out a good way to edit out the duplicated information without erasing the above paragraph which I want to keep.) Now, this stence here is telling: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. Now, you could say that you didn't distribute them together. Until you distribute the work together, the GPL doesn't seem to apply to the pieces used. Using this route you simply can't give people easy installation programs. *sigh* This makes me glad I've started switching to BSD :-). Last night I took libyahoo, got it compiling on Windows, then built it together with a Managed C++ wrapper for easily accessing the Yahoo IM from C#. Released it to the DOTNET mailing list like 4 hours ago. I wonder if this means I'm going to have to take it down and stop offering it until I can reimplement it from scratch in an entirely separate project in C# under a modified BSD license... Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "John B�ckstrand" To: Sent: Wednesday, July 11, 2001 7:25 AM Subject: RE: [Mono-list] BASIC, Compilers and Salutations > how about crtdll.dll and msvcrt.dll? every .exe made with vc++ uses one of > these. > does this mean that its impossible to do gpl/lgpl work with MS vc++ ? From eric.b.lemings@lmco.com Wed Jul 11 14:32:47 2001 From: eric.b.lemings@lmco.com (Eric Lemings) Date: Wed, 11 Jul 2001 07:32:47 -0600 Subject: [Mono-list] Features and advantages of .NET and Mono? References: Message-ID: <3B4C557F.3590A85F@lmco.com> Bob Smith wrote: > Yes, but CORBA falls down in that the languages are almost imposible to > get inprocess, so there can be significant overhead involved. Plus, you > have to deal with IDL and skels/stubs. Everything's automatic and > inprocess with Mono. In that case, I think I'll stick with a ship that floats. Let me know if and when this bigger and better ship that's still on the drawing board is ready to sail. Eric. From Mike Labosh" Message-ID: > Well, there surely is extensive documentation on how VB.NET is > different from VB 6.0. MS doesn't plan on leaving all the million VB > developers just hanging, does it ? They need to be told how to port their > apps ;-) yes. and yes. :) Peace and happy computing, Mike Labosh, MCT, MCSD "Escriba coda ergo sum." -- vbSensei From sujal@sujal.net Wed Jul 11 14:38:29 2001 From: sujal@sujal.net (Sujal Shah) Date: Wed, 11 Jul 2001 09:38:29 -0400 Subject: [Mono-list] License Addendum References: <023a01c109ee$5d3d00f0$d1cd1d18@cruiser> Message-ID: <3B4C56D5.C6B5717E@sujal.net> "Jay Freeman (saurik)" wrote: > > OUCH, I never noticed how that clause forced applications linked with LGPL > binaries to still be freely redistributable (and in modified form to boot). > I totally agree that there are some issues that need to be dealt with here. > It doesn't. IANAL, and this isn't necessarily the appropriate forum, but all it says is that you can't restrict "modification of the work for the customer's own use and reverse engineering for debugging such modifications." Says nothing of redistributing the source at all. It says nothing about redistribution ("for the customer's own use"). I also believe section 6 talks about statically linking the library into the non-LGPLd work ("combine or link ... to produce a work containing portions"). If you use dynamic linking, the work that you distribute (the executable sans library code) should be ok. The second clause seems more problematic, but I seem to remember that is talking about an executable covered by the LGPL. need to go get context, though, and I can't do that right now. I haven't read the whole license in a while, so I may be mistaken (part of this, of course, hinges on the definition of "a work that uses the Library" which conspicuously appears in quotes all over the place. As I said, IANAL. :-) This has been covered in other venues (i.e. KDE and GNOME), and you can easily just email the FSF and get their opinion and intent. Sujal > Sincerely, > Jay Freeman (saurik) > saurik@saurik.com > > ----- Original Message ----- > From: "Sebastien Lambla" > To: > Sent: Wednesday, July 11, 2001 4:11 AM > Subject: [Mono-list] License Addendum > > > here are my worries about the LGPL license. If anyone can show me there's > no > > problems, I'll be very happy to use the LGPL license for mono: > > > > ------ > > 6. As an exception to the Sections above, you may also combine or link a > > "work that uses the Library" with the Library to produce a work containing > > portions of the Library, and distribute that work under terms of your > > choice, provided that the terms permit modification of the work for the > > customer's own use and reverse engineering for debugging such > modifications. > > ------ > > > > That means that a software running on top of mono should include in it's > > license a grant for the users of the application to be able to modify the > > application, reverse engineering it. That means that most closed-source > > programs which will run on top of the .net framework could "technically" > run > > on top of mono, but won't "legally" ? > > > > ------ > > For an executable, the required form of the "work that uses the Library" > > must include any data and utility programs needed for reproducing the > > executable from it. > > ------ > > > > That means publishing the source code of the application and the > compilers, > > right? > > > > > > My main problem with the LGPL license is that it only allow the > application > > ran on top of mono not to be modified for distribution, but it seems to me > > it still requires to publish source code and such? Which will be a > conflict > > for applications which weren't linked "specifically" to the mono library, > > but just built on top of the framework. > > > > Sebastien Lambla > > _______________________________________________ > Mono-list maillist - Mono-list@ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list -- ------ Sujal Shah ---- sujal@sujal.net http://www.sujal.net/ From sebastien.lambla@6sens.com Wed Jul 11 14:47:27 2001 From: sebastien.lambla@6sens.com (Sebastien Lambla) Date: Wed, 11 Jul 2001 15:47:27 +0200 Subject: [Mono-list] BASIC, Compilers and Salutations Message-ID: Jay, I did this assumption mainly because a faulty reasoning on my part where : LGPL component means all LGPL components, GPL means all GPL components. In fact it seems that the only limitation to linking to a GPL/LGPL component is to have a recognized free-software license (that's for linking libraries in the mono library) and enable close-source software to use the library. My opinion is that the code should definitely be open sourced, but should not require applications running on it to be open source, and should try to be compatible to the licenses models of the libraries we are to link to. Based on this, is there a way to have a license that can link to free-software (GPL and such) and that can be linked from non free-software without enforcing anything about source code ? I just think it seems to me LGPL seems quite restrictive for software linked to the mono library. Doesn't help much either, but hey, talking is the best way to go forward :-) Sebastien Lambla -----Message d'origine----- De : mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]De la part de Jay Freeman (saurik) Envoy� : mercredi 11 juillet 2001 15:03 � : mono-list@ximian.com Objet : Re: [Mono-list] BASIC, Compilers and Salutations Sebastien: I don't see where that is a good assumption, you (or was it someone else, forgot) showed last night that it needed to be open-source in some kind, but not neccessarily LGPL (then again, this doesn't help much, hehehe). Sincerely, Jay Freeman (saurik) saurik@saurik.com ----- Original Message ----- From: "Sebastien Lambla" To: Sent: Wednesday, July 11, 2001 7:45 AM Subject: RE: [Mono-list] BASIC, Compilers and Salutations ... > problem lies here. If you make the assumption that to link anything from an > LGPL'd component must be an LGPL'd piece of code, then you definitly can't ... > > Sebastien Lambla _______________________________________________ Mono-list maillist - Mono-list@ximian.com http://lists.ximian.com/mailman/listinfo/mono-list From martin.coxall@itouch.co.uk Wed Jul 11 14:22:49 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Wed, 11 Jul 2001 14:22:49 +0100 Subject: [Mono-list] Icky... no... evil... (was: BASIC, Compilers and Salutations) In-Reply-To: <02b201c10a0a$c3b2f300$d1cd1d18@cruiser> References: <4397F7C260EFD311A0AA00508B6B8C3D9098DD@fileserver> <02b201c10a0a$c3b2f300$d1cd1d18@cruiser> Message-ID: <0107111422490L.01136@gypsumfantastic.uk.itouchnet.net> > I've been reading over the GPL a few times, and I would say "yes, you can't > do GPL work with MS VC++". The initial thing that hits me isn't even the > runtimes dlls but that runtime code is placed in the actual binary whether > you use the DLL form or not for purposes of initializing global variables. > This is software in every sense of the word that MS has written and has > even included a commercial "just for use when debugging" license to along > with VC++, you can step through it and look at it. I know that RMS is familiar with the shortcomings of the current GPL, and plans to resolve these ambiguities in version 3. Perhaps now would be the time to seek clarification from him? --- Martin --- "Where laughing and smiling are not allowed" From Bob_Salita@SoftworksLtd.com Wed Jul 11 16:07:37 2001 From: Bob_Salita@SoftworksLtd.com (Bob Salita) Date: Wed, 11 Jul 2001 10:07:37 -0500 Subject: [Mono-list] I want to get in on this. Message-ID: We are talking about two different things. From a compiler writers point of view, the most difficult problems in writing a VB6 compiler must be recoded for VB.Net (typelib interface - considerable recoding), lots of new stuff must be added. Then there's all that testing stuff. Lots of work. I would guess converting a VB6 to VB.Net compiler is half again as much work as VB6 was. If Mono needs a GB.Net compiler, my advice is start from scratch today and in parallel with GB. From a VB programmers point of view, the current consensus is that it is so difficult to convert VB6 to VB.Net, it isn't worth the effort. So the majority of VB6 code will never move until MS makes the process a whole lot easier -- which may happen. The platform API's difference is just one of many differences and not necessary in the most difficult group since the implementation details are very well known. I consider VB6 and VB.Net the same language in name only. Regarding the use of a yacc-like parser for VB6, its quite problematic. So don't use one. Bob. > > > This is incorrect. The VB.NET language is mostly compatible with VB6's > > > dialect of the VB language. It is possible to produce a VB6.NET and a > > > VB.NET compiler in fact although the vastly different platform > > API in VB6 > > > might pose some serious problems. > > > > How can they be "mostly compatible" and have "vastly different APIs"? > >The syntax & semantics of both languages are "mostly compatible". One is an >evolution of the other. > >The platform APIs are different. One was targetted at Win32, the other at >the .NET platform. > > > The may be syntactically similar (but by no means the same), but > > this is only > > superficial. VB.NET is an entirely new, different language. > >Not at all. It is just the latest iteration of VB from MS. > >Kunle > > >_______________________________________________ >Mono-list maillist - Mono-list@ximian.com >http://lists.ximian.com/mailman/listinfo/mono-list _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From fjh@cs.mu.oz.au Wed Jul 11 16:15:21 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Thu, 12 Jul 2001 01:15:21 +1000 Subject: [Mono-list] About the System namespace In-Reply-To: References: <994779314.974.1.camel@anti-slavery> Message-ID: <20010712011521.A5936@hg.cs.mu.oz.au> On 10-Jul-2001, Sebastien Lambla wrote: > as far as I understand, some classes will be built on top of existing > components. For other classes completely written on top of C# and the > framework, wouldn't it be better to have them published in another namespace > on windows systems so as to provide an open source equivalent to the System > namespace, such as FreeSystem? Well, in theory it would be best to keep the namespace the same, and use a different assembly name. That way you won't need to edit your source code to switch between the open-source version and the mscorlib version, you just change the compilation options and recompile. This works because at the IL level, everything is actually qualified by an assembly name as well as a namespace name. E.g. "[mscorlib]System.Object". In practice some parts of the System namespace (e.g. System.Object) are actually part of the runtime and can't be replaced in a way that preserves their properties (e.g. System.Object being the root of the inheritence hierarchy). Those parts should be put in a separate assembly. -- 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 Wed Jul 11 16:25:07 2001 From: miguel@ximian.com (Miguel de Icaza) Date: 11 Jul 2001 11:25:07 -0400 Subject: [Mono-list] Bonobo/Corba and mono In-Reply-To: Martin Coxall's message of "Wed, 11 Jul 2001 10:49:16 +0100" References: <3B4AF853.5060107@manes.netverk.com.ar> <994786998.16166.9.camel@tazmanian-devil.helixcode.com> <01071110491605.01136@gypsumfantastic.uk.itouchnet.net> Message-ID: > > At least we will provide hooks when running on Unix to talk to Bonobo. > > I guess we'll just rewrite the COM interop classes to be BONOBO interop? COM requires support from the runtime engine. CORBA and Bonobo can be implemented without support from the runtime. > For that matter, why not have DCOP interop as well? Put aside all that > KDE/GNOME bickering in the name of peace and harmony. Same for DCOP. DCOP solves a *different* problem. DCOP is a messaging bus (which is worth having, but it is way down the line at this point) From caseyc@www.sarahandcasey.com Mon Jul 9 20:51:12 2001 From: caseyc@www.sarahandcasey.com (Casey Cady) Date: Mon, 9 Jul 2001 14:51:12 -0500 (CDT) Subject: [Mono-list] MSDN article on Garbage Collection in .Net Message-ID: Anyone interested in the basics of GC as it relates to the CLR might be interested in Microsoft's take on the subject. Check out http://msdn.microsoft.com/msdnmag/issues/1100/GCI/GCI.asp The article is in two parts, with the 2nd part getting into the interesting stuff like weak references and generational GC. Thanks Casey From fjh@cs.mu.oz.au Wed Jul 11 16:50:38 2001 From: fjh@cs.mu.oz.au (Fergus Henderson) Date: Thu, 12 Jul 2001 01:50:38 +1000 Subject: [Mono-list] GCC front-end? In-Reply-To: <000b01c1096e$a7afe6a0$1699b48c@cp102230a> References: <200107101817.OAA28032@trna.ximian.com> <000b01c1096e$a7afe6a0$1699b48c@cp102230a> Message-ID: <20010712015038.B5936@hg.cs.mu.oz.au> On 10-Jul-2001, John Zedlewski wrote: > On the roadmap, it seems to imply that y'all are working on a > completely new "JIT" compiler for the CLI. I'm curious about why this > is a better plan than writing a Gcc front-end for CLI bytecode. I've been seriously thinking about doing that for quite a while now; since long before Mono was announced. Technically I think it is a very good idea. The main drawback, from my perspective, is that doing so would increase the acceptance of .NET, which would be good for Microsoft, which would increase world-wide income inequity, and concentrate too much power in the hands of too few, and that would be bad. I remember when I first heard of C++; it was from Bell Labs, same place as C, and it had some nice technical improvements to C. But it was a new language, and it didn't have the same degree of vendor support that C had. Was it really worth writing code in this new language? I first became convinced that C++ would become popular when I heard that there was a GNU C++ implementation. The existence of a free software implementation can be quite important to people's decisions as to whether or not to adopt a particular piece of technology. > Some old posts from the Mercury folks implied that they were able to do the > Mercury->gcc interface in under 8,000 LOC. The GCC-specific parts were under 8,000 LOC. There's also about 15,000 LOC that accepts parse tree from the front-end (already type-checked, etc.) and converts it into a form which is closer to C. That 15,000 LOC is also used by other back-ends (C, Java, ...). A big part of the work in writing a GCC front-end for CLI bytecode is very similar to the work in writing a CLI decompiler. Once you've got something that is roughly C-like, the rest is pretty easy. -- 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 martin.coxall@itouch.co.uk Wed Jul 11 16:50:26 2001 From: martin.coxall@itouch.co.uk (Martin Coxall) Date: Wed, 11 Jul 2001 16:50:26 +0100 Subject: [Mono-list] Web Forms, Apache module mod_asp.net? In-Reply-To: References: <01071110310004.01136@gypsumfantastic.uk.itouchnet.net> Message-ID: <0107111650260T.01136@gypsumfantastic.uk.itouchnet.net> On Wednesday 11 July 2001 4:24 pm, Miguel de Icaza wrote: > > I'd like to take a stab at implementing the Web Forms classes if that > > were the case: I think that asp.NET is one of the best aspects of the > > .NET infrastructure, and if we can produce a great software libre > > implementation, all the better. > > You do not need the ADO stuff at all to begin working on Web Forms. > > Now, the question is whether this overlaps with Windows.Forms, if they > do, we need to make sure we can work without overlapping the code ;-) No, but what we will need is an apache module. I know nothing about apache modules, so best leave that to someone who does. I mean, I could beg someone on the apache project for assistance, but maybe you would have the greater clout in that respect, me currently having a sum greputation of zero. That module would have to look out for