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.

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.

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

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

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

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.

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

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

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