libera/#commonlisp - IRC Chatlog
Search
4:52:34
jmes
Sorry I dropped my question and ran off for a bit. The answer illuminates some neat behaviour, thanks! Now I should go delete some redundancy in my code...
14:47:13
dim
Hi friends! I have another pgloader related question, with SBCL 2.2.6 (available in debian sid): An unhandled error condition has been signalled: deleting unreachable code
14:47:27
dim
does that ring a bell as something new that could happen when compiling lisp code at run-time?
14:51:04
dim
well you're saying that it's signaling a condition that pgloader code is choosing to interpret as an error?
14:54:20
Bike
where is the "unhandled error condition has been signalled" message coming from, exactly?
14:56:25
dim
just a simple call to the compile function; is the list of conditions reported there documented somewhere? what would code that ignore warnings look like?
14:59:34
beach
If it is just a note, then that means that the compiler has been able to prove that some code is never going to be executed.
15:00:38
dim
yeah I'm okay with that, I don't know before-hand what users are going to provide as input for the command language
15:01:07
dim
I suppose I could somehow arrange for producing lisp code where that never happens, it kind of sounds like the job of the compiler though?
15:02:33
beach
If that note is given in code written by the programmer, it indicates a defect. If it is given in some automatically generated code, perhaps not.
15:04:09
Bike
I meant, where is the message "An unhandled error condition has been signalled" coming from, not the error itself
15:04:18
jackdaniel
that note is annoying when comes from a macroexpansion, i.e `(if ,test ,something ,other) when the test provided by the user is constant
15:05:30
Bike
And I see that elsewhere in pgloader, in the main function, there's a handler bind on (and condition (not (or monitor-error ...)))
15:05:44
Bike
which doesn't have that message, but that would pick up a compiler note, since it's a condition and not one of those pgloader errors
15:06:16
Bike
I do not think that that handler bind is a good idea, becvause it will treat harmless stuff as a fatal error
15:09:17
dim
yeah I think when I wrote that code I was still discovering handler-bind etc, and to be honest, I'm still a beginner in that area
15:09:50
Bike
an sbcl compiler note is a condition but not an error. the program can proceed after the note no problem. so you probably don't want to kill pgloader just over a note
15:09:51
dim
contributions welcome, as always (either advice here, I appreciate your time and discussion, or even pull requests etc)
15:10:16
Bike
(and error ...) or (and serious-condition ...) might be better, since those are things that require manual intervention
15:10:44
dim
I also see now that compile name &optional definition => function, warnings-p, failure-p ; so maybe I should keep silent when failure-p is nil?
15:10:51
Bike
But I don't know if this is what the problem is, because it looks like the definition is different