11:49:32stassatsi'm not going to do anything anyway
11:55:42Baggersstassats: can you give an advice on where to start debugging this? As it works from other languages & lisp implementations it's been tricky to narrow this down. Any hunches would be appreciated
18:03:20stassatsir1-optimize-until-done is pretty convoluted and not explained
18:03:33stassatsbut i think i can do a simple modification that makes 1764847 go away
18:03:54stassatsnot because i want 1764847 to go away, don't really care about it, but because it seems like the right thing
18:05:28stassatsunless it's not the right thing, building and testing to find out
18:07:39pfdietz2I'm not attached to these bugs; you can judge them important or not as you see fit. Some may come up in "real" code but you'd have a better sense of that than I would.
18:08:08stassatstheoretically, it can surface without *max-optimize-iterations*
18:08:52stassatsand i don't want to do anything if it's not actually real, and the failure mode is benign - compilation failure, not a silent corruption
18:11:39stassatsand now it will go away even with *max-optimize-iterations* bound to 1, but it's still potentially there
18:12:20stassatsi'd love *max-optimize-iterations* to go away completely
18:13:59stassatsone place we've discovered it's needed - type derivation can go in cycles
18:14:12pfdietz2I should look for other internal knobs to tweak for testing. Easy way to expand test diversity.
18:14:17stassatsmaybe that could be handled separately
18:14:47stassatspfdietz: could try SB-C::*REOPTIMIZE-AFTER-TYPE-CHECK-MAX*
18:15:04stassatsi really don't like this one either