Lots of bugfixes in this development release for DotGNU Portable.NET 0.6.8.
DotGNU Portable.NET 0.6.8 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
if they would differentiate themselves from Mono by creating a really mature, quality set of bindings for QT. Either that, or they should build on the implementation of Swing that’s part of CLASSPATH and make it a standard part of DotGNU
Mike: They differentiate bu creating mature Sustem.Windows.Forms, which IMHO are better than just having another toolkit bindings (QT bindings also work well with dotgnu.)
P.S. Tell nb to update dotgnu.org! Good luck DotGNU developers, I hope i will once more develop some neat piece of code for it…
Eventhough libjit seems to working nicely , why isn’t it integrated into pnet yet ? . At least a Hello World capable JIT would have been nice !!!.
if they would differentiate themselves from Mono by creating a really mature, quality set of bindings for QT.
That’s already happening. There are two sets based on BINGE and Smoke. Hopefully the BINGE stuff will get migrated to KDE CVS real soon, then we can look and at both approaches.
Mike: They differentiate bu creating mature Sustem.Windows.Forms, which IMHO are better than just having another toolkit bindings (QT bindings also work well with dotgnu.)
I agree there. The DotGNU people are being inclusive in what they are trying to do.
libjit promises to become something really really useful, I’d like to see it integrated so that it could get stronger testing and development.
this project is a complete waste of time.
there is mono on .NET why reimplement the compiler
in c ?
this project is a complete waste of time.
there is mono on .NET why reimplement the compiler
in c ?
Yeah, why write something if someone’s already written something similar right?
Why bother with Linux since there’s already FreeBSD?
Why bother with gcj when linux already has a native port of the JDK?
Oh and by your logic, there should only be one airline, Ford and Chrysler should just pack it in now, and only McDonald’s should stay open to provides us with fast food, right?
If you don’t have anything nice to say, don’t say anything at all. This project is obviously not a waste of time as it is already superior to Mono in some ways and inferior in others. They are different projects with different strenghts and weaknesses.
this project is a complete waste of time.
there is mono on .NET why reimplement the compiler
in c ?
That’s like saying the mono project is a complete waste of time.
PNET runs on more platforms than mono (it even runs on SkyOS). PNET’s compiler compiles more than just C#. It is a well designed compiler with both input and output plugins. I can compile various languages (include C) into IL or Java bytecode. FYI, Microsoft’s C# compiler is written in C(++).
Download the source to PNET, compare with code from mono and notice the stark difference in quality.
but i’ve heard that the pnet compiler doen’t do a
compatible assembly.
is it true ?
Erik, if you mean the assembly version used for IL binaries, then you have heard wrong.
Portable .NET supports different profiles, so you can compile your program with different assembly versions recorded in the IL file.
E.g. it has a profile called “default1.1”, “default1.2” etc.
And if you use default1.1 your assemblies will also work with Microsoft .NET 1.x (and probably 2.x, I don’t know to be honest). If you use 2.x with pnet, they will only work with 2.x of MS .NET since Microsoft’s .NET only runs assemblies that have an equal or lower version than the framework.
PS: pnet’s runtime engine will try to run everything as good as it can, so you probably can run something compiled with MS .NET 2.x even if you are using the 1.1 profile of pnet!
There is a difference between having the basics and having fully supported systems like you mentioned.
The support for generating Java bytecodes is non-functional, this is just like when dotgnu announced that they “supported generics before Microsoft shipped”, when all they had was a parser, and an assembler.
The C# compiler although advanced, is not complete. Neither is the Java compiler or the C compiler.
The rest of the framework is in a similar state, things barely work when you scratch the surface.
I can not test on anything but Intel, but I assume that the
OS support is just like that.
It is possible am wrong, please work with me here, how
do I compile a C# program into a program that can run with
Java.
How can I compile a C program into Java?
“By Erik (IP: —.27-151.libero.it) – Posted on 2004-08-08 12:59:29
this project is a complete waste of time.
there is mono on .NET why reimplement the compiler
in c ?”
like saying the mono project is a complete waste of time because java exited before…
Currently both Mono and PNet have their own good and bad points. In my opinion, the bad thing around here is to try to see only the good things in PNet and the bad ones in mono or visceversa.
Let’s face tha facts: the PNet architecture is an interesting one, but it has some incomplete areas. It has support for bytecode generation and its c# compiler is very fast. Just like these, PNet has somre more other advantages. But it lacks of true support for Generics, and as I just said before, in some areas lot of work must be done.
In Mono, the support for generics is in a middle term. The JIT for x86 is impressive (you can get a very good performance). The are creating very good Gtk# bindings. Fot in the other side, Window.Forms are in betha quality, and so are other areas.
The only one fact is that the work those ways because their leaders have different ideas in terms of building a good and MS compatible platform.
So, just lets stop flaming and, if someone thinks that one of these projects is better than the other, should go and check the true facts, and mention them, please. Nothing is better.
By the way, saying that the quality in PNet code is better in Mono is something that doesn’t says anything important. I mean, could you say us which areas have do you see?
By the way, saying that the quality in PNet code is better in Mono is something that doesn’t says anything important. I mean, could you say us which areas have do you see?
Just look at any part of it (pnet the engine or the class libaries). There’s been clear design. One simple example is how pnet is divided into strict subsystems designed to be abstract from each other (for the purposes of cross platform compatability. Another example is look at the exceptions thrown inside mono’s jit or their class libraries. The error messages are hard coded english. PNET’s exceptions aren’t hard coded in any language.
Another example is how Mono is so coupled with various libraries (glib, libgc etc). PNET is written in pure C and can even be compiled without any extra libraries (you can even compile pnet’s interpreter using VC++). Any “fancy” features are written in a seperate support lib which has fallback implementations written in pure C (kind of like how error messages will fall back to english with pnet rather than be always printed out in english with mono). You won’t find references to various boehm GC data structures or glib data structures or windows data strctures inside the engine or compiler code. All that has been abstracted off and seperated into the ‘support’ library.
Let me tell you the most interesting thing I found out on 0.6.8
Using a garbage collector for the AST nodes in C
It might sound stupid , but the point is to free all the AST nodes obseleted when the tree is rewritten to reduce memory usage.
All it needs is “%option gc_allocator” one place in the entire code and all the compilers (C , java , C# , VB) use libgc automatically !!.
You can’t compile C to JVM bytecode. JVM lacks some instructions C will need.
Pnet also use libgc.
>You can’t compile C to JVM bytecode. JVM lacks some >instructions C will need.
Well you could but it wouldn’t be very fast. (Use channels, buffers for pointers, interfaces for function pointers etc).
>Pnet also use libgc.
Yes. The point is that it’s not tightly coupled with it, unlike mono, the engine contains no references to libgc data structures or headers. The GC has been abstracted out.
I honestly do not see the problem with a glib dependency,
if anything is the purest form of code reuse, not doing so
would lead to unnecessary bloat.
It is easy to speak of clearly separated abstractions, the
problem is that abstractions are not perfect, and they leak.
I used to be a fan of clean abstractions before, but in my
opinion, in this particular case, they are unnecessary bloat.
You point out a clean interface in GC in Pnet, shame that
the interface is incomplete to implement a different GC
system: you need a lot more than what you have to plug a
non-Boehm collector there.
So in reality, I think that your example has no merit.
As for us, we are plugging a precise collector into Mono
right now which as you can imagine requires a lot more
changes than the cute abstractions that you talk about.
No offense is intended, am sure you guys are very proud
of your code, but you are being naive if you think that
clear abstractions are a solution to all of your problems.
You have yet to build a JIT engine into the VM, and you have
yet to address a complete new family of problems that you
are unaware of. I can only wish pnet the best luck, as
I think that multiple implementations are key for cross-
polination of ideas.
You made other abstraction statements, very bold ones
about Java and C, and so far you have dodged the issue:
I bet it is also the case of incomplete abstractions with
incomplete code. I might be wrong, but you have so far
conveniently ignored to reply to that post.
Miguel.
The mono vs pnet discussions that erupt on osnews,
slashdot, etc, every time one or the other posts an
announcement is getting very tiresome.
Neither project is better than the other. Both have
strengths and weaknesses, and there are certainly
differences of opinion on design. We can debate design
until the cows come home and it won’t change the truth:
it is a personal choice as to how one designs a system.
There is no “right” design for this kind of project.
Work on whichever project you feel comfortable with and
leave it at that. Sniping at each other over trivialities
of design style is unhelpful.
>I used to be a fan of clean abstractions before, but in my
>opinion, in this particular case, they are unnecessary bloat.
>You point out a clean interface in GC in Pnet, shame that
>the interface is incomplete to implement a different GC
>system: you need a lot more than what you have to plug a
>non-Boehm collector there.
I think we’ll have to agree to disagree on this. Although the abstractions aren’t perfect (and will have to be looked at again if/when we change GCs) it still helps to isolate the GC from the engine as much as possible. When the time does come, the abstractions will simply need to be extended rather than completely rewritten which would require visiting a lot of code. With a few exceptions, the abstractions are generic to most basic GCs. Obviously copying collectors (etc) need a lot more information that currently isn’t supported.
>No offense is intended, am sure you guys are very proud
>of your code, but you are being naive if you think that
>clear abstractions are a solution to all of your problems.
Ofcourse not! They just make code a lot easier to understand and work with (IMHO).
>You made other abstraction statements, very bold ones
>about Java and C, and so far you have dodged the issue:
>I bet it is also the case of incomplete abstractions with
>incomplete code. I might be wrong, but you have so far
>conveniently ignored to reply to that post.
I’ve looked back and haven’t seen a post regarding that. For the record, I think incomplete abstractions are better than no abstractions. Incomplete abstractions can be extended and they aren’t as brittle when it comes to external API changes.
>I think that multiple implementations are key for cross-
>polination of ideas.
I completely agree. I’m very impressed with Mono’s remoting and ASP.NET implementation (both of which are still unimplemented (for the most part) in PNET).
Hi Miguel,
I see the post you were referring to now.
You’ll have to ask t3minator about the compiler stuff. I just know that the framework is there to allow that kind of stuff to be done (the compiler is designed like gcc). We are just lacking the developers to do it
.