freepascal.ru

Перевел заголовочные файлы Ruby для FPC. По адресу https://github.com/shikhalev/ppruby лежит файл ruby18.pp, с ним можно создавать расширения для Ruby на паскале, или встраивать Ruby в свои программы. В планах — написать обертку, которая будет транслировать в Ruby паскалевские объекты (через RTTI), и таким образом может быть использована как скриптовый движок для программ написанных в Lazarus.

Пожелания, замечания и участие — приветствуются.

Сразу отмечу два момента:

• Лицензия GNU GPL — строгая. В первую очередь, чтобы не париться и не хитрить с лицензией на сам Ruby.
• Версия Ruby — 1.8. Это потому что у меня на Gentoo пакет Ruby 1.9 все еще замаскирован. К тому же по нему гораздо меньше документации (хотя исходники есть, так что можно и заняться...)

Добавлено спустя 3 минуты 10 секунд:
PS. Часть функций, имеющихся в заголовочных файлах Ruby не переведена. Это главным образом те, которые появились в 1.8.7 и отсутствуют в более ранних (для которых имеется документация).
PPS. Объявления callback-функций не очень хороши, поскольку там постоянно используется переменное количество параметров... Можно использовать прямое приведение, если что.

Добавлено спустя 5 часов 44 минуты 56 секунд:
В связи со всем этим — вопрос: есть где-нибудь более-менее полная документация по RTTI? Такое впечатление, что придется выковыривать по кусочкам инфу...
Как-то можно узнать список параметров published-методов? Или не стоит заморачиваться?

В процессе создания обертки возникла мысль сделать вызов Ruby-объектов через варианты (в настоящее время компилятор позволяет обращаться к методам и свойствам таковых). Однако, возникает вопрос, как это реализовать:

1. Как это сделано в модуле ComObj для OLE-объектов + обертка, реализующая IDispatch. В этом случае не будет возможности использовать одновременно с самим ComObj, поскольку используется одна глобальная переменная из модуля Variants. В принципе, конечно, можно пропатчить ComObj, чтобы загнать в {$ifdef } все платформенно-зависимое, и использовать его, но это будет довольно грязный хак, который вряд ли примут в апстрим.
2. Пойти через CustomVariant — т.е. допилить до рабочего состояния модуль Variants. Это можно (и нужно) сделать так, чтобы изменения были приняты. Против этого варианта, пожалуй, только то, что, как и всякий универсальный, он наиболее ресурсоемок. Как в плане трудозатрат, так и в плане использования — пара лишних вызовов на каждую операцию.
3. Самый простой путь — поставить свой вариант DispInvoke в VariantManager. Недостаток — несовместимость уже с модулем Variants и всеми, что от него зависят. Правда, можно сохранять старое значение и вызывать его при необходимости. Тогда мой модуль должен быть обязательно подключен после Variants...
4. Отложить идею с оберткой, пока не будет готов модуль Variants... Опционально — поныть в рассылке разработчиков FPC Полагаю, это только на тот случай, если предыдущие окажутся недоступны (хотя недоступность третьего мне трудно себе представить...)

Идеи, советы?..

Иван Шихалев писал(а):поныть в рассылке разработчиков FPC

Я бы начал именно с этого. В процессе могут выясниться планы разработчиков, и соответственно что они готовы принять в виде патчей, а что нет. Там же могут появиться конкретные советы от тех, кто занимался разработкой модуля Variants. Имхо, строить библиотеку на хаках при Open Source компиляторе -- как то не очень. Для исключительно внутреннего использования может быть и подойдёт, но если есть планы её открыть и привлекать community -- лучше чтобы она была согласована с FPC. А вот как её согласовать с наименьшими трудозатратами -- это как раз и можно попробовать узнать в рассылке.

Пойти через CustomVariant — т.е. допилить до рабочего состояния модуль Variants. Это можно (и нужно) сделать так, чтобы изменения были приняты. Против этого варианта, пожалуй, только то, что, как и всякий универсальный, он наиболее ресурсоемок. Как в плане трудозатрат, так и в плане использования — пара лишних вызовов на каждую операцию.

Или воспользоваться уже допиленным от Kylix 2 OE ,имхо модули фактически от Delphi 6, а они практически не имеют ошибок, по крайней мере я их не встречал, и Лицензия GPL
исходники kylix2 http://narod.ru/disk/27159927000/kylix2_source.7z.html

Odyssey писал(а):могут выясниться планы разработчиков

А что там выяснять? Функциональность модуля, во-первых, известна, поскольку это аналог дельфийского модуля, а во-вторых, уже объявлена в интерфейсной части, только не реализована.

coyot.rush писал(а):и Лицензия GPL

А вот тут надо выяснять — согласны ли на это разработчики — вообще вся RTL идет под LGPL...

Судя по недавней дискуссии в рассылке, где предлагалось включить в состав компилятора библиотеку шаблонов, на GPL разработчики не согласны. Только Modified LGPL.

Это логично. Не следует без особой нужды устраивать зоопарк лицензий в одной RTL.