clc
Могут конечно. Но значительно чаще вызываются методы
На то оно и ООП
Ещё раз напомню, режим обращения по . в CrystalLUA является опциональным и обсуждать здесь нечего
Забавно такое читать от автора либы.
Вообще-то в оригинальном тексте либы НЕТ отключения препроцессинга, это мне пришлось костыли дописывать на ходу, потому как проблемы с препроцессингом задолбали.
grumbler1
Ты прав. Флаг FPreprocess есть, а в свойство он не вынесен
Видно, потерял между коммитами. Но и добавить его не сложно. Не велика беда
На всякий случай отпишусь для истории по личным наблюдениям:
1. при работе с отладчиком ЛуаДжит и стандартная Луа ведут себя немного по-разному: если мы терминируем выполнение скрипта в Луа, он беспрекословном и нормально закругляется. Остановка выполнения в джите требует ОБЯЗАТЕЛЬНОГО обнуления стека, иначе джит просто заваливается.
2. Также в джите не реализованы TAILRET оповещения, а это значит что мы не можем корректно отследить выполнение кода наподобие
return MyFunc()
Что делает Луа:
a. выдает TAILRET - сообщает что мы дошли до конца текущий функции, данные по текущей функции не доступны, но мы знаем, что дальше нас отправят куда-то за вычислением результата.
b. помещает MyFunc() в стек
c. передает управление в копию MyFunc() в стеке БЕЗ ВЫЗОВА функции, а простым переходом!
d. завершает работу MyFunc() обычным RET без описания функции (она же в стеке!)
Что делает ЛуаДжит:
a. помещает MyFunc() в стек
b. передает управление в копию MyFunc() в стеке БЕЗ ВЫЗОВА функции, а простым переходом! Т.е. мы попали неизвестно куда, текущая функция уже завершена, данные не доступны
c. завершает работу MyFunc() обычным RET без описания функции (в стеке!)
Так что рисую отладчик под Луа и под ЛуаДжит надо реализовывать разные технологии поведения. Ваниллу не пробовал, не знаю.
Как определить, с какой либой мы имеем дело?
Я детектю не через таблицы, как некоторые любят, а тупо по наличию модулей и запускаю код сразу после подключения к Луа:
3. Следующее наблюдение - после lua_pcall в стеке мы получаем функцию, которая отвечает за работу текущего скрипта, поэтому если нам надо часто ее вызывать, лучше сохранить куда-то, чтобы потом в стек ее подкидывать при перезапуске. Если функцию не хранить и в стеке не подкидывать, Луа будет постоянно парсить свой же байткод при вызове и формировать в стеке заново функцию. И если мы активно пользуемся памятью (выделение/освобождение) то получим конкретные тормоза, особенно на больших массивах данных...
Узнал я это совершенно случайно, когда в отладчике решил узнать, почему-же каждый раз наша основная функция при запуске идет БЕЗ ИМЕНИ. Оказалось все очень просто - ее каждый раз в стек Луа загоняет, в отличие от первоначальной функции скрипта.
Всем привет
Я таки выделил месяцок, чтобы провести рефакторинг библиотеки
Задача - довести библиотеку до состояния компилируемости в новых версиях Delphi, поддержка x64, а так же опциональный режим Юникода
Можете посмотреть коммиты ветки development, я с определённой периодичностью скидываю обновления
Чем вы можете сейчас помочь
Тут жаловались на справку. Что нет поиска, сумбурно написано, листинги кода слабые
Я думаю можно пересесть на CHM. Причём исходники справки можно хранить в репозитории, а бинарники собирать и закидывать на сайт. Так что кто хочет помочь - раскидайте текущую справку на файлы под CHM. Все вопросы на скайп
Что, опять нету желающих?
Даже справкой заняться? )
Тема в архиве.