freenode/#sbcl - IRC Chatlog
Search
12:36:08
francogrex
hi is it possible to reconnect to a running thread: debugger invoked on a SB-INT:SIMPLE-READER-PACKAGE-ERROR in thread #<THREAD "main thread" RUNNING {23EE7E89}>
12:36:29
francogrex
sbcl hangs and i would like to open another sbcl and connect it to that hanging running thread
22:06:06
scymtym
attila_lendvai: i was going to fix a problem in INSPECT and stumbled upon an apparent problem with *SUPPRESS-PRINT-ERRORS*. do you have a minute to discuss this?
22:10:48
scymtym
i basically wanted to use *SUPPRESS-PRINT-ERRORS* in INSPECT when printing slot values since that can signal errors (e.g. in case of user-written PRINT-OBJECT methods)
22:12:15
scymtym
the reason is that the test harness establishes a condition handler that handles error conditions (or maybe serious conditions, i don't remember)
22:13:33
scymtym
this is because the code in OUTPUT-OBJECT SIGNALs the condition to ;; Give outer handlers a chance.
22:16:08
attila_lendvai
I must note that I merely used/mimic'd this machinery in my backtrace code, but I'm trying to decypher the situation
22:17:38
attila_lendvai
that "Give outer handlers a chance." doesn't make sense to me. if print errors are suppressed, then, well, I expect them suppressed.
22:18:36
attila_lendvai
it's a neat trick to SIGNAL them, as opposed to ERROR them, but it still doesn't make sense to me
22:19:59
scymtym
a handler would have to invoke the CONTINUE restart or not handle the condition for the suppression to work
22:20:44
attila_lendvai
FWIW, I have a construct for such situation (possibility of errors happening while dealing with errors): https://hub.darcs.net/hu.dwim/hu.dwim.util/browse/source/error-handling.lisp#17
22:21:46
scymtym
this behavior is probably ok for BREAK because the condition is not an error in that case
22:23:32
attila_lendvai
it's somewhat convoluted because of other stuff like logging, and thread state tracking, but it made a lot of code behave much better. many headaches involved logging and custom print-object methods triggering a nested error