[Pharo-project] NB squeaksource comits
Hi Igor, sorry for bothering you again with this issue but again somebody (squeaksource ;)) removed me from the commiters of the NB project. Now I have two proposals, a very small one: removing the asm int3, and decrementing the callback counter in #generateCallbackLeaveCodeFor:leaveAddr: so that the vm does not crash on callback error case. Secondly, I have converged to an implementation of NBExternalEnum (using SharedPool) which I think it is cool, and I wanted to share it with you. Maybe you like it... maybe you don't ... ;) Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
On 11 December 2012 00:14, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
Hi Igor,
sorry for bothering you again with this issue but again somebody (squeaksource ;)) removed me from the commiters of the NB project.
added again :)
Now I have two proposals, a very small one: removing the asm int3, and decrementing the callback counter in #generateCallbackLeaveCodeFor:leaveAddr: so that the vm does not crash on callback error case.
no, it should not decrement counter in error case, because you are not leaved from callback. you should always return from callback, otherwise its call will be held on stack.
Secondly, I have converged to an implementation of NBExternalEnum (using SharedPool) which I think it is cool, and I wanted to share it with you. Maybe you like it... maybe you don't ... ;)
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
On Dec 11, 2012 4:55 AM, "Igor Stasenko" <siguctua@gmail.com> wrote:
On 11 December 2012 00:14, Ciprian Teodorov <ciprian.teodorov@gmail.com>
wrote:
Hi Igor,
sorry for bothering you again with this issue but again somebody (squeaksource ;)) removed me from the commiters of the NB project.
added again :) Thanks
Now I have two proposals, a very small one: removing the asm int3, and decrementing the callback counter in #generateCallbackLeaveCodeFor:leaveAddr: so that the vm does not crash on callback error case.
no, it should not decrement counter in error case, because you are not leaved from callback. you should always return from callback, otherwise its call will be held on stack. The I guess that we should be able to continue executing after primitive fail. On my machine VM crashes if I click proceed. It doesn't crash if I abort though... But when aborting the counter is not decremented... What shall we do then? Is there any way to gracefully exit to vm, leaving a proper state?
Secondly, I have converged to an implementation of NBExternalEnum (using SharedPool) which I think it is cool, and I wanted to share it with you. Maybe you like it... maybe you don't ... ;)
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
On 11 December 2012 11:58, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
On Dec 11, 2012 4:55 AM, "Igor Stasenko" <siguctua@gmail.com> wrote:
On 11 December 2012 00:14, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
Hi Igor,
sorry for bothering you again with this issue but again somebody (squeaksource ;)) removed me from the commiters of the NB project.
added again :)
Thanks
Now I have two proposals, a very small one: removing the asm int3, and decrementing the callback counter in #generateCallbackLeaveCodeFor:leaveAddr: so that the vm does not crash on callback error case.
no, it should not decrement counter in error case, because you are not leaved from callback. you should always return from callback, otherwise its call will be held on stack.
The I guess that we should be able to continue executing after primitive fail. On my machine VM crashes if I click proceed. It doesn't crash if I abort though... But when aborting the counter is not decremented... What shall we do then? Is there any way to gracefully exit to vm, leaving a proper state?
The only graceful way is to pass the correct return value, so callback will return to caller. If you have an error there, there's little choice.. either user should manually enter the valid value, or quit :) aborting the process with callback is not a good way too.. because you aborting smalltalk process which handling callback, but it is still there, on stack.. So will it make you happy having callback counter decremented, but in fact having not returned from callback? :) -- Best regards, Igor Stasenko.
participants (2)
-
Ciprian Teodorov -
Igor Stasenko