Latest post of the previous page:
В шапку добавлен файл lfjit-2.1.0-beta3.7z, содержащий обе версии (x86 и x64) интерпретатора.lflua — "юникодный Lua-интерпретатор"
- John Doe
- Бюрократ
- Posts: 13862
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
lflua — "юникодный Lua-интерпретатор"
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
-
- Posts: 6840
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
lflua — "юникодный Lua-интерпретатор"
Существенное уточнение к предыдущему сообщению:
в отличие от lflua, при использовании require "luafar3" процитированные фичи не поддерживаются.
Last edited by Shmuel on Tue 03 Dec, 2019 14:04, edited 1 time in total.
- John Doe
- Бюрократ
- Posts: 13862
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
lflua — "юникодный Lua-интерпретатор"
Существуют какие-то концептуальные препятствия для поддержки этих фич?
-
- Posts: 6840
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
lflua — "юникодный Lua-интерпретатор"
При использовании в качестве загружаемой по требованию библиотеки эти библиотеки и функции уже загружены из оригинального Lua или LuaJIT. Что произойдёт, если их заместить "на лету", не знаю, надо экспериментировать. В случае же оригинального использования LuaFAR (из плагинов), либо из lflua данные юникодные версии изначально загружаются вместо оригинальных.
Реально может не хватать юникодного io.open, остальное менее существенно.
- John Doe
- Бюрократ
- Posts: 13862
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
lflua — "юникодный Lua-интерпретатор"
Если есть опасения, что в некоторых случаях такая замена может оказаться нежелательной, то можно перезагружать функции не безусловно, а отдельной командой.
Например
require("luafar3").inject('io','loadfile','require','package.loadlib')
.Или предоставлять эти функции в модуле 'luafar3' (вместо теперешнего
true
).-
- Posts: 6840
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
lflua — "юникодный Lua-интерпретатор"
Я ж не говорю, что нельзя улучшить, а то, что "надо экспериментировать". Для этого данная задача должна ощущаться приоритетнее многочисленных прочих. Чего пока не случилось.
В любом случае, добавление возможности require "luafar3" ничего не убавило, а только добавило. А уж пользователь разберётся, что ему подходит, а что нет.
В любом случае, добавление возможности require "luafar3" ничего не убавило, а только добавило. А уж пользователь разберётся, что ему подходит, а что нет.
- John Doe
- Бюрократ
- Posts: 13862
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
lflua — "юникодный Lua-интерпретатор"
Подозреваю что сценарии, в которых обнаружатся отдельные несовместимости, не могут не найтись.
Хотя бы то, что уже всплывало: передача файловых дескрипторов в (или из) ffi.