Page 19 of 28

Менеджер Lua-скриптов для Farа

Posted: Thu 25 Apr, 2013 04:00
by IgorZ
Выводит список всех Lua-скриптов Farа и позволяет манипулировать ими.









Требуемая версия Far 3.0.5210+.

Начиная с версии 4.0, скрипт выполнен в виде модуля и набора вызывающих макросов.


Менеджер Lua-скриптов для Farа

Posted: Fri 05 Aug, 2016 09:50
by John Doe

Latest post of the previous page:

IgorZ wrote: Как с таким зацикливанием бороться гарантированно - пока не знаю.
А что вы с ним делаете там? куда разворачиваете?
IgorZ wrote: Могу рекомендовать обходной путь: отказаться от DialogClass.lua и скриптов, его использующих.
Сурово)

Менеджер Lua-скриптов для Farа

Posted: Fri 05 Aug, 2016 10:40
by zg
IgorZ wrote:Автор модуля DialogClass.lua поступает очень "интересно": одно из полей возвращаемого модулем результата - таблица DialogClass, содержащая поле __index, которое определено как DialogClass.__index = DialogClass.
разве? это стандартный метод реализации классов в луа. я точно не уверен, но скорее всего у стандартных классов в moonscript будет то же самое.

Менеджер Lua-скриптов для Farа

Posted: Fri 05 Aug, 2016 11:30
by IgorZ
John Doe wrote:
IgorZ wrote: Как с таким зацикливанием бороться гарантированно - пока не знаю.
А что вы с ним делаете там? куда разворачиваете?
На экран вывожу. Встать в LuaManager на модуль, нажать F3. Если модуль не был загружен ранее, нажать CtrlL. Наблюдать.
John Doe wrote:
IgorZ wrote: Могу рекомендовать обходной путь: отказаться от DialogClass.lua и скриптов, его использующих.
Сурово)
Нет, я не из Челябинска. ;)
А серьёзно, если у пользователя только EnvEdit из пользующихся DialogClass, то нормальная рекомендация. К тому же "обходной путь" подразумевает некоторую меру неполноценности, так что всё честно. Придумаю надёжный алгоритм борьбы с зацикливанием - будет полноценное.

Менеджер Lua-скриптов для Farа

Posted: Fri 05 Aug, 2016 11:39
by IgorZ
zg wrote:
IgorZ wrote:Автор модуля DialogClass.lua поступает очень "интересно": одно из полей возвращаемого модулем результата - таблица DialogClass, содержащая поле __index, которое определено как DialogClass.__index = DialogClass.
разве? это стандартный метод реализации классов в луа. я точно не уверен, но скорее всего у стандартных классов в moonscript будет то же самое.
Может, так. Классами в Луа не занимался вплотную. Но вот навскидку DialogClass.__index = function() return DialogClass end было бы корректнее с точки зрения идеологии ООП, как мне кажется. Как я понимаю, это поле строго R/O по смыслу, и такая реализация приводит идею и реализацию в соответствие. И заодно такое изменение убрало бы обсуждаемую ошибку.

Менеджер Lua-скриптов для Farа

Posted: Fri 05 Aug, 2016 11:40
by aflexus
IgorZ wrote: Кстати, если постфикс сделать не "_64", а, допустим, "_x64" или "x64", всё равно будет ошибка?
Да, как и в случае с "_64", только после второго запуска. Думается, что это как-то связанно с сохранением настроек в профиль.

Менеджер Lua-скриптов для Farа

Posted: Fri 05 Aug, 2016 13:15
by buniak_a_h
IgorZ wrote: Как с таким зацикливанием бороться гарантированно - пока не знаю.
С этой проблемой сталкиваются все программисты, пытающиеся "развернуть" объект, содержащий ссылку на Owner - объект, содержащий "разворачиваемый". Я обходил так: запоминал все разворачиваемые объекты (в стеке) и не давал разворачивать тот, что уже разворачивался, а вместо этого возвращался по стеку.

Менеджер Lua-скриптов для Farа

Posted: Fri 05 Aug, 2016 16:59
by zg
IgorZ wrote:Но вот навскидку DialogClass.__index = function() return DialogClass end было бы корректнее с точки зрения идеологии ООП
так не будет работать. DialogClass.__index = function(table, key) return DialogClass[key] end правильно, но вариант с таблицей - быстрее.

Менеджер Lua-скриптов для Farа

Posted: Fri 05 Aug, 2016 18:27
by Smitis
IgorZ wrote:Но вот навскидку DialogClass.__index = function() return DialogClass end было бы корректнее с точки зрения идеологии ООП, как мне кажется.
Как уже писал zg, DialogClass.__index = DialogClass это вполне себе стандартная реализация. Когда я несколько лет назад с этим экпериметировал, у меня тоже часто зацикливалось. Можно, в принципе, метатаблицу сделать отдельной таблицей, но не знаю насколько это спасёт ситуацию, так как ПОТЕНЦИАЛЬНО, возможно появление других скриптов с подобными зацикливаниями таблиц и перекрёстными ссылками между таблицами.

Менеджер Lua-скриптов для Farа

Posted: Fri 05 Aug, 2016 19:05
by zg
я посмотрел, в moonscript классах именно такая реализация. так что любой moonscript модуль, возвращающий объект будет, как я понимаю, приводить к переполнению стека.

Менеджер Lua-скриптов для Farа

Posted: Sat 06 Aug, 2016 20:56
by John Doe
Хочу обсудить использованию скрипта как модуля.
В настоящий момент это обеспечивается хитрым способом, дополнительным загрузчиком в package.loaders
В связи с этим вопрос: а в чём преимущество перед прямой модификацией package.loaded?

(вроде бы так и было в ранних версиях?)

Менеджер Lua-скриптов для Farа

Posted: Mon 08 Aug, 2016 06:09
by IgorZ
zg wrote:вариант с таблицей - быстрее.
*занудным голосом* ООП - не для скорости, ООП - для идеологической чистоты и удобства использования старых ошибок при написании.
zg wrote:я посмотрел, в moonscript классах именно такая реализация. так что любой moonscript модуль, возвращающий объект будет, как я понимаю, приводить к переполнению стека.
Дык, пилю. Сам предпочитаю исключать любую возможность ошибки.
John Doe wrote:Хочу обсудить использованию скрипта как модуля.
В настоящий момент это обеспечивается хитрым способом, дополнительным загрузчиком в package.loaders
В связи с этим вопрос: а в чём преимущество перед прямой модификацией package.loaded?

(вроде бы так и было в ранних версиях?)
Не знаю. Я вначале именно так и делал, но был жестоко раскритикован неким John Doe ;) и трусливо перешёл к использованию доп. загрузчика.
Если подумать, проблема может возникнуть, если выгрузить такой модуль, а потом снова вызвать его по require.

Менеджер Lua-скриптов для Farа

Posted: Mon 08 Aug, 2016 08:20
by John Doe
IgorZ wrote: Я вначале именно так и делал, но был жестоко раскритикован неким John Doe
Вот он же утверждает, что использование загрузчика ничего не решает.

Менеджер Lua-скриптов для Farа

Posted: Mon 08 Aug, 2016 11:42
by IgorZ
John Doe wrote:
IgorZ wrote: Я вначале именно так и делал, но был жестоко раскритикован неким John Doe
Вот он же утверждает, что использование загрузчика ничего не решает.
Как минимум, решает
Если подумать, проблема может возникнуть, если выгрузить такой модуль, а потом снова вызвать его по require.
И, забегая вперёд, добавление пути к скрипту в пути поиска модулей тоже порождает некоторые проблемы, как я убедился.
Так что отдельный загрузчик всё-таки наименее проблемен, судя по моему опыту.

Менеджер Lua-скриптов для Farа

Posted: Mon 08 Aug, 2016 13:22
by John Doe
IgorZ wrote: Если подумать, проблема может возникнуть, если выгрузить такой модуль, а потом снова вызвать его по require.
Это фантастическая ситуация. Но есть package.preload, где кстати загрузчики по имени индексируются, что избавляет от необходимости в хитрых проверках с использованием debug.
IgorZ wrote: Так что отдельный загрузчик всё-таки наименее проблемен, судя по моему опыту.
Наименее проблемно положить модуль в соответствующую папку. И ни один из других способов не позволит загрузить модуль, если он востребован до загрузки скрипта из scripts (как известно порядок загрузки макросов не определён).

Если же игнорировать эту проблему, то проще всего прямо модифицировать package.loaded, имхо это всё равно лучше чем прочие предложенные способы.

Но вот не знаю почему вы против размещения модуля в соответствующей папке.
Если уж так, то можно ведь и без модулей обойтись, одними макросами:

Code: Select all

Macro {
  area="Common"; key="luamanager";
  action=function() return ManageMacrosEvents end;
}
Вызывать так: local res,luamanager = mf.eval("luamanager",2)

Менеджер Lua-скриптов для Farа

Posted: Mon 08 Aug, 2016 14:52
by Smitis
IgorZ wrote:
zg wrote:вариант с таблицей - быстрее.
*занудным голосом* ООП - не для скорости, ООП - для идеологической чистоты и удобства использования старых ошибок при написании.
Можно сделать и таблицей, точнее таблицами - метатаблицу сделать отдельно от таблицы-класса, т.е. __index из метатаблицы будет указывать на таблицу-класс. Скорость не упадёт, наследование станет ещё более изощрённым, но это решит проблему только с моими скриптами и не спасёт ситуацию в целом.

Менеджер Lua-скриптов для Farа

Posted: Tue 09 Aug, 2016 11:18
by IgorZ
Версия 3.1.6 - В окне просмотра выводимые значения сортируются по типам и именам и не зацикливаются. Проверено на том самом DialogClass. Ссылки на таблицы отображаются "->" или "-^" (для рекурсивных). Рефакторинг.
John Doe wrote:Наименее проблемно положить модуль в соответствующую папку. И ни один из других способов не позволит загрузить модуль, если он востребован до загрузки скрипта из scripts (как известно порядок загрузки макросов не определён).
В смысле, кто-то попытается обратиться к чисто интерактивному скрипту, по определению запускаемому, когда все остальные скрипты уже загружены, в автозагрузке? Прямо в _macroinit.lua, к примеру? Вот честно, не представляю себе такой вариант использования. А если кому-то всё же понадобится, можно воспользоваться mf.postmacro(function() require"LuaManager"() end) - как раз дождётся загрузки всего того, с чем работает, и запустится. Проверил, всё тип-топ.
John Doe wrote:Но вот не знаю почему вы против размещения модуля в соответствующей папке.
Языковые файлы, настройки. Я пробовал. Прикинул, сколько придётся переделывать, и какие костыли лепить, и передумал.