www.digitalmars.com         C & C++   DMDScript  

D - Feature request: support for distributed compilation

reply "Robert Medeiros" <robert.medeiros utoronto.ca> writes:
Another thought for a potential feature of D -- support for distributed
compilation as a standardized part of the compiler, which could possibly
have a daemon (D-mon?) mode letting it run as a background process/service,
or a distinct but included utility that handles networking issues and
forwards information to each local instance of the compiler. Some
interesting software that works with GCC: http://distcc.samba.org/.

Rob
Jan 31 2003
next sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
Robert Medeiros wrote:
 Another thought for a potential feature of D -- support for distributed
 compilation as a standardized part of the compiler, which could possibly
 have a daemon (D-mon?) mode letting it run as a background process/service,
 or a distinct but included utility that handles networking issues and
 forwards information to each local instance of the compiler. Some
 interesting software that works with GCC: http://distcc.samba.org/.
 
 Rob
 

First, it is a compiler feature, since it doesn't add anything to a language. Second, it's not necessarily that all compilers need it. On my notebook, DMC runs ten times as fast as GCC - so why should bother acceleraing GCC through hooking it on the network? I have 2 PCs and a notebook. Well, i could speed up the compilation twice - it's still no comparison to a well-designed compiler. I could even hook up a whole university network - and it still wouldn't be as fast as a normal compiler because too much network traffic would be involved. That's a possibly only ill place of GCC - its speed. And this is a temporary workaround, which is not worth promoting. Better fix the underlying system, right? It certainly still makes sense for a few can't- imagine- how- huge projects. I've recently bocome aware that .net is not as bad as one might think: - it's gonna be standardized by ECMA, so it wouldn't stay in m1cro$oft domain; - it is, unlike Java, suited well for a wide range of languages, by providing an IL; - unlike Java bytecode, the IL is much higher-level and allows for a wide range of compiler optimisations. Different kinds of code generators can be attached, including production-quality static compiling back-ends, or fast JIT VMs. It's much more like a common compiler/ interpreter/ anything infrastructure; - there already is a real open-source project "mono", which has a CPU-independant bytecode interpreter, and a good JIT x86 VM, and C# and VB ->IL compilers, as well as a simplified static compiler (i guess); - they also want to write a backend for GCC to generate IL - so that fast GCC frontends (like GNAT, GPK, FPK, OCaml, OpenD) can benefit from different code generators and instant execution, instead of waiting for current GCC backend to scratch its kin. M1cro$oft would probably benefit from some applications, but they just have taken a step which was due for a long time. It is to assume certain incompatibilities if m1cro$oft products have any underwater (non-ECMA) parts, but who would care after "mono" is ready and having a complete ECMA toolset, for developers as well as for Academia? And i bet academics would soon give us yet better back-ends, as they have for Java, but of better quality since .net doesn't seem to suffer from Java's inherent deficiencies. -i.
Jan 31 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
Hi,

    Comments embedded.

"Ilya Minkov" <midiclub 8ung.at> escreveu na mensagem
news:b1ej56$sks$1 digitaldaemon.com...
[snip]

 I've recently bocome aware that .net is not as bad as one might think:
   - it's gonna be standardized by ECMA, so it wouldn't stay in m1cro$oft
 domain;

Kind of. Most of the libraries used in .net aren't in the ECMA standard, and Microsoft adds a few more every other release. IIRC (my copy of the standard may be outdated) the only libraries in it are: Base Class, Network, Reflection, XML, Floating-Point and Extended Array. Things like GUI aren't standard and most (if not all) applications written using Microsoft .net SDK use something Microsoft specific.
   - it is, unlike Java, suited well for a wide range of languages, by
 providing an IL;

This thing is source of lots of Java vs. C# debates. Provision of an IL gives no guarantees. Java has also a byte-code format, which can be used as an intermediate language. Of course CIL has a different set of byte-codes than Java (e.g. tail call), and different primitives (e.g. structs, pointers). But most of these come from the C-like languages, so it's not like they are really providing a full range of languages. Eiffel# was crippled to be able to compile cleanly to CIL. Mondrian.net and F# aren't fully functional (no pun intended) too. The only non-imperative language that compiles to CIL and isn't crippled is Mercury. There was a problem with Python ports to .net some time ago, and Smallscript has it's issues too.
   - unlike Java bytecode, the IL is much higher-level and allows for a
 wide range of compiler optimisations. Different kinds of code generators
 can be attached, including production-quality static compiling
 back-ends, or fast JIT VMs. It's much more like a common compiler/
 interpreter/ anything infrastructure;

In which ways CIL is "much higher-level" than Java's byte-code? I can think of tail call and polymorphic instructions for all types (like push instead of push int), but both are very similar.
   - there already is a real open-source project "mono", which has a
 CPU-independant bytecode interpreter, and a good JIT x86 VM, and C# and
 VB ->IL compilers, as well as a simplified static compiler (i guess);

Check DotGNU too (www.dotgnu.org). It tries to provide a free alternative to every single feature present in .net, while Mono is more of a C# compiler/CVM implementation.
   - they also want to write a backend for GCC to generate IL - so that
 fast GCC frontends (like GNAT, GPK, FPK, OCaml, OpenD) can benefit from
 different code generators and instant execution, instead of waiting for
 current GCC backend to scratch its kin.

 M1cro$oft would probably benefit from some applications, but they just
 have taken a step which was due for a long time. It is to assume certain
 incompatibilities if m1cro$oft products have any underwater (non-ECMA)
 parts, but who would care after "mono" is ready and having a complete
 ECMA toolset, for developers as well as for Academia? And i bet
 academics would soon give us yet better back-ends, as they have for
 Java, but of better quality since .net doesn't seem to suffer from
 Java's inherent deficiencies.

Again, which deficiencies are inherent to Java, but not to .net?
 -i.

Best regards, Daniel Yokomiso. "Enlightenment does not divide you, just as the moon does not break the water. The depth of the drop is the height of the moon." - Dogen --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003
Feb 02 2003
next sibling parent reply Ilya Minkov <midiclub tiscali.de> writes:
Hello.


Daniel Yokomiso wrote:
 Hi,
 
     Comments embedded.
 
 "Ilya Minkov" <midiclub 8ung.at> escreveu na mensagem
 news:b1ej56$sks$1 digitaldaemon.com...
 [snip]
 
     Kind of. Most of the libraries used in .net aren't in the ECMA standard,
 and Microsoft adds a few more every other release. IIRC (my copy of the
 standard may be outdated) the only libraries in it are: Base Class, Network,
 Reflection, XML, Floating-Point and Extended Array. Things like GUI aren't
 standard and most (if not all) applications written using Microsoft .net SDK
 use something Microsoft specific.

Gnome project has taken care of that as well :) They have written "gtk#". I'll have ti take a look whether it's a mess or not. But i believe the purpose of the gnome project is to bring standards to modern Unix and the chief said it's time to get rid of a mess...
  - it is, unlike Java, suited well for a wide range of languages, by
providing an IL;

This thing is source of lots of Java vs. C# debates. Provision of an IL gives no guarantees. Java has also a byte-code format, which can be used as an intermediate language. Of course CIL has a different set of byte-codes than Java (e.g. tail call), and different primitives (e.g. structs, pointers). But most of these come from the C-like languages, so it's not like they are really providing a full range of languages. Eiffel# was crippled to be able to compile cleanly to CIL. Mondrian.net and F# aren't fully functional (no pun intended) too. The only non-imperative language that compiles to CIL and isn't crippled is Mercury. There was a problem with Python ports to .net some time ago, and Smallscript has it's issues too.

And how is CIL worse than GCC AIL? They are C-based as well. I thought C itself is more or less enough to express all kinds of languages, except for calling convention/tail recursion/ such stuff which is fixed. C-- goes once below this level of abstraction, claiming to be a "universal assembly language" (pity it doesn't work yet well). And AFAIK CIL is about the same level of abstraction. I'd like to know more of CIL limitations, and whether GCC has them as well or not.
     In which ways CIL is "much higher-level" than Java's byte-code? I can
 think of tail call and polymorphic instructions for all types (like push
 instead of push int), but both are very similar.

I guess that CIL tree structure can be reconstructed, allowing for all optimisations of static compilation. Of course, it does not necessarily make sense for JIT/VM, but for static compilation it does. There have been many attempts to compile Java bytecode into native code, but the resulting code quality was still not the same as with native-compiled pogrammes, because some optimisations on structure could not be done. A Java source->native binary project had better success, AFAIK. I thought CIL would enable the possibility of these optimisations as well. Please don't hold what i say here for an absolute truth, i'm not very well informed on these subjects. I have downloaded the whole documentation, but i didn't have time to actually read it. I've got exams in a week and after that i'm free and will multiply my knowledge and power. And write some useful utility for D.
     Check DotGNU too (www.dotgnu.org). It tries to provide a free
 alternative to every single feature present in .net, while Mono is more of a
 C# compiler/CVM implementation.

That split again! Qt# on one side, GTK# on the other! Well yes, i'm more interested in a VM than in the rest, since every already established language would bring its own librarries with it. Example: D. BTW, D is still in a need of a GUI library.
     Again, which deficiencies are inherent to Java, but not to .net?

^^^ Either those, or i have to read more :>
 
     Best regards,
     Daniel Yokomiso.
 
 "Enlightenment does not divide you, just as the moon does not break the
 water. The depth of the drop is the height of the moon."
 - Dogen

-i.
Feb 03 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
Hi,

    Comments embedded.

"Ilya Minkov" <midiclub tiscali.de> escreveu na mensagem
news:b1ll0n$2cf1$1 digitaldaemon.com...
 Hello.


 Daniel Yokomiso wrote:
 Hi,

     Comments embedded.

 "Ilya Minkov" <midiclub 8ung.at> escreveu na mensagem
 news:b1ej56$sks$1 digitaldaemon.com...
 [snip]

     Kind of. Most of the libraries used in .net aren't in the ECMA


 and Microsoft adds a few more every other release. IIRC (my copy of the
 standard may be outdated) the only libraries in it are: Base Class,


 Reflection, XML, Floating-Point and Extended Array. Things like GUI


 standard and most (if not all) applications written using Microsoft .net


 use something Microsoft specific.

Gnome project has taken care of that as well :) They have written "gtk#". I'll have ti take a look whether it's a mess or not. But i believe the purpose of the gnome project is to bring standards to modern Unix and the chief said it's time to get rid of a mess...

There's also QT# ( http://qtcsharp.sourceforge.net/ ), so we have choice when using CIL. But People writing C# using Microsoft stuff will probably depend on their implementation.
  - it is, unlike Java, suited well for a wide range of languages, by
providing an IL;

This thing is source of lots of Java vs. C# debates. Provision of an


 gives no guarantees. Java has also a byte-code format, which can be used


 an intermediate language. Of course CIL has a different set of


 than Java (e.g. tail call), and different primitives (e.g. structs,
 pointers). But most of these come from the C-like languages, so it's not
 like they are really providing a full range of languages. Eiffel# was
 crippled to be able to compile cleanly to CIL. Mondrian.net and F#


 fully functional (no pun intended) too. The only non-imperative language
 that compiles to CIL and isn't crippled is Mercury. There was a problem


 Python ports to .net some time ago, and Smallscript has it's issues too.

And how is CIL worse than GCC AIL? They are C-based as well. I thought C itself is more or less enough to express all kinds of languages, except for calling convention/tail recursion/ such stuff which is fixed. C-- goes once below this level of abstraction, claiming to be a "universal assembly language" (pity it doesn't work yet well). And AFAIK CIL is about the same level of abstraction. I'd like to know more of CIL limitations, and whether GCC has them as well or not.

All languages are equal in the Turing tarpit ;-) CIL has the same problems other imperative language models. The primary parameter passing device is the stack. It supports static overloading of methods, which is resolved statically and it's harmful for languages with multi-methods. It doesn't has generics since day one (I know about their research and future plans, but still it's not integrated in the class library and type system, and generics are a big change of paradigm). Languages with message passing (e.g. Smalltalk or Objective C) for method calling, usually have different forms of method storing instead of vtables, the same goes to generic dispatching mechanism (e.g. multi-dispatch and predicative dispatch). These kind of problems. I don't know GCC AIL, but it may have this same category of problems.
     In which ways CIL is "much higher-level" than Java's byte-code? I


 think of tail call and polymorphic instructions for all types (like push
 instead of push int), but both are very similar.

I guess that CIL tree structure can be reconstructed, allowing for all optimisations of static compilation. Of course, it does not necessarily make sense for JIT/VM, but for static compilation it does. There have been many attempts to compile Java bytecode into native code, but the resulting code quality was still not the same as with native-compiled pogrammes, because some optimisations on structure could not be done. A Java source->native binary project had better success, AFAIK. I thought CIL would enable the possibility of these optimisations as well. Please don't hold what i say here for an absolute truth, i'm not very well informed on these subjects. I have downloaded the whole documentation, but i didn't have time to actually read it. I've got exams in a week and after that i'm free and will multiply my knowledge and power. And write some useful utility for D.

Java source -> native or byte-code -> native aren't that much different, only different forms of representing methods and objects. AFAIK the largest class of problems in Java come from optimization of standard libraries.
     Check DotGNU too (www.dotgnu.org). It tries to provide a free
 alternative to every single feature present in .net, while Mono is more


 C# compiler/CVM implementation.

That split again! Qt# on one side, GTK# on the other! Well yes, i'm more interested in a VM than in the rest, since every already established language would bring its own librarries with it. Example: D. BTW, D is still in a need of a GUI library.

Both runtimes support QT# and GTK#. But DotGNU provides other things, like a application server, a authentication server, webservices support, etc., that aren't Mono's primary target.
     Again, which deficiencies are inherent to Java, but not to .net?

^^^ Either those, or i have to read more :>
     Best regards,
     Daniel Yokomiso.

 "Enlightenment does not divide you, just as the moon does not break the
 water. The depth of the drop is the height of the moon."
 - Dogen

-i.

Best regards, Daniel Yokomiso. "1. Out of clutter, find simplicity. 2. From discord, find harmony. 3. In the middle of difficulty lies opportunity." - Albert Einstein --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003
Feb 03 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Hi.

Anyway, some way must always be found to express a high-level language 
in a machine language. C provides fairly little abstraction over the 
machine. CIL even less. Java and Java Bytecode much more.
The less intermediate abstraction, the better chances are that any 
compilable language can be translated with a justifiable effort. The 
higher the level of abstraction, the better optimisation can be done. 
AFAIK e.g. LCC IL wraps low-level representation into a higher-level, so 
two different levels of abstraction are available at once. I think CIL 
should be similar, thus allowing to compile languages that don't fit a 
bit somewhere with a small loss of efficiency.
I have heard that Java bytecode is stripped down to such extent, that 
reconstruction of higher-level representation (tree) is too complicated, 
and not low-level enough so that most languages would get a huge 
emulation penalty when expressed in it. You can't directly manipulate 
the stack in it, right? Like you would do on every normal computer.
It's really no sense complaining that the IL doesn't provide some ready 
primitive that would be good for your language, since normally you would 
be compiling into assembly and run into similar problems, if the IL 
allows a low level representation. But if it doesn't, you're sacked in.

-i.


Daniel Yokomiso wrote:
 Hi,
 
 Comments embedded.
 
 "Ilya Minkov" <midiclub tiscali.de> escreveu na mensagem 
 news:b1ll0n$2cf1$1 digitaldaemon.com...
 
 Hello.
 
 
 Daniel Yokomiso wrote:
 
 Hi,
 
 Comments embedded.
 
 "Ilya Minkov" <midiclub 8ung.at> escreveu na mensagem 
 news:b1ej56$sks$1 digitaldaemon.com... [snip]
 
 Kind of. Most of the libraries used in .net aren't in the ECMA


standard,
 and Microsoft adds a few more every other release. IIRC (my copy
 of the standard may be outdated) the only libraries in it are:
 Base Class,


Network,
 Reflection, XML, Floating-Point and Extended Array. Things like
 GUI


aren't
 standard and most (if not all) applications written using
 Microsoft .net


SDK
 use something Microsoft specific.

Gnome project has taken care of that as well :) They have written "gtk#". I'll have ti take a look whether it's a mess or not. But i believe the purpose of the gnome project is to bring standards to modern Unix and the chief said it's time to get rid of a mess...

There's also QT# ( http://qtcsharp.sourceforge.net/ ), so we have choice when using CIL. But People writing C# using Microsoft stuff will probably depend on their implementation.
 - it is, unlike Java, suited well for a wide range of
 languages, by providing an IL;

This thing is source of lots of Java vs. C# debates. Provision of an


IL
 gives no guarantees. Java has also a byte-code format, which can
 be used


as
 an intermediate language. Of course CIL has a different set of


byte-codes
 than Java (e.g. tail call), and different primitives (e.g.
 structs, pointers). But most of these come from the C-like
 languages, so it's not like they are really providing a full
 range of languages. Eiffel# was crippled to be able to compile
 cleanly to CIL. Mondrian.net and F#


aren't
 fully functional (no pun intended) too. The only non-imperative
 language that compiles to CIL and isn't crippled is Mercury.
 There was a problem


with
 Python ports to .net some time ago, and Smallscript has it's
 issues too.

And how is CIL worse than GCC AIL? They are C-based as well. I thought C itself is more or less enough to express all kinds of languages, except for calling convention/tail recursion/ such stuff which is fixed. C-- goes once below this level of abstraction, claiming to be a "universal assembly language" (pity it doesn't work yet well). And AFAIK CIL is about the same level of abstraction. I'd like to know more of CIL limitations, and whether GCC has them as well or not.

All languages are equal in the Turing tarpit ;-) CIL has the same problems other imperative language models. The primary parameter passing device is the stack. It supports static overloading of methods, which is resolved statically and it's harmful for languages with multi-methods. It doesn't has generics since day one (I know about their research and future plans, but still it's not integrated in the class library and type system, and generics are a big change of paradigm). Languages with message passing (e.g. Smalltalk or Objective C) for method calling, usually have different forms of method storing instead of vtables, the same goes to generic dispatching mechanism (e.g. multi-dispatch and predicative dispatch). These kind of problems. I don't know GCC AIL, but it may have this same category of problems.
 In which ways CIL is "much higher-level" than Java's byte-code? I
 


can
 think of tail call and polymorphic instructions for all types
 (like push instead of push int), but both are very similar.

I guess that CIL tree structure can be reconstructed, allowing for all optimisations of static compilation. Of course, it does not necessarily make sense for JIT/VM, but for static compilation it does. There have been many attempts to compile Java bytecode into native code, but the resulting code quality was still not the same as with native-compiled pogrammes, because some optimisations on structure could not be done. A Java source->native binary project had better success, AFAIK. I thought CIL would enable the possibility of these optimisations as well. Please don't hold what i say here for an absolute truth, i'm not very well informed on these subjects. I have downloaded the whole documentation, but i didn't have time to actually read it. I've got exams in a week and after that i'm free and will multiply my knowledge and power. And write some useful utility for D.

Java source -> native or byte-code -> native aren't that much different, only different forms of representing methods and objects. AFAIK the largest class of problems in Java come from optimization of standard libraries.
 Check DotGNU too (www.dotgnu.org). It tries to provide a free 
 alternative to every single feature present in .net, while Mono
 is more


of a
 C# compiler/CVM implementation.

That split again! Qt# on one side, GTK# on the other! Well yes, i'm more interested in a VM than in the rest, since every already established language would bring its own librarries with it. Example: D. BTW, D is still in a need of a GUI library.

Both runtimes support QT# and GTK#. But DotGNU provides other things, like a application server, a authentication server, webservices support, etc., that aren't Mono's primary target.
 Again, which deficiencies are inherent to Java, but not to .net?

^^^ Either those, or i have to read more :>
 Best regards, Daniel Yokomiso.
 
 "Enlightenment does not divide you, just as the moon does not
 break the water. The depth of the drop is the height of the
 moon." - Dogen

:> -i.

Best regards, Daniel Yokomiso. "1. Out of clutter, find simplicity. 2. From discord, find harmony. 3. In the middle of difficulty lies opportunity." - Albert Einstein --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003

Feb 04 2003
parent reply "Ken Carpenter" <kencr shaw.ca> writes:
"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:b1ot3f$1me2$1 digitaldaemon.com...
 Hi.

 It's really no sense complaining that the IL doesn't provide some ready
 primitive that would be good for your language, since normally you would
 be compiling into assembly and run into similar problems, if the IL
 allows a low level representation. But if it doesn't, you're sacked in.

If you only intend to program in the single language in question, then I would agree with you. The .NET people, however, seem to have a desire to program in several languages at the same time. If some of your languages treat the IL as a sort of instruction set and others treat map their language features to it one-to-one, then you will get a so-called "impedance mismatch" between the languages. Using MI in Eiffel#, for instance, requires a C# user to know additional class names and to understand how the Eiffel# compiler "tricks" the system into providing MI when it wasn't originally intended to. Whenever you try to add some new feature in a way not originally intended you are asking for trouble. Sometimes the trouble is worth it. Ken Carpenter
Feb 12 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Wouldn't multiple inheritance as a generic feature of a language 
infrastructure force all the languages to support it? Besides, i haven't 
taken a deeper look at Eiffel yet (i should), their MI is said to be 
somehow "different" from C++.


Ken Carpenter wrote:
 "Ilya Minkov" <midiclub 8ung.at> wrote in message
 news:b1ot3f$1me2$1 digitaldaemon.com...
 
Hi.

It's really no sense complaining that the IL doesn't provide some ready
primitive that would be good for your language, since normally you would
be compiling into assembly and run into similar problems, if the IL
allows a low level representation. But if it doesn't, you're sacked in.

If you only intend to program in the single language in question, then I would agree with you. The .NET people, however, seem to have a desire to program in several languages at the same time. If some of your languages treat the IL as a sort of instruction set and others treat map their language features to it one-to-one, then you will get a so-called "impedance mismatch" between the languages. Using MI in Eiffel#, for instance, requires a C# user to know additional class names and to understand how the Eiffel# compiler "tricks" the system into providing MI when it wasn't originally intended to. Whenever you try to add some new feature in a way not originally intended you are asking for trouble. Sometimes the trouble is worth it. Ken Carpenter

Feb 12 2003
parent Daniel Yokomiso <Daniel_member pathlink.com> writes:
In article <b2e59p$4cd$1 digitaldaemon.com>, Ilya Minkov says...
Wouldn't multiple inheritance as a generic feature of a language 
infrastructure force all the languages to support it? Besides, i haven't 
taken a deeper look at Eiffel yet (i should), their MI is said to be 
somehow "different" from C++.

It's like saying that a infrastructure supporting arbitrary jumps and memory access would force all languages using this architecture to support it. A language with SI running on a MI environment could just require their users to be explicit in type inheritance vs. code inheritance, but use a single mechanism at runtime. Each model can simulate the other, but when you need to go through tricks to implement a feature it probably'll be language specific.
Ken Carpenter wrote:
 "Ilya Minkov" <midiclub 8ung.at> wrote in message
 news:b1ot3f$1me2$1 digitaldaemon.com...
 
Hi.

It's really no sense complaining that the IL doesn't provide some ready
primitive that would be good for your language, since normally you would
be compiling into assembly and run into similar problems, if the IL
allows a low level representation. But if it doesn't, you're sacked in.

If you only intend to program in the single language in question, then I would agree with you. The .NET people, however, seem to have a desire to program in several languages at the same time. If some of your languages treat the IL as a sort of instruction set and others treat map their language features to it one-to-one, then you will get a so-called "impedance mismatch" between the languages. Using MI in Eiffel#, for instance, requires a C# user to know additional class names and to understand how the Eiffel# compiler "tricks" the system into providing MI when it wasn't originally intended to. Whenever you try to add some new feature in a way not originally intended you are asking for trouble. Sometimes the trouble is worth it. Ken Carpenter


Feb 13 2003
prev sibling parent reply "Ken Carpenter" <kencr shaw.ca> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:b1ke3d$1jd3$1 digitaldaemon.com...
 But most of these come from the C-like languages, so it's not
 like they are really providing a full range of languages. Eiffel# was
 crippled to be able to compile cleanly to CIL.

When they first brought Eiffel to .NET, it was, indeed, crippled. The current version, however, supports all features of Eiffel, including mulitple inheritance. Here's a link describing how multiple inheritance works with Eiffel# under .NET. http://www.devx.com/codemag/Article/8500 Ken Carpenter
Feb 03 2003
parent reply Daniel Yokomiso <Daniel_member pathlink.com> writes:
In article <b1np1e$uq3$1 digitaldaemon.com>, Ken Carpenter says...
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:b1ke3d$1jd3$1 digitaldaemon.com...
 But most of these come from the C-like languages, so it's not
 like they are really providing a full range of languages. Eiffel# was
 crippled to be able to compile cleanly to CIL.

When they first brought Eiffel to .NET, it was, indeed, crippled. The current version, however, supports all features of Eiffel, including mulitple inheritance. Here's a link describing how multiple inheritance works with Eiffel# under .NET. http://www.devx.com/codemag/Article/8500 Ken Carpenter

The major problem is that CIL doesn't provide multiple-inheritance or genericity, so if I'm writing a class in Python# (just an example), and I want to multiple inherit from two Eiffel for .net classes, I'll be in trouble. But If I want to Use VB to inherit from C#, no problem. This is what I mean by crippled.
Feb 04 2003
parent reply "Ken Carpenter" <kencr shaw.ca> writes:
"Daniel Yokomiso" <Daniel_member pathlink.com> wrote in message
news:b1po0m$271h$1 digitaldaemon.com...
 The major problem is that CIL doesn't provide multiple-inheritance or
 genericity, so if I'm writing a class in Python# (just an example), and I

 to multiple inherit from two Eiffel for .net classes, I'll be in trouble.

 I want to Use VB to inherit from C#, no problem. This is what I mean by
 crippled.

I would hardly fault Eiffel# for the limitations of CIL, Python#, VB and C#. It is certainly not Eiffel# that is crippled in that respect; it's all the other .NET languages! Ken Carpenter
Feb 12 2003
parent reply Daniel Yokomiso <Daniel_member pathlink.com> writes:
In article <b2d150$2i6b$1 digitaldaemon.com>, Ken Carpenter says...
"Daniel Yokomiso" <Daniel_member pathlink.com> wrote in message
news:b1po0m$271h$1 digitaldaemon.com...
 The major problem is that CIL doesn't provide multiple-inheritance or
 genericity, so if I'm writing a class in Python# (just an example), and I

 to multiple inherit from two Eiffel for .net classes, I'll be in trouble.

 I want to Use VB to inherit from C#, no problem. This is what I mean by
 crippled.

I would hardly fault Eiffel# for the limitations of CIL, Python#, VB and C#. It is certainly not Eiffel# that is crippled in that respect; it's all the other .NET languages! Ken Carpenter

I'm not blaming Eiffel# or trying to criticize it. If you read the thread again, you'll see that my point is: Eiffel had to be crippled to compile cleanly into CIL. IIRC I didn't said that Eiffel# was crippled (it being crap and the other languages are good stuff) but it had to be crippled (other languages are less comprehensive and Eiffel# had to give away some features).
Feb 12 2003
parent "Ken Carpenter" <kencr shaw.ca> writes:
"Daniel Yokomiso" <Daniel_member pathlink.com> wrote in message
news:b2ekno$dup$1 digitaldaemon.com...
 I'm not blaming Eiffel# or trying to criticize it. If you read the thread

 you'll see that my point is: Eiffel had to be crippled to compile cleanly

 CIL. IIRC I didn't said that Eiffel# was crippled (it being crap and the

 languages are good stuff) but it had to be crippled (other languages are

 comprehensive and Eiffel# had to give away some features).

Your point was quite clear. I simply pointed out that it was incorrect. When Eiffel# was first released, there were some features missing since they were harder to fit into the CIL model. The current version of Eiffel#, however, is a full implementation of Eiffel including MI and genericity. You are certainly correct that CIL does not directly support MI, genericity or DbC (most unfortunate ommissions IMO) , but again, that in no way reflects on Eiffel#, so including it in your example of a Python# class is a red herring. If you want to write a Python# class that inherits from multiple .NET classes you're in trouble regardless of which other .NET language the base classes were developed in. Anyway, since this has nothing to do with distributed compilation or D, I will not say anymore on the subject. ;-) Ken Carpenter
Feb 13 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Robert Medeiros" <robert.medeiros utoronto.ca> wrote in message
news:b1ed6q$gi1$1 digitaldaemon.com...
 Another thought for a potential feature of D -- support for distributed
 compilation as a standardized part of the compiler, which could possibly
 have a daemon (D-mon?) mode letting it run as a background

 or a distinct but included utility that handles networking issues and
 forwards information to each local instance of the compiler. Some
 interesting software that works with GCC: http://distcc.samba.org/.

DMC++ offers "netbuild" which distributes compiles across machines attached to a network. This was a good idea 10 years ago when machines were slow, but the computers are so much faster now that any speed gain from separate compilation will be more than offset by the vastly slower network traffic. DMC is also the fastest compiler available. DMD is based on the same technology, but the D language is also designed to be much faster to compile than C is. The end result is I don't see a need for a D netbuild.
Jan 31 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
My point. ;)

Walter wrote:
 "Robert Medeiros" <robert.medeiros utoronto.ca> wrote in message
 news:b1ed6q$gi1$1 digitaldaemon.com...
 
Another thought for a potential feature of D -- support for distributed
compilation as a standardized part of the compiler, which could possibly
have a daemon (D-mon?) mode letting it run as a background

process/service,
or a distinct but included utility that handles networking issues and
forwards information to each local instance of the compiler. Some
interesting software that works with GCC: http://distcc.samba.org/.

DMC++ offers "netbuild" which distributes compiles across machines attached to a network. This was a good idea 10 years ago when machines were slow, but the computers are so much faster now that any speed gain from separate compilation will be more than offset by the vastly slower network traffic. DMC is also the fastest compiler available. DMD is based on the same technology, but the D language is also designed to be much faster to compile than C is. The end result is I don't see a need for a D netbuild.

Jan 31 2003
parent "Walter" <walter digitalmars.com> writes:
"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:b1f4at$1dn8$1 digitaldaemon.com...
 My point. ;)

You're right.
Jan 31 2003