Еще один пример, когда красноглазые фанаты пытаются юзать язык не в тему... Язык надо выбирать исходя из задачи. Если уж так приспичило писать логику на лиспе - пиши нормально - сделай простенький script-engine, а не занимайся йоблей в гамаке с надетым противогазом :)

согласен с Esh насчёт посылания..

CreateNamedPipe

где ты видел тормознутый лисп? CMUCL же тебе сказали там! Это почти не хуже по скорости сей.

Что-то типо этого ;) Как говорится , попробовав раз - юзаю и сейчас . Просто я выбирал gvim7 & emacs-cvs . Хочется попробовать XWEM , а никак ...

А если сурьёзно раскажите pls чем он так крут. Часто слышу шо мол очень круто. Главное обьясните нормально и далеко не посылайте.

пайпы через диск?? вот это круто... высказывание даже покруче будет чем _тормознутый лисп_ ))

тормознутость открытых реализаций CL (SBCL/CMUCL/CLISP etc) присутствует разве только в IO, но тут зато LispWorks решает :)

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

а вообще, можно для ознакомления почитать - http://lib.store.yahoo.com/lib/paulgraham/acl1.txt

Интересует один момент, связяанный с организацией обмена управляющей информацией от клиента (driver.lisp) к серверу.

Как я понимаю суть обмена такая: При вызове определенной lisp функции происходит формирование управляющей инструкции вида <КодОперации [Параметр1, Параметр2 ... ]>, затем инструкция через пайп передается серверу, который в завсимости от КодаОперации и параметров выполняет некоторое действие.

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

Хотелось бы уточнить пробывал ли автор реализовать фишку автоматической геренации кода С-шной серверной части по объявлениям "клиентский" функций в lisp программе?

Как я понимаю такое можно сравнительно легко реализовать через механизм макросов

>>скорость в ... Не лучше-ли через SharedMem?(Не знаю есть ли в лиспе)

SharedMem тоже непортабельно :)

И то что предлагали - виндовый аналог с пайпами - врядли получится. На практике портировать такие вещи намного сложнее чем кажется :)

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

Если реально интересно - могу подсказать одного буржуя (американец вроде), с которым я давно знаком в irc и который очень увлекается такими темами в лиспе :)

То есть такого эффекта ( http://photos7.flickr.com/10632497_b83574f61b_o.png ) можно добиться в XEmacs? (Интересует только разный background моделайнов в разных окнах).

Именно так.

> Хотелось бы уточнить пробывал ли автор реализовать фишку автоматической геренации кода С-шной серверной части по объявлениям "клиентский" функций в lisp программе?

Не совсем понял вопрос, но я такого не делал. Правильный подход - встроить в сервер интерпретатор Scheme и _все_ команды обратить в s-expressions. Тогда любая ошибка в команде тут же вылезет при исполнении.

OGRE не тупой. Тупой мой движок - engine.cpp :-)

Портабельно в рамках POSIX.

> Еще один пример, когда красноглазые фанаты пытаются юзать язык не в тему... Язык надо выбирать исходя из задачи. Если уж так приспичило писать логику на лиспе - пиши нормально - сделай простенький script-engine, а не занимайся йоблей в гамаке с надетым противогазом

Подход с FIFO считаю достаточно хорошим для _очень_ широкого класса задач. Скорость обмена через FIFO-файлы значительно выше, чем многим кажется, выше, чем через сокеты, а уж на быстродействие X-сервера мало кто жалуется.

Кроме того, разделение проекта на _процессы_ хорошо изолирует разные части проекта, которые должны разрабатываться отдельно. Например, я могу прогнать driver.lisp без движка, просто отлаживая поток сообщений.

А блин, дотумкал, что речь идёт об издании игр, т.е. о Windows. Я не собираюсь делать игры, а тем более на продажу.

Не могу согласится что это всегда верный подход. Приумножение сущностей без надобности.

Моя идея состоит вот в чем. Есть лисп код клиента:

(defclientfunc create-object ((name str)) (.....)) (defclientfunc delete-object ((object obj)) (.....)) (defclientfunc rotate-object-x ((object obj) (angle double)) (.....))

defclientfunc - макроопредленение. Его задача сгенерировать определение лисп функции. Например

(defunc create-object (name) (......))

и кусок кода C-шного сервера. Например

...

Obj * createObject(char * name);

... switch(opcode) { .... case opCreateObject: char * name = stringParam(0); RETURN(createObject(name)); break; .... }

В итоге при компиляции (интерпретации) лисп клиента получается исполняемый модуль + файлик server.cc, который легко можно вставить в основную графическую программу. Кстати таким же образом можно гененрировать клиенты написанные на других языках. К примеру perl ptyhon, ruby .... в общем для всего что может работать с пайпами.

Кстати забавно, но на связке named pipe + samba (или nfs) можно вообще генерить распределенные приложения.

Превосходная идея! В большом проекте это сэкономит кучу времени при сопровождении протокола.

> То есть такого эффекта ( http://photos7.flickr.com/10632497_b83574f61b_o.png ) можно добиться в
> XEmacs? (Интересует только разный background моделайнов в разных окнах).

почумебы и нет? например так:

  (defun mb-pre-command-hook ()
    (declare (special mb-old-window))
    (setq mb-old-window (selected-window)))

  (defun mb-post-command-hook ()
    (declare (special mb-old-window))
    (unless (eq mb-old-window (selected-window))
      (set-face-background 'modeline "gray70" mb-old-window)
      (set-face-background 'modeline "gray50" (selected-window))))

  (add-hook 'pre-command-hook 'mb-pre-command-hook)
  (add-hook 'post-command-hook 'mb-post-command-hook)

Конгениально! Всё работает. Спасибо.

Ну и жаль... У тебя бы неплохо могло получиться.

Хорошо, уговорил. Буду делать переносимый Орбитер, а то оригинальный только под Windows: http://www.medphys.ucl.ac.uk/~martins/orbit/orbit.html

Lisper.

Спасибо, но хочется обойтись свободным софтом.