← Архив: Common Lisp

Взаимодействие с SBCL через потоки ввода/вывода

Author: · 09.07.2012 04:13
· original author: tirinox
Доброго времени суток!Вопрос, конечно, не по самому Лиспу, а по работе SBCL.
Я написал сервер на Node.js + Websockets, который создает дочерний процесс SBCL и отправляет ему в stdin, все, что получает от клиента, а клиенту отдает все из stdout и stderr. Получился этакий REPL онлайн. 
Плохо то, что
1) мешается звездочка (*), пока я ее вручную в сервере обрезаю. 
Пробовал запускать SBCL с --noinform --noprint, звездочки нет, но он начинает вести себя неадекватно:
(print (+ 5 6))
(print (+ 7 9))
11
(print (+ 1 2))
16
Т.е. выводит ответ не на текущий запрос, а на предыдущий! (Это даже без сервера, просто с терминала, сервер, очевидно, себя также ведет). В чем тут косяк? Может, все работает правильно, только я не так понимаю? Или, может, просто сделать костыль, который начнет общение с Лиспом с бесполезной команды, и дальше все синхронизируется?...

2) непонятно, что делать с ошибками
Я хочу для начала, чтобы при возникновении ошибки я мог просто вернуться в REPL и быть готовым получить новую команду. В принципе достаточно ввести "0 + энтер" после ошибки. Но, когда я делаю запись в stdin "0\n" SBCL никак не реагирует... Может, есть какой-то ключ запуска, который при ошибке сразу делает ABORT?
И еще вопрос: почему всегда только один вариант 0: ABORT? При работе в Emacs+Slime+SBCL всегда много вариантов. При этом, насколько я помню, ABORT там висит не на 0, чаще на 1 или 2, иногда даже на 4.
· original author: dmitry_vk
>При работе в Emacs+Slime+SBCL всегда много вариантов.
Потому что Slime (а, точнее, swank) оборачивает вызовы из REPL в свои обработчики ошибок, а не просто их вызывает.
Вообще, общение с REPL текстом всегда будет приводить к различного рода проблемам. Лучше всего - иметь отдельный thread для обработки запросов, и использовать какой-нибудь нормально сериализуемый протокол для общения между лиспом и управляющей программой. Например, s-exp или json. В этом случае и возвращаемый результат, и информацию об ошибке, и выводимый текст можно разделять.
· original author: tirinox
dmitry_vk, хорошее решение, спасибо. Тоже о нем думал, нужно попробовать.