On Wed, Sep 30, 2009 at 12:38:06PM -0400, David T. Lewis wrote:
On Wed, Sep 30, 2009 at 12:07:26PM +0200, Bert Freudenberg wrote:
On 30.09.2009, at 05:14, Yoshiki Ohshima wrote:
At Wed, 30 Sep 2009 15:49:00 +1300, Simon Guest wrote:
Hi EToy-dev people,
I've found an annoying bug introduced in Etoys 4.0 dev somewhere between update 2192 and 2325, which causes control-C to give a hard lockup.
I reported it on the bug tracker, http://tracker.squeakland.org/browse/SQ-484
Is that enough? Or should I also raise it here? (Like this ;-)
Any ideas on the bug?
The hard lock up part I'm not sure what is causing it, but one thing you could do for now is update the image and then turn off #automaticPlatformSettings (and swapControlAndAltKeys) preferences to use the Alt- key bindings...
No, the hard lockup was caused by an endless recursion. ExtendedClipboardUnixInterface unexpectedly dispatched back to Clipboard which dispatched back etc. The Mac interface does not do such sillyness ;) I'll fix it shortly.
Now, in any case that *should* not cause a hard lockup but for some reason on the Linux VM it still did not react to Alt-. to break into the loop.
Ian, any idea? I have seen this before, but never took time to investigate. Actually I think it did happen on John's VM too but again, I'm not certain.
There was a fix for this sort of problem in Mantis 1041. The patch went into Squeak 3.9, and I am not sure if it has been incorporated into the Etoys image or not. Unfortunately I cannot look into it right now, but will check later.
To follow up on the above, I took a look at an Etoys-dev image, and I am fairly sure that Mantis 1041 is the cause of this problem. The necessary changes are in the VM, and are in Squeak 3.9 and beyond, but are not in Etoys. Unfortunately, just loading the old change set from Mantis did not fix it, so maybe there is some bit rot or other inconsistency that I'm not spotting at the moment.
Dave
On 01.10.2009, at 02:50, David T. Lewis wrote:
On Wed, Sep 30, 2009 at 12:38:06PM -0400, David T. Lewis wrote:
On Wed, Sep 30, 2009 at 12:07:26PM +0200, Bert Freudenberg wrote:
On 30.09.2009, at 05:14, Yoshiki Ohshima wrote:
At Wed, 30 Sep 2009 15:49:00 +1300, Simon Guest wrote:
Hi EToy-dev people,
I've found an annoying bug introduced in Etoys 4.0 dev somewhere between update 2192 and 2325, which causes control-C to give a hard lockup.
I reported it on the bug tracker, http://tracker.squeakland.org/browse/SQ-484
Is that enough? Or should I also raise it here? (Like this ;-)
Any ideas on the bug?
The hard lock up part I'm not sure what is causing it, but one thing you could do for now is update the image and then turn off #automaticPlatformSettings (and swapControlAndAltKeys) preferences to use the Alt- key bindings...
No, the hard lockup was caused by an endless recursion. ExtendedClipboardUnixInterface unexpectedly dispatched back to Clipboard which dispatched back etc. The Mac interface does not do such sillyness ;) I'll fix it shortly.
Now, in any case that *should* not cause a hard lockup but for some reason on the Linux VM it still did not react to Alt-. to break into the loop.
Ian, any idea? I have seen this before, but never took time to investigate. Actually I think it did happen on John's VM too but again, I'm not certain.
There was a fix for this sort of problem in Mantis 1041. The patch went into Squeak 3.9, and I am not sure if it has been incorporated into the Etoys image or not. Unfortunately I cannot look into it right now, but will check later.
To follow up on the above, I took a look at an Etoys-dev image, and I am fairly sure that Mantis 1041 is the cause of this problem. The necessary changes are in the VM, and are in Squeak 3.9 and beyond, but are not in Etoys. Unfortunately, just loading the old change set from Mantis did not fix it, so maybe there is some bit rot or other inconsistency that I'm not spotting at the moment.
Dave
Thanks, David. I opened a ticket for that:
http://tracker.squeakland.org/browse/SQ-489
If anybody could adapt the changeset for current Etoys, that would be awesome!
- Bert -
On Thu, Oct 01, 2009 at 09:53:55PM +0200, Bert Freudenberg wrote:
On 01.10.2009, at 02:50, David T. Lewis wrote:
There was a fix for this sort of problem in Mantis 1041. The patch went into Squeak 3.9, and I am not sure if it has been incorporated into the Etoys image or not. Unfortunately I cannot look into it right now, but will check later.
To follow up on the above, I took a look at an Etoys-dev image, and I am fairly sure that Mantis 1041 is the cause of this problem. The necessary changes are in the VM, and are in Squeak 3.9 and beyond, but are not in Etoys. Unfortunately, just loading the old change set from Mantis did not fix it, so maybe there is some bit rot or other inconsistency that I'm not spotting at the moment.
Thanks, David. I opened a ticket for that:
http://tracker.squeakland.org/browse/SQ-489
If anybody could adapt the changeset for current Etoys, that would be awesome!
Bert,
I am attaching LowSpaceAndInterruptHandler-4Etoys-M1041-dtl.cs, which is an update to the patch from Mantis 1041 with the latest version of each method from the Squeak trunk. If you apply this to the Etoys image, it will address the M1041 issue, which permits the following four tests to be interrupted correctly with alt-period:
"[true] whileTrue" "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1" "Smalltalk createStackOverflow" "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1"
The Etoys image seems to be slower to react to an alt-period (and I think also that the Unix VM reacts more slowly than others). I suspect that there are some additional changes in process scheduling that will improve this, and hopefully as we can get under way with bringing Etoys and Squeak in sync, the improvements well be picked up along the way.
When you apply LowSpaceAndInterruptHandler-4Etoys-M1041-dtl.cs, I would suggest first applying the original LowSpaceAndInterruptHandler-3-dtl.1.cs from Mantis (also attached) and then applying LowSpaceAndInterruptHandler-4Etoys-M1041-dtl.cs afterwards. That will make the change history more clear, and also make it possible to back out the latest Squeak trunk version in case there are some issues or interactions I'm not aware of.
Dave
etoys-dev@lists.squeakfoundation.org