That's a great thing that can be done with the current wrapper
functions.
Look for the use of __DMCSTUB in the .cpp files in ~/jak and you will
find all the stubs.

Jan



Jonathan Andrew wrote:

> Jan Knepper wrote:
> > Anyone doing anything???
> > I will be too busy until after the weekend...
> > Monday/Tuesday I will continue where I left off.
> > Jan
> >
>
> I'm trying to figure out the gcc stuff, For the sake of interfacing, it might be interesting to output whatever the D front end uses as an intermediary representation to a file.
>
> -Jon

Jan Knepper wrote:
> That's a great thing that can be done with the current wrapper
> functions.
> Look for the use of __DMCSTUB in the .cpp files in ~/jak and you will
> find all the stubs.
> 
> Jan
> 
>

I'm guessing genobjfile is the most important one for this, but I still
have to examine the front end source some more and try to understand it
better.

I'm also getting some strange compile errors when I try to use the front
end to parse code. I will try and hunt some of these down, as the same
code compiled fine under windows.

Finally, I think I might try and write the inifile function, unless it's
already been done by someone else.
-Jon

Jonathan Andrew wrote:

> Jan Knepper wrote:
> > That's a great thing that can be done with the current wrapper
> > functions.
> > Look for the use of __DMCSTUB in the .cpp files in ~/jak and you will
> > find all the stubs.
> >
> > Jan
> >
> >
>
> I'm guessing genobjfile is the most important one for this, but I still have to examine the front end source some more and try to understand it better.

That seems to be the main entry to the back-end.

> I'm also getting some strange compile errors when I try to use the front end to parse code. I will try and hunt some of these down, as the same code compiled fine under windows.

What kind of errors?
Can you post them?

> Finally, I think I might try and write the inifile function, unless it's already been done by someone else.

Not that I am aware of.
It might be good if we had a subgroup here probably D.gnu.work or something
like that where people could drop a note when they start on something.
Any one on this?

Jan

>>I'm also getting some strange compile errors when I try to use the front
>>end to parse code. I will try and hunt some of these down, as the same
>>code compiled fine under windows.
> 
> 
> What kind of errors?
> Can you post them?
> 

The only one I can think of right now is when I try to import stdio for
a simple "hello world" program, it gives me

"stdio.d(75): cannot implicitly convert wchar[135034216] to char[]"

Also, the -I flag doesn't appear to work, I may just be doing something
wrong though. Right now I have to move all my source files to the dmd
directory to compile.

>>Finally, I think I might try and write the inifile function, unless it's
>>already been done by someone else.
> 
> 
> Not that I am aware of.
> It might be good if we had a subgroup here probably D.gnu.work or something
> like that where people could drop a note when they start on something.
> Any one on this?
> 

I think that's a good idea.

-Jon

Jonathan Andrew wrote:

> >>I'm also getting some strange compile errors when I try to use the front end to parse code. I will try and hunt some of these down, as the same code compiled fine under windows.
> >
> >
> > What kind of errors?
> > Can you post them?
> >
>
> The only one I can think of right now is when I try to import stdio for a simple "hello world" program, it gives me
>
> "stdio.d(75): cannot implicitly convert wchar[135034216] to char[]"

OK, I know about that one. It think it has to do with char/wchar_t processing. Burton Radons has fixed this I think, but I figured I will wait until Walter posts the next D front-end...

> Also, the -I flag doesn't appear to work, I may just be doing something wrong though. Right now I have to move all my source files to the dmd directory to compile.

This probably has just to do with checking for \ instead of for / on Unix.

> >>Finally, I think I might try and write the inifile function, unless it's already been done by someone else.
> > Not that I am aware of.
> > It might be good if we had a subgroup here probably D.gnu.work or something
> > like that where people could drop a note when they start on something.
> > Any one on this?
> I think that's a good idea.

Anyone else?

Jan

Jan Knepper wrote:

> Actually, I was talking to any one involved in the GLUE layer for the D
> front-end to GCC back-end, but I appreciate your response.
> 
> Did you also run into the problem with the /* */ comments broken over more
> than one line like:
> 
> /*******************
>  *
>  *
>  */
> 
> The D front-end would error on the * on the second line. This construction
> however is being used in phobos quite a few times, so I guess the D
> front-end should parse it.

Yes, it's mistakenly perceiving the "*\n" sequence as being the end of the comment.  Just add a check that it really aborted the loop on a "/".  I haven't the slightest idea why that code works in DOS; I can only imagine that the '\n' was never being seen.

> > Also, the -I flag doesn't appear to work, I may just be doing something wrong though. Right now I have to move all my source files to the dmd directory to compile.
>
> This probably has just to do with checking for \ instead of for / on Unix.

Hmmm, this seems to be implemented!
Are you sure you are using the latest source and in 'linux' defined in your
compile?

Jan

Do you have any more specific's on the char / wchar_t mixup?
I guess under certain circumstances the parse treats a "bla bla" as char and
under others as wchar_t.
Jan



Burton Radons wrote:

> Jan Knepper wrote:
>
> > Actually, I was talking to any one involved in the GLUE layer for the D front-end to GCC back-end, but I appreciate your response.
> >
> > Did you also run into the problem with the /* */ comments broken over more than one line like:
> >
> > /*******************
> >  *
> >  *
> >  */
> >
> > The D front-end would error on the * on the second line. This construction however is being used in phobos quite a few times, so I guess the D front-end should parse it.
>
> Yes, it's mistakenly perceiving the "*\n" sequence as being the end of
> the comment.  Just add a check that it really aborted the loop on a "/".
>   I haven't the slightest idea why that code works in DOS; I can only
> imagine that the '\n' was never being seen.

Burton Radons wrote:

> Jan Knepper wrote:
> 
>> Actually, I was talking to any one involved in the GLUE layer for the D
>> front-end to GCC back-end, but I appreciate your response.
>>
>> Did you also run into the problem with the /* */ comments broken over more
>> than one line like:
>>
>> /*******************
>>  *
>>  *
>>  */
>>
>> The D front-end would error on the * on the second line. This construction
>> however is being used in phobos quite a few times, so I guess the D
>> front-end should parse it.
> 
> 
> Yes, it's mistakenly perceiving the "*\n" sequence as being the end of the comment.  Just add a check that it really aborted the loop on a "/".  I haven't the slightest idea why that code works in DOS; I can only imagine that the '\n' was never being seen.

Wait, I get it - DOS uses "\r\n" sequences, so it was never seeing a "*\n" pattern.  This bug would show up if your tool was using sensible line endings and disappear if it then used DOS.

Jan Knepper wrote:
>>>Also, the -I flag doesn't appear to work, I may just be doing something
>>>wrong though. Right now I have to move all my source files to the dmd
>>>directory to compile.
>>
>>This probably has just to do with checking for \ instead of for / on Unix.
> 
> 
> Hmmm, this seems to be implemented!
> Are you sure you are using the latest source and in 'linux' defined in your
> compile?
> 
> Jan
> 

Hmm, I didn't know I needed to define linux, where do I do this?
-Jon