problema em lualatex e mongo

Question

Não posso afirmar que sou mais do que um amador com Luatex, nem realmente uma pessoa de Lua; Espero que aqueles com mais conhecimento do que eu perdoem meus erros, mas posso pelo menos relatar minha experiência.

Dentro do Luatex, package.searchersé substituído, de modo que quando você usa requireum módulo do TeX, o Luatex usa o mecanismo de busca do TeX, não o usual. Isso significa, na prática, que quando você executa Lua a partir do Luatex, ele não encontrará módulos que seu sistema normal Lua encontra. (Não sei o suficiente sobre arquitetura, maspresumiré deliberado, porque quer ser capaz de manter diferentes estruturas paralelas com segurança e ter certeza de que LuaTeX sempre pegará módulos apropriados para TeX, mesmo se outros módulos estiverem instalados em outro lugar.)

Na prática isso significa que se você instalou um módulo lua via luarocks, você precisará colocar uma cópia, ou incluir um link simbólico, dentro de um diretório que kpathseairá encontrar. Luarocks é uma coisa bastante simplória, até onde eu sei, e simplesmente despeja os arquivos em um diretório conveniente, então você deve ser capaz de encontrá-los e vinculá-los ou copiá-los. A documentação avisa de forma bastante fofa: "É claro que não é grande coisa escrever um carregador alternativo e usá-lo em um pacote de macros", embora para alguns de nós (como eu!) isso possa ser um grande problema.

Não tenho experiência de como isso funciona se você estiver usando um módulo lua que não é Lua pura, mas depende de código compilado de C. O próprio Luatex já vincula algumas dessas bibliotecas (como slnunicode), mas não tenho ideia de como isso pode afetar seu caso de uso, receio. Eu espero que "simplesmente funcione", mas ...

Quando você está construindo algo que deseja testar tanto como independente quanto como algo que será vinculado ao TeX, descobri por tentativa e erro:

Se você precisar (como é possível) de um código que seja executado apenas se estiver em um ambiente ou outro, teste a definição de lua.versionqual será definido se você estiver executando em Luatex. Suponho que, estritamente falando, apenas uma verificação de lua é suficiente (e uma verificação de lua.versionnão é segura, porque se luafor indefinido ocorrerá um erro).
```
if lua and lua.version then
 -- we're in LuaTeX
else
 -- we're not
end
```
Uma maneira de desenvolver em paralelo é usar texluacomo intérprete lua. Se você fizer isso, vocêvaiobter acesso automaticamente às bibliotecas vinculadas estaticamente que sempre fazem parte do luatex (como LPEGe slnunicode, ou seja, sem precisar requiredelas). E seu script será executado mais ou menos "como se" estivesse sendo executado por meio de uma chamada de um documento TeX. Mas há um problema. Texlua não "encontra" automaticamente a kpathseafunção, então você precisa "dizer" a ele o que fazer:
```
kpse.set_program_name("kpsewhich") -- or whatever
```
Agora, por exemplo
```
local xml = require("luaxml-domobject")
```
encontrará o módulo apropriado na árvore de diretórios do TeX, usando kpsewhich: sem essa mágica, você receberá reclamações sombrias por package.loadernão encontrar o módulo. Ou, pior, você obteráamódulo com esse nome, mas não aquele que você obterá quando Luatex estiver "realmente" no comando.

O código abaixo pode ser mais fácil de seguir do que a explicação! Se você executá-lo, texluaobterá uma saída; se tiver luauma saída um pouco diferente, mas em ambos os casos funciona.

local luatexing = lua and lua.version

-- local lpeg shadows global lpeg if luatex is running this
local lpeg = lpeg

if luatexing then
   kpse.set_program_name("kpsewhich")
else
   -- if luatex is not in charge we need to require the library
   lpeg = require("lpeg")
end

-- The output here will differ depending on
-- whether we have luatex (with statically
-- linked unicode library) or not. Of course,
-- we could then `require` something
-- appropriate.

if luatexing then
   io.write(unicode.utf8.lower("Ê") .. "\n")
else
   io.write(string.lower("Ê") .. "!\n")
end

-- But this will work in either case: with
-- luatex via the statically linked lpeg
-- library. With regular lua via the require

j = lpeg.P("a matcher")

io.write(j:match("a matcher") .. "\n")

O que não sei, porque ainda não explorei muito, é se é preciso ter cuidado ao remover a kpathseaconfiguração de um arquivo que será chamado diretamente de um documento TeX, onde já estará definido. Mas para fins de desenvolvimento, esta configuração, se alguma for necessária, permite que você chegue razoavelmente perto da forma como um script será interpretado quando for chamado de dentro de uma execução do TeX.

Answer 1

Não posso afirmar que sou mais do que um amador com Luatex, nem realmente uma pessoa de Lua; Espero que aqueles com mais conhecimento do que eu perdoem meus erros, mas posso pelo menos relatar minha experiência.

Dentro do Luatex, package.searchersé substituído, de modo que quando você usa requireum módulo do TeX, o Luatex usa o mecanismo de busca do TeX, não o usual. Isso significa, na prática, que quando você executa Lua a partir do Luatex, ele não encontrará módulos que seu sistema normal Lua encontra. (Não sei o suficiente sobre arquitetura, maspresumiré deliberado, porque quer ser capaz de manter diferentes estruturas paralelas com segurança e ter certeza de que LuaTeX sempre pegará módulos apropriados para TeX, mesmo se outros módulos estiverem instalados em outro lugar.)

Na prática isso significa que se você instalou um módulo lua via luarocks, você precisará colocar uma cópia, ou incluir um link simbólico, dentro de um diretório que kpathseairá encontrar. Luarocks é uma coisa bastante simplória, até onde eu sei, e simplesmente despeja os arquivos em um diretório conveniente, então você deve ser capaz de encontrá-los e vinculá-los ou copiá-los. A documentação avisa de forma bastante fofa: "É claro que não é grande coisa escrever um carregador alternativo e usá-lo em um pacote de macros", embora para alguns de nós (como eu!) isso possa ser um grande problema.

Não tenho experiência de como isso funciona se você estiver usando um módulo lua que não é Lua pura, mas depende de código compilado de C. O próprio Luatex já vincula algumas dessas bibliotecas (como slnunicode), mas não tenho ideia de como isso pode afetar seu caso de uso, receio. Eu espero que "simplesmente funcione", mas ...

Quando você está construindo algo que deseja testar tanto como independente quanto como algo que será vinculado ao TeX, descobri por tentativa e erro:

Se você precisar (como é possível) de um código que seja executado apenas se estiver em um ambiente ou outro, teste a definição de lua.versionqual será definido se você estiver executando em Luatex. Suponho que, estritamente falando, apenas uma verificação de lua é suficiente (e uma verificação de lua.versionnão é segura, porque se luafor indefinido ocorrerá um erro).
```
if lua and lua.version then
 -- we're in LuaTeX
else
 -- we're not
end
```
Uma maneira de desenvolver em paralelo é usar texluacomo intérprete lua. Se você fizer isso, vocêvaiobter acesso automaticamente às bibliotecas vinculadas estaticamente que sempre fazem parte do luatex (como LPEGe slnunicode, ou seja, sem precisar requiredelas). E seu script será executado mais ou menos "como se" estivesse sendo executado por meio de uma chamada de um documento TeX. Mas há um problema. Texlua não "encontra" automaticamente a kpathseafunção, então você precisa "dizer" a ele o que fazer:
```
kpse.set_program_name("kpsewhich") -- or whatever
```
Agora, por exemplo
```
local xml = require("luaxml-domobject")
```
encontrará o módulo apropriado na árvore de diretórios do TeX, usando kpsewhich: sem essa mágica, você receberá reclamações sombrias por package.loadernão encontrar o módulo. Ou, pior, você obteráamódulo com esse nome, mas não aquele que você obterá quando Luatex estiver "realmente" no comando.

O código abaixo pode ser mais fácil de seguir do que a explicação! Se você executá-lo, texluaobterá uma saída; se tiver luauma saída um pouco diferente, mas em ambos os casos funciona.

local luatexing = lua and lua.version

-- local lpeg shadows global lpeg if luatex is running this
local lpeg = lpeg

if luatexing then
   kpse.set_program_name("kpsewhich")
else
   -- if luatex is not in charge we need to require the library
   lpeg = require("lpeg")
end

-- The output here will differ depending on
-- whether we have luatex (with statically
-- linked unicode library) or not. Of course,
-- we could then `require` something
-- appropriate.

if luatexing then
   io.write(unicode.utf8.lower("Ê") .. "\n")
else
   io.write(string.lower("Ê") .. "!\n")
end

-- But this will work in either case: with
-- luatex via the statically linked lpeg
-- library. With regular lua via the require

j = lpeg.P("a matcher")

io.write(j:match("a matcher") .. "\n")

O que não sei, porque ainda não explorei muito, é se é preciso ter cuidado ao remover a kpathseaconfiguração de um arquivo que será chamado diretamente de um documento TeX, onde já estará definido. Mas para fins de desenvolvimento, esta configuração, se alguma for necessária, permite que você chegue razoavelmente perto da forma como um script será interpretado quando for chamado de dentro de uma execução do TeX.

problema em lualatex e mongo

Responder1

informação relacionada