Lisp & C ф-ции

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

Ну процесс создается только один раз, а потом ему запросы можно как угодно слать. Хотя вызов функции все равно будет быстрее, но не в тысячи раз.

У run-program и stream есть одна "мелкая задница" - callback's. А без них сейчас практически не один нормальный интерфейс не обходится. А если ещё треды вспомнить - нафоркаешься по самое не балуйся. Хотя есть у них и несомненный плюс - при грамотном интерфейсе падение одной из частей не обязательно приводит к краху и второй. А делать подобное и на cffi, я думаю, несколько "напряжно". Хотя, если месье сварганит библиотечку "safe-cffi" - многие наверное спасибо скажут :)

>Что лучше использовать для выаимодействия C ф-ций (прог) и Lisp: cffi или run-program и stream ?

Все очень зависит от конкретики. С библиотеками ситуация не обсуждается -- нужно привязки через ffi делать. А если речь идет о взаимодействии довольно крупных самостоятельных программ, то тут может быть по-разному. Если взаимодействие типа "нажал на кнопочку здесь, а там должна выпрыгнуть птичка", то вполне подойдет взямидействие через сокет. Пользователю же все-равно, какой отклик на событие: 10 мкс или 1 мкс. И то, и то просто незаметно глазу. Ну или ситуация, когда одна программа формирует какой-то набор правил или текстовый набор данных для другой, то тоже совсем необязательно делать ffi. Такие программы больше времени проводят, обрабатывая полученные данные, нежели на взаимодействие.

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

>У run-program и stream есть одна "мелкая задница" - callback's. А без них сейчас практически не один нормальный интерфейс не обходится.

Ну вообще-то, например, в LTK (классический пример того, о чем ты говоришь) эта проблема вполне себе решена. Я не вижу проблем делать callback через тот же stream. Событие там происходит в Tk-интерфейсе, который запущен, как отдельная программа (wish), потом передается в основную (на CL) и обрабатывается.

> Ну вообще-то, например, в LTK (классический пример того, о чем ты говоришь) эта проблема вполне себе решена.

Я его и имел в виду. Да, решён. Но глядя на его решение именно что о ffi и сожалеешь. Нет, он конечно работает, но...

> Я не вижу проблем делать callback через тот же stream.

"Проблем делать" были до не давнего времени только у теоремы Ферма :)

Если уж заниматься "удалённым управлением", то давайте и привлекать соответствующие средства (я не о LTK, а о "callback через stream")

И с задержками не так всё просто: если начать перерисовывать сложные формы динамически при изменении размеров грызуном - они очень даже скажутся.

А именно Tk торчит наружу потрохами настолько, что с ffi можно даже tcl не использовать (разве что интерпретатор инициализировать придётся).

И чего я разошёлся? :) Делайте что хотите. Главное - чтобы работало. А я похоже старею: в единицах из того, что работает, мне нравится _как_ оно работает...

Кстати, я в LTK очень давно сделал простой примерчик рисования эллипса динамически, когда все промежуточные состояния отображаются, пока я мышкой по полю вожу. Не поверишь -- работало без нареканий и весьма быстро. Я не сожалел об ffi.

>И с задержками не так всё просто: если начать перерисовывать сложные формы динамически при изменении размеров грызуном - они очень даже скажутся.

А взаимодействие по X-протоколу? CLX тот же самый (Или он не входит в те единицы, которые нравятся, как работают?). Ну или та же xlib. Там и изменение размеров грызуном, и перерисовка сложных форм. Исключительно *все* взаимодействие идет через сокет.

>1. С точки зрения Lisp-идеологии ?

Здесь нет никакой Lisp-идеологии. Эта идеология ничем не отличается от взаимодействия двух программ на Си. Вспомни все тот же шелл:

$ ls -l | grep "file"

Есть случаи, когда захочешь ffi, а есть случаи, когда IPC. Это архитектурные решения вообще, а не специфичные для Lisp.

>2. Скорость. Тут, наверное, скорость - запуск, передача параметров, возврат значения, т.е. взаимодействие C<->Lisp.

Подумай, какой процент времени программа обрабатывает запрос (что-то рисует) и какой процент занимает собственно передача команды. Вот yyk затронул тему движения мышки. Да новые координаты поинтера (x и y) передаются очень быстро, а вот обработка новой координаты (перерисовка чего-то) может занимать много времени. Так так ли уж важна в данном случае экономия? Почему-то никого не смущает, как работает GLX. А ведь там взаимождействие с OpenGL идет по тому же самому сокету в виде бинарного протокола. Это, конечно, не отменяет ffi к OpenGL, но тем не менее, GLX каждый день многими используется.

Короче, не всегда прямой (через FFI) вызов конкретной функции из внешней программы дает реальный выигрыш во времени. Экономия 0.2% на 0.05% не даст ничего против оставшихся 99.8% времени, в течение которого программа выполняет операции.

Давай конкретный пример того, чего ты хочешь.

> Здесь нет никакой Lisp-идеологии.

Я так спросил. А вдруг ? :)

> Давай конкретный пример того, чего ты хочешь.

Есть набор ф-ций (A,B,C...), реализующих взаимодействие с
PCI-устройством через дровину. 
Сейчас: В C-проге реализован большой case, в зависимости от команды
на входе (pipe, msgget), реализуются различные ф-ции, либо их
определённая последовательность. 
Хочется: 
1. Использовать Lisp для управления ф-циямии (через гуй либо скрипт.
файл и т.д.). 
2. Избавиться от case (который растёт всё время) в C-проге. Если
работать через run-program, то C-прога не меняется, тот же case - в
общем не красиво.
3. По-этому хочю пользовать ф-ции через cffi а всю логику на Lisp. 
Парсить командные файлы и т.д.


Вот и хотелось бы на этот счёт мнения выслушать.

Функции A, B, C делаешь в библиотеке. Через ffi к ней цепляешься.

Кстати, если хочешь взаимодействовать с девайсом, то посмотри на библиотеку sb-posix в SBCL. Можно попробовать даже весь функционал A, B и C сделать без Си, насколько я понял ее назначение. Там есть read/write, ioctl() и пр. Но я ничего не делал и даже не интересовался пока этой библиотекой. Пока, во всяком случае. Она специфична для SBCL. В других реализациях свои библиотеки. Насколько я понимаю, она биндится к *libc.

И такая вот еще хрень запеленгована:

http://common-lisp.net/project/iolib/

> Можно попробовать даже весь функционал A, B и C сделать без Си, насколько я понял ее назначение.

Понял прально. Но зачем за С делать его работу ? :)

А не костыль ли это ?
Может С - С'ишное... :) ?

>Понял прально. Но зачем за С делать его работу ? :)

Встречный вопрос, а зачем городить какие-то непонятные библиотеки типа /usr/lib/libmylibrary.so, делать для них биндинги и т. д. Не знаю, я бы на твоем месте живо поинтересовался возможностью не писать на Си ничего, если есть такая возможность. Ну делай, как знаешь.

>А не костыль ли это ?

Ты о чем? Какой костыль? Может тогда и биндинг к gtk -- тоже костыль? Тебе предоставляется возможность не писать "прослойки", а ты говоришь, что "костыль". Но опять повторю, что сам я этим не пользовался еще и вообще не знаю, что там есть и какие проблемы.

За написание программы управления устройством на Лиспе я бы как минимум лишил премии.

А за такое утверждение я бы уволил. Без основательное и фанатичное. :)

>За написание программы управления устройством на Лиспе я бы как минимум лишил премии.

А какие проблемы? Недетерминированность по времени? Появление в процессе работы сборки мусора? Так не драйвера предлагают писать, а уже то, что выше уровнем. Вот mpg123, скажем, юзает /dev/dsp и управляет им. Это уже пользовательский уровень. И там уже во многих случаях критериев, предъявляемых к драйверам, нет.

ИМХО, был бы очень интересный экспириенс.

> А за такое утверждение я бы уволил.

Надеюсь, что ты начальник OP

> Без основательное и фанатичное. :)

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

> Недетерминированность по времени? Появление в процессе работы сборки мусора?

Нет. Если еще и _это_ является проблемой, то я бы его уволил без выходного пособия.

> ИМХО, был бы очень интересный экспириенс.

Ничего интересного, поверь мне. Делаем на Питоне - работает. Даже скучно :)

> Основание - в природе практически нет людей, знающих Лисп.

Знаешь, скоро про С такое говорить придётся. И что Сишнегофф увольняем ?

>Ничего интересного, поверь мне. Делаем на Питоне - работает. Даже скучно :)

Ах, а я думал, какие-то технические преграды. А ты просто флейм разжечь хочешь на базе Python vs. Lisp :) Все понятно. :)

Тем не менее, ну прикинь, если надо обмен с разными устройствами делать, скажем, по USB. Или с со звуком. И нужно писать на Си POSIX-слой, а потом фигачить свой доморощенный интерфейс, к которому еще и биндинги рисовать. Вместо того, чтобы напрямую поток загнать и прочесть, и поуправлять девайсом. Для этого и сделали POSIX-биндинг. Не вижу пока ничего плохого в таком решении. Хуже будет,е сли мне для работы программы надо будет собирать какую-то libsound4lisp.so, libusb4lisp.so, libcomport4lisp.so и т. д.

>> Основание - в природе практически нет людей, знающих Лисп.

> Знаешь, скоро про С такое говорить придётся.

1) не придется; 2) Си - неизбежен, в отличие от Лиспа

> ты просто флейм разжечь хочешь на базе Python vs. Lisp :)

Нет, я уже понял, что <joke> вас, твердолобых фанатов Лиспа, проще и выгоднее убить, чем убедить </joke>. В данном случае меня интересует, что будет с программой после того, как написавшее ее дарование уволиться.

> Си - неизбежен, в отличие от Лиспа Также когда-то АСМ неизбежен, в отличие от C

Друх, от тебя хоть что-то внятное будет ? Типа, потому, что .......

> Друх, от тебя хоть что-то внятное будет ?

Друх, Си применяется в системном программировании гораздо дольше, чем ты живешь, и уменьшения его доли нет и не прогнозируется. Ты этого не знал, друх?

> Нет, я уже понял, что вас, твердолобых фанатов Лиспа, проще и
выгоднее убить, чем убедить

Нет, я уже понял, что вас, твердолобых фанатов Питона, проще и
выгоднее убить, чем убедить

Товарищ, можно аргументы. Я просо выбираю. Мне надо...

Может я ошибаюсь, но Lisp гораздо старше ...

> Товарищ, можно аргументы. Я просо выбираю. Мне надо...

Ты выбираешь что? Для чего? Между чем и чем? Про FFI и процессы тебе здесь квалифицированно объяснили. Задавай четкие вопросы, и тебе ответит.

> Может я ошибаюсь, но Lisp гораздо старше ...

Ты не ошибаешься - Лисп старше на 15 лет. Фортран - примерно на столько же. И Кобол тоже старше.

> Недетерминированность по времени? Появление в процессе работы сборки мусора?

>Нет. Если еще и _это_ является проблемой, то я бы его уволил без выходного пособия.

Насколько я помню, в разных реализациях есть возможность приостановить GC во время исполнения куска кода. В SBCL это, например, макра (without-gcing ...).

> Насколько я помню, в разных реализациях есть возможность приостановить GC во время исполнения куска кода.

Семантика этого не очень определена, да (лично мне) это и не кажется достаточным. Может, когда родят наконец realtime garbage collector :)

Впрочем, для любителей системно программировать на Лиспе есть BitC :D

> Си - неизбежен, в отличие от Лиспа

и от Питона

>Впрочем, для любителей системно программировать на Лиспе есть BitC :D

Ну биндинг в *libc -- это уже не знаю, как определить. Дальше идет биндинг непосредственно к ядру. Ну а следующий уровень гиканутости -- это ОС на CL. :) Впрочем, и такая есть. Называется Movitz. Операционная система полностью написанная на Common Lisp. Вплоть до драйверов. Там и VGA-драйвер, клавиатура, мышки и пр. Но этот Movitz больше иллюстрация, нежели проект с будующим. Вот драйверочки:

http://common-lisp.net/cgi-bin/viewcvs.cgi/movitz/losp/x86-pc/?root=movitz

>> Си - неизбежен, в отличие от Лиспа

>и от Питона

Яволь, И что? Я привел Питон только как пример написания программы управления устройством на языке более высокого уровня, чем Си. Тебе писать на Питоне не предлагал. Пиши хоть на C# - главное, оставь после себя текст, который можно понять без асиливания (полезной во всех отношениях) SICP.

s/будующим/будущим

>> Впрочем, для любителей системно программировать на Лиспе есть BitC :D

> Ну биндинг в *libc -- это уже не знаю, как определить.

O_O

BitC - это отдельный язык системного программирования. основан на Scheme. Никаких биндингов к libc.

Movitz - мервый плод больного сознания.

> Ну биндинг в *libc -- это уже не знаю, как определить.

Эта фраза относилась не к bitC. Незачем такие O_O круглые глаза делать :)

У tailgunner месячные? Грамотному разработчику не составит проблемы разобраться в коде на Lisp, а если это проблема - то нах такого разработчика. Кроме этого есть _принципиальный_ возражения против Lisp?

> У tailgunner месячные?

Слова не мальчика, но мужа.

Если тебе от этого легче - можешь считать, что месячные. Или климакс. В общем, как скажешь.

> Грамотному разработчику не составит проблемы разобраться в коде на Lisp, а если это проблема - то нах такого разработчика.

Ути-пути... эмигрировал в страну эльфов, да?

>Movitz - мервый плод больного сознания.

С этим спорить не буду. Но раз кому-то интересно поиграться, то пускай будет.

> Пиши хоть на C# - главное, оставь после себя текст, который можно понять без асиливания

Так можно про любой язык сказать. А чтоб что-то хорошее сделать нужно прилажить усилия, и асиливать полюбому что-то придёться... А если чел не может что-то асилить, то НАХ !!!

> Я привел Питон только как пример написания программы управления устройством на языке более высокого уровня, чем Си

Ой ли. ТОварисч пользует связку C++ и питон. Но ещё ниразу вменяемо не объяснил, чем это лучше С и Lisp или чего-то ещё. Товарисч фонатег ? Думаю да. :)

> А взаимодействие по X-протоколу?

Хм, а с Х-ами "общение" идёт тоже на "языке Y", или всё-таки по определённому протоколу, который парсить на порядок легче?

Напишите (ня "с-ях" или чём угодно чрез ffi) библиотеку с интерфейсом к Tk через какой-нибудь RPC или как оно там зовётся. А лепить сначала инструкции на для tcl/tk, которые потом парсятся интерпретатором - вот это мне и не нравится.

> Грамотному разработчику не составит проблемы разобраться в коде на Lisp, а если это проблема - то нах такого разработчика.

У разных языков разный уровень вхождения.

Какие-то (Python) в силу простоты можно выучить относительно быстро и сразу же начать кодировать. И в процессе разработки не приходится прилагать титанических усилий.

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

Так что лучше говорить не в абсолютных, а в относительных величинах: для Python "не составит труда" исчисляется в неделях, для CL - в месяцах.

А дальше возникает естественный вопрос: неужели CL настолько лучше Python, что имеет смысл терять месяцы в надежде, что потом догоним и перегоним? Как-то сомнительно.

> У разных языков разный уровень вхождения.

"У разных людей" этот порог различается на много больше. Может с этого начнём?

> Какие-то (Python) в силу простоты можно выучить относительно быстро и сразу же начать кодировать. И в процессе разработки не приходится прилагать титанических усилий.

Ха-ха. Или выучите Питон _со всеми_ идущими в поставке библиотечными функциями, или выкиньте из CL все аналогичные функции и сравните языки.

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

Только _непривычный синтаксис_ играет заметную роль (для тех, для кого играет :). Всё остальное - его следствия или полная чепуха.

> Так что лучше говорить не в абсолютных, а в относительных величинах: для Python "не составит труда" исчисляется в неделях, для CL - в месяцах.

Личное мнение, или стат. данные? Описание условий проведения эксперимента и его результаты?

> А дальше возникает естественный вопрос: неужели CL настолько лучше Python, что имеет смысл терять месяцы в надежде, что потом догоним и перегоним?

А по мне - абсурд, а не "естественный вопрос" (и это мягко сказано).

> "У разных людей" этот порог различается на много больше. Может с этого начнём?

В ход пошло креативное цитирование? Изначально речь шла про абстрактного "грамотного разработчика".

> Ха-ха. Или выучите Питон _со всеми_ идущими в поставке библиотечными функциями, или выкиньте из CL все аналогичные функции и сравните языки.

Ха-ха. Про библиотеки мы ещё даже не начинали. Пока что речь шла про язык.

> Только _непривычный синтаксис_ играет заметную роль (для тех, для кого играет :). Всё остальное - его следствия или полная чепуха.

Бред.

>> Так что лучше говорить не в абсолютных, а в относительных величинах: для Python "не составит труда" исчисляется в неделях, для CL - в месяцах.

> Личное мнение, или стат. данные?

Стат данные.

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

И список публикаций с индексом цитирования.

> А по мне - абсурд, а не "естественный вопрос" (и это мягко сказано).

У тебя с логикой проблемы.

> Изначально речь шла про абстрактного "грамотного разработчика".

А если этого абстрактного разработчика учили в MIT схеме?

> Ха-ха. Про библиотеки мы ещё даже не начинали. Пока что речь шла про язык.

Если из CL убрать то, что относится к библиотечным функциям, но не выделено из стандарта - останутся слёзы.

> > Только _непривычный синтаксис_ играет заметную роль (для тех, для кого играет :). Всё остальное - его следствия или полная чепуха.

> Бред.

О какой парадигме из поддерживаемых лиспом ты говорил?

> И список публикаций с индексом цитирования.

Урл?

> У тебя с логикой проблемы.

Нет, это у тебя с основаниями для подобных выводов проблемы.