[Mono-list] Update on tasks (a compromise solution?) & Java notes

[Jay Freeman (saurik)]

Obviously I can't speak for Rhys, but if it were me, I would find this a
terrible solution that would just make me lose even more interest in working
on the project than I already have from being snuffed in the first place.
"Yeah, our project needs to grow quickly, and needs to get more developers
on board now by having something that works, so we'll brand what you have
under the Mono banner and slowly replace it as we build technology we like
better."  Imagine if you were the person on the other side of the deal...
would you be that happy with this solution?


Also, I was going to keep this one under my hat, but due to recent comments
from Miguel stressing the need to start developing it, I'm going to come out
now and state that I started working on a Java compiler a week or two ago.
If people from Mono want to work on one, fine, go ahead (as I'm unlikely to
go out of my way to integrate with the Mono environment, although I doubt
that is much of an issue).  I already have mine producing assemblies that
contain shells of classes with the right inheritence hierarchy, and I have
part of my code generator written.  It is written in MC++ using a C# library
I got from Eric Smith on the .NET mailing list for using ANTLR (a powerful
parser that is recommended by the guy who founded most of our current ideas
behind parsing).  I am not using any unmanaged code (excepting a small stub
to marshal the command line arguments to the managed world and a few C++
namespaces with enums to make my life easier but they could be converted, it
would just look ugly), and it could be ported to C# at a later date if there
is ever a demand.  What I'm doing isn't a perfect fit, but you can't
correctly compile Java to .NET anyway (due to the differing methodologies on
permissions and entry points), so anything you do is a hack.

Due to my goals (which involve my original plans of unifying this with my
decompiler and having the stages defined very cleanly with an XML step or
two), this gives plenty of time for people to try to beat me to the punch by
modifying guavac.  However, unlike the metadata parsing library project that
people killed, I am happy to say that this project is one where even if I
release mine months after other people both release and are already using
theirs, I can still have a worthwhile application, and therefor will
continue developing it regardless.  As an added bonus, I will not be doing
any work on it for at least a week due to both my presenting at the
California Technology Forum and the need for me to write a parser for our
engine's 3D shader language in time for SIGGRAPH (I wish someone had told me
before, hehe, it was never a priority before).  I actually encourage other
people to work on this so I don't feel as bad if I hit some problem I can't
solve :-P (and then have a lot of time to go back to my favorite project,
nmap+V).


To people who go to do this:

To make the point, guavac doesn't look to be a good starting point.  About a
half year ago it was actually removed from Debian to be replaced by jikes.
The guy who maintained the RISC OS port of guavac no longer supports his
port, and is recommending jikes.  From what I can tell, the original point
of distribution is an FTP account off of yggdrasil, the latest version
having been released in 1998.  Not many bugs were filed against the version
Debian had, but most people are now confident that this is because no one
used it, not because it is one of those enduringly well written
applications.  The guy who does the Visual C++ port couldn't even contact
the original author and has just been hosting the unofficial patch from his
website.  Reading it's TODO listing (
ftp://ftp.yggdrasil.com/pub/dist/devel/compilers/guavac/TODO ) shows a
rather major problem in dependency analysis, although this was written in
1997 and may be out of date for guavac 1.2 (which I didn't bother expanding
and looking at).  It also seems to be Java 1.1 only.  I'd recommend looking
into some other compiler as your base if you take the modification route
even just due to the lack of support from its original developers.

Personally, in the case of the compiler, I see this as a case where too much
would have to be ripped out to make reusing the core that useful...
outputting unoptimized code isn't that difficult; it's all about having a
good parser as a base that deals with trees well and shuffling meta data
(which is dealt with very differently).  It isn't as if we are talking a
JIT, here, where building off of something else could have interesting
benefits; just find an existing parser and redo the compiler part using
Microsoft's emit API.

Sincerely,
Jay Freeman (saurik)
saurik@saurik.com

----- Original Message -----
From: "Robert Deviasse" <rdeviasse@hotmail.com>
To: <rweather@zip.com.au>; <miguel@ximian.com>
Cc: <mono-list@ximian.com>
Sent: Saturday, July 28, 2001 3:33 PM
Subject: [Mono-list] Update on tasks (a compromise solution?)


...
>
> If you put your time into defining good clean interfaces and you
> plan for change *every step of the way*, the foundation can be
> changed later with little or no impact on the higher layers.
>
> Perhaps there's a solution that's long term idealistic, but
> short term practical that Portable.Net, Mono and even SharpDevelop
> can agree to? I mention SharpDevelop because they need a parser,
> disassember, and debugger. Mono and Portable.Net will need to
> define classes for these same things.
>
> So, Miguel, could Rhys's work be temporarily used until all
> the foundations are in place?
>
...
>
> Is there any room for compromise between Portable.Net and Mono?
>
> I apologize for being longwinded again, but I honestly don't see
> why there's a conflict.
>
> Take care,
>      Robert