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

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

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

Post by IgorZ » Thu 25 Apr, 2013 04:00

Данный скрипт содержит следующие макросы:
  1. Выводит список всех Lua-скриптов Farа и позволяет манипулировать ими.

    Клавиша вызова по умолчанию: AltShiftF11.
  2. Вставка Lua/Moon скрипта (с выбором, какого типа) в редактируемый .lua/.moon файл.
    Клавиша вызова по умолчанию: LCtrlF11.
  3. Вставка Lua/Moon Macro в редактируемый .lua/moon файл.
    Клавиша вызова по умолчанию: RCtrlF11.
  4. Вставка Lua/Moon Event в редактируемый .lua/moon файл.
    Клавиша вызова по умолчанию: RCtrlF11.
  5. Вставка Lua/Moon MenuItem в редактируемый .lua/moon файл.
    Клавиша вызова по умолчанию: RCtrlF11.
  6. Вставка Lua/Moon CommandLine в редактируемый .lua/moon файл.
    Клавиша вызова по умолчанию: RCtrlF11.
  7. Редактирование Lua/Moon скрипта из редактируемого файла.
    Клавиша вызова по умолчанию: CtrlF12.
  8. Вставка строки guid в редактируемый .lua/moon файл.
    Клавиша вызова по умолчанию: RCtrlU.
  9. Перезагрузка всех скриптов.
    Клавиша вызова по умолчанию: CtrlF9.
Требуемая версия Far 3.0.4000+.

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

Attachments
LuaManager.3.1.11.7z
Последняя версия, выполненная в виде скрипта
(50.56 KiB) Downloaded 29 times
LuaManager.4.0.0.7z
Просто последняя версия
(50.22 KiB) Downloaded 40 times

User avatar
John Doe
Бюрократ
Posts: 11076
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 11 times
Been thanked: 64 times

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

Post by John Doe » Fri 05 Aug, 2016 09:50

Latest post of the previous page:

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

User avatar
zg
zero-gravity
Posts: 5231
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 42 times
Contact:

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

Post by zg » Fri 05 Aug, 2016 10:40

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

IgorZ
Posts: 448
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 5 times
Been thanked: 8 times

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

Post by IgorZ » Fri 05 Aug, 2016 11:30

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

IgorZ
Posts: 448
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 5 times
Been thanked: 8 times

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

Post by IgorZ » Fri 05 Aug, 2016 11:39

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

aflexus
Posts: 35
Joined: Sat 12 Mar, 2011 16:57
Has thanked: 4 times

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

Post by aflexus » Fri 05 Aug, 2016 11:40

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

buniak_a_h
Posts: 259
Joined: Sat 20 Apr, 2013 00:17
Location: Питер
Has thanked: 32 times
Been thanked: 4 times
Contact:

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

Post by buniak_a_h » Fri 05 Aug, 2016 13:15

IgorZ wrote: Как с таким зацикливанием бороться гарантированно - пока не знаю.
С этой проблемой сталкиваются все программисты, пытающиеся "развернуть" объект, содержащий ссылку на Owner - объект, содержащий "разворачиваемый". Я обходил так: запоминал все разворачиваемые объекты (в стеке) и не давал разворачивать тот, что уже разворачивался, а вместо этого возвращался по стеку.
Программировать просто. Знай, жми себе на кнопочки... © Владелец IT-компании

User avatar
zg
zero-gravity
Posts: 5231
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 42 times
Contact:

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

Post by zg » Fri 05 Aug, 2016 16:59

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

Smitis
Posts: 1440
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 12 times
Been thanked: 22 times
Contact:

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

Post by Smitis » Fri 05 Aug, 2016 18:27

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

User avatar
zg
zero-gravity
Posts: 5231
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 42 times
Contact:

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

Post by zg » Fri 05 Aug, 2016 19:05

я посмотрел, в moonscript классах именно такая реализация. так что любой moonscript модуль, возвращающий объект будет, как я понимаю, приводить к переполнению стека.

User avatar
John Doe
Бюрократ
Posts: 11076
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 11 times
Been thanked: 64 times

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

Post by John Doe » Sat 06 Aug, 2016 20:56

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

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

IgorZ
Posts: 448
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 5 times
Been thanked: 8 times

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

Post by IgorZ » Mon 08 Aug, 2016 06:09

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

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

User avatar
John Doe
Бюрократ
Posts: 11076
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 11 times
Been thanked: 64 times

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

Post by John Doe » Mon 08 Aug, 2016 08:20

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

IgorZ
Posts: 448
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 5 times
Been thanked: 8 times

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

Post by IgorZ » Mon 08 Aug, 2016 11:42

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

User avatar
John Doe
Бюрократ
Posts: 11076
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 11 times
Been thanked: 64 times

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

Post by John Doe » Mon 08 Aug, 2016 13:22

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)

Smitis
Posts: 1440
Joined: Fri 18 Mar, 2005 12:51
Location: Питер
Has thanked: 12 times
Been thanked: 22 times
Contact:

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

Post by Smitis » Mon 08 Aug, 2016 14:52

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

IgorZ
Posts: 448
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 5 times
Been thanked: 8 times

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

Post by IgorZ » Tue 09 Aug, 2016 11:18

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

User avatar
John Doe
Бюрократ
Posts: 11076
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 11 times
Been thanked: 64 times

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

Post by John Doe » Tue 09 Aug, 2016 11:47

IgorZ wrote: В смысле, кто-то попытается обратиться к чисто интерактивному скрипту, по определению запускаемому, когда все остальные скрипты уже загружены, в автозагрузке?
Именно обратиться, а не запустить.
Например если какой-то скрипт будет содержать в начале local luamanager = require "luamanager"
IgorZ wrote: Языковые файлы, настройки. Я пробовал. Прикинул, сколько придётся переделывать, и какие костыли лепить, и передумал.
Честный модуль может обращаться к своим файлам через require.
Впрочем, несложно получить и полный путь файла модуля.

Собственно я сейчас не агитирую вас заниматься этим, а лишь обращаю внимание что подход с добавлением собственного загрузчика (и особенно манипуляции по его восстановлению после перезагрузки макросов) это совсем уж overkill

Post Reply

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

Who is online

Users browsing this forum: No registered users and 1 guest