ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
* upcoming versions of lmtx
@ 2021-05-07 17:51 Hans Hagen
  0 siblings, 0 replies; only message in thread
From: Hans Hagen @ 2021-05-07 17:51 UTC (permalink / raw)
  To: mailing list for ConTeXt users

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
___________________________________________________________________________________

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-05-07 17:51 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-07 17:51 upcoming versions of lmtx Hans Hagen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).