Latest post of the previous page:
То есть развития макроязыка в этом направлении не предусмотрено, жаль , ну да ладно...Plugin.call(...), plugin.config
Re: Spring — внедрение Lua в качестве макроязыка
ну щас плагин может вернуть только целое число, а хотелось бы большего:
хотя-бы целое число или число с плавающей точкой или строку или логический тип или сообщение об ошибке;
а если уж совсем замахнуться то Лунную ТАБЛИЦУ
хотя-бы целое число или число с плавающей точкой или строку или логический тип или сообщение об ошибке;
а если уж совсем замахнуться то Лунную ТАБЛИЦУ
SimSU ··· ·· -- ··· ··-
-
- Posts: 6836
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
Re: Spring — внедрение Lua в качестве макроязыка
А как насчёт почитать changelog или несколько сообщений выше?SUSim wrote:ну щас плагин может вернуть только целое число, а хотелось бы большего
Re: Spring — внедрение Lua в качестве макроязыка
Сорри, не так выразился, я знаю что плагин может вернуть одно значение - либо Инт, либо строку,
отсюда некоторые неудобства, если требуется вернуть несколько значений то приходится их комбинировать в строку, а в макросе их разбирать в ручную...
или я что-то до конца не понял?
отсюда некоторые неудобства, если требуется вернуть несколько значений то приходится их комбинировать в строку, а в макросе их разбирать в ручную...
или я что-то до конца не понял?
SimSU ··· ·· -- ··· ··-
-
- Posts: 6836
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
Re: Spring — внедрение Lua в качестве макроязыка
Ну прочитайте внимательнее:
P.P.S. А возможно, вы пока не в курсе, что Lua-функция может возвращать несколько величин? Например (пример надуманный):
P.S. Возможно, у вас страница чейнжлога закеширована, сделайте Reload и посмотрите запись 2893.Plugin.Call может возвращать одну или более величин
P.P.S. А возможно, вы пока не в курсе, что Lua-функция может возвращать несколько величин? Например (пример надуманный):
Code: Select all
left,top,width,height = Plugin.Call(guid,"GetCoord")
-
- Posts: 3651
- Joined: Wed 23 Nov, 2005 11:11
- Location: Москва-Питер
- Has thanked: 2 times
- Been thanked: 19 times
Re: Spring — внедрение Lua в качестве макроязыка
А то что при вызове Plugin.Call(guid, 1) приходит FMVT_DOUBLE а не FMVT_INTEGER - это нормально?
И можно ли как то форсировать передачу целого, чтобы плагин не переписывать?
И можно ли как то форсировать передачу целого, чтобы плагин не переписывать?
-
- Posts: 6836
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
Re: Spring — внедрение Lua в качестве макроязыка
1. Это нормально, так как в стандартном Lua нет нативного типа целого числа, а используется double, который представляет без погрешности целые числа до 53 бит.
2. Можно:
2. Можно:
Code: Select all
Plugin.Call(guid, bit64.new(1))
-
- Posts: 3651
- Joined: Wed 23 Nov, 2005 11:11
- Location: Москва-Питер
- Has thanked: 2 times
- Been thanked: 19 times
Re: Spring — внедрение Lua в качестве макроязыка
Так работает, да. Но все-таки - нельзя ли сделать, чтобы по умолчанию плагин получал целое? Писать такую конструкцию в макросах - прямо скажем, неочевидно.
-
- Posts: 6836
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
Re: Spring — внедрение Lua в качестве макроязыка
* Макрос парсится стандартным Lua, поэтому после компиляции нет никакой возможности различить 1 и 1.0.Max Rusov wrote:Так работает, да. Но все-таки - нельзя ли сделать, чтобы по умолчанию плагин получал целое? Писать такую конструкцию в макросах - прямо скажем, неочевидно.
* Можно, конечно, было бы делать дополнительную проверку перед передачей в плагин: если есть дробная часть - передавать как FMVT_DOUBLE, а если нет - то FMVT_INTEGER. Но я не уверен, что эта надстройка не помешает, когда мы действительно хотим передать FMVT_DOUBLE, а у числа нет дробной части.
* Можно сделать синтаксис как в Cи - явно указывать тип из макроса, но это будет ещё более неуклюже.
* Определите в автостартующем скрипте _G.int=bit64.new, и тогда можно будет писать int(1).
P.S.
Уже давно работаю с Lua и абсолютно не скучаю по целым числам. Даже не помню, когда в последний раз мне их недоставало.
-
- Posts: 3651
- Joined: Wed 23 Nov, 2005 11:11
- Location: Москва-Питер
- Has thanked: 2 times
- Been thanked: 19 times
Re: Spring — внедрение Lua в качестве макроязыка
Проблема не в скриптах а в плагинах. Теперь везде где плагин ожидал целое число придется добавлять проверку, что это может быть или целое или вещественное...
-
- Posts: 6836
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
Re: Spring — внедрение Lua в качестве макроязыка
Готов выслушать предложения по улучшению этой ситуации.Max Rusov wrote:Проблема не в скриптах а в плагинах. Теперь везде где плагин ожидал целое число придется добавлять проверку, что это может быть или целое или вещественное...
Например, можно сделать глобальную ф-цию int не в автостартующем макросе, а "из коробки".
- zg
- zero-gravity
- Posts: 6035
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 185 times
- Contact:
Re: Spring — внедрение Lua в качестве макроязыка
для «старых» плагинов в макросе писать bit64.new(…). в новых обрабатывать double. не вижу проблемы.
-
- Posts: 6836
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
Re: Spring — внедрение Lua в качестве макроязыка
Проблемы тоже не вижу. Речь об "удобстве".zg wrote:для «старых» плагинов в макросе писать bit64.new(…). в новых обрабатывать double. не вижу проблемы.
- zg
- zero-gravity
- Posts: 6035
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 185 times
- Contact:
Re: Spring — внедрение Lua в качестве макроязыка
в плагине пара строк для удобства макросов.Shmuel wrote:Проблемы тоже не вижу. Речь об "удобстве".
-
- Posts: 3651
- Joined: Wed 23 Nov, 2005 11:11
- Location: Москва-Питер
- Has thanked: 2 times
- Been thanked: 19 times
Re: Spring — внедрение Lua в качестве макроязыка
Заметил одну особенность асинхронного режима Plugin.Call: если при вызове плагин не открывает никаких диалогов, а просто возвращает несколько значений, то в асинхронном режиме эти значения не возвращаются в макрос, и также не вызывается FarMacroCall.Callback (т.е. получаем утечку памяти). Это by-design, или все таки ошибка?