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
15:20:29
dim
I'm trying to get my head around ignoring the notes but... well... I wonder if you'll find my current approach as horrid as I do:
15:20:44
dim
(let (c) (multiple-value-bind (function warnings-p failure-p) (handler-case (compile nil source) (condition (setf c condition))) (if (and failure-p c) (signal c) function)))
15:21:02
beach
dim: Why would you want to ignore a note that indicates a defect in the code provided?
15:21:32
dim
the user doesn't provide lisp code, I do, the user provides a higher level “command language” that I parse into lisp code
15:22:08
dim
also the unit tests work fine with SBCL 2.2.3 and fail with this problem with SBCL 2.2.6
15:22:10
beach
Still, that means that the command-language code contains a defect. Unless your translation is buggy of course.
15:22:34
dim
it used to work fine, and I want to get back to the thing just working fine, if that makes sense
15:23:05
dim
my bet is that my translation produced code that can safely be removed by the compiler... why would I prevent that from happening?
15:23:06
beach
Not really. It could be "working fine" just because that particular case was never exercised.
15:23:40
dim
yeah it was, it's the same test that works in 2.2.3 and fails in 2.2.6, and this has been fine with SBCL versions 1.x before that
15:25:10
Bike
a code deletion note can indicate problems. for a stupid example, if you have (progn (+ (the symbol a) b) (print c)), sbcl will note that it's deleting the print, because the + will always error
15:26:18
dim
beach: my understanding here is that there exists an approach allowing me to avoid the situation altogether by being smarter about the lisp code I produce ; now, that's some amount of efforts that would merely duplicate what the SBCL compiler is doing for me, right? so I guess you're saying I can't be sure that it's doing that on-purpose, and I'm saying I'm lazy enough to be okay with that, thanks to having a test suite
15:26:54
Bike
i think if you want to ignore notes that's probably okay in general, but your ignoring should not be dying with a fatal error as soon as you get one
15:27:33
beach
dim: My bet is that your code produces snippets that can never be executed only if the command-language source code contains such code. But I am just guessing of course.
15:27:57
White_Flame
from process-command-file, you're passing a pathname as the SOURCE parameter of run-commands, where it'll try (compile nil source). That doesn't seem to make much sense to me, and stuff like that might be the cause of some of your notes
15:28:09
dim
yeah and I don't have a memory model of condition handling in pgloader anymore, so instead of building it, I'm looking into how to “swallow” the harmless condition signalled in the call to compile
15:29:06
dim
White_Flame: there is an option that allows users to provide their own lisp code too, directly, it sounds related
15:29:13
White_Flame
oh ok, the comment does mention it can be a pathname, was reading the wrong thing