[lltx] lualatex-math cannot find unpack function

[Philipp Gesang]

···<date: 2013-08-07, Wednesday>···<from: Wolfgang Jeltsch>···

> Am Mittwoch, den 07.08.2013, 09:14 +0200 schrieb Philipp Gesang:
> > ···<date: 2013-08-06, Tuesday>···<from: Wolfgang Jeltsch>···
> > 
> > > Am Montag, den 05.08.2013, 23:01 +0200 schrieb Philipp Gesang:
> > > > In most documents the fallback is available through luaotfload or
> > > > lualibs since l-lua.lua establishes a compatibility layer [1].
> > > 
> > > I think it would be best if the compatibility code would exist in only
> > > one core Lua module, which is then imported by the other modules. I
> > > think the current solution, where the same patching of table (or _G) is
> > > done in several modules, is somehow wrong.
> > 
> > The code was written by Hans, it is him you have to address your
> > feature requests to.
> 
> Hmm, the lualibs and luaotfload packages don’t list Hans as a
> maintainer, but they do list you. ;-)

To be fair, although the library code is written by Hans he
doesn’t actually “maintain” the lualibs package.

>                                        Furthermore, luaotfload wasn’t
> developed by Hans at all from what I can see on the CTAN package
> description.

First sentence of the manual:

  This package is an adaptation of the ConTEXt font loading system.

This is just one of multiple attributions. Also read the file
headers: they make it precisely clear who contributed which file.
As to the CTAN package: Hans does not maintain luaotfload, he
supplies the fontloader which we integrate into the Latex
ecosystem. Luaotfload does not modify the fontloader code in any
way.

> Is lualibs actually a fork of some parts of ConTeXt that is now further
> developed by the lualibs maintainers? Or does it just mirror some parts
> of ConTeXt, so that it gets its changes from the upstream ConTeXt code?

The libraries are imported from Context untouched on a regular
basis. We only package them into two self-contained files for
convenience. Lualibs is not a fork, and you could as well achieve
the same effect by using the files from Context directly, if you
know how.

> > Although there is a good deal of duplication between Lualibs and
> > Luaotfload code for obvious reasons, I don’t see a problem
> > insofar as the basic modules do not break when loaded multiple
> > times. Anyways, it would be possible to have the Lualibs detect
> > the presence of Luaotfload and then differentiate as to which
> > libraries it loads. But then the parts would be loaded out of
> > order. I’m not optimistic regarding the outcome as some code uses
> > fallbacks for missing functionality and we would have to isolate
> > those regions and reinject them so they use the correct version.
> > Naturally that is going to be a fragile arrangement which would
> > have to be checked every time there is a change to the core
> > libraries. I don’t think that’d be worth the effort since the
> > gain is at best marginal.
> 
> I think you have misunderstood me. I proposed to put the compatibility
> code into a core package that is loaded by all packages that need it.
> There is already luatexbase-compat. Why not use this?

Good question. It wouldn’t hurt, I guess, but in any case the
code in the Lualibs and Luaotfload will stay as it is.

Philipp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://tug.org/pipermail/lualatex-dev/attachments/20130807/e114dd8c/attachment.bin>