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
18:15:38stassatswell, like any a-magic-number-let's-hope-it-will-converge-on-something-consistent
21:11:22Xof*check-consistency* stuff has possibly been ironed out by pfdietz, because the common symptom without it is a function deleting its entire body, then calling it goes directly into the *elsewhere* error-signalling code
21:12:14stassatsthere was some other stuff, like zombie blocks
21:33:02pfdietz2I need to do a mass download of all the Common Lisp projects on github. I've been using quicklisp projects for test generation but more is better.