Cratera compiler support (read: ZBS's table handling is suboptimal)

[SoniEx2]

Debugging the Cratera compiler is a bit of a pain, as the tables used in the parser get converted to "nil" in the stack window. I still managed to do it, but I don't wish this on anyone.

Announcement post, on the Lua mailing list: https://marc.info/?l=lua-l&m=156458156026332&w=2

The files are "testc.lua' (which tests the compiler) and "dirtycompiler.lua" (which contains the compiler).

[pkulchenko]

@SoniEx2, usually tables are shown as nil when there are circular references in them. You may add __tostring or __serialize handlers that will show the content any way you want it.

[SoniEx2]

there aren't circular references in them but still show up as nil. ideally it'd show e.g. the "string" table as just "string" and all the marker tables as TK.something (as they are stored in the "TK" table). similar to how Lua itself does it when an error happens.

[pkulchenko]

Can you run mobdebug.dump and mobdebug.line on one of the tables (in your code) and show the result?

[SoniEx2]

oh, additionally they do have __tostring, see line 754 on file luatokens.lua.

how would you like me to run those?

[pkulchenko]

Just print the results of them from your code and paste the output here.

[SoniEx2]

from the remote console?

[pkulchenko]

No, from your application, without the IDE. Just add local mobdebug=require'mobdebug' and print mobdebug.dump and mobdebug.line results for one of the tables.

[SoniEx2]

I don't have mobdebug, can I run it from the IDE, without debugger attached?

[pkulchenko]

yes; run it from the IDE (using Run/F6).

[SoniEx2]

mobdebug.dump:  do local _={[1]="\n",[2]="\n",[3]="\n",[4]="\n",[5]="\n",[6]="\n",[7]="\n",[8]="\n",[9]="\n",[10]="\n",[11]="\n",[12]="\n",[13]="\n",[14]="\n",[15]="\n",[16]="\n",[17]="\n",[18]="\n",[19]="\n",[20]="\n",[21]="\n",[22]="TK_LOCAL",[23]="TK_NAME",[24]="is51",[25]="=",[26]="(",[27]="TK_FUNCTION",[28]="(",[29]=")",[30]=nil,[31]=nil,[32]="_ENV",[33]="=",[34]="{",[35]=nil,[36]="hasenv",[37]="=",[38]="TK_TRUE",[39]="}",n=39};local __={};_[30]=_[22];_[31]=_[23];_[35]=_[23];return _;end
mobdebug.line:  {"\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "\n", "TK_LOCAL", "TK_NAME", "is51", "=", "(", "TK_FUNCTION", "(", ")", nil --[[ref]], nil --[[ref]], "_ENV", "=", "{", nil --[[ref]], "hasenv", "=", "TK_TRUE", "}", n = 39} --[[table: 0x1437e60]] --[[incomplete output with shared/self-references skipped]]

[SoniEx2]

see, it's making nils.

[pkulchenko]

Right, you can see why in the dump output: _[30]=_[22];_[31]=_[23];_[35]=_[23]. This means that [30] and [22] elements have the same value and it's not possible to serialize them properly as one literal, same for 23, 31, and 35. That's why they are shown as nil with [[ref]] comment indicating that it's a multi-ref value that can't be literal-serialized.

[SoniEx2]

still makes it hard/impossible to debug.