Отладка модулей alterator

Отлаживать модули в alterator пока не так просто и удобно как хотелось бы.
Следующие способы возможно облегчал жизнь:

• Запуск guile в отладочном режиме (в случае ошибки выдаётся очень backtrace, благодаря которому можно понять где возникла проблема):

guile --debug -s /usr/bin/alterator -c standalone.layout <профиль>

• Вставка отладочных сообщений. Во всех компонентах alterator можно ставить отладочные сообщения с выводом в stderr, вывод в stdout можно делать также везде кроме бакендов. Для выдачи сообщений об ошибке можно пользоваться функциями write,display или format (рекомендуемый вариант).

(format (current-error-port) "value=~S~%" value) ; вывод на stderr или (format #t "value=~S~%" value) ; вывод на stdout

• Если подземные стуки раздаются в районе браузера интерфейса, то можно заменить в layout транспорт pipe-in, на std-in, и дав на вход команду "(auth-request)", посмотреть на вывод. Ниже пример layout для использования транспорт std-in.

• Если есть подозрение, что по шине ходят какие-то не такие команды, то можно вставить между интересующими модулями компонент по имени (bridge-book-recorder “name.log”) и потом изучать содержимое log-файла
• Если есть подозрение, что бакенд не отрабатывает как следует, то помимо простых отладочных сообщений, возможны следующие варианты:
  • Если проблема в протоколе обмена, то можно попробовать «пообщаться» с бакендом вручную прямо в shell (протокол описан в соотв. разделе)
    $ backend3/users _message:begin _objects:root action:read _message:end ( gecos "Root" home "/root" shell "/bin/bash" )
    
  • Если проблема в логике, то можно пообщаться с бакендом, используя cmdline интерфейс

$ alterator -l -c cmdline.layout /users/root action read (("/users/root" gecos "Root" home "/root" shell "/bin/bash"))