Page 2 of 2

lflua — "юникодный Lua-интерпретатор"

Posted: Tue 08 Aug, 2017 12:53
by Shmuel

Latest post of the previous page:

В шапку добавлен файл lfjit-2.1.0-beta3.7z, содержащий обе версии (x86 и x64) интерпретатора.

lflua — "юникодный Lua-интерпретатор"

Posted: Tue 03 Dec, 2019 12:22
by John Doe

Code: Select all

shmuel 12.01.2019 19:16:29 +0200 - build 685

1. LuaFAR: добавлена экспортируемая функция luaopen_luafar3.
   - Это делает возможным использование luafar3.dll как обычной библиотеки для скриптов Lua 5.1,
     вне Far Manager (таблицы win, bit64, unicode; "юникодизация" функций работы со строками).
   - Естественно, при этом нельзя будет использовать таблицы, относящиеся к Far API.
   - Загрузка библиотеки: require "luafar3"
Поправьте если ошибаюсь:
- вложения из шапки уже не актуальны, поскольку luafar можно подключить стандартным образом
- свежие версии интерпретатора luajit поддерживаются тут: https://github.com/FarGroup/FarManager/ ... cro/luasdk

lflua — "юникодный Lua-интерпретатор"

Posted: Tue 03 Dec, 2019 13:00
by Shmuel
Вроде так, только "свежие версии интерпретатора" корректнее назвать "соответствующие билду LuaJIT, используемому в Фаре".

lflua — "юникодный Lua-интерпретатор"

Posted: Tue 03 Dec, 2019 14:04
by Shmuel
Shmuel wrote: Wed 16 May, 2012 14:14 * юникодная версия библиотеки io
* юникодные версии функций loadfile, require, package.loadlib
Существенное уточнение к предыдущему сообщению:
в отличие от lflua, при использовании require "luafar3" процитированные фичи не поддерживаются.

lflua — "юникодный Lua-интерпретатор"

Posted: Tue 03 Dec, 2019 14:27
by John Doe
Существуют какие-то концептуальные препятствия для поддержки этих фич?

lflua — "юникодный Lua-интерпретатор"

Posted: Tue 03 Dec, 2019 14:39
by Shmuel
John Doe wrote: Tue 03 Dec, 2019 14:27 Существуют какие-то концептуальные препятствия для поддержки этих фич?
При использовании в качестве загружаемой по требованию библиотеки эти библиотеки и функции уже загружены из оригинального Lua или LuaJIT. Что произойдёт, если их заместить "на лету", не знаю, надо экспериментировать. В случае же оригинального использования LuaFAR (из плагинов), либо из lflua данные юникодные версии изначально загружаются вместо оригинальных.
Реально может не хватать юникодного io.open, остальное менее существенно.

lflua — "юникодный Lua-интерпретатор"

Posted: Tue 03 Dec, 2019 14:56
by John Doe
Shmuel wrote: Tue 03 Dec, 2019 14:39 Что произойдёт, если их заместить "на лету", не знаю, надо экспериментировать.
Если есть опасения, что в некоторых случаях такая замена может оказаться нежелательной, то можно перезагружать функции не безусловно, а отдельной командой.

Например require("luafar3").inject('io','loadfile','require','package.loadlib').
Или предоставлять эти функции в модуле 'luafar3' (вместо теперешнего true).

lflua — "юникодный Lua-интерпретатор"

Posted: Tue 03 Dec, 2019 15:05
by Shmuel
Я ж не говорю, что нельзя улучшить, а то, что "надо экспериментировать". Для этого данная задача должна ощущаться приоритетнее многочисленных прочих. Чего пока не случилось.

В любом случае, добавление возможности require "luafar3" ничего не убавило, а только добавило. А уж пользователь разберётся, что ему подходит, а что нет.

lflua — "юникодный Lua-интерпретатор"

Posted: Tue 03 Dec, 2019 15:14
by John Doe
Shmuel wrote: Tue 03 Dec, 2019 15:05 Я ж не говорю, что нельзя улучшить, а то, что "надо экспериментировать".
Подозреваю что сценарии, в которых обнаружатся отдельные несовместимости, не могут не найтись.
Хотя бы то, что уже всплывало: передача файловых дескрипторов в (или из) ffi.