Thread overview
stringtable implementation
Jul 30, 2002
Jonathan Andrew
Jul 31, 2002
Burton Radons
Jul 31, 2002
Jan Knepper
Jul 31, 2002
Jonathan Andrew
Jul 31, 2002
Jan Knepper
Aug 01, 2002
Jan Knepper
Aug 01, 2002
Jonathan Andrew
Aug 01, 2002
Jan Knepper
Aug 16, 2002
Walter
Aug 16, 2002
Jan Knepper
July 30, 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

July 31, 2002
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.

July 31, 2002
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

July 31, 2002
Jan Knepper wrote:
> Just added the stringtable implementation.
> Seems to work fine.
> Jan
> 
Yeah I just checked out the latest CVS... nice.
-Jon



July 31, 2002
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


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


August 01, 2002
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
> 
Cool, I'll check out the latest CVS. How did you track that down btw?
-Jon



August 01, 2002
> >>>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
> Cool, I'll check out the latest CVS. How did you track that down btw?

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


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



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