Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Hmm.. are we up to it? (the fixing part) I would very much like to see it solved (I suppose I'm not alone ;) and wouldn't mind investing alot of effort into it, but won't be able to without support..
I spent a couple of weeks on it, more or less full time. I gave up eventually. Was utterly defeated. It just laughed at my effort. The problem is built in at a very deep level and there's a lot of code involved.
You or anyone else is of course very (if not to say extremely) welcome to take a stab at it. I'd be happy to assist, but you must be prepared to dig through the resolver machinery at all levels, the program dumper, and the better part of the compiler. Maybe it just needs fresh eyes.
I have a fresh set of eyes, I'll eye through the code to see if I'm able to make out the big picture.. if so, then I wouldn't mind getting out my blade and have a stab at it ;)
If I understand the problem correctly, this is what happends:
compiling A... in A, find reference to B compile B in B, find reference to A already compiling A - error
This can't be the whole truth though, since this far it works fine for me, but toss in some more references between a few more modules, and it all comes down in pieces..
Yes. The reason it works most of the time are that it has been extended several times to cope with the most obvious cases, and later on with many not so obvious cases. But to really solve the problem I believe it's necessary to:
- Make the resolver machinery fully two pass, so that the compilation passes can span several files. This means the resolver code in the master needs to handle compilation passes.
Doesn't sound too awfull, but then I'm not yet in a position to know what I'm talking about here.
- Compile the individual classes in a file independently of each other. Right now the compiler goes through every file from the beginning to the end two times and that's it.
Ooh.. definitely sounds thougher.. Are the rules for how to compile a file set in language.yacc?
The program dumper makes it more interesting since it encodes stuff in a very different order compared to compilation from source. The way that modules really are instantiated classes also complicates matters.
The many partial fixes are problematic since they are fairly elaborate themselves and makes the code difficult to understand (mainly the placeholders and the supporter system in program.c). In my attempt I tried to do yet another add-on solution, but as said earlier that failed miserably. It might work better if one begins by completely removing all the previous solutions in place.
If the files involved gets compiled successfully, won't the dumper be able to produce working object files (or what the files it dumps is called)? At least this could be adressed separately from the compiler issue.(?)
Grubbas project to make a totally new compiler will of course solve this problem (along with many other, on top of being incredibly cool in just about every way). Unfortunately it still has a long way to go to be useful, though.
Exciting! would love to hear (know) more about it :)
I've tried to search in the archives of related discussions, but must have failed to use the right search terms..
Many discussions on this has taken place IRL. I guess most of those that are in writing are in the old swedish forum in InfoKOM (the internal lyskom system at Roxen IS).
Oh, I see.. by "internal" does it mean I can't access it from outside (non roxen people), or from liu's LysKOM? Tried a lyskom client, but came to the conclusion of preferring the mailing list method to comunicate.. ;)
//K