Compilation problems in 7.8

[Frigolit]

When trying to do "indices(FileFormat);" in Hilfe with Pike 7.8.34 i get
the following errors:

/usr/local/pike/7.8.34/lib/modules/FileFormat.pmod/Games.pmod/Duke1.pmod:68:Cannot
inherit program in pass 2 which is not fully compiled yet.
/usr/local/pike/7.8.34/lib/modules/FileFormat.pmod/Games.pmod/Duke1.pmod:68:(You
probably have a cyclic symbol dependency that the compiler cannot handle.)
/usr/local/pike/7.8.34/lib/modules/FileFormat.pmod/Games.pmod/Keen1.pmod:23:Cannot
inherit program in pass 2 which is not fully compiled yet.
/usr/local/pike/7.8.34/lib/modules/FileFormat.pmod/Games.pmod/Keen1.pmod:23:(You
probably have a cyclic symbol dependency that the compiler cannot handle.)

In Keen1.pmod, the lines are the following:
22: class Level {
23:        inherit FileFormat._TileLevelFormat;

It's the same in Duke1.pmod.
So from what I understand, FileFormat.pmod/_TileLevelFormat.pike hasn't
been compiled yet, so the classes in Duke1 and Keen1 can't inherit it.
However this wasn't an issue with at 7.7.145, nor earlier versions (down
to 7.6).

Any ideas on how to solve this?

// Pontus Rodling

Where is FileFormat coming from? It's not in my source.

[Martin Stjernholm]

Pontus Rodling <frigolit@...> wrote:

> So from what I understand, FileFormat.pmod/_TileLevelFormat.pike
> hasn't been compiled yet, so the classes in Duke1 and Keen1 can't
> inherit it.

Yes. In some way the compilation of _TileLevelFormat.pike trigs the
compilation of the other two modules. You can probably solve the cycle
by replacing some typed object references somewhere with "object".

The problem is that they can be tedious to find. The best way to start
could be to replace every object type in _TileLevelFormat.pike that
isn't vital (i.e. not an inherit), see if that solves the problem, and
then reintroduce them gradually.

> However this wasn't an issue with at 7.7.145, nor earlier versions
> (down to 7.6).

I made a fix about a month or so ago that made the delayed compilation
stuff a little more strict. It was necessary to avoid cases where the
compiler in stage 2 could get delayed compiled programs still in stage
1 to inherit.

The cyclic dependencies in the compiler is the single most annoying
problem in pike, imo. To really fix it would unfortunately require a
major rewrite of the whole resolver system.

[Frigolit]

Martin Stjernholm wrote:

> Pontus Rodling <frigolit@...> wrote:
>
>  
>> So from what I understand, FileFormat.pmod/_TileLevelFormat.pike
>> hasn't been compiled yet, so the classes in Duke1 and Keen1 can't
>> inherit it.
>>    
>
> Yes. In some way the compilation of _TileLevelFormat.pike trigs the
> compilation of the other two modules. You can probably solve the cycle
> by replacing some typed object references somewhere with "object".
>
> The problem is that they can be tedious to find. The best way to start
> could be to replace every object type in _TileLevelFormat.pike that
> isn't vital (i.e. not an inherit), see if that solves the problem, and
> then reintroduce them gradually.
>
>  

I found the problem!
In FileFormat.pmod/module.pmod there's a decode() function which
attempts to decode a file using all available modules which of course
includes Keen1 and Duke1.
However _TileLevelFormat is using functions in
FileFormat.pmod/module.pmod which triggered the compilation.

Maybe I should move the decode() function into an ANY module (like
Image.ANY).
Currently I solved it by replacing:
FileFormat.Games.Keen1.decodelevel(data);
FileFormat.Games.Duke1.decodelevel(data);
with:
FileFormat["Games"]["Keen1"]["decodelevel"](data);
FileFormat["Games"]["Duke1"]["decodelevel"](data);

Thanks!
// Pontus Rodling

Moving it to an ANY-module sounds like a good idea. If it solves the
problem it's a bonus.