trace в cmucl

Мда, действительно в clisp, sbcl, lispworks и allegro всё как надо, а в cmucl не работает...

Ага. http://www.pmsf.de/pub/cmucl/release/19b/release-19b.txt

TRACE will work now for the known-return convention, which used to require encapsulation so that only the first call was traced. Useful for tracing recursive functions.

то есть, они считают такое поведение фичей? Странно...

С тебя пиво, за то что сделал за тебя работу:)

Это типа оптимизация.

http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/thread/e6425295...

В самом низу треда решение.

> С тебя пиво, за то что сделал за тебя работу:)

Да без проблем, приезжай в Киев, напою ;)

> Это типа оптимизация.

Неотключаемая фича -- баг. После этого на кмукл теперь забью, даже несмотря на то, что в slime он лучше всего поддерживается. Там еще нельзя русские символы использовать. Фтопку. Тем более, sbcl ненамного хуже + активней развивается

Тем более, тот воркэраунд не пашет :( Ну его нах, в общем

Всмысле не пашет? у меня работает... Мне как-то почти без разницы что cmucl что sbcl, разве что в дебаггере у cmucla поприятнее вывод. Ну ещё по мелочи...

Кстати глюк с русским это глюк slime, но судя по ченджлогам вроде пофиксили недавно, но я как-не проверял - не нужно пока.

Не знаю, даже без слайма русский просто не воспринимается даже ридером. :(

nsav vatutin:~ [2153%1]% cmucl
; Loading #P"/home/nsav/init.lisp".
CMU Common Lisp CVS 19b 19b-release-20050628-3 + minimal debian patches (19B), running on vatutin
With core: /usr/lib/cmucl/lisp.core
Dumped on: Fri, 2005-08-05 14:35:45+03:00 on vatutin
For support see http://www.cons.org/cmucl/support.html Send bug reports to the debian BTS.
or to pvaneynd@debian.org
type (help) for help, (quit) to exit, and (demo) to see the demos

Loaded subsystems:
    Python 1.1, target Intel x86
    CLOS based on Gerd's PCL 2004/04/14 03:32:47
* 'фыва

Reader error on #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>>:
Undefined read-macro character #\ф
   [Condition of type READER-ERROR]

Restarts:
  0: [ABORT] Return to Top-Level.

Debug  (type H for help)

(LISP::%READER-ERROR
 #<Two-Way Stream, Input = #<Synonym Stream to SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>>
 "Undefined read-macro character ~S"
 #\ф)
Source:
; File: target:code/reader.lisp
(ERROR 'READER-ERROR :STREAM STREAM :FORMAT-CONTROL ...)
0]

В sbcl все путем. 

А ты про имена символов, ну это я не проверял, как-то не нужно.

Ну в лиспе между строками и символами есть довольно тесная связь, которую иногда удобно использовать. Например, написать что-то вроде (format t "Все бабы ~a~%" 'стервы) ;)

Иногда(а точнее прямо сейчас) эта связь добивает. Парюсь с clsql если в mysql'ной БД столбец типа text, clsql почему-то читает его как символ а не как строку.

Так в чем проблема? (format nil "~a" что-те-надо) и все в ажуре. Если так уж припекло, то напиши макрос и не парься. :)

Да там фишка в том, что он читает скорее всего read-ом и выдаёт (name db-row) уже скажем FUCKING вместо "Fucking name bla bla bla". Толи глюк, то-ли где настроить надо, сейчас ищу только что-то не пока не нашёл.

Блин вот что бывает, когда привык что программы обычно не такие умные. Оказывается этот clsql не кэшировал запрос из БД, даже после того как я пересоздал таблицу, и выдавал мне мой объекты с первого запроса.

Не самая хорошая идея. Символы все в uppercase переводятся.

В именах символов можно использовать любые символы (сорри за каламбур). Почитай в практикал коммон лиспе, там эта тема хорошо раскрыта

Можно то можно, но не так, как ты это сделал. 'блядищща это будет именно что БЛЯДИЩЩА.