Если тебе интересна интеграция с Lua

[Devil]

Привет, уважаемый форумчанин

Я являюсь разработчиком дорогой для меня библиотеки CrystalLUA. Цель проекта - избавить Delphi/FreePascal программиста от рутины связывания нативного кода и кода Lua. Кто не знает, Lua - самый распространённый скриптовый язык в мире.

Пишу это сообщение не только, чтобы на мой проект обратили внимание. Сейчас актуален другой вопрос. В середине октября я планирую приступить к большой переработке проекта. Среди ключевых нововведений - полная поддержка Unicode, события, и конечно же автобиндинг – механизм, благодаря которому необходимость в регистрации промежуточных калбеков может просто отпасть. Файл документации будет переведён на английский. Так вот мне как воздух сейчас нужны люди. Энтузиасты, способные не только использовать чужие наработки, но и участвовать в развитии проектов "зоны свободного ПО". Если ты посмотришь хотя бы в опубликованную Mind-карту - увидишь, что работы много и дело найдётся каждому. Заявленные фичи и так будут реализованы, просто со сторонней помощью они будут разработаны комфортнее; + можно реализовать вещи за пределами заявленного списка. К примеру на данный момент до полной поддержки FreePascal руки не дошли. Поэтому если ты считаешь, что можешь быть или хотел бы быть в чём-то полезен - жду сообщение в личку или по любому из контактов, указанных в ветке.

p.s. такое сообщение я оставляю на многих русскоязычных форумах. Потому что аудитория Delphi/FreePascal-программистов не велика. Lua используют ещё меньше. А для продуктивной работы с иностранцами не хватит моего знания языка.

в любом случае спасибо за внимание!

[sign]

Скачал, запустил пример.
Упс!

Код: Выделить всё

C:lazaruscomponentscrystal_luaCrystalLUA.pas(5705,55) Error: Incompatible type for arg no. 1: Got "TTypeInfo", expected "PTypeInfo"

Лазарус 1.1
FPC 2.6.1

Добавлено спустя 19 минут:
Было

Код: Выделить всё

5057   typename := GetOrdinalTypeName(PropInfo.PropType^);

Исправил на

Код: Выделить всё

58057  typename := GetOrdinalTypeName(PropInfo.PropType);

Код: Выделить всё

C:lazaruscomponentscrystal_luaCrystalLUA.pas(6662,48) Error: Incompatible type for arg no. 1: Got "TTypeInfo", expected "PTypeInfo"

Исправил аналогично.

Далее:

Код: Выделить всё

C:lazaruscomponentscrystal_luaCrystalLUA.pas(7401,59) Error: Incompatible types: got "Byte" expected "LongBool"

Понял, править нужно много!

Добавлено спустя 6 минут 15 секунд:
А вот таким вообще никогда не занимался, потому невежественен:

Код: Выделить всё

Value.p := Pointer(lua_tocfunction(Handle, stack_index));
C:\lazarus\components\crystal_lua\CrystalLUA.pas(10978,58) Error: Wrong number of parameters specified for call to "<Procedure Variable>"

lua_tocfunction: function(L: Plua_State; idx: Integer): lua_CFunction; cdecl;

lua_CFunction = function(L: Plua_State): integer; cdecl;

[Devil]

sign,

я программирую в основном на Delphi. Библиотека частенько меняется и синхронизировать с компиляцией под FPC не всегда успевается.
в последний раз проект хорошо компилировался под FPC и даже работал
однако были "скользкие" моменты. Например в библиотеке предусмотрен вызов виртуальных методов. При регистрации смотрится: виртуальный он или нет. Однако под FPC такой возможности с наскока добиться не удалось. Кроме того странно вели себя typeinfo. В Delphi к примеру для TRect не генерируется typeinfo. А в FPC он есть и генерируется разный, в зависимости от ключей компиляции в используемых модулях (долго объяснять).

Проработка в FPC - это одно из направлений, которое хотелось бы реализовать (с чьей-то помощью).
Аналогично кроссплатформ x86 (Linux, Mac OS)
не исключаю поддержки других платформ, просто используется много ассемблера, планируется ещё больше (чтобы максимизировать производительность).

Так что если кто-то изъявит желание тщательно проработать многие внутренние вопросы до стабильного состояния - будет здорово.
Единственное что прошу - не относиться к задаче поверхностно. Задача сложна

[alex208210]

Devil
Обратись к mai62, автору handycache. Он тесно работает с Delphi и LUA

[Devil]

alex208210,

написал
но честно говоря от этого форума я хотел бы найти спецов именно по FreePascal и кроссплатформ. Которые естественно заинтересованы в интеграции с Lua

[Mr.Smart]

Devil, у вас профессиональная заинтересованность? Или как?

Добавлено спустя 39 секунд:
з.ы. Знаем, любим - LUA.

[Kemper]

Сразу проситься... Положите вы проект в DVSN, какой-нибудь, хоть Git, хоть Mercurial, хоть fossil, а то помогать и работать без этих инструментов просто не возможно.

[B4rr4cuda]

Недавно как раз смотрел данную библиотеку.. даже правил до состояния проглатывания компилятором.. вот только дальше сигсегв в procedure TLuaRecordInfo.InternalRegField(..
В причинах с наскока разобраться не получилось - отложил до лучших времен.

[Kemper]

viewtopic.php?f=13&t=8333

[Devil]

Mr.Smart,

> у вас профессиональная заинтересованность? Или как?

хороший вопрос. Да, во-первых, у меня профессиональная заинтересованность.
Во-вторых, я человек благодарный, сам часто пользуюсь свободными разработками, хочется отдать что-то миру взамен. Если у меня есть действительно качественные библиотеки - я их стараюсь выложить в интернет. А с учётом того, как тяжело на практике связать Lua с Delphi - мой "продукт" действительно может помочь людям. В-третьих, уже просто созрела серьёзная переработка. Связано это и с Unicode, и с новыми уникодизированными версиями FreePascal/Delphi, и с новыми идеями по оптимизациям, и новым взглядом на проект. Наконец настало время показать проект миру, а для этого надо довести библиотеку до компиляции в современных средствах, доработать документацию и перевести её на английский. Я посмотрел на ажиотаж и базовые возможности библиотеки Lua4Delphi. Ажиотаж большой, либа фигня. ИМХО. Кстати автор недавно психанул, и оставил только платные разработки (я слышал от 1000 фунтов). Я хочу всё сделать бесплатно.


B4rr4cuda,
> TLuaRecordInfo.InternalRegField(..
> В причинах с наскока разобраться не получилось - отложил до лучших времен.

как я уже говорил, вопрос значительно глубже, чем сделать библиотеку компилируемой под FPC.
сделать так, чтобы оно компилировалось под FPC могу и я. Нужно только время потратить.
Вопрос глубже. А именно в виртуальных методах, RTTI и прочих особенностях хранения данных. К примеру реализация ClassParent() в FPC и Delphi немного различаются. Хранение массивов, "количество" в FPC и Delphi различается на единицу. Так вот все эти вопросы надо изучить, проработать, реализовать и оттестировать.

[B4rr4cuda]

как я уже говорил, вопрос значительно глубже, чем сделать библиотеку компилируемой под FPC

Я догадался)

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

[Devil]

All,

давайте на ты

Kemper,

Сразу проситься... Положите вы проект в DVSN, какой-нибудь, хоть Git, хоть Mercurial, хоть fossil, а то помогать и работать без этих инструментов просто не возможно

Может быть это не скромно. Но я достаточно хорошо взвешиваю решения, оцениваю плюсы и минусы, в зависимости от поставленных задач и приоритетов. Весь мой движок (а CrystalLUA только его часть) хостится на частном SVN сервере. Я использую SVN при работе над проектом. Буду ли я давать кому-то координаты на этот проект? Нет. Потому что эта ситуация когда и второй и третий - лишние. Проект сложен уже сейчас, разрабатывать идеологию сложно уже сейчас, если в идеологию кто то будет вмешиваться ещё - я просто потеряю интерес к проекту. Потому что сложности в архитектуре нарастут снежным комом и разгребать это всё - наверное худшая перспектива, которую я сейчас могу представить.

Почему та схема, которая имеется сейчас - самая правильная. (но я уверен, существуют проекты, которые глупо разрабатывать командой без SVN). Проект по сути состоит из всего одной(!) *.pas библиотеки. В каких-то мелких доработках на стороне он не нуждается. Крупные доработки выходят скопом и редко, может быть раз в пол года. Версия всегда маркируется датой выпуска, поэтому обновляться можно крайне редко, сравнивая для начала дату выпуска. Если у проекта будет сайт (ну мало ли), то архив будет храниться там. Пока мне нужна стабильная ссылка и ссылка с моего narod-сайта полностью удовлетворяет. Хотя фиг знает, может и будет потом ссылка на какой-нибудь SourceForge к примеру.

я не против использования DVSN. Я за взвешенную расстановку приоритетов.
сорри если наступил на "больную мозоль"

Подошли к важному вопросу. В чём же состоит ожидаемая помощь.
Ожидаемую помощь я делю на три части: тестирование, проработка информации, разработка сторонних средств

Ну то что тестировать нужно будет на разных данных и платформах, думаю, объяснять не надо.
К части "проработка информации" как раз относится например изучение отличий RTTI, законов компиляции, отличия для платформ. Под "проработкой информации" подразумевается полное теоретическое изучение, а так же практические наработки кодом, которые я уже смогу использовать в библиотеке. Каждую "область проработки" я сопровождаю документом с чётким описанием: 1) почему такая проработка вообще нужна. 2) какие приоритеты. 3) какие шаги предлагаю. К примеру сейчас я пишу документ по interface, OLE, Variant. Если один чувак проработает эту информацию, то скорее всего в скриптах появится возможность использовать Excel, Word и другие Ole-контейнеры так же удобно, как бы это делаем в Delphi (наверно и в FPC). Если кто-то из посетителей этого форума проявит желание проработать вопрос полной совместимости с FreePascal и Linux, Mac OS - то я так же создам полный документ со всем описанием, что нужно проработать.

Сторонние средства - это программные продукты, которые каким либо образом помогают в развитии или использовании библиотеки. К примеру, если получится, один чувак реализует универсальную систему тестирования. И тогда возможно огромная гора проблем с тестированием отпадёт. Один человек, кстати с этого форума, возможно разработает IDE. И тогда разрабатывать Lua скрипты можно будет не только с подсветкой синтаксиса, но и всплывающими подсказками, управлениями проектами, дебагом - всё с учётом именно особенностей работы c CrystalLUA. Существует и ещё 1-2 сторонних средства, которые желательно было бы разработать.

Я пишу "возможно", "желательно", "может быть" - потому что проект не коммерческий и каждый участник может как реализовать, так и не реализовать. Ну а я их просто не потяну, потому что свою большую область работ я уже обрисовал. (можно посмотреть в Mind-карте на том форуме)

Добавлено спустя 1 минуту 5 секунд:
B4rr4cuda,

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

ну я собственно об этом и написал

[Devil]

Апаю тему

на данный момент позиция грамотного FreePascal разработчика свободна
если тебе данная тема интересна - пожалуйста отписывайся. Крайне важно чтобы ты рулили в FreePascal, владел навыками плотной работы с RTTI, имел опыт программирования под WIndows/Linux/Mac OS. Знание ассемблера приветствуется