libera/#commonlisp - IRC Chatlog
Search
7:15:19
Nilby
it must be an implementation bug, but one that's probably my problem since i'm probably using internal debugging functions wrong
7:18:44
Nilby
It's very difficult when there's simultaneously a bug in my program, the debugger, and errors in implementation print-object methods.
8:39:36
Nilby
I wonder what it means when #<FUNCTION <<error printing object>> shows up sbcl's slime backtrace
8:40:56
hayley
It means the object couldn't be printed for some reason, so you get that text to have any backtrace at all.
8:41:20
beach
It looks like someone defined a method on PRINT-OBJECT that calls PRINT-UNREADABLE-OBJECT, but that method is buggy.
9:00:21
ogamita
Nilby: you should be concerned because it's an impediment of your debugging capabilities. You should identify the buggy print-object method and debug it.
9:01:24
ogamita
Now it's a little strange because what's expected there is a function name (a symbol), or perhaps a lambda-expression, and those are usually quite printable. Perhaps you have some unprintable literal object in this function?
9:04:08
Nilby
I looked at it. It gets a type-error in the function printing code, like #<TYPE-ERROR expected-type: FUNCTION.
9:12:13
beach
You can do that with the SLIME debugger as well. Just hit RETURN in the REPL window and you get a SLIME REPL.
9:22:54
beach
Yes, specifically: https://github.com/phoe/portable-condition-system/blob/master/src/debugger.lisp
9:24:43
Nilby
As far as I can see it doesn't do stack printing or have any terminal stuff like command line editing etc. But I know I'm weird by running Lisp not under Emacs.