www.digitalmars.com         C & C++   DMDScript  

D - Is a Linux port of D planned/in the works?

reply Vesselin Peev <Vesselin_member pathlink.com> writes:
Hello,

I'm starting to look at D and from what I've seen, it's quite nice.
Especially when Walter, the man who implemented Zortech/Symantec C all by
himself, is totally behind it.
I'm looking into starting a large project with D (at least considering it as one
of the implementation languages), but the problem is,
I want to know the chances that there would be a Linux port of D and
accompanying tools in 1 or 2 years from now.
If there won't be -- OK, that's great, but if there would be -- it would be even
better.

Just asking.

Wishing the best,
Vesselin.
Aug 09 2002
next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Vesselin Peev wrote:


 I'm starting to look at D and from what I've seen, it's quite nice.
 Especially when Walter, the man who implemented Zortech/Symantec C all by
 himself, is totally behind it.
 I'm looking into starting a large project with D (at least considering it as
one
 of the implementation languages), but the problem is,
 I want to know the chances that there would be a Linux port of D and
 accompanying tools in 1 or 2 years from now.
 If there won't be -- OK, that's great, but if there would be -- it would be
even
 better.


1 or 2 years indeed.  You can get my port at:

http://amateur-scrolls.sourceforge.net/old/dli

It's not presentable yet if you need it to produce efficient code.
Aug 09 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:
I know you've still probably got lots of work to do on it, but:
Would it be possible for Walter to provide a link from the alpha page to
this?

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D53E5E2.9050208 users.sourceforge.net...

 Vesselin Peev wrote:


 I'm starting to look at D and from what I've seen, it's quite nice.
 Especially when Walter, the man who implemented Zortech/Symantec C all




by

 himself, is totally behind it.
 I'm looking into starting a large project with D (at least considering




it as one

 of the implementation languages), but the problem is,
 I want to know the chances that there would be a Linux port of D and
 accompanying tools in 1 or 2 years from now.
 If there won't be -- OK, that's great, but if there would be -- it would




be even

 better.


 1 or 2 years indeed.  You can get my port at:

 http://amateur-scrolls.sourceforge.net/old/dli

 It's not presentable yet if you need it to produce efficient code.
Aug 09 2002
next sibling parent reply Vesselin Peev <Vesselin_member pathlink.com> writes:
Very, very nice.
And yes, the port deserves attention, so a link at the front page should be
provided.
Boy, it sure is a comfortable feeling knowing that I'm *NOT* speaking to large
corporations here intent on controlling the world for money gain and fame.

Something else I'd like to say about D:

Please do not include generics ala C++.
Something along the lines of _parametric polymorphism_ should be way better.
Agree?

Reading the D spec, I couldn't find information about the current implementation
of the garbage collector, and I still haven't run anything significant to
measure its performance.
I'm working on a JVM implementatation at work, so I've recently become
acquainted with some gritty-nitty details in Java and a GC for it, too, so I
think it would be useful to comment.

I think that the spec may mislead the less knowledgeable of us, because it
reads:

"It is not predictable when a collection gets run, so the program can
arbitrarilly pause. 
The time it takes for a collection to run is not bounded. While in practice it
is very quick, this cannot be guaranteed."

The first sentence is not necessarily true if D has an incremental GC.
This should be the way to go, in fact, since there are many applications like
games and even network apps that do not like GC "hiccups" at all, and would fail
when these occur. Garbage collection should be distributed over time.
For those who say that this may detract a program written in D from achieving
maximum performance, it should be said that most users do not care if something
runs a tiny bit slower all the time, but they do care if they perceive speedy
execution interrupted by intermittent pauses.

The second sentence is not necessarily true, too. While an absolute guarantee
cannot be done by current algorithms that I know of, a lot can be done to
achieve almost guaranteed upper bound. The "train" scheme does this, for
example.

So a concurrent generational incremental algorithm with predictable upper-bound
should be the Holy Grail here, and for just one example, Sun's reference Java
implementation has come a long way in this regard with its 1.4 version.

Anyway, one thing is to speak, another is to implement... ;-)
I'd be glad if I hear any comments.

Kind regards to everyone on this forum!
I'll watch this space closely...


In article <aj0qcu$2dkj$1 digitaldaemon.com>, anderson says...

I know you've still probably got lots of work to do on it, but:
Would it be possible for Walter to provide a link from the alpha page to
this?

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D53E5E2.9050208 users.sourceforge.net...

 Vesselin Peev wrote:


 I'm starting to look at D and from what I've seen, it's quite nice.
 Especially when Walter, the man who implemented Zortech/Symantec C all




by

 himself, is totally behind it.
 I'm looking into starting a large project with D (at least considering




it as one

 of the implementation languages), but the problem is,
 I want to know the chances that there would be a Linux port of D and
 accompanying tools in 1 or 2 years from now.
 If there won't be -- OK, that's great, but if there would be -- it would




be even

 better.


 1 or 2 years indeed.  You can get my port at:

 http://amateur-scrolls.sourceforge.net/old/dli

 It's not presentable yet if you need it to produce efficient code.
Aug 09 2002
next sibling parent Burton Radons <loth users.sourceforge.net> writes:
Vesselin Peev wrote:


 Please do not include generics ala C++.
 Something along the lines of _parametric polymorphism_ should be way better.
 Agree?



Err, I see C++ templates often described as parametric polymorphism. 
Could you be explicit about what you mean?



 Reading the D spec, I couldn't find information about the current
implementation
 of the garbage collector, and I still haven't run anything significant to
 measure its performance.



My garbage collector doesn't work; it'll delete anything owned only be 
globals, and is not yet type-based.  Sometime the generator will create 
_very_ fast functions for scanning objects, and that's useful no matter 
what.

I'm dubious of generational GC benefits, but the train algorithm looks 
fine to me.  It's not a current priority, and I don't know much about GC 
in any case.



 I think that the spec may mislead the less knowledgeable of us, because it
 reads:
 
 "It is not predictable when a collection gets run, so the program can
 arbitrarilly pause. 
 The time it takes for a collection to run is not bounded. While in practice it
 is very quick, this cannot be guaranteed."



This is stating what can be expected from an arbitrary implementation; 
it's not saying anything about the potential.  The easiest 
implementation is offloading this onto a Hans Boehm where these 
statements are true, so that's the basis you should be writing your code 
from when you want maximum portability.
Aug 10 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Vesselin Peev" <Vesselin_member pathlink.com> wrote in message
news:aj1cn4$30g8$1 digitaldaemon.com...

 Very, very nice.
 And yes, the port deserves attention, so a link at the front page should


be

 provided.
 Boy, it sure is a comfortable feeling knowing that I'm *NOT* speaking to


large

 corporations here intent on controlling the world for money gain and fame.


<g>


 Please do not include generics ala C++.
 Something along the lines of _parametric polymorphism_ should be way


better.

 Agree?


There will be some form of generics, but I don't know what form it will
take, just that I think there's *got* to be a better way than C++ templates.



 Reading the D spec, I couldn't find information about the current


implementation

 of the garbage collector, and I still haven't run anything significant to
 measure its performance.


It's a simple mark/sweep collector. I would say it's performance is usable,
but not great. The spec deliberately leaves out what kind of algorithms to
use in the collector, as that should be a quality of implementation issue. D
implementors should be as free as possible to innovate in the GC area.


 I'm working on a JVM implementatation at work, so I've recently become
 acquainted with some gritty-nitty details in Java and a GC for it, too, so


I

 think it would be useful to comment.


I learned about GC doing improved collectors for JVMs, too <g>.


 I think that the spec may mislead the less knowledgeable of us, because it
 reads:
 "It is not predictable when a collection gets run, so the program can
 arbitrarilly pause.
 The time it takes for a collection to run is not bounded. While in


practice it

 is very quick, this cannot be guaranteed."
 The first sentence is not necessarily true if D has an incremental GC.


Correct, but I wish to leave the GC algorithm up to the implementor, so it
is true from a spec point of view.


 This should be the way to go, in fact, since there are many applications


like

 games and even network apps that do not like GC "hiccups" at all, and


would fail

 when these occur. Garbage collection should be distributed over time.


I foresee that possibly many different GC's can be "plugged in" to D
runtimes for different application needs.


 For those who say that this may detract a program written in D from


achieving

 maximum performance, it should be said that most users do not care if


something

 runs a tiny bit slower all the time, but they do care if they perceive


speedy

 execution interrupted by intermittent pauses.


Yes, I agree.


 The second sentence is not necessarily true, too. While an absolute


guarantee

 cannot be done by current algorithms that I know of, a lot can be done to
 achieve almost guaranteed upper bound. The "train" scheme does this, for
 example.


I know that one can almost guarantee it, but that still falls a bit short
for apps that must have an absolute guarantee.
Aug 13 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:aj0qcu$2dkj$1 digitaldaemon.com...

 I know you've still probably got lots of work to do on it, but:
 Would it be possible for Walter to provide a link from the alpha page to
 this?


Done.
Aug 13 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D53E5E2.9050208 users.sourceforge.net...

 1 or 2 years indeed.  You can get my port at:

 http://amateur-scrolls.sourceforge.net/old/dli

 It's not presentable yet if you need it to produce efficient code.


I just put up a couple links to your port. On your web page, could you put
up a few comments about it, what it does, the state it is in, etc., instead
of just the zip? Thanks!
Aug 13 2002
prev sibling parent Vesselin Peev <Vesselin_member pathlink.com> writes:
Oops, just saw D.gnu to be handling what I asked about...

In article <aj0nqk$2as3$1 digitaldaemon.com>, Vesselin Peev says...

Hello,

I'm starting to look at D and from what I've seen, it's quite nice.
Especially when Walter, the man who implemented Zortech/Symantec C all by
himself, is totally behind it.
I'm looking into starting a large project with D (at least considering it as one
of the implementation languages), but the problem is,
I want to know the chances that there would be a Linux port of D and
accompanying tools in 1 or 2 years from now.
If there won't be -- OK, that's great, but if there would be -- it would be even
better.

Just asking.

Wishing the best,
Vesselin.
Aug 09 2002