August 12, 2002
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
> 
> 


August 12, 2002
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


August 13, 2002
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.

August 13, 2002
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

August 13, 2002
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.
> 


August 13, 2002
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


August 13, 2002
>
>
><g> No Kidding!
>  
>
Of course that doesn't say much.  Between an unpatched (for windows 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.
>  
>
Yes.  I think the effort is in good hands with you.  I'll certainly help 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.
>  
>
Yes, and I think that the multiplatform compiler is crucial, but I also think the servlet apis etc are crucial (especially to my business needs).

-Andy

>Jan
>
>
>
>  
>


August 13, 2002
>
>
> 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).

Hmm, unfortunately, it would seem there _isn't enough_ to read about the gcc
tree
structure :(.  I will post anything I find here though.

-Jon


1 2
Next ›   Last »