Search
Friday, 18th of January 2019, 17:10:56 UTC
18:32:30
karlosz
anyone ever encounter "The value NIL is not of type SB-C::VOP" in add-representation-costs?
18:32:41
karlosz
it seems like there's a tn-ref that never gets assigned a vop up to that point
18:33:13
karlosz
does that mean a vop generator has been written inconsistently?
18:33:25
stassats
what kind of a TN do you have there?
18:39:22
karlosz
well the tn being referred to is a normal one
18:39:35
karlosz
its also only the first tn-ref in the list to not have a vop assigned
18:39:45
karlosz
the next one in the list has pop-values or something
18:43:02
karlosz
another instance has multiple-call-local as the next tn's vop
18:43:31
karlosz
it seems like the only time the tn-ref's vops get assigned is during emit-vop
18:43:43
karlosz
which makes it seem like one of the vops i wrote is somehow wrong
18:43:51
karlosz
for a ref to never get a vop assigned to it
18:44:07
karlosz
or one of the stubs defined is insufficiently specified
19:45:59
karlosz
ah, i see. writing the nlx vops solved it
22:04:31
stassats
looks like i can again optimize (position 1 (the simple-bit-vector x)), using a new approach for mv-b+if+values handling
22:05:21
stassats
instead of converting to let directly, remove the unused variable-argument pairs, and hope it'll get optimized elsewhere
23:10:20
stassats
and i broke assert-type-error
23:10:56
stassats
as it uses nth-value 1 on ignore-errors, but now m-v-bind is too smart and can figure out that the value is unused and doesn't signal an error
23:12:15
stassats
guess i'll just include the return value in the error message
23:29:49
stassats
SB-VM::COMPUTE-DIRECT-CALL-GRAPH in slad produces an error, but the streams are already
23:34:42
stassats
of course, when i switch them up it doesn't fail
Saturday, 19th of January 2019, 5:10:56 UTC