Digital Mars - D.gnu - checked out the D port for Linux?

↑ ↓ ← → Jan Knepper <jan smartsoft.cc> writes:

What do you mean???
The current CVS 'HEAD' should compile and indeed run... It will give you a
couple of messages because of stub-functions, but yes, it parses and invokes
a backend that isn't there. <g>

I expect that the way things have been setup now, i.e. hardly any changes to
the original D-front-end sources, a separate directory with replacement
files for the missing code (and back-end) writing the GLUE layer should be
very well defined within boundaries. I mean, on the D-front-end side we have
the stubs (and there are quite a few of 'em). The back-end (GCC) is known,
but indeed a horrid beast. So may be we can put some BEAUTY in between and
hope we do not get into a copyright conflict with Walt Disney... <g>

Jan



andy wrote:

 Has anyone else checked out the D port for linux?  It works!  I was
 impressed!  I'm starting to think its a better approach because gcc is a
 nasty horrid beast and the more I've dug in it the more I think it sucks
 (gcc).

 -Andy

Aug 11 2002

↑ ↓ ← → andy <acoliver apache.org> writes:

http://amateur-scrolls.sourceforge.net/old/dli/dli-0.0.5.tar.gz

This guy already compiles on linux.

Jan Knepper wrote:
 What do you mean???
 The current CVS 'HEAD' should compile and indeed run... It will give you a
 couple of messages because of stub-functions, but yes, it parses and invokes
 a backend that isn't there. <g>
 
 I expect that the way things have been setup now, i.e. hardly any changes to
 the original D-front-end sources, a separate directory with replacement
 files for the missing code (and back-end) writing the GLUE layer should be
 very well defined within boundaries. I mean, on the D-front-end side we have
 the stubs (and there are quite a few of 'em). The back-end (GCC) is known,
 but indeed a horrid beast. So may be we can put some BEAUTY in between and
 hope we do not get into a copyright conflict with Walt Disney... <g>
 
 Jan
 
 
 
 andy wrote:
 
 
Has anyone else checked out the D port for linux?  It works!  I was
impressed!  I'm starting to think its a better approach because gcc is a
nasty horrid beast and the more I've dug in it the more I think it sucks
(gcc).

-Andy

Aug 11 2002

↑ ↓ ← → andy <acoliver apache.org> writes:

(it being the actor and not the direct object -- meaning it compiles my 
hello world program at least:
http://www.pragmaticprogrammer.com/cgi-local/pragprog?TheDLanguage
)

andy wrote:
 http://amateur-scrolls.sourceforge.net/old/dli/dli-0.0.5.tar.gz
 
 This guy already compiles on linux.
 
 Jan Knepper wrote:
 
 What do you mean???
 The current CVS 'HEAD' should compile and indeed run... It will give 
 you a
 couple of messages because of stub-functions, but yes, it parses and 
 invokes
 a backend that isn't there. <g>

 I expect that the way things have been setup now, i.e. hardly any 
 changes to
 the original D-front-end sources, a separate directory with replacement
 files for the missing code (and back-end) writing the GLUE layer 
 should be
 very well defined within boundaries. I mean, on the D-front-end side 
 we have
 the stubs (and there are quite a few of 'em). The back-end (GCC) is 
 known,
 but indeed a horrid beast. So may be we can put some BEAUTY in between 
 and
 hope we do not get into a copyright conflict with Walt Disney... <g>

 Jan



 andy wrote:


 Has anyone else checked out the D port for linux?  It works!  I was
 impressed!  I'm starting to think its a better approach because gcc is a
 nasty horrid beast and the more I've dug in it the more I think it sucks
 (gcc).

 -Andy

Aug 11 2002

↑ ↓ ← → Jan Knepper <jan opend.org> writes:

Cool!
Great that he visited the newsgroup and told everybody about it! <g>
Jan



andy wrote:
 http://amateur-scrolls.sourceforge.net/old/dli/dli-0.0.5.tar.gz
 
 This guy already compiles on linux.
 
 Jan Knepper wrote:
 
 What do you mean???
 The current CVS 'HEAD' should compile and indeed run... It will give 
 you a
 couple of messages because of stub-functions, but yes, it parses and 
 invokes
 a backend that isn't there. <g>

 I expect that the way things have been setup now, i.e. hardly any 
 changes to
 the original D-front-end sources, a separate directory with replacement
 files for the missing code (and back-end) writing the GLUE layer 
 should be
 very well defined within boundaries. I mean, on the D-front-end side 
 we have
 the stubs (and there are quite a few of 'em). The back-end (GCC) is 
 known,
 but indeed a horrid beast. So may be we can put some BEAUTY in between 
 and
 hope we do not get into a copyright conflict with Walt Disney... <g>

 Jan



 andy wrote:


 Has anyone else checked out the D port for linux?  It works!  I was
 impressed!  I'm starting to think its a better approach because gcc is a
 nasty horrid beast and the more I've dug in it the more I think it sucks
 (gcc).

 -Andy

Aug 11 2002

↑ ↓ ← → andy <acoliver apache.org> writes:

He visited the main newsgroup.

Jan Knepper wrote:
 Cool!
 Great that he visited the newsgroup and told everybody about it! <g>
 Jan
 
 
 
 andy wrote:
 
 http://amateur-scrolls.sourceforge.net/old/dli/dli-0.0.5.tar.gz

 This guy already compiles on linux.

 Jan Knepper wrote:

 What do you mean???
 The current CVS 'HEAD' should compile and indeed run... It will give 
 you a
 couple of messages because of stub-functions, but yes, it parses and 
 invokes
 a backend that isn't there. <g>

 I expect that the way things have been setup now, i.e. hardly any 
 changes to
 the original D-front-end sources, a separate directory with replacement
 files for the missing code (and back-end) writing the GLUE layer 
 should be
 very well defined within boundaries. I mean, on the D-front-end side 
 we have
 the stubs (and there are quite a few of 'em). The back-end (GCC) is 
 known,
 but indeed a horrid beast. So may be we can put some BEAUTY in 
 between and
 hope we do not get into a copyright conflict with Walt Disney... <g>

 Jan



 andy wrote:


 Has anyone else checked out the D port for linux?  It works!  I was
 impressed!  I'm starting to think its a better approach because gcc 
 is a
 nasty horrid beast and the more I've dug in it the more I think it 
 sucks
 (gcc).

 -Andy

Aug 11 2002

↑ ↓ ← → Jan Knepper <jan smartsoft.cc> writes:

Well, I guess we'll have to see what to do next...

I took a quick look at it, but dli is far from done as well. Besides that it
deviates from 'D'...
It would be great if we all could work together someway...

Jan



andy wrote:

 He visited the main newsgroup.

 Jan Knepper wrote:
 Cool!
 Great that he visited the newsgroup and told everybody about it! <g>
 Jan



 andy wrote:

 http://amateur-scrolls.sourceforge.net/old/dli/dli-0.0.5.tar.gz

 This guy already compiles on linux.

 Jan Knepper wrote:

 What do you mean???
 The current CVS 'HEAD' should compile and indeed run... It will give
 you a
 couple of messages because of stub-functions, but yes, it parses and
 invokes
 a backend that isn't there. <g>

 I expect that the way things have been setup now, i.e. hardly any
 changes to
 the original D-front-end sources, a separate directory with replacement
 files for the missing code (and back-end) writing the GLUE layer
 should be
 very well defined within boundaries. I mean, on the D-front-end side
 we have
 the stubs (and there are quite a few of 'em). The back-end (GCC) is
 known,
 but indeed a horrid beast. So may be we can put some BEAUTY in
 between and
 hope we do not get into a copyright conflict with Walt Disney... <g>

 Jan



 andy wrote:


 Has anyone else checked out the D port for linux?  It works!  I was
 impressed!  I'm starting to think its a better approach because gcc
 is a
 nasty horrid beast and the more I've dug in it the more I think it
 sucks
 (gcc).

 -Andy










--
Jan Knepper
Smartsoft, LLC
88 Petersburg Road
Petersburg, NJ 08270
U.S.A.

http://www.smartsoft.cc/

Phone : 609-628-4260
FAX   : 609-628-1267

In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <forsythe alum.mit.edu>

Aug 11 2002

↑ ↓ ← → andy <acoliver apache.org> writes:

Jan Knepper wrote:
 Well, I guess we'll have to see what to do next...
 
 I took a quick look at it, but dli is far from done as well. Besides that it
 deviates from 'D'...


look'd minor.  Walter?  Have you looked at the deviations?  Are they 
going to make it back into D or is this a real fork?

 It would be great if we all could work together someway...
 


totally agree

 Jan
 
 
 
 andy wrote:
 
 
He visited the main newsgroup.

Jan Knepper wrote:

Cool!
Great that he visited the newsgroup and told everybody about it! <g>
Jan



andy wrote:


http://amateur-scrolls.sourceforge.net/old/dli/dli-0.0.5.tar.gz

This guy already compiles on linux.

Jan Knepper wrote:


What do you mean???
The current CVS 'HEAD' should compile and indeed run... It will give
you a
couple of messages because of stub-functions, but yes, it parses and
invokes
a backend that isn't there. <g>

I expect that the way things have been setup now, i.e. hardly any
changes to
the original D-front-end sources, a separate directory with replacement
files for the missing code (and back-end) writing the GLUE layer
should be
very well defined within boundaries. I mean, on the D-front-end side
we have
the stubs (and there are quite a few of 'em). The back-end (GCC) is
known,
but indeed a horrid beast. So may be we can put some BEAUTY in
between and
hope we do not get into a copyright conflict with Walt Disney... <g>

Jan



andy wrote:



Has anyone else checked out the D port for linux?  It works!  I was
impressed!  I'm starting to think its a better approach because gcc
is a
nasty horrid beast and the more I've dug in it the more I think it
sucks
(gcc).

-Andy










 --
 Jan Knepper
 Smartsoft, LLC
 88 Petersburg Road
 Petersburg, NJ 08270
 U.S.A.
 
 http://www.smartsoft.cc/
 
 Phone : 609-628-4260
 FAX   : 609-628-1267
 
 In God we Trust -- all others must submit an X.509 certificate.
     -- Charles Forsythe <forsythe alum.mit.edu>

Aug 12 2002

↑ ↓ ← → Jan Knepper <jan smartsoft.cc> writes:

andy wrote:

 Jan Knepper wrote:
 Well, I guess we'll have to see what to do next...

 I took a quick look at it, but dli is far from done as well. Besides that it
 deviates from 'D'...


 look'd minor.  Walter?  Have you looked at the deviations?  Are they
 going to make it back into D or is this a real fork?


Yes, it looked minor, but I rather have NO deviations, what-so-ever...

Aug 12 2002

↑ ↓ ← → Jonathan Andrew <jon ece.arizona.edu> writes:

Jan Knepper wrote:

 What do you mean???
 The current CVS 'HEAD' should compile and indeed run... It will give you a
 couple of messages because of stub-functions, but yes, it parses and invokes
 a backend that isn't there. <g>

 I expect that the way things have been setup now, i.e. hardly any changes to
 the original D-front-end sources, a separate directory with replacement
 files for the missing code (and back-end) writing the GLUE layer should be
 very well defined within boundaries. I mean, on the D-front-end side we have
 the stubs (and there are quite a few of 'em). The back-end (GCC) is known,
 but indeed a horrid beast. So may be we can put some BEAUTY in between and
 hope we do not get into a copyright conflict with Walt Disney... <g>

 Jan


Yes, I think it is great that there is another option for using D in linux!
Anything
to give more people the opportunity to use this great language. However,
working
to adapt D to the gcc backend opens up D for use in many more platforms than
just linux, and despite the fact that gcc might not be everyone's favorite
compiler,
it is everywhere, and people have come to trust it because of that fact. So
while
I am very glad to see Burton's success, I don't think we have wasted any effort

in working to create the glue layer for GCC, its still a very desirable goal.

Doing things in this fashion also makes the compiler less dependent on changes
to Walter's front end, and should ensure it is more compliant with Walter's
specs.

My two cents,
 -Jon

Aug 12 2002

↑ ↓ ← → andy <acoliver apache.org> writes:

How do you feel Jan?  Is it better to work toward a D compiler in D 
based on Burton's code or to continue to hack GCC?

Burton, what our your plans for this?  Are you interested in working 
with others?  Is this to be open?

I'm on the fence.

-Andy

Jonathan Andrew wrote:
 Jan Knepper wrote:
 
 
What do you mean???
The current CVS 'HEAD' should compile and indeed run... It will give you a
couple of messages because of stub-functions, but yes, it parses and invokes
a backend that isn't there. <g>

I expect that the way things have been setup now, i.e. hardly any changes to
the original D-front-end sources, a separate directory with replacement
files for the missing code (and back-end) writing the GLUE layer should be
very well defined within boundaries. I mean, on the D-front-end side we have
the stubs (and there are quite a few of 'em). The back-end (GCC) is known,
but indeed a horrid beast. So may be we can put some BEAUTY in between and
hope we do not get into a copyright conflict with Walt Disney... <g>

Jan


 
 Yes, I think it is great that there is another option for using D in linux!
 Anything
 to give more people the opportunity to use this great language. However,
 working
 to adapt D to the gcc backend opens up D for use in many more platforms than
 just linux, and despite the fact that gcc might not be everyone's favorite
 compiler,
 it is everywhere, and people have come to trust it because of that fact. So
 while
 I am very glad to see Burton's success, I don't think we have wasted any effort
 
 in working to create the glue layer for GCC, its still a very desirable goal.
 
 Doing things in this fashion also makes the compiler less dependent on changes
 to Walter's front end, and should ensure it is more compliant with Walter's
 specs.
 
 My two cents,
  -Jon

Aug 12 2002

↑ ↓ ← → Jan Knepper <jan smartsoft.cc> writes:

andy wrote:

 How do you feel Jan?  Is it better to work toward a D compiler in D based on
 Burton's code or to continue to hack GCC?


Well, currently the approach to get the D-front-end hooked up with the
GCC-back-end
and integrate the build into the GCC build had a couple of reasons:
1.    It should work on all platforms supporting GCC and interface without too
much
trouble with C and C++ object code generated by GCC.
2.    We do not have to create/write a back-end.
3.    Not too much (preferably no) changes to the current D-front-end as that
is an
ongoing process. Walter will probably work on it as long as he lives. I do not
know
how often Walter will decided to release newer D-front-end code, but when ever
he
does, I prefer to be able to plug it in the current GLUE layer without too much
changing. For this reason I have marked all changes so far with // JAK, so
Walter
could reintegrate them into the D-front-end if he wants to and may be make the
whole
D-front-end upgrading easier.
4.    ??? I am sure there was more...

Currently I feel like Burton's code is of help, but is basically going to be a
different strain of the D compiler. He obviously had more time to spend on it
lately
than I had. Although, it would have been great oif he had shared the code
earlier. A
quick look at the code showed me that Burton made quite a couple more changes
than
might have been necessary, deviating more and more from the D-standard. Sorry,
but I
am very much against this. Thus for now I think not so much hacking, but
integrating
into GCC is still the path to go for us.

Of course, the Open D project is free, so if Burton wants to join the club and
add
his development to opend.org, that would be fine with me.

Jan

Aug 12 2002

↑ ↓ ← → Burton Radons <loth users.sourceforge.net> writes:

andy wrote:
 How do you feel Jan?  Is it better to work toward a D compiler in D 
 based on Burton's code or to continue to hack GCC?


There are good reasons to continue working on GCC, but my personal 
desires didn't match that so I didn't.  That's all that this is boiling 
down to, what you want from the port.  I just wanted something that 
worked, and don't care about proving D to the masses or anything other 
than an i386.

 Burton, what our your plans for this?  Are you interested in working 
 with others?  Is this to be open?


I'll register a SourceForge project once the code is settled.  At this 
point I'm keeping plans on simmer - filling out the implementation is a 
higher priority.  There's no nontrivial missing features, except that 
threads may be troublesome.

Aug 12 2002

↑ ↓ ← → Jonathan Andrew <jon ece.arizona.edu> writes:

Burton Radons wrote:

 I'll register a SourceForge project once the code is settled.  At this
 point I'm keeping plans on simmer - filling out the implementation is a
 higher priority.  There's no nontrivial missing features, except that
 threads may be troublesome.


Ugg, I can only imagine... But then again, you really did a good job
writing the rest of it, so I'm sure you will have no trouble with threads.

-Jon

Aug 13 2002

↑ ↓ ← → andy <acoliver apache.org> writes:

Burton,

Are you interested in working with us at opend.org.  I can tell you its
more reliable than sourceforge.

Secondly,

Jan, Not to tick you off, but for my personal itch, while I may agree 
with you, Burton's code satisfies my reason for getting involved (I 
needed a compiler).  I'll contribute to any specific tasks you can 
assign me, but with GCC, I'm admittedly over my head (I've never done 
this type of work before and GCC is really bad code which makes it hard 
for someone who's not done that kind of work before to get into it) and 
require very specific direction.  Regardless I think if you continue the 
GCC port its in really good hands, if you need my help and can give me 
specific tasks, I'm still willing to help.

I'm going to watch for Burton's threading code and start looking at what 
I needed a working D compiler on Linux for in the first place.

My plans:

A servlet API much like Java's for D. ** why
A minimalistic Servlet Engine to support it.
A Java servlet compatibility bridge.  ** why

** I plan to take a lessons learned approach and only implement the good 
stuff while throwing out the bad.  I'll consult heavily with the folks 
who participated on the Servlet API spec who are able/willing to talk to 
me.  (I know a few of them)

To me widespread open cheap compilers and multiplatform apis that meet 
"standard" business needs are what is required.  The servlet API is the 
biggy for me.

-Andy

Burton Radons wrote:
 andy wrote:
 
 How do you feel Jan?  Is it better to work toward a D compiler in D 
 based on Burton's code or to continue to hack GCC?


 
 There are good reasons to continue working on GCC, but my personal 
 desires didn't match that so I didn't.  That's all that this is boiling 
 down to, what you want from the port.  I just wanted something that 
 worked, and don't care about proving D to the masses or anything other 
 than an i386.
 
 Burton, what our your plans for this?  Are you interested in working 
 with others?  Is this to be open?


 
 I'll register a SourceForge project once the code is settled.  At this 
 point I'm keeping plans on simmer - filling out the implementation is a 
 higher priority.  There's no nontrivial missing features, except that 
 threads may be troublesome.

Aug 13 2002

↑ ↓ ← → Jan Knepper <jan smartsoft.cc> writes:

andy wrote:

 Are you interested in working with us at opend.org.  I can tell you its
 more reliable than sourceforge.


<g> No Kidding!

 Jan, Not to tick you off, but for my personal itch, while I may agree
 with you, Burton's code satisfies my reason for getting involved (I
 needed a compiler).  I'll contribute to any specific tasks you can
 assign me, but with GCC, I'm admittedly over my head (I've never done
 this type of work before and GCC is really bad code which makes it hard
 for someone who's not done that kind of work before to get into it) and
 require very specific direction.  Regardless I think if you continue the
 GCC port its in really good hands, if you need my help and can give me
 specific tasks, I'm still willing to help.


That does not tick me off, don't worry about that.

The GLUE layer is serious enough and I am not about to start coding on that
yet. (Too much to read about the GCC TREE structure first). Once when is
crystal clear what needs to be done, i.e which stubs need to be filled in, it
probably will be  posted opend.org and implementing should take off from
there. But even getting there is still weeks if not months at the current
rate.

 I'm going to watch for Burton's threading code and start looking at what I
 needed a working D compiler on Linux for in the first place. [ ... snip ...
 ]


<g> You seem to be more wanting to have a D compiler for using it than
actually building a compiler. Which is fine and a good reason, but different
that my reasons which are just to get the compiler. I am not up to using it
yet... To hooked up to C++ at this point.

Jan

Aug 13 2002

↑ ↓ ← → "Andrew C. Oliver" <andy superlinksoftware.com> writes:

<g> No Kidding!
  


people that means running with no "Service packs") copy of Windows 2000 
with IIS and sourceforge.....its a toss up.  Perhaps if they deleted 
some of the projects that were created and NEVER HAD A SINGLE commit, 
they could save themselves a few dimes.

That does not tick me off, don't worry about that.

The GLUE layer is serious enough and I am not about to start coding on that
yet. (Too much to read about the GCC TREE structure first). Once when is
crystal clear what needs to be done, i.e which stubs need to be filled in, it
probably will be  posted opend.org and implementing should take off from
there. But even getting there is still weeks if not months at the current
rate.
  


once there are atomic tasks.  I want to brush up
on my C skills.  (even if I have to work with that detestable mutant 
version in the process ;-) )

  

I'm going to watch for Burton's threading code and start looking at what I
needed a working D compiler on Linux for in the first place. [ ... snip ...
]
    


<g> You seem to be more wanting to have a D compiler for using it than
actually building a compiler. Which is fine and a good reason, but different
that my reasons which are just to get the compiler. I am not up to using it
yet... To hooked up to C++ at this point.
  


think the servlet apis etc are crucial (especially to my business needs).

-Andy

Jan

Aug 13 2002