problema en lualatex y mongo

Question

No puedo pretender ser más que un aficionado a Luatex, ni realmente una persona de Lua; Espero que aquellos con más conocimientos que yo perdonen mis errores, pero al menos puedo contar mi experiencia.

Dentro de Luatex, package.searchersse reemplaza, de modo que cuando ingresa requireun módulo de TeX, Luatex usa el mecanismo de búsqueda de TeX, no el habitual. En la práctica, eso significa que cuando ejecuta Lua desde Luatex, no encontrará módulos que encuentre su sistema normal Lua. (No sé lo suficiente sobre la arquitectura, peroasumires deliberado, porque quiere poder mantener de forma segura diferentes estructuras paralelas y asegurarse de que LuaTeX siempre elija módulos apropiados para TeX, incluso si otros módulos están instalados en otro lugar).

En la práctica, eso significa que si ha instalado un módulo lua a través de luarocks, necesitará colocar una copia o incluir un enlace simbólico dentro de un directorio que kpathseaencontrará. Luarocks es algo bastante simple, hasta donde yo sé, y simplemente descarga archivos en un directorio conveniente, por lo que debería poder encontrarlos y vincularlos o copiarlos. La documentación advierte de manera bastante linda: "Por supuesto, no es gran cosa escribir un cargador alternativo y usarlo en un paquete de macros", aunque para algunos de nosotros (¡como yo!) eso puede ser un gran problema.

No tengo experiencia de cómo funciona esto si estás usando un módulo lua que no es Lua puro pero que se basa en código compilado desde C. El propio Luatex ya vincula algunas de esas bibliotecas (como slnunicode), pero no tengo idea de cómo eso puede afectar tu Caso de uso, me temo. Espero que "simplemente funcione", pero...

Cuando estás creando algo que quieres probar de forma independiente y como algo vinculado a TeX, encontré por prueba y error:

Si necesita (como es posible) código que se ejecute solo si está en un entorno u otro, pruebe la definición que lua.versionse definirá si está ejecutando en Luatex. Supongo que, estrictamente hablando, basta con comprobar lua (y comprobar lua.versionno es seguro, porque si luano está definido se producirá un error).
```
if lua and lua.version then
 -- we're in LuaTeX
else
 -- we're not
end
```
Una forma de desarrollarse en paralelo es utilizartexlua como intérprete de lua. Si haces eso, tuvoluntadobtenga acceso automáticamente a las bibliotecas vinculadas estáticamente que siempre forman parte de luatex (como LPEGy slnunicode, es decir, sin necesidad de requirehacerlo). Y su secuencia de comandos se ejecutará más o menos "como si" se estuviera ejecutando mediante una llamada desde un documento TeX. Pero hay un problema. Texlua no "encuentra" automáticamente la kpathseafunción, por lo que debe "decirle" qué hacer:
```
kpse.set_program_name("kpsewhich") -- or whatever
```
Ahora, por ejemplo
```
local xml = require("luaxml-domobject")
```
encontrará el módulo apropiado en el árbol del directorio TeX, usando kpsewhich: sin esa magia, recibirá las tristes quejas depackage.loader no encontrar el módulo. O, peor aún, obtendrásamódulo con ese nombre, pero no el que obtendrá cuando Luatex esté "realmente" a cargo.

¡El siguiente código puede ser más fácil de seguir que la explicación! Si lo ejecuta, texluaobtendrá un resultado; si con luauna salida ligeramente diferente, pero en ambos 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")

Lo que no sé, porque realmente no lo he explorado, es si hay que tener cuidado al eliminar la kpathseaconfiguración de un archivo que se va a llamar directamente desde un documento TeX, donde ya estará configurada. Pero para fines de desarrollo, esta configuración, si es que se necesita alguna, le permite acercarse razonablemente a la forma en que se interpretará un script cuando se llame desde una ejecución de TeX.

Answer 1

No puedo pretender ser más que un aficionado a Luatex, ni realmente una persona de Lua; Espero que aquellos con más conocimientos que yo perdonen mis errores, pero al menos puedo contar mi experiencia.

Dentro de Luatex, package.searchersse reemplaza, de modo que cuando ingresa requireun módulo de TeX, Luatex usa el mecanismo de búsqueda de TeX, no el habitual. En la práctica, eso significa que cuando ejecuta Lua desde Luatex, no encontrará módulos que encuentre su sistema normal Lua. (No sé lo suficiente sobre la arquitectura, peroasumires deliberado, porque quiere poder mantener de forma segura diferentes estructuras paralelas y asegurarse de que LuaTeX siempre elija módulos apropiados para TeX, incluso si otros módulos están instalados en otro lugar).

En la práctica, eso significa que si ha instalado un módulo lua a través de luarocks, necesitará colocar una copia o incluir un enlace simbólico dentro de un directorio que kpathseaencontrará. Luarocks es algo bastante simple, hasta donde yo sé, y simplemente descarga archivos en un directorio conveniente, por lo que debería poder encontrarlos y vincularlos o copiarlos. La documentación advierte de manera bastante linda: "Por supuesto, no es gran cosa escribir un cargador alternativo y usarlo en un paquete de macros", aunque para algunos de nosotros (¡como yo!) eso puede ser un gran problema.

No tengo experiencia de cómo funciona esto si estás usando un módulo lua que no es Lua puro pero que se basa en código compilado desde C. El propio Luatex ya vincula algunas de esas bibliotecas (como slnunicode), pero no tengo idea de cómo eso puede afectar tu Caso de uso, me temo. Espero que "simplemente funcione", pero...

Cuando estás creando algo que quieres probar de forma independiente y como algo vinculado a TeX, encontré por prueba y error:

Si necesita (como es posible) código que se ejecute solo si está en un entorno u otro, pruebe la definición que lua.versionse definirá si está ejecutando en Luatex. Supongo que, estrictamente hablando, basta con comprobar lua (y comprobar lua.versionno es seguro, porque si luano está definido se producirá un error).
```
if lua and lua.version then
 -- we're in LuaTeX
else
 -- we're not
end
```
Una forma de desarrollarse en paralelo es utilizartexlua como intérprete de lua. Si haces eso, tuvoluntadobtenga acceso automáticamente a las bibliotecas vinculadas estáticamente que siempre forman parte de luatex (como LPEGy slnunicode, es decir, sin necesidad de requirehacerlo). Y su secuencia de comandos se ejecutará más o menos "como si" se estuviera ejecutando mediante una llamada desde un documento TeX. Pero hay un problema. Texlua no "encuentra" automáticamente la kpathseafunción, por lo que debe "decirle" qué hacer:
```
kpse.set_program_name("kpsewhich") -- or whatever
```
Ahora, por ejemplo
```
local xml = require("luaxml-domobject")
```
encontrará el módulo apropiado en el árbol del directorio TeX, usando kpsewhich: sin esa magia, recibirá las tristes quejas depackage.loader no encontrar el módulo. O, peor aún, obtendrásamódulo con ese nombre, pero no el que obtendrá cuando Luatex esté "realmente" a cargo.

¡El siguiente código puede ser más fácil de seguir que la explicación! Si lo ejecuta, texluaobtendrá un resultado; si con luauna salida ligeramente diferente, pero en ambos 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")

Lo que no sé, porque realmente no lo he explorado, es si hay que tener cuidado al eliminar la kpathseaconfiguración de un archivo que se va a llamar directamente desde un documento TeX, donde ya estará configurada. Pero para fines de desarrollo, esta configuración, si es que se necesita alguna, le permite acercarse razonablemente a la forma en que se interpretará un script cuando se llame desde una ejecución de TeX.

problema en lualatex y mongo

Respuesta1

información relacionada