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

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.

"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.

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.

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b1f4at$1dn8$1@digitaldaemon.com...
> My point. ;)

You're right.

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

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.

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

"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

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
> 
>