Посоветуйте «lisp»

В Racket она таки доступна для FFI. При сборе указателя через GC вызывается указанный финализатор для FFI объекта.

Я писал, что не знаю насчет racket. Хорошо, что есть. Спасибо за информацию.

В яве пока еще больше библиотек, чем в ракетке. Хотя, конечно, всё зависит от области применения.

Например, в кложуре нет необходимости в аналогах defcfun / foreign-funcall.

дефайны можно генерировать автоматом из хедеров. foreign-funcall нинужен.

Не понял, гц уже отменили?

А разве он будет работать в CL для ссылок на неродные объекты?

Суть вообще в том, что один хрен на практике it just does not works. Чтобы нормально использовать библиотеку написанную на X в языке Y при условии, что семантика ЯП сильно отличается (а она в случае кложуры/джавы очень сильно отличается) надо писать прослойку. Банальный пример - коллекции в кложуре дефолтно ленивые и иммутабельные. Каким образом можно делать интероп с жабой, если там все наоборот?

Не знаю на счет CL. А в Racket можно менеджить ссылки своим ГЦ.

Применительно к C/CFFI оно прекрасно заменяется обычным для CL with-* стилем.

with-* макросы — это нормальная практика. Но их нужно писать. В clojure можно просто использовать объекты и методы java. Хотя, конечно, приходится учитывать мутабельную семантику явы.

В простейших случаях работает. А вообще, согласен. Уже упоминал это. Но, ИМХО, сделать в clojure обертку над ява в общем случае проще, чем сделать аналогичную обертку в CL над C.

А разве он будет работать в CL для ссылок на неродные объекты

Будет. Тип cffi:pointer — вполне родной. Далее в момент сбора также (не ANSI CL, но реализовано почти везде) можно прицепить финалайзер (через trivial-garbage)

В общем, выглядит так

(defun gced-foreign-alloc (type &rest rest)
  (let* ((ptr (apply #'foreign-alloc type rest))
         (addr (pointer-address ptr)))
    (tg:finalize ptr
                 (lambda ()
                   (foreign-free (make-pointer addr))))))

Это практически полный аналог malloc из Racket. Для указателей на FFI объекты делается также, но с деструктором вместе с foreign-free.

Можно пример использования?

with-* макросы — это нормальная практика. Но их нужно писать.

В СFFI уже написаны. Можно просто использовать. И это уже не «ручной» закат, а разумно-достаточный полуавтомат :) Интегрировать в GC тожем можно но для C имеет относительный смысл.

сделать в clojure обертку над ява в общем случае проще, чем сделать аналогичную обертку в CL над C

Когда как. Проще только в ситуации: чужой код создаёт и удаляет объекты. В остальных случаях или одинаково просто (java.system и libc) или одинаково сложно (java hibernate и Gtk).

Интегрировать в GC тожем ожно но для C имеет относительный смысл.

С этого места поподробнее =)

Можно пример использования?

Дык.

(let ((ptr (gced-foreign-alloc :int)))
    (foreing-funcall :scanf "%i" ptr)
    (mem-ref ptr :int))

освобождается автоматически.

одинаково сложно (java hibernate

Хм, 110 строчек. Непохоже,чтобы это было действительно сложно.

С этого места поподробнее

Я думаю, что он имеет в виду, что для Си лучше программирование в стиле RAII:

(with-foreign-object (ptr :int)
  (foreing-funcall :scanf "%i" ptr)
  (mem-ref ptr :int))

Мне GC в FFI понадобился только для ООП. Когда надо какое-то время хранить ссылку на структуру в Си.

Хм, не так уж страшно =)

Monk выше уже привел пример я имел ввиду именно этот вариант. Вариат «относительный» потом что С своего GC не имеет, а болтающиеся ссылки на стороне лиспа не есть хоорошо.

Мне GC в FFI понадобился только для ООП. Когда надо какое-то время хранить ссылку на структуру в Си.

Ну то есть, CL плохо подходит для интеропа с объектно-ориентированными библиотеками (в случае C++ отдельные пляски с бубном).

CL плохо подходит для интеропа с объектно-ориентированными библиотеками

С объектно-ориентированными — замечательно. Пишется макрос аналогичный gced-foreign-alloc и на каждый класс описание в виде

(def-constructor
  (make-object (i :int) (c :string))
  free-object)
; создаёт функции make-object и free-object. make-object регистрирует free-object финализатором

Основная проблема с char*. Если их держать как указатели, то приходится конвертировать при каждом чтении. Если преобразовывать, то может оказаться, что надо изменить данные именно в той строке (по тому адресу), что получено из Си.

Ну и в Сишных заголовках нигде не указано, надо ли освобождать полученную строку и как. Вот GObjectIntrospection завоюет мир, тогда будет проще.

Брр. Вот это я и называю закатом солнца вручную.

Вот GObjectIntrospection завоюет мир, тогда будет проще.

Помнится, пару лет назад с этим были серьезные проблемы. Существует ли хоть одна production ready реализация биндингов gtk в CL?

Существует ли хоть одна production ready реализация биндингов gtk в CL

https://github.com/andy128k/cl-gobject-introspection

Хорошо, верю =)

А насколько полна эта реализация? Какие версии gtk поддерживает? Можно ли рисовать интерфейс для CL-программ на glade? И какие платформы и реализации поддерживает?

А насколько полна эта реализация?

Нет частных случае типа GArray и GHash в качестве типов значений. Общие вроде все.

Какие версии gtk поддерживает?

Любые, для которых есть GObjectIntrospection. По факту 2 и 3.

Можно ли рисовать интерфейс для CL-программ на glade?

Разумеется. Там же с точки зрения API обычный объект Gtk для рисования интерфейса.

Годно. CCL поддерживается? На оффтопике запустится?

CCL поддерживается?

Да

На оффтопике запустится?

Да. Только найти gobjectintrospection для него тяжело. Я с какого-то совсем левого места качал, не помню уже.

Аргументы в #:args обязательны.

Спасибо.

Значит всё-таки невнимательно смотрел... забавно, что на одном лисп-форуме про это спрашивал - ответили в духе «это (отсутствие параметра) и самому проверить не сложно».

Только найти gobjectintrospection для него тяжело.

Эх, неприятные нюансы. Спасибо.

Вообше говоря, действительно не сложно.