Latest post of the previous page:
Как предполагается "встраивать"? По аналогии с sqlite (сорцы внутрь) или как внешняя dll?Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
We are the Borg. You will be assimilated.
So Say We All!
So Say We All!
- NightRoman
- Posts: 6034
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 20 times
- Been thanked: 49 times
- Contact:
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
Разве это важно? Лишь бы все свое было с собой и не зависело от внешнего мира (до разумного предела, конечно).
-
- Posts: 6217
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 31 times
- Been thanked: 348 times
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
Если встраивать Lua, то (на мой взгляд) lua5.1.dll должна быть снаружи:Skirda wrote:Как предполагается "встраивать"? По аналогии с sqlite (сорцы внутрь) или как внешняя dll?
1. Возможность использования одних и тех же внешних библиотек как с Фаром, так и без оного.
2. Возможность замены этой dll на одноимённую LuaJIT dll.
А вот части, функционально аналогичные luafar3.dll, должны быть внутри, для доступа к внутренней информации.
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
Юзер пропотерял/ему не дали/глюк инсталлятора/нету lua5.1.dll. Прощай макросы? Точнее - привет только кнопкосочетания?
We are the Borg. You will be assimilated.
So Say We All!
So Say We All!
-
- Posts: 6217
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 31 times
- Been thanked: 348 times
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
Совсем недавно в ночной сборке не было Far.exe. Бедный юзер.Skirda wrote:Юзер пропотерял/ему не дали/глюк инсталлятора/нету lua5.1.dll. Прощай макросы? Точнее - привет только кнопкосочетания?

- Tim Sobolev
- Posts: 715
- Joined: Fri 01 Apr, 2005 14:46
- Location: Украина
- Has thanked: 1 time
- Been thanked: 2 times
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
Ну он, внезапно, использовался в трёх последних играх от ValveNightRoman wrote:Squirrel - заманчиво, но уж больно непопулярно (Tiobe рейтинг вообще не упоминает такой язык), это плохо и на будущее ненадежно.

-
- Posts: 6217
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 31 times
- Been thanked: 348 times
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
Skirda
Я не агитирую за замену макроязыка на Lua. Если выберут другой язык - ОК для меня. Если останется существующий макроязык - тоже ОК. Просто если выберут Lua, то поучаствую в меру своих возможностей.
Я не агитирую за замену макроязыка на Lua. Если выберут другой язык - ОК для меня. Если останется существующий макроязык - тоже ОК. Просто если выберут Lua, то поучаствую в меру своих возможностей.
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
Мне пофигу что будет, просто Луа в этой теме звучал чаще. 
Я здесь в качестве "плохого полицейского"...

Я здесь в качестве "плохого полицейского"...
We are the Borg. You will be assimilated.
So Say We All!
So Say We All!
- zg
- zero-gravity
- Posts: 5878
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 158 times
- Contact:
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
в фармайл скрипт 44 встроенных функции, лишь в два раза меньше чем в фаре. никаких специальных инструкций в вм там нет.Skirda wrote:Что-то мне с трудом верится, что с таким подходом ты не начнешь ваять всё те же инструкции
можешь набрать в гугле "embedded language". почитать. луа модно не сегодня. языку 19 лет.Кстати, а почему не Повершел (пр.), а Луа? Потому, что это модно/"сегодня" нравится тебе?
валя, это раздел девелопмеент, здесь неконструктивные посты караются баном. помни об этом начиная писать новый пост.А что будет если ты увлечешься браинфаком?
- zg
- zero-gravity
- Posts: 5878
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 158 times
- Contact:
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
не спешить это понятие растяжимое. может пока мы будем луа в фар добавлять, он и перейдёт. опять же luajit как мне кажется не самоцель. и мой личный опыт показывает, что если при переходе на что-то новое есть проблемы, то чем дольше откладывается переход, тем больше становятся эти проблемы.Shmuel wrote:Автор LuaJIT в своё время высказывался, что не будет спешить с переходом на Lua 5.2. Но, как говорят, время покажет.
- WARP ItSelf
- Самый умный
- Posts: 1011
- Joined: Tue 15 Mar, 2005 23:19
- Contact:
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
Вернитесь к обсуждению технической реализации (если таковая возможна), пожалуйста.
P.S. Прошу модераторов рассмотреть возможность отрезать страницы полторы комментариев и выкинуть их нафиг.
P.S. Прошу модераторов рассмотреть возможность отрезать страницы полторы комментариев и выкинуть их нафиг.
Никто не знал, а я...
- WARP ItSelf
- Самый умный
- Posts: 1011
- Joined: Tue 15 Mar, 2005 23:19
- Contact:
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
Дальнейшее обсуждение предлагается вести в следующем ключе: чего не хватает внешним плагинам/программам для полноценного управления Far'ом. Т.е. внешний плагин реализует поддержку некого языка, на языке пишутся «макросы». Чего не хватает, чтобы эти макросы не уступали по функционалу текущим встроенным макросам. А Lua там будет или Brainfuck — это уже не столь важно.
Никто не знал, а я...
-
- Posts: 6217
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 31 times
- Been thanked: 348 times
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
Lua 5.2 - это тоже вариант.zg wrote:опять же luajit как мне кажется не самоцель. и мой личный опыт показывает, что если при переходе на что-то новое есть проблемы, то чем дольше откладывается переход, тем больше становятся эти проблемы.
Просто LuaJIT - это такая фантастическая штука, от которой жалко отказываться:
1. Производительность. При правильно написанном коде приближается к скорости программы на Си, а в отдельных случаях может её превосходить, как это ни странно звучит.
2. Встроенный лёгкий доступ к функциям любых внешних DLL. В "обычном" Lua для этого требуется внешняя библиотека FFI, либо отдельные "bindings".
Да, ещё LuaJIT из коробки может переходить корутинами границу между Lua и Си, правда не знаю, релевантно ли это к "проблеме ф-ции Keys" - пока не попробуем - не узнаем.
- NightRoman
- Posts: 6034
- Joined: Fri 18 Aug, 2006 13:52
- Location: Cambridge, UK
- Has thanked: 20 times
- Been thanked: 49 times
- Contact:
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
Пока больше из спортивного интереса и для доказательства концепции работоспособности подхода с coroutine сделал в PowerShellFar возможным выполнение макро-скриптов типа такого, например (суть в комментариях):
Тут и создание/открытие панелей, и обычные макросы, и интеракция с пользователем. Это смесь обычного PowerShell кода и псевдо-инструкций yield, которые отдают управление Фару с последующим перевызовом-возобновлением и опционально просят запостить обычный макрос, который с точки зрения такого скрипта будет выполнен синхронно, а не поставлен в очередь, как из обычных скриптов. И тут еще важно, что все выполняется в одном контексте скрипта (локальные переменные и т.п. - все действует на время выполнения скрипта), в этом отличие от уже имеющихся в PSF "супер-макросов", где приходится временные глобальные сущности использовать для сохранения контекста.
Это к тому, что это даже в PowerShell возможно организовать, где нет coroutine, как таковых. В языках с поддержкой coroutine, да еще с более тесной интеграцией с Фаром должно быть еще проще, по идее.
А суть для Фара (в данном случае только это ядро Фарнет) такая - вызов макро-скрипта в отдельном потоке (чтобы можно было замораживать его при yield) и ожидание данных из yield. Если это макросы - проигрываем их и возобновляем тот поток, а сами ждем дальше. При этом в скрипте не надо беспокоится о том, что это неосновной поток, ибо он не фоновый - когда он выполняется, то главный ничего не делает, то-есть конфликтов нет. Как-то так.
Code: Select all
Start-FarMacro {
# the panel 1 (in normal scripts this should be the last command)
Get-Process | Out-FarPanel
# let the panel be opened and go to another one
yield 'Tab'
# the panel 2 (in normal scripts this should be the last command)
Get-ChildItem | Out-FarPanel
# let the panel be opened
yield
# show a message with some info
$Far.Message('You see two panels.')
# close panels (Esc closes PSF panels)
yield 'Esc Tab Esc'
# show yet another message
$Far.Message('Panels are closed.')
}
Это к тому, что это даже в PowerShell возможно организовать, где нет coroutine, как таковых. В языках с поддержкой coroutine, да еще с более тесной интеграцией с Фаром должно быть еще проще, по идее.
А суть для Фара (в данном случае только это ядро Фарнет) такая - вызов макро-скрипта в отдельном потоке (чтобы можно было замораживать его при yield) и ожидание данных из yield. Если это макросы - проигрываем их и возобновляем тот поток, а сами ждем дальше. При этом в скрипте не надо беспокоится о том, что это неосновной поток, ибо он не фоновый - когда он выполняется, то главный ничего не делает, то-есть конфликтов нет. Как-то так.
- zg
- zero-gravity
- Posts: 5878
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 158 times
- Contact:
Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
ну подход работает, да. даже выполнение макросов типаNightRoman wrote:Пока больше из спортивного интереса и для доказательства концепции работоспособности подхода с coroutine сделал в PowerShellFar возможным выполнение макро-скриптов типа такого, например (суть в комментариях)
Code: Select all
far.Keys("CtrlO") for ii=1,10 do far.Keys("A") end

Re: Идея о замене макроязыка Фара на Lua, JavaScript и т.п.
Сейчас из основного функционала не хватает аналогов mmode, clip, history.disable и функций работы с меню, предлагаю добавить:WARP ItSelf wrote:Дальнейшее обсуждение предлагается вести в следующем ключе: чего не хватает внешним плагинам/программам для полноценного управления Far'ом.
Code: Select all
ACTL_ENABLEREDRAW, Param1=1 - разрешить перерисовку окна фара, Param1=0 - запретить перерисовку, Param1=-1 - получить текущее состояние
ACTL_ENABLEHISTORY - параметры аналогичные, разрешает/запрещает историю
ACTL_USEINTERNALCLIPBOARD - включает/выключает использование внутреннего буфера обмена
ACTL_GETMENUINFO - получить информацию о текущем меню, Param2 указывает на структуру:
struct FarMenuInfo
{
size_t StructSize;
GUID PluginId; //гуид плагина или фара
GUID Id; //гуид меню
size_t ItemsNumber; //элементов в меню
size_t CurrentItem; //текущий элемент
};
ACTL_GETMENUITEM - получить элемент меню, Param1 - размер буфера, на который указывает Param2, Param2 - указатель на FarMenuItem. Возвращает нужный размер буфера