Should I be able to hang my pharo 1.1 image so easily?

> Hi guys - it seems really easy to hang my seaside image and then have to force quit and restart. I thought that cmd-. was supposed to recover, but it never seems to work for me.
>
> Am I doing something wrong? (I am using a pharo 1.1 seaside3.0rc3 image with the mac 4.2.5 vm).
>
> I had the following code:
>
> modelUpdate
>    self pusher javascript: [ :jsScript |
>        jsScript << (self generateUpdateScriptWith: jsScript) ]
>
>
> generateUpdateScriptWith: jsScript
>
>    ^aJScript goto: anActionUrl withoutQuery
>
>
> I think that the << operator is adding something that has already been added via aJScript goto: - and so its recursive.
>
> Anyway - when I hit this with my browser - the cpu of my Pharo image goes to 99% and I can hit Cmd-. all I want, but eventually it just dies - or I have to do a force quit.
>
> Should it be so easy to kill an image like this?
>
> Tim

> I think I have the same problem. It does not actually jam the image
> right away but makes it really slow which renders it unusable. After a
> while memory runs out and it crashes. Have not seen this many times
> thou. It would help if there was a key sequence which would suspend
> other than UI process.
>
> --
> Panu
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> thanks for reporting that.
> do you have a case that we could reproduce or have an image people could access?
>
> Stef
>
> On Aug 17, 2010, at 8:30 PM, Panu Suominen wrote:
>
>> I think I have the same problem. It does not actually jam the image
>> right away but makes it really slow which renders it unusable. After a
>> while memory runs out and it crashes. Have not seen this many times
>> thou. It would help if there was a key sequence which would suspend
>> other than UI process.
>>
>> --
>> Panu
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> On Aug 17, 2010, at 3:38 20PM, TimM wrote:
>
>> Henrik Johansen wrote:
>>
>>> Is this code run in a separate process?
>>> UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles.
>>> Whether that is desired behaviour or not, is up for discussion :)
>>
>> I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed.
>>
>> Tim
> There's only one UI Process (tm) in Pharo/Squeak, responsible for updating the UI, running doits, etc.
>
> Not quite sure how Seaside does its magic when requests are coming in, but if it forks of their processing with priority >= UIProcess priority, it will indeed "hose" the image with no means of recovering using Cmd-dot in the case of an infinite loop.
>
> Try the following from a workspace to illustrate:
>
> "Interruptable with Cmd-dot"
> [true ] whileTrue.
>
> "Forking at lower than UI process, so UI stays responsive, but does not interrupt runaway process with Cmd-dot (you can terminate it using process browser)"
> [[true ] whileTrue] forkAt: Processor activePriority - 1    "Code run from a workspace will run in the UI process, so active priority will be the UI process priority"
>
> "Forking at same as UI process, Cmd-dot interrups UI process rather than runaway, but debugger is (almost) never displayed since runaway process takes almost all cycles"
> [[true] whileTrue] fork    "Fork forks of the process at same priority as active process"
>
>
> Cheers,
> Henry
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> I think I have the same problem. It does not actually jam the image
> right away but makes it really slow which renders it unusable. After a
> while memory runs out and it crashes. Have not seen this many times
> thou. It would help if there was a key sequence which would suspend
> other than UI process.
>
> --
> Panu
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Lukas Renggli
> Sent: Tuesday, August 17, 2010 4:53 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?
>
> On 17 August 2010 23:36, Schwab,Wilhelm K <[hidden email]> wrote:
>> Hello all,
>>
>> The answer in general is "no."  The only caveat with Seaside code is that (I gues due to continuations??), it is possible to make simple mistakes with harsh consequences.  My early attempts at Seaside programming were not pretty; with two books now available, it should be easier to start out knowing not to render in callbacks and vice versa.
>>
>> Is the Seaside code in this case poorly-behaved?
>
> Seaside doesn't use continuations anymore, unless you have a WATask.
>
> Continuations do not affect the interrupt behavior.
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> Bill
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Lukas Renggli
> Sent: Tuesday, August 17, 2010 4:53 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?
>
> On 17 August 2010 23:36, Schwab,Wilhelm K <[hidden email]> wrote:
>> Hello all,
>>
>> The answer in general is "no."  The only caveat with Seaside code is that (I gues due to continuations??), it is possible to make simple mistakes with harsh consequences.  My early attempts at Seaside programming were not pretty; with two books now available, it should be easier to start out knowing not to render in callbacks and vice versa.
>>
>> Is the Seaside code in this case poorly-behaved?
>
> Seaside doesn't use continuations anymore, unless you have a WATask.
>
> Continuations do not affect the interrupt behavior.
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
>
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Lukas Renggli
> Sent: Tuesday, August 17, 2010 5:11 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?
>
> On 18 August 2010 00:06, Schwab,Wilhelm K <[hidden email]> wrote:
>> Lukas,
>>
>> Interesting!  How do I get rid of my tasks then, traits??
>
> Uhh? That has nothing to do with traits.
>
> http://book.seaside.st/book/components/calling/show-answer
>
> Lukas
>
>
>
>>
>> Bill
>>
>>
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Lukas Renggli
>> Sent: Tuesday, August 17, 2010 4:53 PM
>> To: [hidden email]
>> Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?
>>
>> On 17 August 2010 23:36, Schwab,Wilhelm K <[hidden email]> wrote:
>>> Hello all,
>>>
>>> The answer in general is "no."  The only caveat with Seaside code is that (I gues due to continuations??), it is possible to make simple mistakes with harsh consequences.  My early attempts at Seaside programming were not pretty; with two books now available, it should be easier to start out knowing not to render in callbacks and vice versa.
>>>
>>> Is the Seaside code in this case poorly-behaved?
>>
>> Seaside doesn't use continuations anymore, unless you have a WATask.
>>
>> Continuations do not affect the interrupt behavior.
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Lukas Renggli
> Sent: Tuesday, August 17, 2010 5:11 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?
>
> On 18 August 2010 00:06, Schwab,Wilhelm K <[hidden email]> wrote:
>> Lukas,
>>
>> Interesting!  How do I get rid of my tasks then, traits??
>
> Uhh? That has nothing to do with traits.
>
> http://book.seaside.st/book/components/calling/show-answer
>
> Lukas
>
>
>
>>
>> Bill
>>
>>
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> Lukas Renggli
>> Sent: Tuesday, August 17, 2010 4:53 PM
>> To: [hidden email]
>> Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?
>>
>> On 17 August 2010 23:36, Schwab,Wilhelm K <[hidden email]> wrote:
>>> Hello all,
>>>
>>> The answer in general is "no."  The only caveat with Seaside code is that (I gues due to continuations??), it is possible to make simple mistakes with harsh consequences.  My early attempts at Seaside programming were not pretty; with two books now available, it should be easier to start out knowing not to render in callbacks and vice versa.
>>>
>>> Is the Seaside code in this case poorly-behaved?
>>
>> Seaside doesn't use continuations anymore, unless you have a WATask.
>>
>> Continuations do not affect the interrupt behavior.
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> I heard about that problem too...
>
> In Squeak 3.9 I can interrupt [[true] whileTrue] fork, but not in Pharo.
>
> Has anybody an idea why this doesn't work anymore?
>
> Adrian
>
> On Aug 17, 2010, at 16:27 , Henrik Johansen wrote:
>
> >
> > On Aug 17, 2010, at 3:38 20PM, TimM wrote:
> >
> >> Henrik Johansen wrote:
> >>
> >>> Is this code run in a separate process?
> >>> UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles.
> >>> Whether that is desired behaviour or not, is up for discussion :)
> >>
> >> I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed.
> >>
> >> Tim
> > There's only one UI Process (tm) in Pharo/Squeak, responsible for updating the UI, running doits, etc.
> >
> > Not quite sure how Seaside does its magic when requests are coming in, but if it forks of their processing with priority >= UIProcess priority, it will indeed "hose" the image with no means of recovering using Cmd-dot in the case of an infinite loop.
> >
> > Try the following from a workspace to illustrate:
> >
> > "Interruptable with Cmd-dot"
> > [true ] whileTrue.
> >
> > "Forking at lower than UI process, so UI stays responsive, but does not interrupt runaway process with Cmd-dot (you can terminate it using process browser)"
> > [[true ] whileTrue] forkAt: Processor activePriority - 1    "Code run from a workspace will run in the UI process, so active priority will be the UI process priority"
> >
> > "Forking at same as UI process, Cmd-dot interrups UI process rather than runaway, but debugger is (almost) never displayed since runaway process takes almost all cycles"
> > [[true] whileTrue] fork    "Fork forks of the process at same priority as active process"
> >
> >
> > Cheers,
> > Henry
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Probably completely off the mark but just in case it jogs someone's
> memory, the fixes for this issue that went into  Squeak 3.9 were
> tracked on Mantis here:
>
>  http://bugs.squeak.org/view.php?id=1041
>
> Possibly one of the patches got undone by accident?
>
> HTH,
> Dave
>
>
> On Tue, Aug 17, 2010 at 10:28:31PM +0200, Adrian Lienhard wrote:
>> I heard about that problem too...
>>
>> In Squeak 3.9 I can interrupt [[true] whileTrue] fork, but not in Pharo.
>>
>> Has anybody an idea why this doesn't work anymore?
>>
>> Adrian
>>
>> On Aug 17, 2010, at 16:27 , Henrik Johansen wrote:
>>
>>>
>>> On Aug 17, 2010, at 3:38 20PM, TimM wrote:
>>>
>>>> Henrik Johansen wrote:
>>>>
>>>>> Is this code run in a separate process?
>>>>> UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles.
>>>>> Whether that is desired behaviour or not, is up for discussion :)
>>>>
>>>> I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed.
>>>>
>>>> Tim
>>> There's only one UI Process (tm) in Pharo/Squeak, responsible for updating the UI, running doits, etc.
>>>
>>> Not quite sure how Seaside does its magic when requests are coming in, but if it forks of their processing with priority >= UIProcess priority, it will indeed "hose" the image with no means of recovering using Cmd-dot in the case of an infinite loop.
>>>
>>> Try the following from a workspace to illustrate:
>>>
>>> "Interruptable with Cmd-dot"
>>> [true ] whileTrue.
>>>
>>> "Forking at lower than UI process, so UI stays responsive, but does not interrupt runaway process with Cmd-dot (you can terminate it using process browser)"
>>> [[true ] whileTrue] forkAt: Processor activePriority - 1    "Code run from a workspace will run in the UI process, so active priority will be the UI process priority"
>>>
>>> "Forking at same as UI process, Cmd-dot interrups UI process rather than runaway, but debugger is (almost) never displayed since runaway process takes almost all cycles"
>>> [[true] whileTrue] fork    "Fork forks of the process at same priority as active process"
>>>
>>>
>>> Cheers,
>>> Henry
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> thanks david for the pointer.
> Yes we should investigate that again.
>
>
> On Aug 18, 2010, at 3:20 AM, David T. Lewis wrote:
>
>> Probably completely off the mark but just in case it jogs someone's
>> memory, the fixes for this issue that went into  Squeak 3.9 were
>> tracked on Mantis here:
>>
>> http://bugs.squeak.org/view.php?id=1041
>>
>> Possibly one of the patches got undone by accident?
>>
>> HTH,
>> Dave
>>
>>
>> On Tue, Aug 17, 2010 at 10:28:31PM +0200, Adrian Lienhard wrote:
>>> I heard about that problem too...
>>>
>>> In Squeak 3.9 I can interrupt [[true] whileTrue] fork, but not in Pharo.
>>>
>>> Has anybody an idea why this doesn't work anymore?
>>>
>>> Adrian
>>>
>>> On Aug 17, 2010, at 16:27 , Henrik Johansen wrote:
>>>
>>>>
>>>> On Aug 17, 2010, at 3:38 20PM, TimM wrote:
>>>>
>>>>> Henrik Johansen wrote:
>>>>>
>>>>>> Is this code run in a separate process?
>>>>>> UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles.
>>>>>> Whether that is desired behaviour or not, is up for discussion :)
>>>>>
>>>>> I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed.
>>>>>
>>>>> Tim
>>>> There's only one UI Process (tm) in Pharo/Squeak, responsible for updating the UI, running doits, etc.
>>>>
>>>> Not quite sure how Seaside does its magic when requests are coming in, but if it forks of their processing with priority >= UIProcess priority, it will indeed "hose" the image with no means of recovering using Cmd-dot in the case of an infinite loop.
>>>>
>>>> Try the following from a workspace to illustrate:
>>>>
>>>> "Interruptable with Cmd-dot"
>>>> [true ] whileTrue.
>>>>
>>>> "Forking at lower than UI process, so UI stays responsive, but does not interrupt runaway process with Cmd-dot (you can terminate it using process browser)"
>>>> [[true ] whileTrue] forkAt: Processor activePriority - 1    "Code run from a workspace will run in the UI process, so active priority will be the UI process priority"
>>>>
>>>> "Forking at same as UI process, Cmd-dot interrups UI process rather than runaway, but debugger is (almost) never displayed since runaway process takes almost all cycles"
>>>> [[true] whileTrue] fork    "Fork forks of the process at same priority as active process"
>>>>
>>>>
>>>> Cheers,
>>>> Henry
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> I've submitted a slice to inbox, which contains a proposed fix.
> Details in the issue (2825) for those interested.
>
> Cheers,
> Henry
>
> On Aug 18, 2010, at 9:25 52AM, Stéphane Ducasse wrote:
>
>> thanks david for the pointer.
>> Yes we should investigate that again.
>>
>>
>> On Aug 18, 2010, at 3:20 AM, David T. Lewis wrote:
>>
>>> Probably completely off the mark but just in case it jogs someone's
>>> memory, the fixes for this issue that went into  Squeak 3.9 were
>>> tracked on Mantis here:
>>>
>>> http://bugs.squeak.org/view.php?id=1041
>>>
>>> Possibly one of the patches got undone by accident?
>>>
>>> HTH,
>>> Dave
>>>
>>>
>>> On Tue, Aug 17, 2010 at 10:28:31PM +0200, Adrian Lienhard wrote:
>>>> I heard about that problem too...
>>>>
>>>> In Squeak 3.9 I can interrupt [[true] whileTrue] fork, but not in Pharo.
>>>>
>>>> Has anybody an idea why this doesn't work anymore?
>>>>
>>>> Adrian
>>>>
>>>> On Aug 17, 2010, at 16:27 , Henrik Johansen wrote:
>>>>
>>>>>
>>>>> On Aug 17, 2010, at 3:38 20PM, TimM wrote:
>>>>>
>>>>>> Henrik Johansen wrote:
>>>>>>
>>>>>>> Is this code run in a separate process?
>>>>>>> UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles.
>>>>>>> Whether that is desired behaviour or not, is up for discussion :)
>>>>>>
>>>>>> I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed.
>>>>>>
>>>>>> Tim
>>>>> There's only one UI Process (tm) in Pharo/Squeak, responsible for updating the UI, running doits, etc.
>>>>>
>>>>> Not quite sure how Seaside does its magic when requests are coming in, but if it forks of their processing with priority >= UIProcess priority, it will indeed "hose" the image with no means of recovering using Cmd-dot in the case of an infinite loop.
>>>>>
>>>>> Try the following from a workspace to illustrate:
>>>>>
>>>>> "Interruptable with Cmd-dot"
>>>>> [true ] whileTrue.
>>>>>
>>>>> "Forking at lower than UI process, so UI stays responsive, but does not interrupt runaway process with Cmd-dot (you can terminate it using process browser)"
>>>>> [[true ] whileTrue] forkAt: Processor activePriority - 1    "Code run from a workspace will run in the UI process, so active priority will be the UI process priority"
>>>>>
>>>>> "Forking at same as UI process, Cmd-dot interrups UI process rather than runaway, but debugger is (almost) never displayed since runaway process takes almost all cycles"
>>>>> [[true] whileTrue] fork    "Fork forks of the process at same priority as active process"
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Henry
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project