freenode/lisp - IRC Chatlog
Search
21:50:55
sveit
I am confused how condition tests are supposed to work. Why is it that with custom condition types, '(nil) is always passed as the condition to the test? A simple failing example is: https://pastebin.com/QE87KacT
21:54:04
sveit
phoe: i was just copying the error i get from sbcl when I run the example in my pastebin (which just defines an custom condition and a conditional restart). More precisely, sbcl complains "no applicable method for generic function test-slot when called with arguments (NIL)"
21:55:09
Bike
also, p hoe is right: test functions should be prepared to accept nil, and also any condition object.
21:55:12
phoe
if COMPUTE-RESTARTS is called without a condition object, then restart test functions will be called with NIL
21:55:41
phoe
if they're called with a condition object - then that argument will be that condition boject
21:56:38
sveit
ah, thanks. didn't see that in the hyperspec. seems like a strange convention, isn't compute-restarts in the usual case called without a condition object?
21:57:36
phoe
the debugger is allowed (and should) call COMPUTE-RESTARTS *with* a condition object, in particular, with the condition object that the debugger has been entered with
21:58:13
phoe
it's not really specified in the spec (as the debugger isn't really specified), but it's the only logical behavior
21:58:43
sveit
hmm. Doesn't seem to be the behaviour in my SBCL (that error I get was from interactively calling (test-function) in REPL)
21:58:46
phoe
users are also allowed to do the same, e.g. if they end up in the debugger REPL and want to resolve the situation manually via calling FIND-RESTART and INVOKE-RESTART and what else
21:59:47
sveit
phoe: i mean that the debugger seems to be calling COMPUTE-RESTARTS *without* a condition object, since nil is being passed to the condition test
22:03:52
phoe
there's also the issue with asynchronous printing and intertwined lines, but eh, things are still visible
22:04:18
phoe
anyway, this is allowed, so a test function must be prepared to accept anything of type (OR NULL CONDITION).
22:06:23
sveit
phoe: thanks for clearing that up. is there some "convention" that one should tend to return 't from the test if the condition type is null/not the type you are signaling?
22:07:31
phoe
it only gets to use two sources of information to compute the answer: the condition object or lack thereof, and the dynamic environment in which it runs
22:08:50
phoe
and whether it should be visible in all cases (when the argument is NIL) or only if specific conditions are signaled
22:09:22
phoe
and even then, if these conditions have some proper internal state - you can check that by querying the slots of the condition object
22:10:02
phoe
so, basically - that's a rather generic framework for restart visibility, and usually the answer will be trivial
22:11:22
phoe
for an example, you don't want to try and offer to save a crash dump file to the default disk drive if you just got a NO-SPACE-LEFT-ON-DEVICE error mentioning that particular disk drive
22:11:56
phoe
or, you don't want to try and resend data on a network socket if that network socket just git a CONNECTION-RESET
22:12:33
phoe
that's the general idea - the test function should answer the question of "is the restart applicable in this particular context?"