www.digitalmars.com         C & C++   DMDScript  

D.gnu - d-front-end.tar.gz

reply Jan Knepper <jan opend.org> writes:
I did some work on porting the sources to FreeBSD/Linux. Placed them in 
a directory 'd' as subdirectory if the 'gcc' subdirectory in the GNU 
Compiler Collection (GCC).

Not done yet, but most of the files compile, although some still will 
need quite a bit of work as Walter's Complex Numbers implementation is 
unique in itself, but not quite as portable to other compilers/target 
platforms.

The files are in CVS and at 03:00 EST (00:00 PST) everyday an export is 
done to create the d-front-end.tar.gz file which becomes available for 
download through http://www.opend.org/

Let me know who also wants to work on it and needs CVS access.

Jan
Jul 25 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
I'd suggest just skipping the complex number stuff until the compiler gets
bootstrapped.

"Jan Knepper" <jan opend.org> wrote in message
news:3D40B3D8.8090403 opend.org...
 I did some work on porting the sources to FreeBSD/Linux. Placed them in
 a directory 'd' as subdirectory if the 'gcc' subdirectory in the GNU
 Compiler Collection (GCC).

 Not done yet, but most of the files compile, although some still will
 need quite a bit of work as Walter's Complex Numbers implementation is
 unique in itself, but not quite as portable to other compilers/target
 platforms.

 The files are in CVS and at 03:00 EST (00:00 PST) everyday an export is
 done to create the d-front-end.tar.gz file which becomes available for
 download through http://www.opend.org/

 Let me know who also wants to work on it and needs CVS access.

 Jan

Jul 26 2002
parent Jan Knepper <jan smartsoft.cc> writes:
That's EXACTLY my thinking. So for now I just #ifdef __DMC__'ed it out!
Jan



Walter wrote:

 I'd suggest just skipping the complex number stuff until the compiler gets
 bootstrapped.

 "Jan Knepper" <jan opend.org> wrote in message
 news:3D40B3D8.8090403 opend.org...
 I did some work on porting the sources to FreeBSD/Linux. Placed them in
 a directory 'd' as subdirectory if the 'gcc' subdirectory in the GNU
 Compiler Collection (GCC).

 Not done yet, but most of the files compile, although some still will
 need quite a bit of work as Walter's Complex Numbers implementation is
 unique in itself, but not quite as portable to other compilers/target
 platforms.

 The files are in CVS and at 03:00 EST (00:00 PST) everyday an export is
 done to create the d-front-end.tar.gz file which becomes available for
 download through http://www.opend.org/

 Let me know who also wants to work on it and needs CVS access.

 Jan


Jul 26 2002
prev sibling parent reply Jan Knepper <jan opend.org> writes:
OK,
I did some more porting and disabled quite a bit of code that had to 
much to do with the back-end. Disabled it and put a 'stub' in place.
Also added quite a couple of files with 'stub's' for other missing 
back-end code.
Right now almost everything compiles. It actually does all compile with 
Digital Mars C++ and creates a .exe file too.
So... Who else is going to do something???

Jan



Jan Knepper wrote:
 I did some work on porting the sources to FreeBSD/Linux. Placed them in 
 a directory 'd' as subdirectory if the 'gcc' subdirectory in the GNU 
 Compiler Collection (GCC).
 
 Not done yet, but most of the files compile, although some still will 
 need quite a bit of work as Walter's Complex Numbers implementation is 
 unique in itself, but not quite as portable to other compilers/target 
 platforms.
 
 The files are in CVS and at 03:00 EST (00:00 PST) everyday an export is 
 done to create the d-front-end.tar.gz file which becomes available for 
 download through http://www.opend.org/
 
 Let me know who also wants to work on it and needs CVS access.

Jul 28 2002
next sibling parent reply andy <acoliver apache.org> writes:
Okay so this is to say that you've gotten the Front end code to compile 
with DMC++.  Okay lets identify the tasks at hand.

1. Agree on C++ Coding conventions - I suggest following Walter's 
constructs as they seem a very nice way to write C++ to me and it will 
produce good code.

2. Getting the front end to compile within the GCC make process, 
bootstrapped and all.

3. Document the above

3. Identifying the middle "tier", come up with some sturdy interfaces

4. Come up with a list of features to implement for our first round.

I should have *some* time to work on this for the moment.  I've still a 
bit more work to do on my time monopolizing task, but its wrapping up 
nicely.

-Andy


Jan Knepper wrote:
 OK,
 I did some more porting and disabled quite a bit of code that had to 
 much to do with the back-end. Disabled it and put a 'stub' in place.
 Also added quite a couple of files with 'stub's' for other missing 
 back-end code.
 Right now almost everything compiles. It actually does all compile with 
 Digital Mars C++ and creates a .exe file too.
 So... Who else is going to do something???
 
 Jan
 
 
 
 Jan Knepper wrote:
 
 I did some work on porting the sources to FreeBSD/Linux. Placed them 
 in a directory 'd' as subdirectory if the 'gcc' subdirectory in the 
 GNU Compiler Collection (GCC).

 Not done yet, but most of the files compile, although some still will 
 need quite a bit of work as Walter's Complex Numbers implementation is 
 unique in itself, but not quite as portable to other compilers/target 
 platforms.

 The files are in CVS and at 03:00 EST (00:00 PST) everyday an export 
 is done to create the d-front-end.tar.gz file which becomes available 
 for download through http://www.opend.org/

 Let me know who also wants to work on it and needs CVS access.


Jul 29 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
andy wrote:

 Okay so this is to say that you've gotten the Front end code to compile
 with DMC++.  Okay lets identify the tasks at hand.

 1. Agree on C++ Coding conventions - I suggest following Walter's
 constructs as they seem a very nice way to write C++ to me and it will
 produce good code.

Sorry, since I am coding and I seem to have been the only one that has been coding so far I will follow my own C++ coding conventions. Take a look at it. They are rather easy to follow.
 2. Getting the front end to compile within the GCC

99 % of that is done as I suspect that the new changes will compile without too much trouble.
 make process, bootstrapped and all.

Creating the necessary Config/makefile. No biggie.
 3. Document the above

I think I will stay away from doing to much on that! <g>
 4. Identifying the middle "tier", come up with some sturdy interfaces

I think the interface is basically already there. All the current stub functions that will required implementation at some time.
 5. Come up with a list of features to implement for our first round.

Well, go ahead and take a look at the sources...
 I should have *some* time to work on this for the moment.  I've still a
 bit more work to do on my time monopolizing task, but its wrapping up
 nicely.

I have heard this for some time now and have not seen one line of code you wrote or one change in a Makefile, readme or anything else, but posts in the newsgroup or through email. I have not heard the first positive comment about toy2 indicating that some actually looked at it and now you suggest I use someone else's C++ coding conventions? I guess it is time to wake up. I've got an EGO too you know! Jan
 -Andy

 Jan Knepper wrote:
 OK,
 I did some more porting and disabled quite a bit of code that had to
 much to do with the back-end. Disabled it and put a 'stub' in place.
 Also added quite a couple of files with 'stub's' for other missing
 back-end code.
 Right now almost everything compiles. It actually does all compile with
 Digital Mars C++ and creates a .exe file too.
 So... Who else is going to do something???

 Jan



 Jan Knepper wrote:

 I did some work on porting the sources to FreeBSD/Linux. Placed them
 in a directory 'd' as subdirectory if the 'gcc' subdirectory in the
 GNU Compiler Collection (GCC).

 Not done yet, but most of the files compile, although some still will
 need quite a bit of work as Walter's Complex Numbers implementation is
 unique in itself, but not quite as portable to other compilers/target
 platforms.

 The files are in CVS and at 03:00 EST (00:00 PST) everyday an export
 is done to create the d-front-end.tar.gz file which becomes available
 for download through http://www.opend.org/

 Let me know who also wants to work on it and needs CVS access.



-- 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>
Jul 29 2002
parent reply andy <acoliver apache.org> writes:
 
 Well, go ahead and take a look at the sources...
 

I'm doing that right now.
 
I should have *some* time to work on this for the moment.  I've still a
bit more work to do on my time monopolizing task, but its wrapping up
nicely.

I have heard this for some time now and have not seen one line of code you wrote or one change in a Makefile, readme or anything else, but posts in the newsgroup or through email. I have not heard the first positive comment about toy2 indicating that some actually looked at it and now you suggest I use someone else's C++ coding conventions? I guess it is time to wake up. I've got an EGO too you know!

I looked at it, I haven't gotten it to compile yet. Looking at it, so far I'm impressed. I have to install gcc 2.96x on my linux box and then I can compile it. (toy doesn't compile on my windows laptop). The statement on coding conventions was general as we're about to undertake a realtively large undertaking in C++ (which I believe even you stated that strong coding conventions were needed), I nominated walters because it sounded the least contentious and I have some understanding of his (having a large code sampling to look at). If you would kindly document yours or give me a large code sampling to look at I'm ameniable to using them instead. You've very sensitive. We'll need to find a way to work together keeping in mind that I'm not very sensitive. -Andy
 Jan
 
 
 
 
-Andy

Jan Knepper wrote:

OK,
I did some more porting and disabled quite a bit of code that had to
much to do with the back-end. Disabled it and put a 'stub' in place.
Also added quite a couple of files with 'stub's' for other missing
back-end code.
Right now almost everything compiles. It actually does all compile with
Digital Mars C++ and creates a .exe file too.
So... Who else is going to do something???

Jan



Jan Knepper wrote:


I did some work on porting the sources to FreeBSD/Linux. Placed them
in a directory 'd' as subdirectory if the 'gcc' subdirectory in the
GNU Compiler Collection (GCC).

Not done yet, but most of the files compile, although some still will
need quite a bit of work as Walter's Complex Numbers implementation is
unique in itself, but not quite as portable to other compilers/target
platforms.

The files are in CVS and at 03:00 EST (00:00 PST) everyday an export
is done to create the d-front-end.tar.gz file which becomes available
for download through http://www.opend.org/

Let me know who also wants to work on it and needs CVS access.



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

Jul 29 2002
parent Jan Knepper <jan smartsoft.cc> writes:
andy wrote:

 Well, go ahead and take a look at the sources...


Good!
I should have *some* time to work on this for the moment.  I've still a
bit more work to do on my time monopolizing task, but its wrapping up
nicely.

wrote or one change in a Makefile, readme or anything else, but posts in the newsgroup or through email. I have not heard the first positive comment about toy2 indicating that some actually looked at it and now you suggest I use someone else's C++ coding conventions? I guess it is time to wake up. I've got an EGO too you know!

far I'm impressed. I have to install gcc 2.96x on my linux box and then I can compile it. (toy doesn't compile on my windows laptop).

I think I compiled toy2 with 2.95.1...
 The statement on coding conventions was general as we're about to
 undertake a realtively large undertaking in C++ (which I believe even
 you stated that strong coding conventions were needed),

Yeah, we had a discussion about that a while back in relation to excessive use of C++ features. Well, believe me, I will stay away from those as that is my preference. Also... I do not think the undertaking is relatively that large... Just the GLUE layer does not seem nearly as large as my usual projects... However, I am used to a certain coding style. I.e. a how formating of headers and sources which I am dependent on to be able to work fast and effective. Toy2 is a little example of that. Not the best, but it will do. The latest additions to CVS are an example of that too. When you take a look at it you will get the idea. I do not expect others (since we are out here all in our own time) to use the exact same formatting. Other things I would like, no MI and no STL, preferably no templates. Might come up with a few more...
 I nominated walters because it sounded the least contentious and I have some
 understanding of his (having a large code sampling to look at).  If you
 would kindly document yours or give me a large code sampling to look at
 I'm ameniable to using them instead.

toy2 and the new additions to CVS.
 You've very sensitive.  We'll need to find a way to work together keeping in
mind
 that I'm not very sensitive.

<g> Sensitive? Excuse me... I think we're all sensitive at times. I feel like I am the only one that has put as much time and effort in this project. It might have been better to write something 'after' review of what currently has been done. I think it would have made a bit more sense. Jan
Jul 29 2002
prev sibling parent reply Jonathan Andrew <jon ece.arizona.edu> writes:
I've been trying to get it to compile it on my 2.95.3, everything
worked except the 3 files you mentioned in the README, did you say
you've corrected those?

Oh, I also had to add the -fpermissive switch to get around some
"integer constant out of range" errors in lexer.c.
I'm not sure if that would break compilation with gcc 3.1 or not,
but it might be a nice thing to add to the makefile to make
the build process a little more version agnostic for those
who want to get involved without upgrading their compiler version.
Just an idea, its no trouble for me personally.

I didn't have much luck fixing the errors in the other files.
depending on where you got with them, I will take a harder
look today. (func.c, tocsym.c, and todt.c)

-Jon
Jul 29 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
Jonathan Andrew wrote:

 I've been trying to get it to compile it on my 2.95.3, everything
 worked except the 3 files you mentioned in the README, did you say
 you've corrected those?

Well, I stubbed them as tocsym.c and todt.c seem to be very involved with the backend of which we do not have the sources.
 Oh, I also had to add the -fpermissive switch to get around some
 "integer constant out of range" errors in lexer.c.
 I'm not sure if that would break compilation with gcc 3.1 or not,
 but it might be a nice thing to add to the makefile to make
 the build process a little more version agnostic for those
 who want to get involved without upgrading their compiler version.
 Just an idea, its no trouble for me personally.

Hmmm, I used gcc 3.1.1
 I didn't have much luck fixing the errors in the other files.
 depending on where you got with them, I will take a harder
 look today. (func.c, tocsym.c, and todt.c)

func.c is kinda cute. tocsym.c and todt.c have new versions in CVS and for sure in the .tar.gz file I think. Jan
Jul 29 2002
parent reply Jonathan Andrew <jon ece.arizona.edu> writes:
Jan Knepper wrote:

 
 func.c is kinda cute.
 tocsym.c and todt.c have new versions in CVS and for sure in the
 .tar.gz file I think.
 Jan
 
 

non-lvalue in unary & error in func.c? I tried mucking around with it, but I'm a total noob, and gcc's cryptic error messages don't help much, though I hear 3.1.x is much better than previous versions in that regard. -Jon
Jul 29 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
Jonathan Andrew wrote:

 Jan Knepper wrote:

 func.c is kinda cute.
 tocsym.c and todt.c have new versions in CVS and for sure in the
 .tar.gz file I think.

non-lvalue in unary & error in func.c? I tried mucking around with it, but I'm a total noob, and gcc's cryptic error messages don't help much, though I hear 3.1.x is much better than previous versions in that regard.

That's one of the funny onces I need to take a closer look at. The problem is that g++ does not know how to determine an address of a 'this' pointer: for (pf = &this; *pf; pf = &(*pf)->overnext) { One of the reasons why we should have Digital Mars C++ for BSD and Linux I guess. I just made a couple more changes. They will be available in the .tar.gz file at 0:00 PST. Jan
Jul 29 2002
next sibling parent Jonathan Andrew <jon ece.arizona.edu> writes:
 
 That's one of the funny onces I need to take a closer look at.
 The problem is that g++ does not know how to determine an address of a
 'this' pointer:
 
    for (pf = &this; *pf; pf = &(*pf)->overnext)
    {
 
 One of the reasons why we should have Digital Mars C++ for BSD and Linux
 I guess.
 
 I just made a couple more changes. They will be available in the .tar.gz
 file at 0:00 PST.
 
 Jan
 

Well, if DMC++ for linux existed, We most likely wouldn't be porting DMD over to linux, and what fun would that be? I'll see if I can figure anything out in func.c, I'll also check out the new tarball. Any changes I should look out for? -Jon
Jul 29 2002
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Jan Knepper wrote:

 Jonathan Andrew wrote:
 
 
Jan Knepper wrote:


func.c is kinda cute.
tocsym.c and todt.c have new versions in CVS and for sure in the
.tar.gz file I think.

non-lvalue in unary & error in func.c? I tried mucking around with it, but I'm a total noob, and gcc's cryptic error messages don't help much, though I hear 3.1.x is much better than previous versions in that regard.

That's one of the funny onces I need to take a closer look at. The problem is that g++ does not know how to determine an address of a 'this' pointer: for (pf = &this; *pf; pf = &(*pf)->overnext) {

This is using it for read only, so just make a copy and get the address of that: FuncDeclaration *pthis = this; for (ph = &pthis; *pf; pf = &(*pf)->overnext)
Jul 29 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
Burton Radons wrote:

 That's one of the funny onces I need to take a closer look at.
 The problem is that g++ does not know how to determine an address of a
 'this' pointer:

    for (pf = &this; *pf; pf = &(*pf)->overnext)
    {

This is using it for read only, so just make a copy and get the address of that: FuncDeclaration *pthis = this; for (ph = &pthis; *pf; pf = &(*pf)->overnext)

That is not quite the same... &this is the address of the 'this' pointer probably somewhere on the stack or in a register??? &pthis is the address of 'pthis' which is probably an address on the stack, but at a different location than 'this'. However, the code does not seem to depend on this, so it will work. Jan
Jul 29 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Jan Knepper" <jan smartsoft.cc> wrote in message
news:3D461EDB.11F7B733 smartsoft.cc...
 However, the code does not seem to depend on this, so it will work.

Yes, I folded the change in to the mainline. Any other mods to help gcc, let me know. -Walter
Aug 18 2002
parent Jan Knepper <jan smartsoft.cc> writes:
 Yes, I folded the change in to the mainline. Any other mods to help gcc, let
 me know.

Yes! If you download the tar.gz. file (WinZip will expand it) and grep on 'JAK' just in the sources in the dmd directory. It isn't that much, but there are a few things... Thanks! Jan
Aug 19 2002