D.gnu - stringtable implementation
- Jonathan Andrew (13/13) Jul 30 2002 Anybody having luck with the stringtable?
- Burton Radons (8/16) Jul 31 2002 I just put in a linear list. lookup should return a stringvalue or
- Jan Knepper (4/17) Jul 31 2002 Just added the stringtable implementation.
- Jonathan Andrew (3/7) Jul 31 2002 Yeah I just checked out the latest CVS... nice.
- Jan Knepper (16/41) Jul 31 2002 The compiler to use is gcc 3.1.1 I guess.
- Jan Knepper (4/8) Jul 31 2002 Fixed this. This was a little problem in StringTable/StringValue
- Jonathan Andrew (3/16) Jul 31 2002 Cool, I'll check out the latest CVS. How did you track that down btw?
- Jan Knepper (17/25) Aug 01 2002 What do you mean 'track'...
- Walter (3/6) Aug 16 2002 I posted the source to them in the latest zip.
- Jan Knepper (5/11) Aug 16 2002 Thanks!
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
Jul 30 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.
Jul 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
Jul 31 2002
Jan Knepper wrote:Just added the stringtable implementation. Seems to work fine. JanYeah I just checked out the latest CVS... nice. -Jon
Jul 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
Jul 31 2002
Jan Knepper wrote:Fixed this. This was a little problem in StringTable/StringValue which has been resolved. JanIt would read in d source code but wasn't parsing it correctly, complaining about missing semicolons where there were none needed.
Jul 31 2002
Jan Knepper wrote:Jan Knepper wrote:Cool, I'll check out the latest CVS. How did you track that down btw? -JonFixed this. This was a little problem in StringTable/StringValue which has been resolved. JanIt would read in d source code but wasn't parsing it correctly, complaining about missing semicolons where there were none needed.
Jul 31 2002
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... JanCool, I'll check out the latest CVS. How did you track that down btw?Fixed this. This was a little problem in StringTable/StringValue which has been resolved. JanIt would read in d source code but wasn't parsing it correctly, complaining about missing semicolons where there were none needed.
Aug 01 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.
Aug 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.
Aug 16 2002