Posted by
timothy
on from the not-the-same-as-self-flagellation dept.
Bob Smith writes: "Miguel just commited the last patch nessisary to get Mono's C# compiler to compile itself. After 7 odd months, MCS is now self hosting."jbarn adds: "Mono-list email is here."
Request
by
Anonymous Coward
·
· Score: 4, Informative
I ask that people submit more articles about accomplishments in the world of compilers. Does anyone recall the functional programming contest? There were many excellnt compilers featured that are being improved constantly, and/. should focus some of its attention on those, too. C# is getting too much attention just cause it's a microsoft thing...:)
Re:a dumb question
by
pthisis
·
· Score: 5, Informative
If the compiler can build itself, then people can work on improving the compiler without needing to have a different compiler to build it with.
In this case, until now you needed to have Windows and a C# compiler for Windows in order to work on the C# compiler for Linux--that would shut someone like me (who has no Windows) out from being able to do compiler work. Not that I want to work on C# anyway, but you get the point.
Imagine if all the gcc developers had to buy a C compiler to work on developing the free one!
Sumner
-- rage, rage against the dying of the light
Re:Someone please?
by
xer.xes
·
· Score: 2, Informative
Okay:
c# compiler source + gnu c compiler = C# compiler
C# compiler source + c# compiler = another c# compiler
app source code + c# compiler = app
So it's not the application (exe?) that can compile, but it's the compiler that can compile...
Uhmm.. Yeah..:)
-- xer.xes -- 4181
Mono is does not depend on .NET
by
Carnage4Life
·
· Score: 5, Informative
Isn't it wonderful having C# and.NET on Linux, after all they won't have the problems that Samba boys have trying to keep up with MS deliberately changing things to stop them, and it won't be miles worse.
Dare Obasanjo: Similarly what happens if
Dan Kusnetzky's prediction comes true and
Microsoft changes the.NET APIs in the
future? Will the Mono project play catchup or will it
become an incompatible implementation
of.NET on UNIX platforms?
Miguel de Icaza: Microsoft is remarkably good
at keeping their APIs backwards
compatible (and this is one of the reasons I think
they have had so
much success as a platform vendor). So I think that
this would not be
a problem.
Now, even if this was a problem, it is always possible
to have
multiple implementations of the same APIs and use the
correct one by
choosing at runtime the proper "assembly". Assemblies
are a new
way of dealing with software bundles and the files
that are part of an
assembly can be cryptographically checksummed and
their APIs
programmatically tested for compatibility.
[Dare -- Description
of Assemblies from MSDN gloassary]
So even if they deviate from the initial release, it
would be possible
to provide assemblies that are backwards compatible
(we can both do
that: Microsoft and ourselves)
.NET isn't a revolution, its a way to build poor quality mainframes, lots of boxes, poor IO. I
No.NET isn't a revolution, it's simply a slight improvement on an old idea of how things can be done. The same way Linux, Apache, BSD, Perl, Java, XML, P2P, the world wide web, etc. aren't revolutions but simply new spins on decades old concepts.
However, does this somehow preclude their usefulness or the fact that they are all innovative in their own way?
Re:This might make it a bit more intriguing
by
image
·
· Score: 5, Informative
You wrote:
The cost of using soap means the XML has to use DOM and it has to validate the required nodes.
and:
Anyone working with XML knows that validating DOM structure can be very costly for complex tree structures.
SOAP does not use the DOM. The SOAP DTD can be validated without it. As can any XML DTD.
Yes, the DOM is heavyweight, but it is also totally orthogonal to this problem. Where did you get the idea that SOAP required a DOM, anyway? The spec you reference certainly doesn't say that, and they really don't have anything to do with each other.
Re:Samba anyone ?
by
griffits
·
· Score: 2, Informative
>>Right now, all Linux has for standard
>>middleware is CORBA. Sure there are Linux
>>die-hards that will stand by CORBA, but most
>>will agree that COM is superior.
Don't you mean COM+. CORBA encapsulates a wire protocol, transaction capabilities, security etc. COM is really just "IUnknown" and anyway if it is so superior, why is it being replaced by.NET?
Warning: The above post is clueless
by
Carnage4Life
·
· Score: 3, Informative
Unfortunately, SOAP is a bit heavy for the most simple web services (what ever it means to microsoft).
SOAP is the standard protocol accepted INDUSTRY WIDE for web services. This is not just across companies from Microsoft to Sun to Oracle, etc. but across programming languages from C# to Java to Perl.
The cost of using soap means the XML has to use DOM and it has to validate the required nodes.
One does not need a DOM to validate an XML document. There are many validating SAX readers and in fact there also validating Pull-based XML APIs like Microsoft's XmlValidatingReader or XPP.
It's too bad microsoft's whitepapers don't credit the orginal authors, since a lot of people worked to push XML forward. In some ways, it feels like SOAP and.NET is a bastardized version of Burners Lee's vision of a semantic web using XML web services and RDF. Perhaps all the press.NET has generated for XML services will help create the critical mass needed to get semantic web [w3.org] moving.
Now it is clear you have no idea what you are talking about. The push for the semantic web is a push for a richer web experience by adding more meta data to the content of the web.
SOAP is a distributed computing protocol similar to predefined protocol the Internet Inter-ORB Protocol (IIOP) for CORBA, the Object Remote Procedure Call (ORPC) for DCOM, and the Java Remote Method Protocol (JRMP) for Java/RMI but defined in XML instead of a binary format.
Generally, how mature is a compiler when it reaches self compiling capabilities? young? is it a main goal of the project?
One way of porting a language to a new architecture involves a kind of bootstrapping, wherein a compiler for a simple subset of the language is written in some host language (C, say) that is already available. Then more sophisticated parts of the compiler can be coded using the first generation of the compiler. Where the new language is already largely a superset of the porting language (as is the case with c-like languages), you can end up with a compiler that can compile itself.
So it's a feature of the method used to port the language. Obviously if a C# compiler were written in Pascal or Fortran, say, it would not ever be able to compile itself, no matter how mature it became.
The ability to write compilers is definitely a useful feature of any language, but producing a self-compiling compiler isn't necessarily a goal. If portability is important, a porting kit for the language should be provided in C or some other lingua franca.
Re:Th is is a serious question (slighty OT)
by
Anonymous Coward
·
· Score: 1, Informative
I don't know why anyone would call it "just another visual basic". It's a C++/Java like language. What makes it interesting is that it's interpreted by a virtual machine, and mixing matching langages is easy. You can have a class, with the methods written in C#. Then you can inherit that class in VB. I think there's also a perl.net implementation.
Pascal was actually designed to be compiled in a single pass. Although literally executing a Pascal compiler by hand would take _ages_, you can use a high level language as a guide to hand-produce an equivalent assembler routine from prefabricated sections (ie macros).
But this isn't what Wirth did. First he had a student code a compiler in Fortran, but this proved unsatisfactory. He then worked for several years on implementations before finally coming up with what we now call p-code--a simple virtual stack machine that could be implemented easily in any assembler language then available. The bootstrap compiler generated p-code, and thus porting the language was reduced to writing a few simple low level i/o routines and a p-code interpreter.
I believe one or two younger readers may recognise this concept from a very popular modern programming language.:)
Re:Microsoft and "standards"
by
rabtech
·
· Score: 5, Informative
Is that why some 15 year old HP-UX boxen running some ancient version of samba can still talk to my Windows 2000 server?
I find it hilarious that you would accuse Microsoft of changing the API; SMB hasn't changed at all on NT/2K except for a few upgrades to the password scheme to make it more secure and a few other small patches to fix bugs.
What Microsoft did do is come up with a new and improved filesharing protocol, CIFS, and implemented it as a >separate library running on different ports. If you honestly believe they are going to totally change the way their server OS works and lock out Win9x/NT4 clients, you are sadly mistaken.
Similarly, the Win32 API hasn't ever been CHANGED... it has only had things added to it. And with NTVDM/WOW, I can still run my ancient DOS and Win3.1 programs (for the most part) under Windows 2000; tell me where they've changed the API here?
*ALMOST EVERY* Time Microsoft wants to make a change that would break something, they just implement it in a separate standard or New API rather than b0rking the old one, which is the way it should be done.
If anyone is spouting FUD and nonsense here, it is you.
-- Natural != (nontoxic || beneficial)
Re:This might make it a bit more intriguing
by
borgboy
·
· Score: 2, Informative
but is this saying that any program or class compiled in C# becomes, in effect, a SOAP server?
Not quite, but that step is an insanely easy one:
You preface the methods that you wish exposed as web services with a declarative like this
[WebMethod]
like
public class Foo {
private void NotSeen {}
public void NotAService {}
[WebMethod]
public string imaWebService
{ return "Hello Dave"; }
}
If you want access to the http server context and stuff, you inherit from System.Web.Services.WebService
-- meh.
Re:Microsoft and "standards"
by
duffbeer703
·
· Score: 3, Informative
You are right and wrong.
Most Windows 2000 implementations run in compatability mode to allow legacy NT 3.51/4.0 and Windows 9x clients to connect.
If Windows 2000/Active Directory is running in native mode, these clients will be unable to connect. Many of the more advanced features of AD can only work in native environments.
-- Conformity is the jailer of freedom and enemy of growth. -JFK
Slashdot Mirror
I ask that people submit more articles about accomplishments in the world of compilers. Does anyone recall the functional programming contest? There were many excellnt compilers featured that are being improved constantly, and /. should focus some of its attention on those, too. C# is getting too much attention just cause it's a microsoft thing...:)
Miguel's Mono Roadmap
If the compiler can build itself, then people can work on improving the compiler without needing to have a different compiler to build it with.
In this case, until now you needed to have Windows and a C# compiler for Windows in order to work on the C# compiler for Linux--that would shut someone like me (who has no Windows) out from being able to do compiler work. Not that I want to work on C# anyway, but you get the point.
Imagine if all the gcc developers had to buy a C compiler to work on developing the free one!
Sumner
rage, rage against the dying of the light
Okay:
:)
c# compiler source + gnu c compiler = C# compiler
C# compiler source + c# compiler = another c# compiler
app source code + c# compiler = app
So it's not the application (exe?) that can compile, but it's the compiler that can compile...
Uhmm.. Yeah..
xer.xes -- 4181
Mono is not a clone of
Secondly as miguel said in my interview with him which originally ran on Slashdot and then on MSDN
No
However, does this somehow preclude their usefulness or the fact that they are all innovative in their own way?
You wrote:
The cost of using soap means the XML has to use DOM and it has to validate the required nodes.
and:
Anyone working with XML knows that validating DOM structure can be very costly for complex tree structures.
SOAP does not use the DOM. The SOAP DTD can be validated without it. As can any XML DTD.
Yes, the DOM is heavyweight, but it is also totally orthogonal to this problem. Where did you get the idea that SOAP required a DOM, anyway? The spec you reference certainly doesn't say that, and they really don't have anything to do with each other.
>>Right now, all Linux has for standard
.NET?
>>middleware is CORBA. Sure there are Linux
>>die-hards that will stand by CORBA, but most
>>will agree that COM is superior.
Don't you mean COM+. CORBA encapsulates a wire protocol, transaction capabilities, security etc. COM is really just "IUnknown" and anyway if it is so superior, why is it being replaced by
Unfortunately, SOAP is a bit heavy for the most simple web services (what ever it means to microsoft).
.NET is a bastardized version of Burners Lee's vision of a semantic web using XML web services and RDF. Perhaps all the press .NET has generated for XML services will help create the critical mass needed to get semantic web [w3.org] moving.
SOAP is the standard protocol accepted INDUSTRY WIDE for web services. This is not just across companies from Microsoft to Sun to Oracle, etc. but across programming languages from C# to Java to Perl.
The cost of using soap means the XML has to use DOM and it has to validate the required nodes.
One does not need a DOM to validate an XML document. There are many validating SAX readers and in fact there also validating Pull-based XML APIs like Microsoft's XmlValidatingReader or XPP.
It's too bad microsoft's whitepapers don't credit the orginal authors, since a lot of people worked to push XML forward. In some ways, it feels like SOAP and
Now it is clear you have no idea what you are talking about. The push for the semantic web is a push for a richer web experience by adding more meta data to the content of the web.
SOAP is a distributed computing protocol similar to predefined protocol the Internet Inter-ORB Protocol (IIOP) for CORBA, the Object Remote Procedure Call (ORPC) for DCOM, and the Java Remote Method Protocol (JRMP) for Java/RMI but defined in XML instead of a binary format.
One way of porting a language to a new architecture involves a kind of bootstrapping, wherein a compiler for a simple subset of the language is written in some host language (C, say) that is already available. Then more sophisticated parts of the compiler can be coded using the first generation of the compiler. Where the new language is already largely a superset of the porting language (as is the case with c-like languages), you can end up with a compiler that can compile itself.
So it's a feature of the method used to port the language. Obviously if a C# compiler were written in Pascal or Fortran, say, it would not ever be able to compile itself, no matter how mature it became.
The ability to write compilers is definitely a useful feature of any language, but producing a self-compiling compiler isn't necessarily a goal. If portability is important, a porting kit for the language should be provided in C or some other lingua franca.
I don't know why anyone would call it "just another visual basic". It's a C++/Java like language. What makes it interesting is that it's interpreted by a virtual machine, and mixing matching langages is easy. You can have a class, with the methods written in C#. Then you can inherit that class in VB. I think there's also a perl .net implementation.
But this isn't what Wirth did. First he had a student code a compiler in Fortran, but this proved unsatisfactory. He then worked for several years on implementations before finally coming up with what we now call p-code--a simple virtual stack machine that could be implemented easily in any assembler language then available. The bootstrap compiler generated p-code, and thus porting the language was reduced to writing a few simple low level i/o routines and a p-code interpreter.
I believe one or two younger readers may recognise this concept from a very popular modern programming language. :)
Is that why some 15 year old HP-UX boxen running some ancient version of samba can still talk to my Windows 2000 server?
I find it hilarious that you would accuse Microsoft of changing the API; SMB hasn't changed at all on NT/2K except for a few upgrades to the password scheme to make it more secure and a few other small patches to fix bugs.
What Microsoft did do is come up with a new and improved filesharing protocol, CIFS, and implemented it as a >separate library running on different ports. If you honestly believe they are going to totally change the way their server OS works and lock out Win9x/NT4 clients, you are sadly mistaken.
Similarly, the Win32 API hasn't ever been CHANGED... it has only had things added to it. And with NTVDM/WOW, I can still run my ancient DOS and Win3.1 programs (for the most part) under Windows 2000; tell me where they've changed the API here?
*ALMOST EVERY* Time Microsoft wants to make a change that would break something, they just implement it in a separate standard or New API rather than b0rking the old one, which is the way it should be done.
If anyone is spouting FUD and nonsense here, it is you.
Natural != (nontoxic || beneficial)
but is this saying that any program or class compiled in C# becomes, in effect, a SOAP server?
Not quite, but that step is an insanely easy one:
You preface the methods that you wish exposed as web services with a declarative like this
[WebMethod]
like
public class Foo {
private void NotSeen {}
public void NotAService {}
[WebMethod]
public string imaWebService
{ return "Hello Dave"; }
}
If you want access to the http server context and stuff, you inherit from System.Web.Services.WebService
meh.
You are right and wrong.
Most Windows 2000 implementations run in compatability mode to allow legacy NT 3.51/4.0 and Windows 9x clients to connect.
If Windows 2000/Active Directory is running in native mode, these clients will be unable to connect. Many of the more advanced features of AD can only work in native environments.
Conformity is the jailer of freedom and enemy of growth. -JFK
You can load code dynamically into your application . You can even generate code on the flight and execute it (with System.Reflection.Emit).
C# does not have inner classes, but it has delegates, which can be thought as closures. They basically encapsulate a method plus its object.
Miguel.
Actually, you can use getenv to determine the user's HOMEPATH.