View Issue Details

IDProjectCategoryView StatusLast Update
0003286Wishes.PluginsLuaMacro / Macro Browserpublic2018-05-13 20:50
ReporterJohnDoeAssigned Toshmuel 
PrioritynormalSeverityfeatureReproducibilityN/A
Status closedResolutionfixed 
Platformx86OSWindowsOS VersionXP SP3
Product Version3.0 
Target VersionFixed in Version 
Summary0003286: Возможность выполнить скрипт только один раз при загрузке
DescriptionПредлагаю реализовать в LuaMacro стандартный способ:
- либо после первой загрузки устанавливать какую-то глобальную переменную
- либо использовать механизм, аналогичный применяемому сейчас в LuaFar-плагинах, т.е. передавать скрипту дополнительный аргумент при первой загрузке.
Steps To ReproduceСейчас я поступаю примерно так:
В _macroinit.lua:
mf.postmacro(function() _G.runonce_done = true end
В остальных скриптах:
if not runonce_done then
  --участок кода который необходимо исполнить однократно

end


Такой способ устраивает всем, за исключением того, что он нестандартен, а значит при обмене скриптами будут возникать ньюансы.
Additional Informationhttp://forum.farmanager.com/viewtopic.php?p=140189#p140189

P.S.
Кроме того, возникает и обратная потребность: выполнять код однократно при выгрузке плагина
http://forum.farmanager.com/viewtopic.php?f=15&t=7693&p=140411#p140411
TagsNo tags attached.

Relationships

related to 0003448 closedshmuel ExitFAR объединяет два типа событий, которые надо разъединить 

Activities

JohnDoe

2017-07-28 12:55

updater   bugnote:0015499

Last edited: 2017-07-28 14:12

View 2 revisions

Об упомянутом в P.S. создан отдельный тикет 0003448

shmuel

2018-05-08 21:53

developer   bugnote:0016077

Перечитал здесь и на форуме, возникла такая мысль:
поскольку макросы могут загружаться и перезагружаться из разных мест (согласно документации), то просто глобальная переменная не решит проблему. Или, например, добавили макрофайл и перезагрузили макросы. Для добавленного макрофайла это будет первое исполнение, для остальных - второе или больше. Получается, что нужно хранить данную информацию для каждого макрофайла в отдельности (не то, чтобы это было трудно, вопрос лишь в том, стоит ли игра свеч).

JohnDoe

2018-05-10 17:20

updater   bugnote:0016083

Действительно, простой глобальной переменной не обойтись, как минимум нужна таблица, индексируемая полными именами файлов.
Также возможен компромиссный вариант: плагин только создаёт таблицу, а наполняют её уже сами скрипты, по необходимости.

Возможно, игра действительно не стоит свеч.

shmuel

2018-05-11 00:09

developer   bugnote:0016085

Last edited: 2018-05-11 00:10

View 2 revisions

Можно сделать вариант в духе первоначального предложения, поскольку оно достаточное для подавляющего большинства случаев использования макросов. Если же пользователь добавляет "на ходу" код, который должен исполняться 1 раз, то надо перезагрузить Фар.

Добавлять глобальную переменную не очень бы хотелось, скорее второй аргумент при исполнении макрофайла.

JohnDoe

2018-05-11 09:52

updater   bugnote:0016087

shmuel wrote

Можно сделать вариант в духе первоначального предложения
Что в таком случае будет если фар загружен с ключем /ma, а потом уже выполнена lm:load?

shmuel wrote

скорее второй аргумент при исполнении макрофайла.
Аргументы начинают накапливаться. Может быть стоит вместо этого организовать доступ к потенциальным различным свойствам и методам посредством индексации некоего объекта (который может передаваться параметром, или добавляться в окружение)?

Пример свойств: FirstRun, FileName
Пример методов: AddExitHandler

(если у такого подхода есть шанс, то предлагаю обсудить в отдельном issue)

shmuel

2018-05-12 00:24

developer   bugnote:0016089

Last edited: 2018-05-12 00:25

View 2 revisions

> Что в таком случае будет если фар загружен с ключем /ma, а потом уже выполнена lm:load?

Механизм "однократного исполнения" относится к коду загрузки макросов, а не к их исполнению. Макросы с флагом "RunAfterFARStart" исполняются по сигналу от FAR. В случае /ma Far не посылает этот сигнал плагину LuaMacro. Поэтому мне кажется, что нет связи между этими вещами.

> Аргументы начинают накапливаться. Может быть стоит вместо этого организовать доступ
> к потенциальным различным свойствам и методам посредством индексации некоего объекта

Добавление 2-го параметра за примерно 5.5 лет я не назвал бы накапливанием. Если параметры документированы, то в чём проблема? С объектом было бы элегантнее, да, но это является ломкой существующего API, причём без какой-то выгоды, если не считать "красивость". Я против ломки API.
Добавление объекта в окружение не ломает API, но это будет ещё одна новая сущность, плодить которые тоже не хотелось бы.

JohnDoe

2018-05-12 13:23

updater   bugnote:0016091

shmuel wrote

Поэтому мне кажется, что нет связи между этими вещами.

Не уловил между какими.

shmuel wrote

С объектом было бы элегантнее, да, но это является ломкой существующего API


local mt = {
  __tostring=function(self)
    return self.FileName
  end;
}
local script = setmetatable({FileName="c:\\sample.lua"},mt)
far.Show(script,script.FileName)


shmuel wrote

причём без какой-то выгоды, если не считать "красивость"
Наглядность, расширяемость.
Хотя, ради замены двух аргументов может и не стоит, да.

shmuel

2018-05-12 13:35

developer   bugnote:0016093

> Не уловил между какими.
Между темой данного тикета и запуском Фара с ключом /ma

Ваш пример с метатаблицей - не понял о чём он, особенно в контексте нежелательности создания новых сущностей там, где можно обойтись одним простым параметром.

JohnDoe

2018-05-12 14:17

updater   bugnote:0016095

shmuel wrote

Между темой данного тикета и запуском Фара с ключом /ma
Моя ошибка, имелся ввиду флаг /m

shmuel wrote

Ваш пример с метатаблицей - не понял о чём он,
Так процитировано же, о том что АПИ не сломается, аргумент можно будет использовать и как объект, и как строку (сейчас же строка)

shmuel wrote

где можно обойтись одним простым параметром.
На это я уже ответил, и в целом согласился с вами.

shmuel

2018-05-12 14:33

developer   bugnote:0016098

> Моя ошибка, имелся ввиду флаг /m
В этом случае первый вызов lm:load будет выполнять роль первой загрузки, и будет исполнен "одноразовый" код. Вроде логичное поведение.

Пример с метатаблицей теперь понятен, остроумно, но (субъективно) не хотелось бы.

JohnDoe

2018-05-12 14:45

updater   bugnote:0016099

shmuel wrote

Вроде логичное поведение.
Согласен

shmuel

2018-05-12 15:25

developer   bugnote:0016100

Last edited: 2018-05-12 15:38

View 2 revisions

Кстати, по поводу решения с метатаблицей - оно недостаточно функционально.
Для far.Show() оно работает, но для других функций, где ожидается тип string (sub, find, match и т.д.), оно работать не будет.
Нужно в метатаблицу ещё добавить поле __index.

JohnDoe

2018-05-12 18:02

updater   bugnote:0016101

Last edited: 2018-05-12 18:08

View 3 revisions

Например:
  __index=function(self,k)
    local f = unicode.utf8[k]
    if f then return function(self,...)
      return f(self.FileName,...)
    end end
  end;


shmuel

2018-05-12 18:18

developer   bugnote:0016103

Last edited: 2018-05-12 18:38

View 2 revisions

Уже лучше, хотя и не оптимально (при каждой индексации создаётся closure).

Ну и ещё наверное надо добавить как минимум метаметод __eq, а для педантов ещё и __lt и т.д.
Нет, это не получится. При сравнении разных типов в Lua 5.1 метаметоды не работают.

shmuel

2018-05-12 21:12

developer   bugnote:0016105

Да, пожалуй оптимизировать ваш вариант __index невозможно. Так что можно считать его оптимальным.

shmuel

2018-05-13 01:25

developer   bugnote:0016106

LuaMacro build 652.

JohnDoe

2018-05-13 20:43

updater   bugnote:0016107

Работает.
Теперь для того чтобы выполнить однократно достаточно обернуть код в
if select(2,...)==1 then
-- 
end

shmuel

2018-05-13 20:50

developer   bugnote:0016108

OK, спасибо за сотрудничество.

Issue History

Date Modified Username Field Change
2016-08-30 12:40 JohnDoe New Issue
2017-07-28 12:55 JohnDoe Note Added: 0015499
2017-07-28 14:12 JohnDoe Note Edited: 0015499 View Revisions
2017-08-05 12:37 shmuel Relationship added related to 0003448
2018-05-08 21:53 shmuel Note Added: 0016077
2018-05-10 17:20 JohnDoe Note Added: 0016083
2018-05-11 00:09 shmuel Note Added: 0016085
2018-05-11 00:10 shmuel Note Edited: 0016085 View Revisions
2018-05-11 09:52 JohnDoe Note Added: 0016087
2018-05-12 00:24 shmuel Note Added: 0016089
2018-05-12 00:25 shmuel Note Edited: 0016089 View Revisions
2018-05-12 13:23 JohnDoe Note Added: 0016091
2018-05-12 13:35 shmuel Note Added: 0016093
2018-05-12 14:17 JohnDoe Note Added: 0016095
2018-05-12 14:33 shmuel Note Added: 0016098
2018-05-12 14:45 JohnDoe Note Added: 0016099
2018-05-12 15:25 shmuel Note Added: 0016100
2018-05-12 15:38 shmuel Note Edited: 0016100 View Revisions
2018-05-12 18:02 JohnDoe Note Added: 0016101
2018-05-12 18:04 JohnDoe Note Edited: 0016101 View Revisions
2018-05-12 18:08 JohnDoe Note Edited: 0016101 View Revisions
2018-05-12 18:18 shmuel Note Added: 0016103
2018-05-12 18:38 shmuel Note Edited: 0016103 View Revisions
2018-05-12 21:12 shmuel Note Added: 0016105
2018-05-13 01:25 shmuel Assigned To => shmuel
2018-05-13 01:25 shmuel Status new => feedback
2018-05-13 01:25 shmuel Note Added: 0016106
2018-05-13 20:36 JohnDoe Status feedback => resolved
2018-05-13 20:43 JohnDoe Note Added: 0016107
2018-05-13 20:50 shmuel Status resolved => closed
2018-05-13 20:50 shmuel Resolution open => fixed
2018-05-13 20:50 shmuel Note Added: 0016108