[perl #39714] [TODO] Refactor IMCC to remove static globals

[Audrey Tang]

# New Ticket Created by Audrey Tang
# Please include the string: [perl #39714]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39714 >


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.

[Kjstol]

--001636c5bcc5b650e40462c0ce29
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Thu, Feb 12, 2009 at 9:22 PM, Will Coleda via RT <

Post by Audrey Tang
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

--
Will "Coke" Coleda
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Will Coleda]

Post by Kjstol
On Thu, Feb 12, 2009 at 9:22 PM, Will Coleda via RT <

Post by Audrey Tang
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."

[Jerry Gay]

Post by Will Coleda

Post by Kjstol
On Thu, Feb 12, 2009 at 9:22 PM, Will Coleda via RT <

Post by Audrey Tang
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

[Kjstol]

--001485f91c3047b1010462c9c0b0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Post by Kjstol

Post by Will Coleda

Post by Kjstol
On Thu, Feb 12, 2009 at 9:22 PM, Will Coleda via RT <

Post by Audrey Tang
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

Post by Will Coleda

Post by Kjstol

eventually want PIRC to take over. Anyone think this falls into the

same

Post by Will Coleda

Post by Kjstol

category?

I would like to indicate that while most of PIRC's done, it's not

finished

Post by Will Coleda

Post by Kjstol
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

Post by Will Coleda

Post by Kjstol
work on that recently. The rest is just a matter of test+fix cycle; I'm

sure

Post by Will Coleda

Post by Kjstol
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

Post by Will Coleda

Post by Kjstol
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

Then it needs to be documented (perhaps in the book) that imcc is not
reentrant. (not entirely sure what that implies, though, as I think that
:immediate .subs load'ing_bytecode works now)

kjs