On Sat, Sep 5, 2015 at 7:17 PM, David Carlisle <[email protected]> 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!
