Alterator/debug: различия между версиями
(Import from freesource.info) |
Ilis (обсуждение | вклад) Нет описания правки |
||
Строка 6: | Строка 6: | ||
==== Распространённые ошибки при работе с внешними | ==== Распространённые ошибки при работе с внешними бэкендами. ==== | ||
Внешние | Внешние бэкенды альтератора (backend3) общаются с ядром через stdin/stdout. С одной стороны - это очень хорошо, с другой - частенько порождает сложно понимаемые ошибки. <div style="display: inline; color: red;">Список перечисленных ниже известных проблем является одновременно и пожеланием к будущим внешним бэкендам (backend4).</div> | ||
1. '''Паразитный вывод от утилит''' - некоторые утилиты могут неожиданно для автора | 1. '''Паразитный вывод от утилит''' - некоторые утилиты могут неожиданно для автора бэкенда произвести печать чего-нибудь на stdout. В результате альтератор воспримет это как ответ. В результате может быть выдано сообщение об неподдерживаемой команде или ,что ещё хуже, alterator просто зависнет. Последнее может происходить в случае, когда утилита выдала на stdout кавычку, двойную кавычку или скобку, и alterator начинает ожидать завершения строки. | ||
2. '''Отсутствие ответа''' - можно ошибиться и какая-нибудь из утилит (например grep), будет висеть и в месте с ней будет висеть и весь alterator. | 2. '''Отсутствие ответа''' - можно ошибиться и какая-нибудь из утилит (например grep), будет висеть и в месте с ней будет висеть и весь alterator. | ||
3. '''Два ответа вместо одного''' - alterator не сбрасывает буфер чтения перед началом чтения очередного ответа от | 3. '''Два ответа вместо одного''' - alterator не сбрасывает буфер чтения перед началом чтения очередного ответа от бэкенда, поэтому если бэкенд ответил два раза, ядро и бэкенд начинают работать в "противофазе" выдавая неожиданные ответы в неожиданных местах. Внешне всё выглядит как будто модуль то работает, а то не работает. | ||
4. '''Неверный формат вывода списка''' - давным давно alterator стал использовать для вывода списков странную систему, в которой в отличие от остальных случаев первым идёт строка с именем. Пользователи не читают документацию, поэтому часто вместо '("a" param "pam-pam") выводят '(name "a" param "pam-pam") ... в результате | 4. '''Неверный формат вывода списка''' - давным давно alterator стал использовать для вывода списков странную систему, в которой в отличие от остальных случаев первым идёт строка с именем. Пользователи не читают документацию, поэтому часто вместо '("a" param "pam-pam") выводят '(name "a" param "pam-pam") ... в результате бэкенд не работает. | ||
5. '''Неверный тип данных в ответе''' - | 5. '''Неверный тип данных в ответе''' - бэкенд принимает всё как строки, а вот отдаёт уже данные типизированные в формате scheme. Если вы выдадите не тот тип, то может рухнуть не очень аккуратно написанный код где-нибудь в ядре (<div style="display: inline; color: red;">по этому поводу надо сразу же повесить сообщение об ошибке</div>). А если забудете о квотировании строк, то всё может просто-напросто повиснуть, ожидая окончание строки. | ||
6. '''Несоответствие | 6. '''Несоответствие бэкенда правилам workflow''' - в HTML интерфейсе автоматические workflow (такие как form и card-index) требуют определённого подхода к размещению параметров в "дереве" бэкенда. В GUI вся динамика пока пишется вручную, поэтому там это не так критично. | ||
==== Вставка отладочных сообщений ==== | ==== Вставка отладочных сообщений ==== | ||
Во внешних | Во внешних бэкендах остаётся свободным stderr, поэтому можно выводить отладочные сообщения именно туда. В нативных бэкендах и во всём остальном alterator свободны и stdout и stderr. Для вывода в коде scheme рекомендуется использовать функцию format. Например: | ||
<pre>(format #t "debug-message:obj1=~S,obj2=~S~%" obj1 obj2) ; вывод на stdout | <pre>(format #t "debug-message:obj1=~S,obj2=~S~%" obj1 obj2) ; вывод на stdout | ||
(format (current-error-port) "debug-message~%") ; вывод в stderr</pre> | (format (current-error-port) "debug-message~%") ; вывод в stderr</pre> | ||
Очень полезно отладить | Очень полезно отладить бэкенд сначала в интерфейсе командной строки, а потом уже проверять как он работает в других более сложных интерфейсах - так будет проще найти виноватого. | ||
==== Интерпретация некоторых загадочных сообщений ==== | ==== Интерпретация некоторых загадочных сообщений ==== |
Версия от 13:35, 21 октября 2008
Отладка модулей alterator
Распространённые ошибки при работе с внешними бэкендами.
Внешние бэкенды альтератора (backend3) общаются с ядром через stdin/stdout. С одной стороны - это очень хорошо, с другой - частенько порождает сложно понимаемые ошибки.
1. Паразитный вывод от утилит - некоторые утилиты могут неожиданно для автора бэкенда произвести печать чего-нибудь на stdout. В результате альтератор воспримет это как ответ. В результате может быть выдано сообщение об неподдерживаемой команде или ,что ещё хуже, alterator просто зависнет. Последнее может происходить в случае, когда утилита выдала на stdout кавычку, двойную кавычку или скобку, и alterator начинает ожидать завершения строки. 2. Отсутствие ответа - можно ошибиться и какая-нибудь из утилит (например grep), будет висеть и в месте с ней будет висеть и весь alterator. 3. Два ответа вместо одного - alterator не сбрасывает буфер чтения перед началом чтения очередного ответа от бэкенда, поэтому если бэкенд ответил два раза, ядро и бэкенд начинают работать в "противофазе" выдавая неожиданные ответы в неожиданных местах. Внешне всё выглядит как будто модуль то работает, а то не работает. 4. Неверный формат вывода списка - давным давно alterator стал использовать для вывода списков странную систему, в которой в отличие от остальных случаев первым идёт строка с именем. Пользователи не читают документацию, поэтому часто вместо '("a" param "pam-pam") выводят '(name "a" param "pam-pam") ... в результате бэкенд не работает.
5. Неверный тип данных в ответе - бэкенд принимает всё как строки, а вот отдаёт уже данные типизированные в формате scheme. Если вы выдадите не тот тип, то может рухнуть не очень аккуратно написанный код где-нибудь в ядре (
). А если забудете о квотировании строк, то всё может просто-напросто повиснуть, ожидая окончание строки.
6. Несоответствие бэкенда правилам workflow - в HTML интерфейсе автоматические workflow (такие как form и card-index) требуют определённого подхода к размещению параметров в "дереве" бэкенда. В GUI вся динамика пока пишется вручную, поэтому там это не так критично.
Вставка отладочных сообщений
Во внешних бэкендах остаётся свободным stderr, поэтому можно выводить отладочные сообщения именно туда. В нативных бэкендах и во всём остальном alterator свободны и stdout и stderr. Для вывода в коде scheme рекомендуется использовать функцию format. Например:
(format #t "debug-message:obj1=~S,obj2=~S~%" obj1 obj2) ; вывод на stdout (format (current-error-port) "debug-message~%") ; вывод в stderr
Очень полезно отладить бэкенд сначала в интерфейсе командной строки, а потом уже проверять как он работает в других более сложных интерфейсах - так будет проще найти виноватого.
Интерпретация некоторых загадочных сообщений
- Если по какой-то причине вы получаете, нечто подобное в fbi
key=wrong-type-arg,args=("string-append" "Wrong type argument (expecting ~A): ~S" ("STRINGP" adduser) #f)
- Это означает, что ваш backend спросили, а он вернул просто слово, а не строку. Для того чтобы понять, что вас спросили,
- лучше всего использовать в вашем backend'е следующую конструкцию
on_message() echo "имя_вашего_модуля= $(date +%H/%M/%S): action=$in_action and objects=$in__objects" >> /tmp/alterator-debug.txt 2>&1
- Теперь, если заглянуть в файл /tmp/alterator-debug.txt то можно видеть, какой последним был запрос, допустим это было
имя_модуля= 00/33/22: action=read and objects=/someobject
- Стоит произвести следующую диагностику
alterator-cmdline /имя_модуля/someobject action read /usr/share/guile/1.6/alterator/exit-handler.scm:19:7: In procedure string-append in expression (apply throw args): /usr/share/guile/1.6/alterator/exit-handler.scm:19:7: Wrong type argument (expecting STRINGP): что-то тут
- На самом деле ответ должен выглядеть как-нибудь так (полностью зависит от вашей реализации модуля у меня это мой пример)
(("/имя_модуля/someobject" name "что-то тут"))
- Особое внимание на "что-то тут" -- кавычки, если писать на shell, то обычно кавычки забывают передать, используют конструкцию "string", а не "\"string\""