Lisp for fun

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

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

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

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

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

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

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

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

Именно так.

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

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

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

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

> Не совсем понял вопрос, но я такого не делал. Правильный подход - встроить в сервер интерпретатор 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, который легко можно вставить в основную графическую программу.

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