Среда разработки

[Zaam]

Кто чем пользуется для написания аддонов? Сам пользую Notepad++ и всё бы хорошо, но очень не хватает препроцессора, чтобы не коментить вручную вагон отладочного кода перед компиляцией.

 

С очередной обновой выпилили очередную функцию (о чём, кстати, забыли помянуть в ChangeList), а она была в отладочном куске кода, который я забыл закоментить в своей время, и всё, аддон не работает. 

 

Можно, конечно, завести какой-нибудь local DEBUG и загонять весь отладочный код в if DEBUG then, но это лишние инструкции, в том числе и в циклах и лишний объем памяти под скрипт, не хорошо в общем.

 

Еще бы было неплохо, чтобы потенциальная IDE умела компилировать скрипт в одну кнопку, чтобы не рисовать под каждый скрипт батник для компиляции.

[hal.dll]

С очередной обновой выпилили очередную функцию (о чём, кстати, забыли помянуть в ChangeList), а она была в отладочном куске кода, который я забыл закоментить в своей время, и всё, аддон не работает.

 

Тут тебя препроцессор вряд ли бы спас.

___

 

В некоторых аддонах спецом оставляю отладочный код, чтобы при случае пользователи могли отладочную инфу предоставить. (по умолчанию спам отключен, разумеется).

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

По идее в Notepad++ должна быть где-то зарыта эта вполне себе стандартная функция. Или может плагин есть какой.

 

Можно, конечно, завести какой-нибудь local DEBUG и загонять весь отладочный код в if DEBUG then, но это лишние инструкции, в том числе и в циклах и лишний объем памяти под скрипт, не хорошо в общем.

Лично я часто именно так и делаю.

Можно поинтересоваться, о каких циклах идет речь? Какая сложность (O(n))? Какого порядка само n?

Если это в обработчике дамага, или бафов, или других часто приходящих сообщений, то, конечно, if DEBUG then нельзя использовать.

Если же это что-то вроде 2-3 отладочных сообщения при клике на кнопку раз в полгода, то проверка условия перед их печатью - вообще ничто по сравнению с остальными действиями.

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

Когда алгоритм вместо 1 секунды начал выполняться 0.1 секунду - это оптимизация.

Когда алгоритм вместо 1 секунды начал выполняться 0.9998 секунд - это маразм и впустую потраченное на правку скрипта время.

[LEM]

Кто чем пользуется для написания аддонов? Сам пользую Notepad++ и всё бы хорошо, но очень не хватает препроцессора, чтобы не коментить вручную вагон отладочного кода перед компиляцией.

 

С очередной обновой выпилили очередную функцию (о чём, кстати, забыли помянуть в ChangeList), а она была в отладочном куске кода, который я забыл закоментить в своей время, и всё, аддон не работает. 

 

Можно, конечно, завести какой-нибудь local DEBUG и загонять весь отладочный код в if DEBUG then, но это лишние инструкции, в том числе и в циклах и лишний объем памяти под скрипт, не хорошо в общем.

 

Еще бы было неплохо, чтобы потенциальная IDE умела компилировать скрипт в одну кнопку, чтобы не рисовать под каждый скрипт батник для компиляции.

Мой блокнот с плюсами компилирует/дает лист/запускает за одно нажатие по кнопке.

http://sourceforge.net/projects/npp-plugins/files/NppExec/

[Zaam]

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

Тоже сорт оф костыль.

 

 

Можно поинтересоваться, о каких циклах идет речь? Какая сложность (O(n))? Какого порядка само n?

Алхимия. Комбинаторика. Бывало и O(n!/(n-5)!) и n=24, хотя от такого ужаса уже избавился.

 

 

Мой блокнот с плюсами компилирует/дает лист/запускает за одно нажатие по кнопке.

Благодарствую, буду посмотреть. Но тема не закрыта, интересно мнение остальных. 

[logg]

Npp

нарисовал универсальный батник, делает из mainscript.lua luac из той папки из которой запускается.

[Zaam]

нарисовал универсальный батник, делает из mainscript.lua luac из той папки из которой запускается.

Такой батник у меня тоже есть. Но с ним пара проблем имеется:

1. Нужно отдельное окно для запуска батника, это, я так понимаю, можно решить вышеупомянутым NppExec'ом.
2. Лишний файл в папке (и это тоже, думаю, можно решить тем же).
3. Иногда надо компилировать больше одного файла.

Всё это, конечно, мелочи, но вдруг счастье где-то рядом.

[hal.dll]

Тоже сорт оф костыль.

В общем случае - да. У меня токен как правило - вызов функции печати отладочной информации. Так что выглядит совершенно безобидно.

 

Кстати, для любителей батников, в винде есть консольная прога findstr, работает по принципу линуксовского grep (если это кому-то о чем-то говорит...).

http://habrahabr.ru/post/71568/

http://admin-gu.ru/windows/windows-grep

Собственно, вызов findstr /V DEBUG_TOKEN MyScript.lua на выходе выдает почищенный от ненужных строк код.

Это можно прописать в IDE в команде компиляции в пайп перед передачей в luajit, либо в команде препроцессора, если таковая имеется.

[Setras]

Я пользую SCiTE, но только для редактирования, никаких приблуд типа сборки/компиляции не юзаю. С тех пор как одоны на сайте шифруются вообще не юзаю компиляцию - можно будет получить мои исходники если я вдруг помру

[Altair]

Непосредственно для написания кода использую тоже NPP. И тоже очень не хватает препроцессора. Причем не только для выпиливания дебага. Находил в инете несколько вариантов lua-препроцессоров написанных на том же lua, но чота они замороченные какие-то и выглядят страшными, поэтому так рука и не поднялась их интегрировать в сборку.

 

Ну а сборка выглядит примерно вот так:

 

Фичи:

• Собирается всё одной кнопкой Build. Можно из этого же окна задать Output папку - игровую папку с аддонами. Можно открыть её или папку с сорцами любого аддона, если дабл-кликнуть по нему в списке.
• Debug - это нескомпиленная версия, кладется в Output отдельной папочкой.
• Release - сборка скомпиленного и упакованного в pak аддона. Если ставлю галку Distribution, то складывается туда, откуда был запущен билдер, иначе - в Output.
• Автоматом инкрементируются и могут подставляться версии/ревизии в имя аддона (которое в *.(UIAddon).xdb), в localizedName/Desc, в имя pak-файла или куда-нибудь еще по желанию.
• Есть папка _SharedLibraries, где лежат всякие "общие" lua-скрипты типа LibDnD, всяких хелперов и прочего. Эдакая помойка, откуда можно поиметь код на все случаи жизни. Зареференсить оттуда файл в аддоне можно прописав тэг [shared] перед именем файла в стандартном *.(UIAddon).xdb. Пример из ACP: 

  <Item href="[Shared]Core.lua" />
  

  В таком случае файл Core.lua кладется в аддоне в подпапочку Libraries, а его путь в xdb аддона подменяется на соответствующий.

• Можно скипнуть компиляцию для любого скрипта, добавив аналогично предыдущему пункту тэг [skipCompile]

• Есть система "патчей" (папочка _Patches), которая представляет собой независимые от аддона ресурсы, которые могут складываться в любой аддон. К примеру, есть у меня MessageBox, я могу интегрировать его в несколько аддонов, при этом файлы MessageBox'а лежат в одном месте. В патчах же могут лежать и более мелкие ресурсы. Например, шаренные одинаковые текстуры, чтоб руками не перекладывать туда-сюда.

Я почти доволен этой штукой. Если б еще препроцессор был и можно было прыгать по сорцам как в любой другой IDE через Go to definition, то вообще б лепота.

[Zaam]

Я почти доволен этой штукой.

Я так понимаю, штука самописная? Была такая мысль, но я 100 лет не запускал ничего приличнее VBA, так что пока отложил эту идею.

[Altair]

Кстати насчет дебага добавлю. Т.к. можно оверрайдить функции любые (в том числе библиотечные, вроде как), то как вариант вместо препроцессинга можно добавлять в проект debug.lua, в котором будет написано что-то типа (в некоторой степени псевдокод):

local _logInfo = _G["LogInfo"]
_G["LogInfo"] = function(...)
    _logInfo("additional_debug_data", ...)
end

Соответственно, если НЕ добавлять, то ничо оверрайдиться не будет. Таким образом можно заранее определить несколько функций как пустые, а потом в debug.lua их переопределить и написать какое-нибудь тело.

 

 

Я так понимаю, штука самописная?

Ога.

[hal.dll]

Соответственно, если НЕ добавлять, то ничо оверрайдиться не будет. Таким образом можно заранее определить несколько функций как пустые, а потом в debug.lua их переопределить и написать какое-нибудь тело.

Буду выглядеть глупо в контексте моего же комментария, что не надо гоняться за мифической оптимизацией в 10 наносекунд, но скажу, что вызов пустой функции с кучей инфы для печати отнимает несколько больше времени, чем проверка глобальной переменной и переход в другой кусок кода. Что в принципе очевидно.

Вот, когда-то тестировал:

Global("Config", {})
...
    -- Test LogDebug
    local TestDebug1 = function(x, y, z)
        if Config.DebugVerbose then LogInfo(x, y, z) end
    end
    local TestDebug2 = Config.DebugVerbose and function(x, y, z) LogInfo(x, y, z) end or function(x, y, z) end

    local time1 = common.GetMsFromDateTime(common.GetLocalDateTime())
    while a < 1000000 do
        a = a + 1;
        -- case 1:
        --if Config.DebugVerbose then LogInfo(1, 2, 3) end -- 53 ms
        -- case 2:
        --TestDebug1(1, 2, 3) -- 154 ms
        -- case 3:
        --TestDebug2(1, 2, 3) -- 95 ms
        b = b + 1;
    end
    local time2 = common.GetMsFromDateTime(common.GetLocalDateTime())
...

[Altair]

В моем понимании "вырезание Debug'а" - это не столько вопрос производительности, сколько вопрос чистки кода от нежелательных вещей. В этом контексте смириться с разницей во временах выполнения пустой функции и проверки переменной вполне себе можно. А если заморачиваться, то тогда уж надо вплотную смотреть на препроцессор.

[hal.dll]

В моем понимании "вырезание Debug'а" - это не столько вопрос производительности, сколько вопрос чистки кода от нежелательных вещей. В этом контексте смириться с разницей во временах выполнения пустой функции и проверки переменной вполне себе можно. А если заморачиваться, то тогда уж надо вплотную смотреть на препроцессор.

Хорошие отладочные сообщения и пользователю будут приятны

Но в целом понимаю твою позицию.

Препроцессор - понятие достаточно абстрактное, чтобы не зацикливаться на lua модуле интегрированном в систему/компилятор/прочее. Подойдет любая внешняя программа, если ее можно вклинить между IDE и LuaJIT. Кстати, LuaJIT сам по себе содержит какие-то внешние модули (bc.lua, bcsave.lua...). Может там есть что-то похожее на препроцессинг?

[Saionaro]

Не совсем среда разработки, но очень удобный редактор кода:

http://www.sublimetext.com/3