On Thu, Feb 12, 2009 at 15:53, Will Coleda <w...@coleda.com> wrote: > On Thu, Feb 12, 2009 at 6:09 PM, kjstol <parrotc...@gmail.com> wrote: >> On Thu, Feb 12, 2009 at 9:22 PM, Will Coleda via RT < >> parrotbug-follo...@parrotcode.org> wrote: >> >>> On Tue Jul 04 19:30:44 2006, autri...@gmail.com wrote: >>> > IMCC currently relies on a lot of static globals to carry state, and >>> > cannot reliably restore them when an error occurs. (grep for >>> > "static" and "FIXME global" in the IMCC tree.) >>> > >>> > Allison had ruled that reentrancy should be possible for IMCC, and >>> > this would be a good refactoring project. >>> >>> We've rejected a lot of "clean up IMCC" tickets with the thought that we >>> eventually want PIRC to take over. Anyone think this falls into the same >>> category? >>> >> >> I would like to indicate that while most of PIRC's done, it's not finished >> yet. Major issue now is the bug with STRING and FLOATVAL constants bug >> (there's 1 or 2 tickets on that). I haven't really had the energy or time to >> work on that recently. The rest is just a matter of test+fix cycle; I'm sure >> there's all sorts of cases that should be tested more properly than I've >> done. So, although I'm confident that together we can fix PIRC, don't throw >> out imcc just yet.. >> >> kjs > > To be clear, I'm not saying "throw out IMCC", I'm saying, "Let's not > bother trying to fix tricky bits of IMCC if we're just going to throw > it out later." > i want to go into production (1.0) knowing what's broken in imcc rather than hiding the broken things in closed/rejected tickets. what do we get by hiding bugs? surprises. i could use fewer of those--my teeth still hurt from that surprise trip to the dentist this week.
~jerry