LINUX.ORG.RU

[FFI] CL крут

 


1

3

В каком высокоуровневом языке еще есть такой FFI, или хотя бы возможность его создания?

http://github.com/Lovesan/virgil

//gcc -std=c99 -shared -o virgil_examples[.dll/.so] virgil_examples.c
#include <stdio.h>

typedef void (*matrix_callback)(float* matrix, int m, int n, void* param);

void print_matrix(float* matrix, int m, int n)
{
    for(int i = 0; i<m; ++i)
    {
        for(int j = 0; j<n; ++j)
            printf("%g ", matrix[i*n+j]);
        printf("\n");
    }
}

void foo (float* matrix, int m, int n, matrix_callback f, void* param)
{
    print_matrix(matrix, m, n);
    f(matrix, m, n, param);
}
(deftype matrix () '(simple-array single-float (* *)))

(define-foreign-library virgil-examples
  (t (:default "virgil_examples")))

(use-foreign-library virgil-examples)

(define-external-function "foo"
    (:cdecl virgil-examples)
  (void)
  (matrix (& (simple-array single-float) :inout))
  (m int :aux (array-dimension matrix 0))
  (n int :aux (array-dimension matrix 1))
  (callback pointer)
  (param (& float :in t) :optional void))

(define-callback add-number
    void ((data pointer) (m int) (n int) (param (& float :in t)))
  (with-value (matrix data `(simple-array single-float (,m ,n)) :inout)
    (let ((param (if (voidp param) 0.0 param)))
      (dotimes (i m)
        (dotimes (j n)
          (incf (aref matrix i j) param))))))

(defun main (matrix)
  (declare (type matrix matrix))
  (format t "~&Matrix:~%~a~%" matrix)
  (force-output *standard-output*)
  (foo matrix (get-callback 'add-number) 1.0)
  (format t "~&After processing:~%~a" matrix))
* (defparameter *matrix* (make-array '(4 4) :element-type 'single-float
                           :initial-contents '((1.0  2.0  3.0  4.0)
                                               (5.0  6.0  7.0  8.0)
                                               (9.0  10.0 11.0 12.0)
                                               (13.0 14.0 15.0 16.0))))
;;==> *MATRIX*

* (main *matrix*)
;;на stdout ==>
Matrix:
#2A((1.0 2.0 3.0 4.0)
    (5.0 6.0 7.0 8.0)
    (9.0 10.0 11.0 12.0)
    (13.0 14.0 15.0 16.0))
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
After processing:
#2A((2.0 3.0 4.0 5.0)
    (6.0 7.0 8.0 9.0)
    (10.0 11.0 12.0 13.0)
    (14.0 15.0 16.0 17.0))
Даже питоновский ctypes и рядом не валялся, особенно в плане производительности.

Ответ на: комментарий от Love5an

>>Даже из чистых Си-хедеров можно извлечь то, что ты сейчас пишешь руками.

Извлечь можно слишком мало, чтобы этим заморачиваться.


Чтобы извлечь много, нужен полноценный статический анализ. см. публикацию про KLEE.

anonymous
()
Ответ на: комментарий от anonymous

>> с другой стороны, если в CL-сообществе еще нет хорошего (на основе реального компилятора) _генератора_ биндингов, то он нужен.

gcc-xml? есть такой проектик, но он практически сдох и не обновлялся:

Пакеты есть в Debian Testing и Sid, гента не интересует. Но, как я сказал, можно использовать любой нормальный фронтенд.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> gccxml сдох

Его труп еще послужит.


Прекратите насиловать труп!!111
Если хочется именно GCC, можно смотреть MEL — лисп внутри GCC, или лиспоподобные описания GIMPLE, GENERIC, RTL и прочих деревьев внутри GCC. Распарсить их гораздо легче, чем возиться с обёртками вроде gccxml.

anonymous
()
Ответ на: комментарий от tailgunner

>> gcc-xml? есть такой проектик, но он практически сдох и не обновлялся:

Пакеты есть в Debian Testing и Sid, гента не интересует.


когда эти пакеты последний раз обновлялись? даже здесь всё сдохло
http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=gcc-xml-ffi.git

ну и да, libffi как бы моднее

anonymous
()
Ответ на: комментарий от anonymous

>>> gccxml сдох

Его труп еще послужит.

Прекратите насиловать труп!!111

Ты так говоришь, будто это что-то плохое.

Если хочется именно GCC, можно смотреть MEL — лисп внутри GCC, или лиспоподобные описания GIMPLE, GENERIC, RTL и прочих деревьев внутри GCC. Распарсить их гораздо легче

Я на Питоне пишу, у нас всё и так работает. Про MEL агитируй ловсанчега. Хотя... это напрасная трата времени, он слишком любит писать на Лиспе.

gcc-xml? есть такой проектик, но он практически сдох и не обновлялся:

Пакеты есть в Debian Testing и Sid, гента не интересует.

когда эти пакеты последний раз обновлялись?

В Sid - версия 0.9.0+cvs20100501-2, что как бы намекает на последнее обновление кодовой базы полгода назад.

tailgunner ★★★★★
()
Ответ на: комментарий от Love5an

> Извлечь можно слишком мало, чтобы этим заморачиваться.

Говорят, здесь --- http://www.cliki.net/Zeta-C , сделали компилятор С на лиспе. Правда там же сказано, что будет сложно его портировать на КЛ.

ugoday ★★★★★
()

> CL крут

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

На ЛОРе бесконечные и обширные холивары на тему CL идут, наверное, лет десять. Какой реальных софт на CL был создан их участниками за это время? К чему тогда были все эти крити и битьё себя в грудь?

archimag ★★★
()
Ответ на: комментарий от Love5an

>Кроме того, большая часть работы компилируется в крайне эффективный код(в данном случае - все, кроме маршалинга матрицы в коллбэке - спецификация типа при компиляции не известна, и ее требуется интерпретировать в рантайме).

Уверен, что эффективный? Сишный код, вызывающий лисповые коллбеки, емнип накладывает ограничения на работу сборщика мусора.

Waterlaz ★★★★★
()
Ответ на: комментарий от Deleted

Не так давно кажется на лоре проскакивала статейка про скорость работы разных языков (там несколько синтетических тестов было) и CL там был сильно далеко от фаворитов.

Примерно как твой кругозор по данной тематике :) Человек в теме, глядя на результаты, удивляется и спрашивает себя: «А чего это лисп такой быстрый?».

mv ★★★★★
()
Ответ на: комментарий от mv

> удивляется и спрашивает себя: «А чего это лисп такой быстрый?».

и памяти ест всего раз в 20 больше конкурентов

anonymous
()
Ответ на: комментарий от anonymous

и памяти ест всего раз в 20 больше конкурентов

SBCL? Несомненно. Зато он память выделяет быстрее конкурентов :)

mv ★★★★★
()
Ответ на: комментарий от mv

> В си (libc), кстати, память выделяется гораздо медленней.

в си, кстати, есть достаточно много вариантов работы с памятью, благо язык позволяет

anonymous
()
Ответ на: комментарий от anonymous

Логично, тысяча чертей

Си нужен для работы с памятью, тогда как КЛ --- для решения прикладных задач.

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

> в си, кстати, есть достаточно много вариантов работы с памятью,

благо язык позволяет


Сколько?

Вообще есть не на чём не основанное суждение (точнее, сложившееся по историческим причинам), что ручное управление памятью быстрее, чем автоматическое.

archimag ★★★
()
Ответ на: комментарий от anonymous

в си, кстати, есть достаточно много вариантов работы с памятью, благо язык позволяет

Я только два могу вспомнить: автоматическое размещение в стэке и статическое в сегменте данных (загружаемом из elf'а). mmap - это свойство операционной система, а malloc работает через него (или brk/sbrk). В лиспе тоже можно дёргать mmap.

mv ★★★★★
()
Ответ на: комментарий от archimag

Зато быстрее освобождается ;)

Да, достаточно с указателем раз неправильно сработать, как вся память, занимаемая процессом, автоматически освободится ;)

mv ★★★★★
()
Ответ на: комментарий от mv

Можно написать свой аллокатор. Например как Slice Allocator в GLib, он эффективнее для выделения памяти под структуры

anonymous
()
Ответ на: комментарий от anonymous

Можно написать свой аллокатор. Например как Slice Allocator в GLib, он эффективнее для выделения памяти под структуры

Можно. Но простое увеличения указателя - это всё равно мегабыстро ;) Пока память не кончится, в которой указатель можно увеличивать.

mv ★★★★★
()
Ответ на: комментарий от archimag

> Сколько

достаточно много (с) пулы, выделение на стеке( alloca ), возможность повторно использовать выделенный блок памяти для других целей( можно тот же пул заново «запустить» ), тот же mmap, юнионы( как средство экономии памяти ), obstacks, можно использовать любой произвольный менеджер памяти вместо стандартных malloc и free, можно работать с ядром минуя (g)libc и т.д.

anonymous
()
Ответ на: комментарий от archimag

> Как часто это делают на практике?

более чем часто

Как часто имеют с этим проблемы?


не чаще чем с другим кодом на С

anonymous
()
Ответ на: комментарий от no-such-file

Товарищ! Не отводите взгляд, а попытайтесь встать на место обезьян, подобных мне, ну вот как, ради всего святого, скажите, как писать прикладуху на CL? Пока это похоже на говно из моей жопы — можно обмазаться, понюхать, лизнуть, бросить в соседа, но орех как будет в скорлупе, так в ней и останется и только старый добрый камень исправит ситуацию.

baverman ★★★
()
Ответ на: комментарий от tailgunner

Естественно.

Вообще, видимо, проблема хороших привязок — в первую очередь забота авторов библиотеки.

baverman ★★★
()
Ответ на: комментарий от baverman

> как писать прикладуху на CL?

Могу рассказать, как писать веб-приложения на CL или даже вообще сервера приложений. Что вас конкретно интересует?

archimag ★★★
()
Ответ на: комментарий от archimag

Что вас конкретно интересует?

Я не ставлю под сомнение возможность (при известном желании, наличии свободного времени, квалификации и упорства) написания прикладного CL кода.

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

Положив руку на сердце, скажи, ведь реально много пришлось писать побочного (утилитарного) кода, чтоб завести сайт?

Не спорю, разработка библиотек — очень увлекательное занятие, можно расслабиться и отвлечься от рутины, но не постоянно же этим заниматься.

baverman ★★★
()
Ответ на: комментарий от baverman

> Большинство лисповых библиотек разрабатывается «для себя», практически без обратной связи

Что хорошо демонстрирует начальный пост.

tailgunner ★★★★★
()
Ответ на: комментарий от elipse

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

baverman ★★★
()
Ответ на: комментарий от baverman

> как писать прикладуху на CL?

пишешь программу в текстовом редакторе. компилируешь. запускаешь. Не самый эффективный путь, но тебе так будет привычнее.

ugoday ★★★★★
()
Ответ на: комментарий от baverman

> Положив руку на сердце, скажи, ведь реально много пришлось

писать побочного (утилитарного) кода, чтоб завести сайт?


lisper.ru я сделал с использование библиотек, которые были мне нужны по работе. Конкретно, потребовались

* cl-closure-template - чуть более 1000 строк кода
* cl-routes - 500 строк кода
* restas - чуть более 600 строк кода

данные не учитывают размер тестов, примеров и т.п., но их можно и не считать.

Итого: примерно 2000 строк кода. Которые уже написаны и их не надо больше повторять.

Вопрос только в количестве строчек, которое в итоге придется набить.


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

но не постоянно же этим заниматься.


А я занимаюсь этим по мере необходимости. Ту же cl-closure-template я написал за 5 дней, а потом правил по мелочи, плюс, было несколько патчей от других людей.

archimag ★★★
()
Ответ на: комментарий от baverman

Каков вопрос, таков ответ. Или ты ожидал конкретный ответ, на максимально общий вопрос? Извини родной, телепаты в отпуске.

ugoday ★★★★★
()
Ответ на: комментарий от baverman

> как, ради всего святого, скажите, как писать прикладуху на CL?

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

ugoday ★★★★★
()
Ответ на: комментарий от baverman

Товарищ! Не отводите взгляд, а попытайтесь встать на место обезьян, подобных мне, ну вот как, ради всего святого, скажите, как писать прикладуху на CL?

С удовольствием, быстро и за хорошие деньги.

mv ★★★★★
()
Ответ на: комментарий от archimag

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

)) вах, ну прям сама объективность

elipse ★★★
()
Ответ на: комментарий от archimag

данные не учитывают размер тестов

Вообще-то, размер тестов в хороших библиотеках, которыми приятно пользоваться, сравним с количеством основного кода.

примеров и т.п.,

Но на это тоже было потрачено время.

Итого: примерно 2000 строк кода. Которые уже написаны и их не надо больше повторять.

Но их теперь нужно поддерживать, это же правильные CL библиотеки, не as-is поделки, я верно понимаю?

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

Черт, после этой фразы начинается классический лиспосрач. Пожалуй, нужно остановиться.

baverman ★★★
()
Ответ на: комментарий от simplex

Это потому что писатели прикладных программ не осиливают CL.

это Вы сейчас про «масло масляное» сказали, ответьте лучше на вопрос «почему так происходит»?

shty ★★★★★
()
Ответ на: комментарий от ugoday

Это был риторический вопрос?

Формальные признаки риторического вопроса точно были.

Риторический вопрос — риторическая фигура, представляющая собой вопрос, ответ на который заранее известен, или вопрос, на который даёт ответ сам спросивший. По сути, риторический вопрос - это вопрос, ответ на который не требуется или не ожидается в силу его крайней очевидности. В любом случае вопросительное высказывание подразумевает вполне определённый, всем известный ответ, так что риторический вопрос, фактически, представляет собой утверждение, высказанное в вопросительной форме. Например, задающий вопрос «Сколько еще мы будем терпеть эту несправедливость?» не ожидает ответа, а хочет подчеркнуть, что «Мы терпим несправедливость.»

baverman ★★★
()
Ответ на: комментарий от mv

С удовольствием, быстро и за хорошие деньги.

У-у, мизантроп. За хорошие деньги я и сам с удовольствием попишу на лиспе.

baverman ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.