[luatex] Allowing or switching to string indexes in Lua bytecode registers

[Kalrish Bäakjen]

On Sat, Sep 5, 2015 at 7:17 PM, David Carlisle <d.p.carlisle at gmail.com> wrote:
> The relevant files are not yet on ctan (and so not in texlive) the sources
> are available from the web view of the svn, but you would need to
> extract the ltluatex.tex and ltluatex.lua files or wait for the next release
> (hopefully in a few weeks)
>
> meanwhile if you have ltluatex.dtx from SVN (make sure you have the current one,
> it's been updated a few times today)  then just make a file
> ltluatex.ins that looks like
>
> \input docstrip
> \generate{\file{ltluatex.tex}{\from{ltluatex.dtx}{tex,plain}}}
> \nopostamble
> \nopreamble
> \generate{\file{ltluatex.lua}{\from{ltluatex.dtx}{lua}}}
>
> run tex in that to get ltluatex.tex and .lua then
>
> \input{ltluatex}
>
> in a document should work.

Thank you! I'll see if I can try without breaking my installation, hehe.

> in ltluatex the assumption is that you can just use require() rather than
> needing a special wrapper (as require uses kpse anyway now)

If I have understood you correctly, the "custom searcher" that I
speculated about could solve the limitation in discussion without any
change on the packages' side (that is, without any "special wrapper";
they would continue to use require just as they do now, and the
searcher would take care of putting the code in a bytecode register or
restoring it from one if on a dumping session).

> it seems to me that you can't
> byte compile arbitrary code, and this is such a case, that  (for
> simple use at least)
> the code could be structured so that you can  byte compile each file separately.

Why can't arbitrary code be byte-compiled? Is what you refer to
related to what's mentioned in the LuaTeX Reference Manual (see
below)?

> Section 4.8.1 (LUA bytecode registers)
> Note: The function must not contain any upvalues. Currently, functions containing upvalues can be stored (and their upvalues are set to nil), but this is an artifact of the current Lua implementation and thus subject to change.

I had been wondering what the consequences of this were.

> On the other hand a more general scheme could probably work although
> I'd need to try building a test case to follow the details below.
> I see the general direction you are suggesting but some of the details
> escape me:-)

I can write some code, but not today :-). If the "custom searcher"
solution fits, I think that something at the core of LuaTeX (either
LuaTeX itself or the LuaTeX format) would require changes, which would
indeed not be something to decide lightly. Feel free to discuss
further.

Thank you!