Hi,
With luametatex becoming more mature, it's time to get rid of some old
code. For instance, we have lmt files that assume 5.4, but regular lua
files should work for luajittex (5.2) and luatex (5.3). Most noticable
are the lack of bitwise operators and integer devision in luajittex, but
there are more details.
Till now, part of this problem is deals with by using functions that can
actually be seen as macros that can are optimized when the format is
made (kind of c-ish). It's not pretty, but works and probably no one
ever noticed it. That mechanism will probably stay (for the fun of it)
but the less it's used for creating the format the better.
Another complication is that we use mtxrun for both running luatex and
luametatex so there we need to be friendly to all three engines. But ...
eventually luametatex will be the stub for also luatex and then mtxrun
can become 5.4+ (the --luatex flag already works that way). An
alternative is that we have mtxrun.lmt as well as mtxrun.lua but why
bother.
I also need to keep in mind that there are users of the font code that
expect it to work with luajittex but that can be dealt with by splitting
files.
By splitting modules in lua and lmt variants we can tune for luametatex
so that will happen anyway (less code, no engine specific sections,
again a smaller format file, etc).
All these adaptations have no functional consequences but of course
there can be temporary hickups because of some oversight.
At the engine level there is also some occasional cleanup, like
replacing some left-over low level 5.2/5.3 lua api things by 5.4 but
that's kind of ongoing (as lua progresses). In principle users should
not notice such changes, just like probably no one noticed that we now
use a different zip library (in the beginning some high speed variants
were tested too but it's not that critical and I just don't want
architecture dependencies that complicate a build and can influence
stability). I still try to minimize the code base and dependencies,
although I admit that sometimes stuff gets added (like the more
efficient memory allocator). But my target max binary size of 3MB (less
with link time optimization and related stripping) and fast compilation
goals are still met.
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___________________________________________________________________________________
