ПроектыФорумУтилиты

Высокоуровневая библиотека CrystalLUA. Delphi + Lua (15 стр)

Страницы: 110 11 12 13 14 15
#210
20:05, 29 апр 2017

clc

Могут конечно. Но значительно чаще вызываются методы
На то оно и ООП

#211
13:09, 30 апр 2017

Ещё раз напомню, режим обращения по . в CrystalLUA является опциональным и обсуждать здесь нечего

Забавно такое читать от автора либы.
Вообще-то в оригинальном тексте либы НЕТ отключения препроцессинга, это мне пришлось костыли дописывать на ходу, потому как проблемы с препроцессингом задолбали.

#212
17:14, 30 апр 2017

grumbler1

Ты прав. Флаг FPreprocess есть, а в свойство он не вынесен
Видно, потерял между коммитами. Но и добавить его не сложно. Не велика беда

#213
20:41, 30 апр 2017

На всякий случай отпишусь для истории по личным наблюдениям:
1. при работе с отладчиком ЛуаДжит и стандартная Луа ведут себя немного по-разному: если мы терминируем выполнение скрипта в Луа, он беспрекословном и нормально закругляется. Остановка выполнения в джите требует ОБЯЗАТЕЛЬНОГО обнуления стека, иначе джит просто заваливается.

2. Также в джите не реализованы TAILRET оповещения, а это значит что мы не можем корректно отследить выполнение кода наподобие
return MyFunc()

Что делает Луа:
a. выдает TAILRET - сообщает что мы дошли до конца текущий функции, данные по текущей функции не доступны, но мы знаем, что дальше нас отправят куда-то за вычислением результата.
b. помещает MyFunc() в стек
c. передает управление в копию MyFunc() в стеке БЕЗ ВЫЗОВА функции, а простым переходом!
d. завершает работу MyFunc() обычным RET без описания функции (она же в стеке!)

Что делает ЛуаДжит:
a. помещает MyFunc() в стек
b. передает управление в копию MyFunc() в стеке БЕЗ ВЫЗОВА функции, а простым переходом! Т.е. мы попали неизвестно куда, текущая функция уже завершена, данные не доступны
c. завершает работу MyFunc() обычным RET без описания функции (в стеке!)

Так что рисую отладчик под Луа и под ЛуаДжит надо реализовывать разные технологии поведения. Ваниллу не пробовал, не знаю.
Как определить, с какой либой мы имеем дело?
Я детектю не через таблицы, как некоторые любят, а тупо по наличию модулей и запускаю код сразу после подключения к Луа:

+ Показать

3. Следующее наблюдение - после lua_pcall в стеке мы получаем функцию, которая отвечает за работу текущего скрипта, поэтому если нам надо часто ее вызывать, лучше сохранить куда-то, чтобы потом в стек ее подкидывать при перезапуске. Если функцию не хранить и в стеке не подкидывать, Луа будет постоянно парсить свой же байткод при вызове и формировать в стеке заново функцию. И если мы активно пользуемся памятью (выделение/освобождение) то получим конкретные тормоза, особенно на больших массивах данных...
Узнал я это совершенно случайно, когда в отладчике решил узнать, почему-же каждый раз наша основная функция при запуске идет БЕЗ ИМЕНИ. Оказалось все очень просто - ее каждый раз в стек Луа загоняет, в отличие от первоначальной функции скрипта.

#214
13:56, 26 мая 2017

Всем привет
Я таки выделил месяцок, чтобы провести рефакторинг библиотеки
Задача - довести библиотеку до состояния компилируемости в новых версиях Delphi, поддержка x64, а так же опциональный режим Юникода
Можете посмотреть коммиты ветки development, я с определённой периодичностью скидываю обновления

Чем вы можете сейчас помочь
Тут жаловались на справку. Что нет поиска, сумбурно написано, листинги кода слабые
Я думаю можно пересесть на CHM. Причём исходники справки можно хранить в репозитории, а бинарники собирать и закидывать на сайт. Так что кто хочет помочь - раскидайте текущую справку на файлы под CHM. Все вопросы на скайп

#215
16:46, 12 июня 2017

Что, опять нету желающих?
Даже справкой заняться? )

Страницы: 110 11 12 13 14 15
ПроектыФорумУтилиты

Тема в архиве.