I uploaded an update of lmtx. The current version of luametatex is 2.05 which is kind of the first supposedly stable release because it incorperates most of what was on my agenda for the first phase (functionality level 20200229 which was when it happened). Of course I expect there to be bugs but not much that can't be solved fast. This version will be the starting point for Wolfgang and me to explore future possibilities (more deep down in the context source code as well as in the engine). We'll see.

Although the performance of lmtx compared to mkiv is hit by more time onsuming backend code, it gets compensated by some optimizations elswehere, a smaller memory footprint, etc. As no one complains about performance it doesn't matter much anyway. Unless you used luajittex there will be no real difference in most cases.

We're in tex live code freeze time so I don't want to change much to the lua and tex part of the distribution right now but nevertheless there has been some minor (practical) adaptations in applying fonts that also reflects on mkiv but that should not be noticeable in practice (also because I rejected some adaptations that had a performance impact in mkiv).

Mojca and I decided to support yet another platform, this time arm 64 bit for which we use a raspberry pi running ubuntu 64 bit, which brings the platforms supported by the build bot to 15:

    freebsd      freebsd-amd64
    openbsd6.5   openbsd6.5-64
    openbsd6.6   openbsd6.6-64
    linux-armhf  linux-aarch64
    linux        linux-64
    mswin        win64

plus windows-clang-x86_64 and windows-x86_64 because they help to identify issues (and provide useful compiler warnings) but for now we stick to the mingw variants because they run a few percent faster than the (smaller) native windows version.

For those interested in tiny machines: the rpi performs roughly one third of what my laptop does which is not bad, although I suppose a more modern intel gen 10 i9 machine will be quite a bit faster. The benchmark is processing the luametatex manual which takes about 12 seconds on the laptop (252 pages, lots of tables, 250+ mp images, 20+ fonts files). A 64 rpi is a little faster than the 32 bit variant. Because tex is a single thread/core process overclocking the little thingie has a positive effect too.

Anyway, it makes us confident that when the source gets into the distribution, which depends on the upcoming repository setup and should not interfere with the tl code freeze, users can compile themselves, something that can contribute to a more comfortable feeling of independence of complex and large compilation infrastructures.

Hopefully I didn't mess up too much,


                                          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 

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

Reply via email to