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

Здесь выкладываются готовые к использованию макросы и скрипты.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

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

Post by IgorZ »

Выводит список всех Lua-скриптов Farа и позволяет манипулировать ими.









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

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

Attachments
LuaManager.6.0.2.7z
Версия для Far 3.0.0.5934+
(65.47 KiB) Downloaded 88 times
LuaManager.5.2.0.7z
Версия для Far 3.0.0.5210+
(58.78 KiB) Downloaded 219 times
LuaManager.5.0.6.7z
Последняя опубликованная версия, поддерживающая Far 3.0.0.4000 и выше
(59.02 KiB) Downloaded 351 times
LuaManager.3.1.11.7z
Последняя версия, выполненная не в виде модуля
(50.56 KiB) Downloaded 515 times
Last edited by IgorZ on Wed 25 Oct, 2023 10:02, edited 24 times in total.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

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

Post by John Doe »

Latest post of the previous page:

IgorZ wrote: Как с таким зацикливанием бороться гарантированно - пока не знаю.
А что вы с ним делаете там? куда разворачиваете?
IgorZ wrote: Могу рекомендовать обходной путь: отказаться от DialogClass.lua и скриптов, его использующих.
Сурово)
User avatar
zg
zero-gravity
Posts: 6016
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 185 times
Contact:

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

Post by zg »

IgorZ wrote:Автор модуля DialogClass.lua поступает очень "интересно": одно из полей возвращаемого модулем результата - таблица DialogClass, содержащая поле __index, которое определено как DialogClass.__index = DialogClass.
разве? это стандартный метод реализации классов в луа. я точно не уверен, но скорее всего у стандартных классов в moonscript будет то же самое.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

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

Post by IgorZ »

John Doe wrote:
IgorZ wrote: Как с таким зацикливанием бороться гарантированно - пока не знаю.
А что вы с ним делаете там? куда разворачиваете?
На экран вывожу. Встать в LuaManager на модуль, нажать F3. Если модуль не был загружен ранее, нажать CtrlL. Наблюдать.
John Doe wrote:
IgorZ wrote: Могу рекомендовать обходной путь: отказаться от DialogClass.lua и скриптов, его использующих.
Сурово)
Нет, я не из Челябинска. ;)
А серьёзно, если у пользователя только EnvEdit из пользующихся DialogClass, то нормальная рекомендация. К тому же "обходной путь" подразумевает некоторую меру неполноценности, так что всё честно. Придумаю надёжный алгоритм борьбы с зацикливанием - будет полноценное.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

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

Post by IgorZ »

zg wrote:
IgorZ wrote:Автор модуля DialogClass.lua поступает очень "интересно": одно из полей возвращаемого модулем результата - таблица DialogClass, содержащая поле __index, которое определено как DialogClass.__index = DialogClass.
разве? это стандартный метод реализации классов в луа. я точно не уверен, но скорее всего у стандартных классов в moonscript будет то же самое.
Может, так. Классами в Луа не занимался вплотную. Но вот навскидку DialogClass.__index = function() return DialogClass end было бы корректнее с точки зрения идеологии ООП, как мне кажется. Как я понимаю, это поле строго R/O по смыслу, и такая реализация приводит идею и реализацию в соответствие. И заодно такое изменение убрало бы обсуждаемую ошибку.
aflexus
Posts: 74
Joined: Sat 12 Mar, 2011 16:57
Has thanked: 23 times
Been thanked: 1 time

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

Post by aflexus »

IgorZ wrote: Кстати, если постфикс сделать не "_64", а, допустим, "_x64" или "x64", всё равно будет ошибка?
Да, как и в случае с "_64", только после второго запуска. Думается, что это как-то связанно с сохранением настроек в профиль.
User avatar
buniak_a_h
Posts: 4236
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 643 times
Contact:

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

Post by buniak_a_h »

IgorZ wrote: Как с таким зацикливанием бороться гарантированно - пока не знаю.
С этой проблемой сталкиваются все программисты, пытающиеся "развернуть" объект, содержащий ссылку на Owner - объект, содержащий "разворачиваемый". Я обходил так: запоминал все разворачиваемые объекты (в стеке) и не давал разворачивать тот, что уже разворачивался, а вместо этого возвращался по стеку.
Программировать просто. Знай, жми себе на кнопочки... © Владелец IT-компании
User avatar
zg
zero-gravity
Posts: 6016
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 185 times
Contact:

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

Post by zg »

IgorZ wrote:Но вот навскидку DialogClass.__index = function() return DialogClass end было бы корректнее с точки зрения идеологии ООП
так не будет работать. DialogClass.__index = function(table, key) return DialogClass[key] end правильно, но вариант с таблицей - быстрее.
User avatar
Smitis
Posts: 1709
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 23 times
Been thanked: 55 times

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

Post by Smitis »

IgorZ wrote:Но вот навскидку DialogClass.__index = function() return DialogClass end было бы корректнее с точки зрения идеологии ООП, как мне кажется.
Как уже писал zg, DialogClass.__index = DialogClass это вполне себе стандартная реализация. Когда я несколько лет назад с этим экпериметировал, у меня тоже часто зацикливалось. Можно, в принципе, метатаблицу сделать отдельной таблицей, но не знаю насколько это спасёт ситуацию, так как ПОТЕНЦИАЛЬНО, возможно появление других скриптов с подобными зацикливаниями таблиц и перекрёстными ссылками между таблицами.
Разум когда-нибудь победит.
User avatar
zg
zero-gravity
Posts: 6016
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 185 times
Contact:

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

Post by zg »

я посмотрел, в moonscript классах именно такая реализация. так что любой moonscript модуль, возвращающий объект будет, как я понимаю, приводить к переполнению стека.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

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

Post by John Doe »

Хочу обсудить использованию скрипта как модуля.
В настоящий момент это обеспечивается хитрым способом, дополнительным загрузчиком в package.loaders
В связи с этим вопрос: а в чём преимущество перед прямой модификацией package.loaded?

(вроде бы так и было в ранних версиях?)
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

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

Post by IgorZ »

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

(вроде бы так и было в ранних версиях?)
Не знаю. Я вначале именно так и делал, но был жестоко раскритикован неким John Doe ;) и трусливо перешёл к использованию доп. загрузчика.
Если подумать, проблема может возникнуть, если выгрузить такой модуль, а потом снова вызвать его по require.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

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

Post by John Doe »

IgorZ wrote: Я вначале именно так и делал, но был жестоко раскритикован неким John Doe
Вот он же утверждает, что использование загрузчика ничего не решает.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

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

Post by IgorZ »

John Doe wrote:
IgorZ wrote: Я вначале именно так и делал, но был жестоко раскритикован неким John Doe
Вот он же утверждает, что использование загрузчика ничего не решает.
Как минимум, решает
Если подумать, проблема может возникнуть, если выгрузить такой модуль, а потом снова вызвать его по require.
И, забегая вперёд, добавление пути к скрипту в пути поиска модулей тоже порождает некоторые проблемы, как я убедился.
Так что отдельный загрузчик всё-таки наименее проблемен, судя по моему опыту.
User avatar
John Doe
Бюрократ
Posts: 13807
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 73 times
Been thanked: 426 times
Contact:

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

Post 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)
User avatar
Smitis
Posts: 1709
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 23 times
Been thanked: 55 times

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

Post by Smitis »

IgorZ wrote:
zg wrote:вариант с таблицей - быстрее.
*занудным голосом* ООП - не для скорости, ООП - для идеологической чистоты и удобства использования старых ошибок при написании.
Можно сделать и таблицей, точнее таблицами - метатаблицу сделать отдельно от таблицы-класса, т.е. __index из метатаблицы будет указывать на таблицу-класс. Скорость не упадёт, наследование станет ещё более изощрённым, но это решит проблему только с моими скриптами и не спасёт ситуацию в целом.
Разум когда-нибудь победит.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

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

Post by IgorZ »

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

Return to “Полезные макросы и скрипты”