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 и рядом не валялся, особенно в плане производительности.

многа букав, не асилил

З.Ы. успокойтесь уже, lisp крут, а остальные языки сосут. только хватит это доказывать, надоело уже.

antony986
()

> В каком высокоуровневом языке еще есть такой FFI

такой - только в Лиспе, б/п.

или хотя бы возможность его создания?

Да во всех, включая сам Си %)

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

>Да во всех, включая сам Си %)
В Си и так есть б/п.

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

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

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

Доо, а CL раскрывает макросы и парсит Си-код божьим духом.

Или... OH SHI~, ты не парсишь Си-код, а пишешь это _руками_? O_O

tailgunner ★★★★★
()

а на arm проканает?
а если вместо float будет массив структур через макрос определённых, тогда не надо будет в начале gcc -E применять?

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

Очередной высер очередного ниасилятора CL...

Врубись сначала, что код делает, потом умничай - код достаточно наглядный и тривиальный. Он работает с _лисповскими_данными_ посредством сишных функций. Причем, достигается это исключительно средствами самого CL(не надо подключать какие-то левые «модули на Си», кроме тех, с которыми непосредственно работаем). Кроме того, большая часть работы компилируется в крайне эффективный код(в данном случае - все, кроме маршалинга матрицы в коллбэке - спецификация типа при компиляции не известна, и ее требуется интерпретировать в рантайме).

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

SWIG это средство генерации описаний, а не FFI. Для CL он генерирует CFFI-биндинги, например. Но делает это, надо признать, так дерьмово, что лучше самому писать.

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

>Или... OH SHI~, ты не парсишь Си-код, а пишешь это _руками_? O_O
Генераторы типа SWIG не асиливают сгенерировать всякие там :out и :optional по метаинформации в заголовочных файлах(если оная даже и присутствует, что вообще редкость). Поэтому для качественных биндингов надо или все ручками или писать свой специфический парсер.

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

>> Или... OH SHI~, ты не парсишь Си-код, а пишешь это _руками_? O_O

Генераторы типа SWIG

Генераторы типа SWIG нужны тем, у кого нет нормальных генераторов типа xml2py.

Поэтому для качественных биндингов надо или все ручками или писать свой специфический парсер.

Так ты написал парсер или ручками это всё?

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

«Это» это что?
Вон в http://github.com/Lovesan/doors я все ручками пишу.

Потому что вот на такие преобразования:
http://www.linux.org.ru/jump-message.jsp?msgid=5498557&cid=5508266
ни один генератор из известных мне не способен.

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

> Вон в http://github.com/Lovesan/doors я все ручками пишу.

Всё? Сукажесть. А ты не думал, что 80% инфы уже есть в заголовочных файлах? Или даже 90%?

Потому что вот на такие преобразования: http://www.linux.org.ru/jump-message.jsp?msgid=5498557&cid=5508266 ни один генератор из известных мне не способен.

Вместо она^Wпридумывания еще одного FFI, написал бы на основе gccxml такой генератор - и тебе слава, и людям польза.

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

>А ты не думал, что 80% инфы уже есть в заголовочных файлах? Или даже 90%?
В MS-овских заголовочных файлах есть, и то не все. И их еще хер распарсишь.

написал бы на основе gccxml такой генератор

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

Вместо она^Wпридумывания еще одного FFI,

Собственно FFI и генерация описаний его типов из заголовочных файлов это ортогональные вещи.

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

>> написал бы на основе gccxml такой генератор

Это не особо генерируемое, я же написал.

Ты написал о CreateProcess, а у тебя в doors написанные руками defstruct. Они же руками написаны, ты сам сказал - а поля и типы полей полностью есть в h-файле.

А в общем случае, не в случае заголовочных файлов MS, то есть - совсем не генерируемое, ибо узнается только из документации.

А если ты не можешь решить задачу на 100%, ты ее вообще не решаешь? Ну епт.

Вместо она^Wпридумывания еще одного FFI,

Собственно FFI и генерация описаний его типов из заголовочных файлов это ортогональные вещи.

Поэтому я и написал «вместо».

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

>Ты написал о CreateProcess, а у тебя в doors написанные руками defstruct. Они же руками написаны, ты сам сказал - а поля и типы полей полностью есть в h-файле.

В winapi структур достаточно немного(по сравнению с количеством функций). Кроме того, с ними тоже часто нужно ручками работать - в случае с юнионами, или структурами вида
struct{int data_len, int* data}

Поэтому я и написал «вместо».

Ну и нафиг вместо?

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

>> Ты написал о CreateProcess, а у тебя в doors написанные руками defstruct. Они же руками написаны, ты сам сказал - а поля и типы полей полностью есть в h-файле.

В winapi структур достаточно немного

Твой virgil - он только для winapi сделан?

(по сравнению с количеством функций).

Даже прототип CreateProcess можно сгенерировать по большей части автоматически, а если добавить свои аннотации - то и полностью автоматически.

Поэтому я и написал «вместо».

Ну и нафиг вместо?

Еще раз, медленно и печально: твой virgil никому нафиг не нужен, потому что никаких явных преимуществ перед CFFI не имеет; с другой стороны, если в CL-сообществе еще нет хорошего (на основе реального компилятора) _генератора_ биндингов, то он нужен. Прежде чем изойти на говно в мою сторону, подумай еще раз. Считай, что я просто незнакомый тебе лиспер, который изложил вышесказанное у тебя в ЖЖ и в вежливой форме.

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

>Твой virgil - он только для winapi сделан?
Нет. Но ты начал про то, что в doors все руками.

Даже прототип CreateProcess можно сгенерировать по большей части автоматически, а если добавить свои аннотации - то и полностью автоматически.

Это че, еще все заголовочные файлы прочесывать и в них аннотации расставлять на каждом шагу? Мне делать больше нехер, да. Не проще ли сразу писать биндинги?

твой virgil никому нафиг не нужен, потому что никаких явных преимуществ перед CFFI не имеет;

Нужен. Ты не понял, чтоле, какие у него преимущества перед CFFI? В CFFI мы возимся с самой сишной памятью. CFFI - очень низкоуровневое. У него есть ряд объективных и неизлечимых проблем(с аллокацией данных агрегированных типов, и автоматическим освобождением ресурсов внутри них). И в cffi нет плюшек типа :in/:out/:inout параметров у функций, и прочего. И оно малорасширяемое.

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

Хороший в общем случае сделать нельзя. Особенно такой, который генерировал бы высокоуровневые биндинги, по типу к Virgil.
В принципе, есть тот же SWIG, но его никто для чего-то большего, чем наколенные поделки под свои мелкие нужды, не использует.

Максимум из того, что можно, в общем случае, извлечь из сишных хедеров это тупорылый перевод этих хедеров в описания типов FFI. В результате мы будем работать совершенно как Си, но на CL. А нахер это надо? Это крайне неудобно и криво(CL не предназначен для низкоуровневого байтоковыряния - в нем оно выглядит слишком многословно и громоздко).

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

>> Твой virgil - он только для winapi сделан?

Нет.

Тогда к чему аргумент про то, что в winapi мало структур? Вдруг мне надо обернуть Си-либу, в которой стопицот структур.

Это че, еще все заголовочные файлы прочесывать и в них аннотации расставлять на каждом шагу?

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

Мне делать больше нехер, да. Не проще ли сразу писать биндинги?

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

В принципе, есть тот же SWIG

SWIG - это тупик, и в любом случае, это не настоящий компилятор. Настоящий - это gccxml или LLVM.

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

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

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

>Вдруг мне надо обернуть Си-либу, в которой стопицот структур.

Тогда можно и самому написать парсер.

Си-библиотека может быть нижним уровнем двухязыковой программы


Крайне малораспространенная практика в CL-сообществе. Современные реализации CL не тормозят, и поэтому, как правило, нет смысла какие-либо части писать на Си. Возможно только в случае необходимости интеграции лисп-системы в программу на Си/другом языке, да и то - в таком случае вряд ли лисп-система будет общаться с программой через FFI типа CFFI/Virgil.

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


Это та же самая ручная работа.
Какая разница, будем бы в сишных заголовочных файлах писать для каждой функции типа
'int foo(int* x, int* y)'
аннотации типа
'__library(libxynta) __last_error(not_zero) int foo(__inout __retval int* x, __out __retval int* y)'
или сразу писать
'(define-external-function «foo» (:cdecl libxynta) ((last-error int not-zero) rv (values x y)) (x (& int :inout)) (y (& int :out)))'

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


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

Ну а из аннотированных - и гораздо больше.


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

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

Аналог самого верхнего кода на C#, пжлст.

Сигнатура foo в C# должна выглядеть примерно так, если переводить с CL:

//причем matrix - произвольных размерностей
//m и n чтоб автоматически вычислялись - хрен уж с ними, не надо
void foo(ref float[][] matrix, int m, int n, IntPtr callback, ref float param)

И, кстати, в коллбэке указатель на время «становится» матрицей произвольных(с помощью макроса with-value), опять же, размерностей. Как вот _это_ выглядит на C#, я даже не представляю.

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

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

from ctypes import *

virgil = CDLL('./virgil.so')

MatrixCallback = CFUNCTYPE(None, POINTER(c_float), c_int, c_int, c_void_p)

def adder(matrix, m, n, param):
    param = cast(param, POINTER(py_object)).contents.value
    for i in range(m):
        for j in range(n):
            matrix[i*n+j] += param


matrix = (c_float * 6)(1, 2, 3, 4, 5, 6)

virgil.foo(matrix, 2, 3, MatrixCallback(adder), byref(py_object(1)))

print '\nafter processing:'
virgil.print_matrix(matrix, 2, 3)
baverman ★★★
()
Ответ на: комментарий от baverman

Это кривая херня и совершенно не аналог.

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

byref(py_object(1))

param = cast(param, POINTER(py_object)).contents.value


И это, что, тривиальность? Да это говно какое-то.
Чтобы всего лишь передать/получить какой-то вонючий флоат по указателю - ручной боксинг и анбоксинг, выделение в куче(ведь в куче? для одного вонючего флоата вызывать аллокатор!), куча лишних сущностей и куча лишнего кода. А если надо будет :inout семантику? Я боюсь себе представить даже. Наверное, будет такое же говно как и вот в этом случае:

POINTER(c_float)

matrix = (c_float * 6)(1, 2, 3, 4, 5, 6)


matrix[i*n+j]


[i*n+j]



Посмеялся, спасибо. Может, надо было назвать переменую «bullshit_that_is_not_a_matrix_because_python_cannot_into_convenient_ffi»?
Во-первых, в лиспе оно лисповская структура данных(!), во-вторых, матрица(!!). Причем, произвольных размерностей.

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

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

Да хотя бы в .NET.

изобретаете swig ?

swig не работает, я проверял.

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

>Да хотя бы в .NET.
В .NET нет, я проверял

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

Именно такого ответа и ждал, спасибо, что оправдал мои чаяния.

Скажи, что мне мешает сделать обертки для автоматизации рутинных вещей? Тот же with-value?

какой-то вонючий флоат по указателю

Это не какой-то вонючий флоат. Во-первых, это полноценный питонячий объект, а во-вторых, это инт.

Во-первых, в лиспе оно лисповская структура данных(!), во-вторых, матрица(!!).

Вопрос: в твоем случае она боксится? Или тебе повезло и в памяти она лежит удобным образом?

В первом случае, что мне мешает сделать соответствующий декоратор?

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

Только не надо из CL делать исключительное, наделенное магическими свойствами супер-пупер нечто. Ну не такой он.

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

> swig не работает, я проверял.

Работает ещё как. Хотя об всего лишь генератор этих оберток.

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

>Именно такого ответа и ждал, спасибо, что оправдал мои чаяния.

Скажи, что мне мешает сделать обертки для автоматизации рутинных вещей? Тот же with-value?

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

Это не какой-то вонючий флоат. Во-первых, это полноценный питонячий объект, а во-вторых, это инт.

В лиспе и инты и флоаты тоже полноценные объекты, и тем не менее.

Вопрос: в твоем случае она боксится? Или тебе повезло и в памяти она лежит удобным образом?

В Virgil маршалинг массивов происходит следующим образом:
Если характер передачи данных - :in, под «сишное представление» массива выделяется память, лисповский массив туда маршалится, указатель на выделенную память передается в сишную функцию. После вызова функции память освобождается.
Если размера массива известен статически, память выделяется на стеке(последнее, вообще говоря, верно для всех ссылочных типов данных с фиксированным размером).

Если характер передачи :out, то, если тип элементов массива - один из «машинных типов», поддерживаемых некоей конкретной реализацией CL(напр. массив single-float или (signed-byte 32)), то указатель на данные берется из самого лисповского массива(стандарт CL гарантирует row-major расположение элементов), память не выделяется. Если же тип элементов другого рода - под массив память выделяется аналогично :in, но в отличие от :in, перед вызовом функции в память ничего не пишется, а пишется наоборот, в массив из памяти, и после вызова сишной функции.

:inout - комбинация :in и :out соответственно.

В первом случае, что мне мешает сделать соответствующий декоратор?

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

Или тебе повезло и в памяти она лежит удобным образом?

См. выше.

Только не надо из CL делать исключительное, наделенное магическими свойствами супер-пупер нечто. Ну не такой он.

Именно такой, именно исключительный.
Я, кажется, уже упоминал - большая часть трансляций объектов производится автоматически и с помощью кода, сгенерированного макросами при компиляции. Соответственно, получаем офигительную эффективность при офигительном удобстве использования. Ни в одном другом языке такого не добиться.
Пример сгенерированного машкода:
http://paste.lisp.org/display/116366

Love5an
() автор топика

ТС, слюни подотри. каждый язык может быть круче всех остальных в отдельно взятом случае. А вот если мы померяем среднюю температуру по больнице, то, боюсь, твой CL будет глубоко в Ж. Не так давно кажется на лоре проскакивала статейка про скорость работы разных языков (там несколько синтетических тестов было) и CL там был сильно далеко от фаворитов.

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

>ТС, слюни подотри. каждый язык может быть круче всех остальных в отдельно взятом случае. А вот если мы померяем среднюю температуру по больнице, то, боюсь, твой CL будет глубоко в Ж.

По-моему, слюни это у тебя потекли. Или это мозг плавится? «Слышал то, не знаю что, не знаю где».

Как нахрен «средняя температура по больнице»? «Усредненная производительность языка» это само по себе довольно некорректное понятие, но по отношению к CL оно вообще совершенно бредовое. На нем можно писать как на Си, а можно как на Руби каком-нибудь(хотя в последнем случае производительность все-равно на порядок от оригинала будет отличаться, в лучшую сторону), или даже еще круче.

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

Синтетические тесты, особенно на шутауте - совершенно неадекватное говно. Хотя бы потому, что люди, которые в достаточной мере знают CL, и умеют его оптимизировать, обычно такой херней, как меряние пиписьками на синтетических тестах, не страдают(хотя г-н. swizard вот выделяется в этом плане в последнее время:)

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

> огромные тормоза и выделение памяти

Тормоза, дикий консинг

Соответственно, получаем офигительную эффективность при офигительном удобстве использования.


Ни в одном другом языке такого не добиться.



Немножко похоже на аргументацию адептов C++, не находишь?

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

Пример сгенерированного машкода:


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

К чему это все? Как простого, обделенного скоростью питониста, меня совершенно не впечатляет возможность генерации эффективнейших байндингов. Си/С++-стам грустно от твоего кода. А у каждого лиспера, наверно, и так свой велосипед на эту тему написан.

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

>Немножко похоже на аргументацию адептов C++, не находишь?

Только наполовину, возможно. Потому что удобство использования в C++ нифига никак не получается. В отличие от CL, где мы можем совмещать эффектные абстракции с эффективными их реализациями.

Почему реальное преимущество CL — компиляция в рантайме, так и не стало киллерфичей?

Реальных преимущества у CL несколько, и компиляция в рантайме - не самое крутое из них. А одно из самых крутых это, как раз, неделимость кода и данных, и макросы соответственно.

И вызову ее через ctypes или cython, это не так уж и сложно.

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

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

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

Си/С++-стам грустно от твоего кода.

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

А у каждого лиспера, наверно, и так свой велосипед на эту тему написан.

Насколько мне известно, это первая публичная разработка на тему. Велосипеды есть, безусловно, у всех библиотек-биндингов, использующих cffi по причине кривоты оного cffi(например, в cl-gtk2). И что?

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

А одно из самых крутых это, как раз, неделимость кода и данных, и макросы соответственно

Было бы крутым — не надо было б тебе на ЛОРе надрываться.

и общаться в терминах высокоуровневого языка, а не в терминах указателей и прочего говна

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

если бы ты врубился в вышеприведенный код

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

Они завидовать должны - в теплом ламповом CL мы работаем с высокоуровневыми структурами данных

Оставим сишников, они бородаты и суровы, но жду в треде плюсовиков, утверждающих что С++ — это ЯВУ, и байтики в нем дрочат только из-за отсутствия должного образования.

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

Удачи, что уж там. Посмотрим сколько вотчеров появится.

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

>Было бы крутым — не надо было б тебе на ЛОРе надрываться.
Если никто не будет об этом постоянно напоминать, как люди вообще узнают, что оно круто? Да никак(что мы сейчас и наблюдаем - на знают-с).

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

Само по себе это не стоит, естественно, внимания, если бы не:
А) То, что оно делается автоматически.
Б) То, что в Virgil можно добавлять свои алгоритмы маршалинга и практически как угодно комбинировать существующие(посредством спецификаций типов).
Б) То, что оно компилируется в крайне эффективный код.

что С++ — это ЯВУ, и байтики в нем дрочат только из-за отсутствия должного образования.

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

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

Я не думаю, что парсер ZetaC способен разбираться в тоннах MS-специфичных builtin-функций, операторов и макросов, и, особенно, в коде на C++(декларации com-интерфейсов etc.)

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

> Генераторы типа SWIG не асиливают сгенерировать всякие там :out и :optional по метаинформации в заголовочных файлах(если оная даже и присутствует, что вообще редкость). Поэтому для качественных биндингов надо или все ручками или писать свой специфический парсер.

необязательно всё ручками, хотя ситуация в целом примерно такая,как ты и описал. Можно использовать статический анализ С кода, см. http://llvm.org/pubs/2009-06-PLDI-LibraryBindings.html http://llvm.org/pubs/2009-06-PLDI-LibraryBindings.pdf — там применили klee из llvm.
Выводы примерно те же: для полноценных биндингов не хватает метаданных, но в их работе требуемые метаданные выводятся статическим анализом из С-кода.

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

> написал бы на основе gccxml такой генератор

gccxml сдох, его даже в уютненькой генте выкинули, ибо неподдерживаемо в апстриме. Смотреть надо в сторону LLVM, ClangAnalyzer или KLEE.

anonymous
()

>В каком высокоуровневом языке еще есть такой FFI

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

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

>Как нахрен «средняя температура по больнице»? «Усредненная производительность языка» это само по себе довольно некорректное понятие, но по отношению к CL оно вообще совершенно бредовое.

Садись, Два!

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

Посему фанатичные заявления о невероятной скорости CL, опираясь только на один аспект, по меньшей мере некорректы.

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

а после таких заявлений мне даже не интересно дальше дискутировать.

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

парсер ZetaC, действительно, где-то на уровне pcc, плюс лиспмашины захардкожены (см., например, реализацию malloc в си библиотеке через пулы и gc на лиспе).
Код вроде деклараций сом-интерфейсов успешно парсил в своё время ещё Dylan: См. melange http://www.opendylan.org/old-docs/maker-out/melange.htm http://www.opendylan.org/melange.phtml и код embedded MSIE as ActiveX на Dylan: пример кода http://double.co.nz/dylan/projects/simplewebbrowser.htm заготовки http://double.co.nz/dylan/libraries/dylanlibs/index.htm http://double.co.nz/dylan/index.html

там достаточно сказать define interface #include «foobar.h» end define, чтобы си хедер распарсился melange и составился нужный FFI.

есть такой вот pdf: http://web.archive.org/web/20050307120121/http://www.acm.org/pubs/articles/jo... http://web.archive.org/web/20050307120121/www.functionalobjects.com/resources... где маршалинг для COM-объектов рассматривается подробно ещё см. http://www.opendylan.org/documentation/opendylan/interop2/index.htm

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

>> написал бы на основе gccxml такой генератор

gccxml сдох

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

его даже в уютненькой генте выкинули

Гента? Что это такое?

Смотреть надо в сторону LLVM, ClangAnalyzer или KLEE.

Про LLVM я сказал.

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

> В winapi структур

Любопытно, а что такого масштабного ты хотел написать на winapi, что пришлось собственный ffi городить?

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

> твой virgil никому нафиг не нужен, потому что никаких явных преимуществ перед CFFI не имеет;

имеет. Маршаллинг данных вроде проще выглядит. Кастуем автора «virgil нужен»

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


gcc-xml?

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

http://www.cl-user.net/asp/mRgQ/sdataQ1WPzqWKlS5IDQd1$y8X8yBX8yBXnMq=/sdataQu3F$sSHnB== http://www.cyrusharmon.org/cl/projects/gcc-xml-ffi/

так что нужны нормальные биндинги, нужны. Вот для Qt, например, приспособили аж Smoke из KDE, см. commonQt или cl-smoke. Думается, лучше бы LLVM+KLEE приспособили.

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

>> Вдруг мне надо обернуть Си-либу, в которой стопицот структур.

Тогда можно и самому написать парсер.

Можно. А можно использовать уже существующий.

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

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

Ну а из аннотированных - и гораздо больше.

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

Мде. Это даже дальше от Стэнфорда, чем Нью-Джерси.

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

>fld [edi+1]

Дальше не читал. О выравнивании это поделие не имеет ни малейшего представления, а о какой эффективности после такого может идти речь?

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