Practical Common Lisp http://www.gigamonkeys.com/book/

LOR как источник идей - это LOL!

аффтар! Тебя любой издатель с твоими убогими непортабельными fifo отправит в пешее эротическое путешествие!

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

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

хочется что-то ручками править - прикрути Lua/Python, а из тормознутого Lisp вызывать ну очень быструю C-шную GL библиотеку - право извращение.

> убогими непортабельными fifo

CreateNamedPipe

>хочется что-то ручками править - прикрути Lua/Python, а из тормознутого Lisp вызывать ну очень быструю C-шную GL библиотеку - право извращение.

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

Согласен изврат. Мож не прав, но пайпы вроде через диск => скорость в ... Не лучше-ли через SharedMem?(Не знаю есть ли в лиспе)

>Это ты, брат, хочешь Гну Емакс без последователей оставить. :) Как только >будет возможность выбора морды у (S)XEmacs - я, например, скорее всего >перелезу таки. ;)

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

Это не Lisp for fun это Just for lisp. и Software is like lisp.

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

Позволь согласится :) Меня тоже на emacs-cvs дердит только gtk2 морда и unicode...

> Согласен изврат. Мож не прав, но пайпы вроде через диск => скорость в ... Не лучше-ли через SharedMem?(Не знаю есть ли в лиспе)

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

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

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

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

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

про 20 лет я, конечно, погорячился - от 20 до 50 :)

Забавная программка.

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

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

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

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

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

А почему движок-то тупой? На OGRE сделано несколько коммерческих игр.

>>Согласен изврат. Мож не прав, но пайпы вроде через диск =>

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

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

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

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

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

> все свойства face (такие как background, foreground, font, etc, вобщем те которые в built-in-face-specifiers<v>) -- это specifierы! то есть значения могут меняться как хочешь в зависимости от домена specifierа (buffer, frame или window)

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

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

Именно так.

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

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

> А почему движок-то тупой? На OGRE сделано несколько коммерческих игр.

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

> аффтар! Тебя любой издатель с твоими убогими непортабельными fifo отправит в пешее эротическое путешествие!

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

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

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

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

> аффтар! Тебя любой издатель с твоими убогими непортабельными fifo отправит в пешее эротическое путешествие!

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

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

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

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

(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) можно вообще генерить распределенные приложения.

> В итоге при компиляции (интерпретации) лисп клиента получается исполняемый модуль + файлик server.cc, который легко можно вставить в основную графическую программу.

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

> То есть такого эффекта ( 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

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

С помощью Lispworks и OpenGL FFI bindingов удается писать под Open GL без всяких там Си с крестами.

Lisper.

> С помощью Lispworks и OpenGL FFI bindingов удается писать под Open GL без всяких там Си с крестами.

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