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

Ordan

;)
Только будь внимателен, работает только на старых Delphi, до 2007 включительно

Отложенная регистрация функций.
Почему данная конструкция не работает:

program LuaMy;

{$APPTYPE CONSOLE}

uses
  SysUtils,
  Windows,
  Messages,
  CrystalLUA in 'pas\CrystalLUA.pas';

var
  Lua: TLua;

function LuaMyFic(const Args: TLuaArgs): TLuaArg;
begin
  ....
end;
  
function LuaInit(const Args: TLuaArgs): TLuaArg;
begin
  Lua.RegConst('osInherited',255); // Регистрирует
  Lua.RegProc('MyFic',@LuaMyFic); // Не регистрирует
end;

begin
  Lua := CreateLua; // Создаем Lua экземпляр
  
  Lua.RegProc('Init',@LuaInit);
  
  Lua.LoadScript('Test.lua'); // Выполнить стартовый скрипт
  Lua.Free; // Удаляем Lua экземпляр
end.

И в коде Lua:

Можно по обработке ошибок еще пояснить: На второй странице данного форума написано: "- добавлена поддержка Chunk-ов. В частности теперь в сообщении об ошибке указывается исходный код:"
Когда запускаю приложения из делфи непосредственно сообщение о синтаксической ошибке выходит. Но когда запускаю откомпилированный файл сообщений об ошибках нет, программа просто закрывается.
Можно по возможности пример как вывести "Своё" сообщение об ошибке.

DevilDevil
Поиск пути,  по крайней мере и на 64 работает :)

Mira

Тут тоже планировался и Unicode, и x64/ARM, и регистрация как в PascalScript, и IDE
Даже есть жгучее желание отказаться от dll в пользу obj
Кто знает, может со временем реализовано будет
Но на данный момент нет ни спонсоров, ни желающих реализовывать этот функционал

gadmaker

Данный функционал касается скриптов, загруженных в исходниках
С подключаемыми модулями не работал
Можешь исследовать эту область, подумать, как грамотнее внедрить, написать пул реквест или просто скинуть правленную версию, я сам после инспекции кода внесу коррективы и выложу в репозиторий

gadmaker

Если говорить о регистрации в отрыве от твоей задачи, на мой взгляд регистрация нативных типов и методов должна происходить только до первого старта скрипта

DevilDevil
> По идее надо в препроцессинге отслеживать require и подгружать модули
> автоматически

изначально я думал сделать такой вариант как решение, однако сделал универсальный вызов через LoadModule, т.к. обработка препроцессором require не решает вопрос loadfile/dofile/loadstring и для них все равно надо писать свое решение. Вторая беда препроцессора - это принудительные скобки для модулей, которые отрабатываются в require. По правильному, вообще полностью препроцессинг надо переписывать, потому и забил на него, уж извини. Более того, есть некоторые оригинальные скрипты/либы, которые написаны с "нормальным" синтаксисом Луа, который при подгрузке коверкает препроцессор. После того, как мне как-то попадались пара таких либ, пришлось еще и отключаемый препроцессинг делать. Теперь у меня есть возможность грузить либы как с препроцессором, так и без оного - для не родных скриптов.

grumbler1

Так сейчас препроцессинг простой. Единственное, что делает - заменяет точки на двоеточия
Каким образом надо сделать препооцессинг require.
  - Анализировать синтаксис кода
  - Если найден require - заменить его пробелами, а самому (рекурсивно) подгружать (с препроцессингом) модуль
  - Можно расширить синтаксис Lua для require: заменять точку на точку с запятой или нет
  - предусмотреть загрузку dll-скриптов, а так же скриптов в бинарном виде
  - на сколько я помню, можно ещё делать что-то типа load module; эти функции тоже предварительно анализировать

Я все это прекрасно понимаю, потому и забил - переписывать надо полностью всю логику препроцессинга.

grumbler1

Тебе не стыдно?
Код PreprocessScript меньше сотни строк  😂

нет, не стыдно. если переписывать, то там от всего кристаллуа камня на камне не останется, в том числе и с асмом придется прощаться - это бесперспективняк как для не вин платформ, равно как и для вин на новом с-ленге с ключем -о3 в токио 10.2.
Я правлю по свои малые нужды и этого мне хватает, так как я не пишу глобальных и платных прог. вся сфера моих интересов чисто академическое программирование с приспосабливанием здесь и сейчас, и д2007 меня вполне устраивает.
именно поэтому уже сейчас кристаллуа превратилась в моем варианте в некий далекий отпрыск от родителя, ибо мне и отладчик понадобился и передача таблиц обратно в скрипт и прочее-прочее. И такие мелочи как парсер препроцессора, на который потратишь неделю, а толку как с него, как с козла молока, потому что он НЕ РЕШАЕТ проблем на 100%, как я уже писал - dofile/loadfile/loadstring никак не связано с препроцессором, а это значит, что развивать логику препроцессора я пока не вижу смысла. Может оно кому-то надо, я не против, но не в таком виде, не здесь и не сейчас.

grumbler1

А какой смысл явно вызывать dofile/loadfile/loadstring, если над ними есть высокоуровневая обертка LoadScript, которая производит препроцессинг?
С чего ты взял, что препроцессинг require затрет пол кода библиотеки - я не знаю. Находишь в коде require и лично подгружаешь модуль. Вот и вся логика.

Касательно твоих доработок. А с чего ты взял, что проекту не нужна отладка, передача таблиц и прочее? Наоборот, это полезные фичи, которые можно внедрить и радовать других коллег по Delphi/Lua

Я не разрабатываю проект, а занимаюсь другими, только потому, что не вижу отдачи от пользователей в виде финансов или кода. Уж кто-кто, а ты в состоянии внести лепту в развитие проекта. Как минимум из чувства элементарной благодарности

Кто в лес, кто по дрова. Еще раз. Я не развивал и не планирую развивать идею препроцессинга из-за:
1. переписывать надо полностью весь препроцессинг. А у меня он и так не такой, как в стандартном КристалЛуа.
2. Препроцессинг мне нафиг не нужен, я собираюсь от него отказаться вообще по одной единственной причине - глюки. Луа слишком гибкий язык, чтобы сделать качественный препроцессинг без глюков. Я не спорю - сделать можно, но это много времени на парсинг. Зачем? Вопрос риторический. Я не знаю - зачем и мне это не надо. И всем остальным советую забить на препроцессинг и не коверкать язык ни себе в голове, ни людям, которые потом этот код будут смотреть.
3. Есть скрипты, которые НЕ НУЖДАЮТСЯ в препроцессинге, это стандартные либы, которые распространяются в исходниках. И им препроцессинг как корове 5 нога. Не нужен. И это тоже надо понимать. Не все пишут лабораторные работы, типа "привет, мир",
4. Препроцессинг ни коим образом не может влиять на те самые dofile/loadfile/loadstring, потому что это две разные не пересекающиеся вселенные. А раз так им надо оболочка типа моего LoadModule, которая просто посылает нафиг все обработки стандартного LoadScript и делает все сама, так как в СТАНДАРТНОМ ВИДЕ КристалЛуа НЕ СПОСОБНА ТАКОЕ ДЕЛАТЬ. Вот код моей обертки
  function luaLoadModule(const Args: TLuaArgs): TLuaArg;
  var
    i: integer;
    PP: boolean;
  begin
    Result.Empty:=true;
    PP:=LUA.Preprocess;
    try
      if Length(Args) >1 then LUA.Preprocess:=Args[1].ForceBoolean
        else LUA.Preprocess:=_PREPROCESS_;
      LUA.LoadScript(Args[0].ForceString);
      i := lua_gettop(LUA.Handle);
      if i > 1 then
      begin
        // просто передаем по стеку обратно ответ, даже не заглядывая туда
        lua_settop(Lua.Handle, -i+1);
        Result.SetTypeONSTACK;
      end;
    except
      on E: Exception do
        WriteLog('Ошибка загрузки скрипта '+E.Message);
    end;
    LUA.Preprocess:=PP;
  end;

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

grumbler1

Начну издалека.
Нельзя смотреть на продукт в контексте "что в нём есть". Задачи усложняются, проекты развиваются. Нужно смотрел на то, каким проект может стать в перспективе.
Каким я вижу будущее проекта. Это Lua-совместимый компилятор, ядро которого написано на Си (или Delphi), с другой организацией внутренних структур, менеджмента памяти, дебага. С JIT-исполнением, если это позволяет платформа. С дополнительными возможностями, такими как, например, опциональная типизация и "ситуативный GC". "Ситуативный GC" предполагает мгновенную "сборку мусора", как это принято в традиционных языках программирования, без необходимости вызывать функцию GarbageCollection (в CrystalLUA она вызывается автоматически, но не мгновенно). Т.е. если я пишу List = nil, то деструктор вызывается сразу же, а не спустя какое-то время. Так вот в рамках этого понимания, нужны люди, которые понимают и/или умеют делать самое первое и простое в компиляции - лексический анализ. Кроме того лексику нужно будет анализировать и в случае регистрации "сигнатуры" метода, как это делается в PascalScript.

Касательно сегодняшних реалий, ты же сам ругался, что не работает require. Если не для замены точки на двоеточие, то модуль необходимо хотя бы проанализировать с целью выявления ошибок в нём. То есть нужно вместо require делать что-то похожее на твой LoadModule. Почему это ненужный функционал и его мега сложно реализовать - я так и не понял.

Честно говоря не встречал готовые библиотеки на Lua, которые имеет смысл инклюдить в свой проект. Но в любом случае если в коде стоит двоеточие - замена его не коснётся

P.S. Не помню, чтобы ты говорил хотя бы спасибо за мои 6+ месяцев работы над библиотекой