• Jonathan Andrew <jon ece.arizona.edu> Jul 30 2002
• Burton Radons <loth users.sourceforge.net> Jul 31 2002
• Jan Knepper <jan smartsoft.cc> Jul 31 2002
• Jonathan Andrew <jon ece.arizona.edu> Jul 31 2002
• Jan Knepper <jan smartsoft.cc> Jul 31 2002
• Jan Knepper <jan smartsoft.cc> Jul 31 2002
• Jonathan Andrew <jon ece.arizona.edu> Jul 31 2002
• Jan Knepper <jan smartsoft.cc> Aug 01 2002
• "Walter" <walter digitalmars.com> Aug 16 2002
• Jan Knepper <jan smartsoft.cc> Aug 16 2002

Anybody having luck with the stringtable?
I think this is probably just a simple hash table, which might be
evidenced by the presence of hash functions in root.c, they don't
seem to be called many places, so perhaps they are meant
to be used in stringtable::insert, stringtable::update, and
stringtable::lookup,
all 3 of which are currently just stub functions, and unfortunately
their absence makes the front end crash upon execution.

Walter, (or anybody else that knows) could you clarify this for me?
An idea of how the stringtable is used and how it is composed would be
a great help.

Thanks,
 -Jon

Jonathan Andrew wrote:

 Anybody having luck with the stringtable?
 I think this is probably just a simple hash table, which might be
 evidenced by the presence of hash functions in root.c, they don't
 seem to be called many places, so perhaps they are meant
 to be used in stringtable::insert, stringtable::update, and
 stringtable::lookup,
 all 3 of which are currently just stub functions, and unfortunately
 their absence makes the front end crash upon execution.



I just put in a linear list.  lookup should return a stringvalue or 
NULL; insert should put in a new entry if it doesn't exist or return 
NULL if it does, and update should return the current value if it does 
exist or create a new one if it doesn't.

For the StringValues, the "ptrvalue" field is used by the client. 
"lstring.string" points to the alocated string.  "length" is the length 
of the string.  That's all that used.

Just added the stringtable implementation.
Seems to work fine.
Jan



Jonathan Andrew wrote:

 Anybody having luck with the stringtable?
 I think this is probably just a simple hash table, which might be
 evidenced by the presence of hash functions in root.c, they don't
 seem to be called many places, so perhaps they are meant
 to be used in stringtable::insert, stringtable::update, and
 stringtable::lookup,
 all 3 of which are currently just stub functions, and unfortunately
 their absence makes the front end crash upon execution.

 Walter, (or anybody else that knows) could you clarify this for me?
 An idea of how the stringtable is used and how it is composed would be
 a great help.

 Thanks,
  -Jon

Jan Knepper wrote:
 Just added the stringtable implementation.
 Seems to work fine.
 Jan
 


-Jon

Jonathan Andrew wrote:

 Hey Jan, sorry to bug you, I replaced the assert(0); in
 File::remove()
 in root.c with std::remove((char *)this->name->toChars()); ,
 got it to
 compile and produce an executable.


I would just use an 'unlink' there instead.

 It would read in d source code but wasn't parsing it
 correctly,
 complaining about missing semicolons where there were none
 needed.

 I think it might have had to do something with a change I made
 in
 lexer.h.

 In struct Token in lexer.h  there is an anonymous struct
 struct{
   wchar_t *ustring;
   unsigned len;
 };


The compiler to use is gcc 3.1.1 I guess.

 My compiler would complain about that, so I took out the
 struct{ };
 part, leaving the variable declarations, gcc (2.95.3) didn't
 have
 a problem with it, so I assumed it was fine.

 In short, could removing that struct part have caused the
 strange
 parsing I saw, or do you think there is something else wrong?


Could, but I do not know. I have not tried to run a .d file
through it yet.

Also, use gcc 3.1.1 since that seems to compile the front end
better and is closer to the latest version of GCC.

Also, do not try to modify files in
~/dmd
~/root
As these are Walter's original files. The more we keep those the
same, the easier it will be to upgrade to a newer D front-end.
Although, the unlink was necessary.
The missing functions are basically stubbed in ~/jak and ~/unix
where you can change what ever is necessary.

Jan

Jan Knepper wrote:

 It would read in d source code but wasn't parsing it
 correctly,
 complaining about missing semicolons where there were none
 needed.




Fixed this. This was a little problem in StringTable/StringValue
which has been resolved.
Jan

Jan Knepper wrote:
 Jan Knepper wrote:
 
 
It would read in d source code but wasn't parsing it
correctly,
complaining about missing semicolons where there were none
needed.




 Fixed this. This was a little problem in StringTable/StringValue
 which has been resolved.
 Jan
 


-Jon

It would read in d source code but wasn't parsing it
correctly,
complaining about missing semicolons where there were none
needed.




 which has been resolved.
 Jan




What do you mean 'track'...

I do not always 'track' things down.

In this case I was working on something else (I have to make a living
too!) and all to sudden realized that if there was nothing wrong with all
the other minor patches it had to be StringTable/StringValue. Than it hit
me like lightning where I had made a mistake in my strain of thought. So
I just opened the files. Made the changes, recompiled it and after that
it worked...

Well, I found an other problem with comments like /* */ when broken over
more than one line like:
/************************
 *
 *
 */
Not being processed correctly which I also fixed and reported to Walter.
I am sure he fixed it already, but just to make sure...

Jan

I posted the source to them in the latest zip.

"Jonathan Andrew" <jon ece.arizona.edu> wrote in message
news:3D4702CD.3E73F15C ece.arizona.edu...
 Walter, (or anybody else that knows) could you clarify this for me?
 An idea of how the stringtable is used and how it is composed would be
 a great help.

Thanks!
Will use your's instead in dgcc.
Less code to duplicate...
Jan



Walter wrote:

 I posted the source to them in the latest zip.

 "Jonathan Andrew" <jon ece.arizona.edu> wrote in message
 news:3D4702CD.3E73F15C ece.arizona.edu...
 Walter, (or anybody else that knows) could you clarify this for me?
 An idea of how the stringtable is used and how it is composed would be
 a great help.