Fixed case 11996 -- exception handler search bug
Andres and I developed a fix at ESUG for case 11996. The search for exception handlers was not taking into account the general case of exception handlers established or exceptions signaled while already in a handler block, so could find the wrong handler. I put the slices for this fix in the inbox a while back, but neglected to let the list know. Is there anything else I need to do to get this integrated into 4.0? Regards, -Martin
On 22 Sep 2014, at 07:30, Martin McClure <martin@hand2mouse.com> wrote:
Andres and I developed a fix at ESUG for case 11996. The search for exception handlers was not taking into account the general case of exception handlers established or exceptions signaled while already in a handler block, so could find the wrong handler.
I put the slices for this fix in the inbox a while back, but neglected to let the list know.
Is there anything else I need to do to get this integrated into 4.0?
it is important to notify about it. There are >600 issues in the tracker, that means that just solving something but not telling will only lead to action if by chance someone looks a the issue tracker entry. (which means, it is very very unlikely). There are two ways to notify: 1) putting the issue to âfix review neededâ 2) send a mail to the list (the second option is good for complex cases) Marcius
On 22.09.2014, at 09:12, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Sep 2014, at 07:30, Martin McClure <martin@hand2mouse.com> wrote:
Andres and I developed a fix at ESUG for case 11996. The search for exception handlers was not taking into account the general case of exception handlers established or exceptions signaled while already in a handler block, so could find the wrong handler.
I put the slices for this fix in the inbox a while back, but neglected to let the list know.
Is there anything else I need to do to get this integrated into 4.0?
it is important to notify about it. There are >600 issues in the tracker, that means that just solving something but not telling will only lead to action if by chance someone looks a the issue tracker entry. (which means, it is very very unlikely).
There are two ways to notify:
1) putting the issue to âfix review neededâ
I noticed that I canât do that (at least not for the issues I havenât opened myself). Donât know if thatâs a deliberate choice but if you want to delegate a bit of work (and if the behaviour can be changed of course) I suggest that everyone should be able to set that status.
2) send a mail to the list
(the second option is good for complex cases)
Marcius
On 22 Sep 2014, at 09:21, Max Leske <maxleske@gmail.com> wrote:
On 22.09.2014, at 09:12, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Sep 2014, at 07:30, Martin McClure <martin@hand2mouse.com> wrote:
Andres and I developed a fix at ESUG for case 11996. The search for exception handlers was not taking into account the general case of exception handlers established or exceptions signaled while already in a handler block, so could find the wrong handler.
I put the slices for this fix in the inbox a while back, but neglected to let the list know.
Is there anything else I need to do to get this integrated into 4.0?
it is important to notify about it. There are >600 issues in the tracker, that means that just solving something but not telling will only lead to action if by chance someone looks a the issue tracker entry. (which means, it is very very unlikely).
There are two ways to notify:
1) putting the issue to âfix review neededâ
I noticed that I canât do that (at least not for the issues I havenât opened myself). Donât know if thatâs a deliberate choice but if you want to delegate a bit of work (and if the behaviour can be changed of course) I suggest that everyone should be able to set that status.
I will have a look how to configure that. Marcus
On 22 Sep 2014, at 11:21, Ben Coman <btc@openInWorld.com> wrote:
Max Leske wrote:
On 22.09.2014, at 09:12, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Sep 2014, at 07:30, Martin McClure <martin@hand2mouse.com> wrote:
Andres and I developed a fix at ESUG for case 11996. The search for exception handlers was not taking into account the general case of exception handlers established or exceptions signaled while already in a handler block, so could find the wrong handler.
I put the slices for this fix in the inbox a while back, but neglected to let the list know.
Is there anything else I need to do to get this integrated into 4.0?
it is important to notify about it. There are >600 issues in the tracker, that means that just solving something but not telling will only lead to action if by chance someone looks a the issue tracker entry. (which means, it is very very unlikely).
There are two ways to notify:
1) putting the issue to âfix review neededâ
I noticed that I canât do that (at least not for the issues I havenât opened myself). Donât know if thatâs a deliberate choice but if you want to delegate a bit of work (and if the behaviour can be changed of course) I suggest that everyone should be able to set that status.
I've never had a problem with that, and I don't think anything special was ever done to my account. btw, You do need to click the <Resolve> button to get those choices. cheers -ben
yes, there are no special configs⦠you probably are not pressing âresolveâ :) Esteban
⦠*rolling my eyes*⦠*facepalm*⦠On 22.09.2014, at 11:55, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 22 Sep 2014, at 11:21, Ben Coman <btc@openInWorld.com> wrote:
Max Leske wrote:
On 22.09.2014, at 09:12, Marcus Denker <marcus.denker@inria.fr> wrote:
On 22 Sep 2014, at 07:30, Martin McClure <martin@hand2mouse.com> wrote:
Andres and I developed a fix at ESUG for case 11996. The search for exception handlers was not taking into account the general case of exception handlers established or exceptions signaled while already in a handler block, so could find the wrong handler.
I put the slices for this fix in the inbox a while back, but neglected to let the list know.
Is there anything else I need to do to get this integrated into 4.0?
it is important to notify about it. There are >600 issues in the tracker, that means that just solving something but not telling will only lead to action if by chance someone looks a the issue tracker entry. (which means, it is very very unlikely).
There are two ways to notify:
1) putting the issue to âfix review neededâ
I noticed that I canât do that (at least not for the issues I havenât opened myself). Donât know if thatâs a deliberate choice but if you want to delegate a bit of work (and if the behaviour can be changed of course) I suggest that everyone should be able to set that status.
I've never had a problem with that, and I don't think anything special was ever done to my account. btw, You do need to click the <Resolve> button to get those choices. cheers -ben
yes, there are no special configs⦠you probably are not pressing âresolveâ :)
Esteban
On 09/22/2014 12:12 AM, Marcus Denker wrote:
On 22 Sep 2014, at 07:30, Martin McClure <martin@hand2mouse.com> wrote:
Andres and I developed a fix at ESUG for case 11996. The search for exception handlers was not taking into account the general case of exception handlers established or exceptions signaled while already in a handler block, so could find the wrong handler.
I put the slices for this fix in the inbox a while back, but neglected to let the list know.
Is there anything else I need to do to get this integrated into 4.0?
it is important to notify about it. There are >600 issues in the tracker, that means that just solving something but not telling will only lead to action if by chance someone looks a the issue tracker entry. (which means, it is very very unlikely).
There are two ways to notify:
1) putting the issue to âfix review neededâ 2) send a mail to the list
(the second option is good for complex cases)
OK, thanks. It would be good to add the "Press resolve" and "set to fix review needed" steps to http://pharo.org/contribute-propose-fix. Right now it just says" "Update the bug entry to mention that you submitted a slice in the inbox. Now you can feel good!" Regards, -Martin
This fix required multiple slices since loading things in the wrong order broke exceptions badly enough to hang the system. I packaged things in five slices. (It's possible that if Monticello was smart enough I could have done it in less than five, but it did need more than one). The automatic test runner seems to only load the first of the five slices. Therefore two exception tests fail, which is expected. All exception tests should pass after all five slices are loaded in order. Is there a way to tell the automatic test runner to load all five, or does this one require manual testing? (I did test it manually before dropping the slices in the inbox, but that was a month ago.) Regards, -Martin
Martin McClure wrote:
This fix required multiple slices since loading things in the wrong order broke exceptions badly enough to hang the system. I packaged things in five slices. (It's possible that if Monticello was smart enough I could have done it in less than five, but it did need more than one).
The automatic test runner seems to only load the first of the five slices. Therefore two exception tests fail, which is expected. All exception tests should pass after all five slices are loaded in order.
Is there a way to tell the automatic test runner to load all five, or does this one require manual testing? (I did test it manually before dropping the slices in the inbox, but that was a month ago.)
Regards,
-Martin
There is no built in mechanism for loading multiple slices. Now perhaps your slice can contain only a "Dummy class>>initialize" method that scripts Gopher to load the slices in order. Disclaimer, never tried it - just thinking out loud. cheers -ben
On 22 Sep 2014, at 17:35, Ben Coman <btc@openInWorld.com> wrote:
Martin McClure wrote:
This fix required multiple slices since loading things in the wrong order broke exceptions badly enough to hang the system. I packaged things in five slices. (It's possible that if Monticello was smart enough I could have done it in less than five, but it did need more than one).
The automatic test runner seems to only load the first of the five slices. Therefore two exception tests fail, which is expected. All exception tests should pass after all five slices are loaded in order.
Is there a way to tell the automatic test runner to load all five, or does this one require manual testing? (I did test it manually before dropping the slices in the inbox, but that was a month ago.)
Regards,
-Martin
There is no built in mechanism for loading multiple slices. Now perhaps your slice can contain only a "Dummy class>>initialize" method that scripts Gopher to load the slices in order. Disclaimer, never tried it - just thinking out loud.
I think the easiest is to make sub-cases: then they will be checked with the leaf first, after it is integrated (and closed), the parent gets tested, and so on. Marcus
On 22 Sep 2014, at 17:05, Martin McClure <martin@hand2mouse.com> wrote:
This fix required multiple slices since loading things in the wrong order broke exceptions badly enough to hang the system. I packaged things in five slices. (It's possible that if Monticello was smart enough I could have done it in less than five, but it did need more than one).
The automatic test runner seems to only load the first of the five slices. Therefore two exception tests fail, which is expected. All exception tests should pass after all five slices are loaded in order.
Is there a way to tell the automatic test runner to load all five, or does this one require manual testing? (I did test it manually before dropping the slices in the inbox, but that was a month ago.)
Maybe for a complex change like that we should sync off list⦠the normal machinery is good for normal stuff, everything else needs exceptional work. (e.g. we could load changesets, could be simpler than using monticello) Marcus
On 09/22/2014 09:50 AM, Marcus Denker wrote:
On 22 Sep 2014, at 17:05, Martin McClure <martin@hand2mouse.com> wrote:
This fix required multiple slices since loading things in the wrong order broke exceptions badly enough to hang the system. I packaged things in five slices. (It's possible that if Monticello was smart enough I could have done it in less than five, but it did need more than one).
The automatic test runner seems to only load the first of the five slices. Therefore two exception tests fail, which is expected. All exception tests should pass after all five slices are loaded in order.
Is there a way to tell the automatic test runner to load all five, or does this one require manual testing? (I did test it manually before dropping the slices in the inbox, but that was a month ago.)
Maybe for a complex change like that we should sync off list⦠the normal machinery is good for normal stuff, everything else needs exceptional work. (e.g. we could load changesets, could be simpler than using monticello)
OK, let me know how you want to proceed. If you load the five slices from the inbox, in sequence, you do get something that works better as far as I can tell. And has additional test methods. Regards, -Martin
On 23 Sep 2014, at 00:50, Martin McClure <martin@hand2mouse.com> wrote:
On 09/22/2014 09:50 AM, Marcus Denker wrote:
On 22 Sep 2014, at 17:05, Martin McClure <martin@hand2mouse.com> wrote:
This fix required multiple slices since loading things in the wrong order broke exceptions badly enough to hang the system. I packaged things in five slices. (It's possible that if Monticello was smart enough I could have done it in less than five, but it did need more than one).
The automatic test runner seems to only load the first of the five slices. Therefore two exception tests fail, which is expected. All exception tests should pass after all five slices are loaded in order.
Is there a way to tell the automatic test runner to load all five, or does this one require manual testing? (I did test it manually before dropping the slices in the inbox, but that was a month ago.)
Maybe for a complex change like that we should sync off list⦠the normal machinery is good for normal stuff, everything else needs exceptional work. (e.g. we could load changesets, could be simpler than using monticello)
OK, let me know how you want to proceed. If you load the five slices from the inbox, in sequence
Looks good! Last time I merged I got strange conflicts, but now everything looks fine. I will integrate all this with 5 updates later today. Thanks! Marcus
On 23 Sep 2014, at 09:32, Marcus Denker <marcus.denker@inria.fr> wrote:
On 23 Sep 2014, at 00:50, Martin McClure <martin@hand2mouse.com> wrote:
On 09/22/2014 09:50 AM, Marcus Denker wrote:
On 22 Sep 2014, at 17:05, Martin McClure <martin@hand2mouse.com> wrote:
This fix required multiple slices since loading things in the wrong order broke exceptions badly enough to hang the system. I packaged things in five slices. (It's possible that if Monticello was smart enough I could have done it in less than five, but it did need more than one).
The automatic test runner seems to only load the first of the five slices. Therefore two exception tests fail, which is expected. All exception tests should pass after all five slices are loaded in order.
Is there a way to tell the automatic test runner to load all five, or does this one require manual testing? (I did test it manually before dropping the slices in the inbox, but that was a month ago.)
Maybe for a complex change like that we should sync off list⦠the normal machinery is good for normal stuff, everything else needs exceptional work. (e.g. we could load changesets, could be simpler than using monticello)
OK, let me know how you want to proceed. If you load the five slices from the inbox, in sequence
Looks good! Last time I merged I got strange conflicts, but now everything looks fine.
I will integrate all this with 5 updates later today.
All are in 20243-40246 Marcus
participants (5)
-
Ben Coman -
Esteban Lorenzano -
Marcus Denker -
Martin McClure -
Max Leske