Search
Friday, 20th of September 2019, 7:13:49 UTC
13:30:20
pfdietz
I am seeing a heap corruption error in some varieties of random testing on the SEARCH function. Trying to track it down, but reproducibility is difficult.
16:39:43
stassats
feels unlikely that SEARCH itself is broken
17:42:44
stassats
right, a type conflict
17:51:06
stassats
so, search can return an index beyond the sequence...
17:54:16
stassats
judging by the comments, i did envision that, but " only when searching for "" and :start2 being equal to :end2"
17:55:54
stassats
i really need to invent some NIL type derivation catcher
17:56:29
stassats
so that it doesn't just go off the rails
18:06:32
stassats
ok, that's easy, now, why doesn't (position a (the (simple-vector 8) b)) derive that it's below 8
18:11:44
stassats
it loses the type after getting transformed to SB-KERNEL:%FIND-POSITION
18:18:12
stassats
suppose i can make it stick around, still it may be too early
18:18:33
stassats
but i'm not that eager to define a type deriver on %find-position
18:18:58
stassats
this is where attaching type derivation to lvars would have come in handy
18:20:32
stassats
i should try making a proof of concept, before drowning in duplicate transforms/type derivers
18:22:18
pkhuong
might also be useful to have another kind of note to drive the post-IR1 pattern matching
18:22:39
pkhuong
and more easily replace useless inlining with the original call
18:25:53
stassats
will start with type derivation, as i don't have to think about removing dead code
18:26:43
stassats
and improving position is a good case
18:29:51
eschatologist_
** NICK eschatologist
Friday, 20th of September 2019, 19:13:49 UTC