проблема с lualatex и mongo

Question

Я не могу утверждать, что являюсь более чем любителем Luatex, и не являюсь настоящим пользователем Lua; надеюсь, более осведомленные люди простят мне мои ошибки, но я, по крайней мере, могу поделиться своим опытом.

В Luatex, package.searchersзаменяется, так что когда вы requireмодуль из TeX, Luatex использует механизм поиска TeX, а не обычный. Это означает на практике, что когда вы запускаете Lua из Luatex, он не найдет модули, которые находит ваша обычная система Lua. (Я не знаю достаточно об архитектуре, но япредполагать(Это сделано намеренно, поскольку необходимо обеспечить возможность безопасной поддержки различных параллельных структур и гарантировать, что LuaTeX всегда будет подбирать модули, соответствующие TeX, даже если в другом месте установлены другие модули.)

На практике это означает, что если вы установили модуль lua через luarocks, вам нужно будет либо поместить копию, либо включить символическую ссылку в каталог, который kpathseaнайдет. Luarocks — довольно простая штука, насколько я могу судить, и просто сбрасывает файлы в удобный каталог, так что вы должны иметь возможность найти их и сослаться на них или скопировать их. Документация довольно мило предупреждает: «Конечно, не так уж и сложно написать альтернативный загрузчик и использовать его в пакете макросов», хотя для некоторых из нас (вроде меня!) это может быть довольно большой проблемой.

У меня нет опыта, как это работает, если вы используете модуль lua, который не является чистым Lua, а полагается на код, скомпилированный из C. Сам Luatex уже связывает некоторые такие библиотеки (например, slnunicode), но я, боюсь, понятия не имею, как это может повлиять на ваш вариант использования. Я бы надеялся, что это будет "просто работать", но...

Когда вы создаете что-то, что хотите протестировать и как автономное, и как то, что будет связано с TeX, я методом проб и ошибок пришел к следующему:

Если вам нужен (а вы, вероятно, можете) код, который выполняется только в том случае, если он находится в той или иной среде, проверьте определение, lua.versionкоторое будет определено, если вы работаете в Luatex. Я полагаю, строго говоря, достаточно просто проверки lua (а проверка lua.versionнебезопасна, потому что если luaне определено, то возникнет ошибка).
```
if lua and lua.version then
 -- we're in LuaTeX
else
 -- we're not
end
```
Один из способов параллельной разработки — использовать texluaв качестве интерпретатора lua. Если вы это сделаете, то выволяавтоматически получить доступ к статически связанным библиотекам, которые всегда являются частью luatex (как LPEGи slnunicode, т.е. без необходимости в requireних). И ваш скрипт будет работать более или менее "как будто" он был запущен через вызов из документа TeX. Но есть одна загвоздка. Texlua автоматически не "находит" функцию kpathsea, поэтому вам нужно "сказать" ей, что делать:
```
kpse.set_program_name("kpsewhich") -- or whatever
```
Сейчас, например,
```
local xml = require("luaxml-domobject")
```
найдет нужный модуль в дереве каталогов TeX, используя kpsewhich: без этой магии вы получите унылые жалобы о package.loaderтом, что не нашли модуль. Или, что еще хуже, вы получитеамодуль с таким названием, но не тот, который вы получите, когда Luatex «действительно» будет у руля.

Код ниже может быть проще для понимания, чем объяснение! Если вы запустите его с , то texluaполучите один вывод; если с , то luaнемного другой вывод, но в обоих случаях это работает.

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")

Чего я не знаю, поскольку я действительно не исследовал это, так это нужно ли быть осторожным, чтобы удалить настройку kpathseaиз файла, который будет вызываться напрямую из документа TeX, где она уже будет установлена. Но для целей разработки эта настройка, если она вообще нужна, позволяет вам достаточно близко подойти к тому, как будет интерпретироваться скрипт, когда он вызывается из запуска TeX.

Answer 1

Я не могу утверждать, что являюсь более чем любителем Luatex, и не являюсь настоящим пользователем Lua; надеюсь, более осведомленные люди простят мне мои ошибки, но я, по крайней мере, могу поделиться своим опытом.

В Luatex, package.searchersзаменяется, так что когда вы requireмодуль из TeX, Luatex использует механизм поиска TeX, а не обычный. Это означает на практике, что когда вы запускаете Lua из Luatex, он не найдет модули, которые находит ваша обычная система Lua. (Я не знаю достаточно об архитектуре, но япредполагать(Это сделано намеренно, поскольку необходимо обеспечить возможность безопасной поддержки различных параллельных структур и гарантировать, что LuaTeX всегда будет подбирать модули, соответствующие TeX, даже если в другом месте установлены другие модули.)

На практике это означает, что если вы установили модуль lua через luarocks, вам нужно будет либо поместить копию, либо включить символическую ссылку в каталог, который kpathseaнайдет. Luarocks — довольно простая штука, насколько я могу судить, и просто сбрасывает файлы в удобный каталог, так что вы должны иметь возможность найти их и сослаться на них или скопировать их. Документация довольно мило предупреждает: «Конечно, не так уж и сложно написать альтернативный загрузчик и использовать его в пакете макросов», хотя для некоторых из нас (вроде меня!) это может быть довольно большой проблемой.

У меня нет опыта, как это работает, если вы используете модуль lua, который не является чистым Lua, а полагается на код, скомпилированный из C. Сам Luatex уже связывает некоторые такие библиотеки (например, slnunicode), но я, боюсь, понятия не имею, как это может повлиять на ваш вариант использования. Я бы надеялся, что это будет "просто работать", но...

Когда вы создаете что-то, что хотите протестировать и как автономное, и как то, что будет связано с TeX, я методом проб и ошибок пришел к следующему:

Если вам нужен (а вы, вероятно, можете) код, который выполняется только в том случае, если он находится в той или иной среде, проверьте определение, lua.versionкоторое будет определено, если вы работаете в Luatex. Я полагаю, строго говоря, достаточно просто проверки lua (а проверка lua.versionнебезопасна, потому что если luaне определено, то возникнет ошибка).
```
if lua and lua.version then
 -- we're in LuaTeX
else
 -- we're not
end
```
Один из способов параллельной разработки — использовать texluaв качестве интерпретатора lua. Если вы это сделаете, то выволяавтоматически получить доступ к статически связанным библиотекам, которые всегда являются частью luatex (как LPEGи slnunicode, т.е. без необходимости в requireних). И ваш скрипт будет работать более или менее "как будто" он был запущен через вызов из документа TeX. Но есть одна загвоздка. Texlua автоматически не "находит" функцию kpathsea, поэтому вам нужно "сказать" ей, что делать:
```
kpse.set_program_name("kpsewhich") -- or whatever
```
Сейчас, например,
```
local xml = require("luaxml-domobject")
```
найдет нужный модуль в дереве каталогов TeX, используя kpsewhich: без этой магии вы получите унылые жалобы о package.loaderтом, что не нашли модуль. Или, что еще хуже, вы получитеамодуль с таким названием, но не тот, который вы получите, когда Luatex «действительно» будет у руля.

Код ниже может быть проще для понимания, чем объяснение! Если вы запустите его с , то texluaполучите один вывод; если с , то luaнемного другой вывод, но в обоих случаях это работает.

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")

Чего я не знаю, поскольку я действительно не исследовал это, так это нужно ли быть осторожным, чтобы удалить настройку kpathseaиз файла, который будет вызываться напрямую из документа TeX, где она уже будет установлена. Но для целей разработки эта настройка, если она вообще нужна, позволяет вам достаточно близко подойти к тому, как будет интерпретироваться скрипт, когда он вызывается из запуска TeX.

проблема с lualatex и mongo

решение1

Связанный контент