the mooc is a mine for Pharo bugs... In the video at 6:12, we have a new method sending the new message. I've made similar mistakes and Pharo does lock up, but then the operating system (Windows 10) kills the Pharo VM. (Or perhaps there's a bug in Pharo itself which just crashes the whole VM. I can't tell the difference.) Is that because it's a memory leak? Does the VM have a fixed amount of memory available, or can it request more from the OS? Is there a way to recover from this error without killing the whole VM? Most GUI systems I've used have at least two threads so that pushing a button doesn't lock up the whole UI if the task takes a while. Does Pharo always lock up for long-running tasks, or does it have some kind of threading ability too? If a background thread gets in an infinite loop, how do you kill it without killing the whole VM? here was my answer The real answer is a bit more complex so I may write some approximations: - what you did a really tight loops that fills up the memory really fast. - depending on the OS the VM can or not (in its current state) allocate more. In some versions it has to preallocate. "Most GUI systems I've used have at least two threads so that pushing a button doesn't lock up the whole UI if the task takes a while. Does Pharo always lock up for long-running tasks, or does it have some kind of threading ability too? If a background thread gets in an infinite loop, how do you kill it without killing the whole VM?" Pharo has a full model for concurrent programming. Check the class Process, Semaphore. We have some stress tests that create thousands of threads without problems. You have also package such TaskIt to schedule tasks Now the actual problem that you see and that I would love to see fix in the future is that the code you execute is run in the UI thread (arghhhhh) It is still like that for historical reason. We should do one pass on that but this is not that simple because it will raise a couple of bugs. Now I think that it would be great if people from the pharo core would browse in diagonal the problems that students encounter because there are our real customers and they show many problems of the system. Especially the ones we do not see anymore.
Regarding the first part of your email, about UI lockups, it is almost unavoidable, because in Pharo almost everything happens in the main thread, as you pointed out. When only UI events should happen there, and have background processes/async tasks for computation and I/O that updates the UI by means of some sort of message channel between the process and the UI. This isn't a "feature" of Pharo only, other Smalltalks[1] have the same "design" (or lack thereof) regarding what it is done in the main/UI thread. I can't imagine a plan for changing that in the current tools, I think it would require a major overhaul. OTOH newer tools like Spotter seems to use background threads to do its stuff, so the shift might have already begun. Regards, Esteban A. Maringolo [1] VisualAge came with an separate OS process that could halt the vm at a very low level when it was stuck in a tight loop. ST/X has a process/message queue per os window, which allows you to kill one window without taking down the whole image/vm. 2016-06-03 2:56 GMT-03:00 stepharo <stepharo@free.fr>:
the mooc is a mine for Pharo bugs...
In the video at 6:12, we have a new method sending the new message. I've made similar mistakes and Pharo does lock up, but then the operating system (Windows 10) kills the Pharo VM. (Or perhaps there's a bug in Pharo itself which just crashes the whole VM. I can't tell the difference.) Is that because it's a memory leak? Does the VM have a fixed amount of memory available, or can it request more from the OS? Is there a way to recover from this error without killing the whole VM? Most GUI systems I've used have at least two threads so that pushing a button doesn't lock up the whole UI if the task takes a while. Does Pharo always lock up for long-running tasks, or does it have some kind of threading ability too? If a background thread gets in an infinite loop, how do you kill it without killing the whole VM?
here was my answer
The real answer is a bit more complex so I may write some approximations: - what you did a really tight loops that fills up the memory really fast. - depending on the OS the VM can or not (in its current state) allocate more. In some versions it has to preallocate. "Most GUI systems I've used have at least two threads so that pushing a button doesn't lock up the whole UI if the task takes a while. Does Pharo always lock up for long-running tasks, or does it have some kind of threading ability too? If a background thread gets in an infinite loop, how do you kill it without killing the whole VM?" Pharo has a full model for concurrent programming. Check the class Process, Semaphore. We have some stress tests that create thousands of threads without problems. You have also package such TaskIt to schedule tasks Now the actual problem that you see and that I would love to see fix in the future is that the code you execute is run in the UI thread (arghhhhh) It is still like that for historical reason. We should do one pass on that but this is not that simple because it will raise a couple of bugs.
Now I think that it would be great if people from the pharo core would browse in diagonal the problems that students
encounter because there are our real customers and they show many problems of the system. Especially the ones we do not see anymore.
Le 3/6/16 à 19:16, Esteban A. Maringolo a écrit :
Regarding the first part of your email, about UI lockups, it is almost unavoidable, because in Pharo almost everything happens in the main thread, as you pointed out. Yes. This is all my point.
When only UI events should happen there, and have background processes/async tasks for computation and I/O that updates the UI by means of some sort of message channel between the process and the UI.
This isn't a "feature" of Pharo only, other Smalltalks[1] have the same "design" (or lack thereof) regarding what it is done in the main/UI thread. :)
I can't imagine a plan for changing that in the current tools, I think it would require a major overhaul. I would like to see this point addressed. It would be good to have less addition in Pharo before such point gets addressed.
OTOH newer tools like Spotter seems to use background threads to do its stuff, so the shift might have already begun.
Regards,
Esteban A. Maringolo
[1] VisualAge came with an separate OS process that could halt the vm at a very low level when it was stuck in a tight loop. ST/X has a process/message queue per os window, which allows you to kill one window without taking down the whole image/vm. Yes in VW it is the same.
2016-06-03 2:56 GMT-03:00 stepharo <stepharo@free.fr>:
the mooc is a mine for Pharo bugs...
In the video at 6:12, we have a new method sending the new message. I've made similar mistakes and Pharo does lock up, but then the operating system (Windows 10) kills the Pharo VM. (Or perhaps there's a bug in Pharo itself which just crashes the whole VM. I can't tell the difference.) Is that because it's a memory leak? Does the VM have a fixed amount of memory available, or can it request more from the OS? Is there a way to recover from this error without killing the whole VM? Most GUI systems I've used have at least two threads so that pushing a button doesn't lock up the whole UI if the task takes a while. Does Pharo always lock up for long-running tasks, or does it have some kind of threading ability too? If a background thread gets in an infinite loop, how do you kill it without killing the whole VM?
here was my answer
The real answer is a bit more complex so I may write some approximations: - what you did a really tight loops that fills up the memory really fast. - depending on the OS the VM can or not (in its current state) allocate more. In some versions it has to preallocate. "Most GUI systems I've used have at least two threads so that pushing a button doesn't lock up the whole UI if the task takes a while. Does Pharo always lock up for long-running tasks, or does it have some kind of threading ability too? If a background thread gets in an infinite loop, how do you kill it without killing the whole VM?" Pharo has a full model for concurrent programming. Check the class Process, Semaphore. We have some stress tests that create thousands of threads without problems. You have also package such TaskIt to schedule tasks Now the actual problem that you see and that I would love to see fix in the future is that the code you execute is run in the UI thread (arghhhhh) It is still like that for historical reason. We should do one pass on that but this is not that simple because it will raise a couple of bugs.
Now I think that it would be great if people from the pharo core would browse in diagonal the problems that students
encounter because there are our real customers and they show many problems of the system. Especially the ones we do not see anymore.
On 04 Jun 2016, at 9:13 , stepharo <stepharo@free.fr> wrote:
Le 3/6/16 à 19:16, Esteban A. Maringolo a écrit :
Regarding the first part of your email, about UI lockups, it is almost unavoidable, because in Pharo almost everything happens in the main thread, as you pointed out. Yes. This is all my point.
IMHO, all Pharo beginner tutorials should start by showing off Cmd - dot (or Alt - dot, on Win / Linux). Not just because it's cool, but because it's necessary :) Cheers, Henry
On 08 Jun 2016, at 10:40, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 04 Jun 2016, at 9:13 , stepharo <stepharo@free.fr> wrote:
Le 3/6/16 à 19:16, Esteban A. Maringolo a écrit :
Regarding the first part of your email, about UI lockups, it is almost unavoidable, because in Pharo almost everything happens in the main thread, as you pointed out. Yes. This is all my point.
IMHO, all Pharo beginner tutorials should start by showing off Cmd - dot (or Alt - dot, on Win / Linux).
Not just because it's cool, but because it's necessary :)
Cheers, Henry
Very true. Yet, and I have already mentioned this years ago, it is technically totally possible to properly detect massive stack growth, before things get out of control. Sadly, VM people think this is not needed (or too costly). Consider the following in Common Lisp (LispWorks): CL-USER 1 > (defun fac (n) (if (< n 2) 1 (* n (fac (1- n))))) FAC CL-USER 2 > (fac 5) 120 CL-USER 3 > (fac 100) 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 CL-USER 4 > (fac 400) Stack overflow (stack size 31744). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 5 : 1 > :c 1 Stack overflow (stack size 48128). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 6 : 1 > :c 1 64034522846623895262347970319503005850702583026002959458684445942802397169186831436278478647463264676294350575035856810848298162883517435228961988646802997937341654150838162426461942352307046244325015114448670890662773914918117331955996440709549671345290477020322434911210797593280795101545372667251627877890009349763765710326350331533965349868386831339352024373788157786791506311858702618270169819740062983025308591298346162272304558339520759611505302236086810433297255194852674432232438669948422404232599805551610635942376961399231917134063858996537970147827206606320217379472010321356624613809077942304597360699567595836096158715129913822286578579549361617654480453222007825818400848436415591229454275384803558374518022675900061399560145595206127211192918105032491008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 CL-USER 7 > (defun infinite () (cons 'a (infinite))) INFINIT CL-USER 8 > (infinite) Stack overflow (stack size 80896). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options. CL-USER 9 : 1 > :a CL-USER 10 > Just having an upper limit to the stack catches 99% of infinite loops - that would be nice to have. This has existed for 10s of years AFAIK. Sven PS: Of course, the stack size can be set larger to begin with, if necessary. I believe it is even per execution thread.
IMHO, all Pharo beginner tutorials should start by showing off Cmd - dot (or Alt - dot, on Win / Linux).
Not just because it's cool, but because it's necessary :)
Cheers, Henry
Very true.
Yet, and I have already mentioned this years ago, it is technically totally possible to properly detect massive stack growth, before things get out of control. Sadly, VM people think this is not needed (or too costly).
Not entirely true :-) There are smalltalks out there that detect such stack growth and do the same as CL, throw a (resumable) exception. Super-handy. Some of them have this for at least 10 years now :-) And, it could be done with virtually no costs at all - hardware check for this anyway. Jan
On 08 Jun 2016, at 11:24, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
IMHO, all Pharo beginner tutorials should start by showing off Cmd - dot (or Alt - dot, on Win / Linux).
Not just because it's cool, but because it's necessary :)
Cheers, Henry
Very true.
Yet, and I have already mentioned this years ago, it is technically totally possible to properly detect massive stack growth, before things get out of control. Sadly, VM people think this is not needed (or too costly).
Not entirely true :-) There are smalltalks out there that detect such stack growth and do the same as CL, throw a (resumable) exception. Super-handy. Some of them have this for at least 10 years now :-)
I was talking about our VM. It is good to know that it already exists in other Smalltalk implementations. You mean Smalltalk/X ?
And, it could be done with virtually no costs at all - hardware check for this anyway.
Good to know ! There is hope then ;-)
Jan
2016-06-08 6:29 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 08 Jun 2016, at 11:24, Jan Vrany <jan.vrany@fit.cvut.cz> wrote: Not entirely true :-) There are smalltalks out there that detect such stack growth and do the same as CL, throw a (resumable) exception. Super-handy. Some of them have this for at least 10 years now :-)
I was talking about our VM. It is good to know that it already exists in other Smalltalk implementations. You mean Smalltalk/X ?
Dolphin has this feature (see atached file), and AFAIR VisualAge too. I implemented an infinite recursion, which was handled by Dolphin, but crashed Pharo. Regards,
May be you should raise the question in the vm mailing-list. It would be a really great feature. Stef Le 8/6/16 à 21:33, Esteban A. Maringolo a écrit :
2016-06-08 6:29 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 08 Jun 2016, at 11:24, Jan Vrany <jan.vrany@fit.cvut.cz> wrote: Not entirely true :-) There are smalltalks out there that detect such stack growth and do the same as CL, throw a (resumable) exception. Super-handy. Some of them have this for at least 10 years now :-) I was talking about our VM. It is good to know that it already exists in other Smalltalk implementations. You mean Smalltalk/X ? Dolphin has this feature (see atached file), and AFAIR VisualAge too. I implemented an infinite recursion, which was handled by Dolphin, but crashed Pharo.
Regards,
On Wed, Jun 08, 2016 at 11:11:13AM +0200, Sven Van Caekenberghe wrote:
On 08 Jun 2016, at 10:40, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 04 Jun 2016, at 9:13 , stepharo <stepharo@free.fr> wrote:
Le 3/6/16 ?? 19:16, Esteban A. Maringolo a ??crit :
Regarding the first part of your email, about UI lockups, it is almost unavoidable, because in Pharo almost everything happens in the main thread, as you pointed out. Yes. This is all my point.
IMHO, all Pharo beginner tutorials should start by showing off Cmd - dot (or Alt - dot, on Win / Linux).
Not just because it's cool, but because it's necessary :)
Cheers, Henry
Very true.
Yet, and I have already mentioned this years ago, it is technically totally possible to properly detect massive stack growth, before things get out of control. Sadly, VM people think this is not needed (or too costly).
Hi Sven, I think that I remember this topic being discussed from time to time, but I cannot recall specifics. Do you have a pointer to any discussions on the mailing lists? I'm sure that there would be interest in doing this if it can be done in an efficent manner. Thanks, Dave
Consider the following in Common Lisp (LispWorks):
CL-USER 1 > (defun fac (n) (if (< n 2) 1 (* n (fac (1- n))))) FAC
CL-USER 2 > (fac 5) 120
CL-USER 3 > (fac 100) 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
CL-USER 4 > (fac 400)
Stack overflow (stack size 31744). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0.
Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options.
CL-USER 5 : 1 > :c 1
Stack overflow (stack size 48128). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0.
Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options.
CL-USER 6 : 1 > :c 1 64034522846623895262347970319503005850702583026002959458684445942802397169186831436278478647463264676294350575035856810848298162883517435228961988646802997937341654150838162426461942352307046244325015114448670890662773914918117331955996440709549671345290477020322434911210797593280795101545372667251627877890009349763765710326350331533965349868386831339352024373788157786791506311858702618270169819740062983025308591298346162272304558339520759611505302236086810433297255194852674432232438669948422404232599805551610635942376961399231917134063858996537970147827206606320217379472010321356624613809077942304597360699567595836096158715129913822286578579549361617654480453222007825818400848436415591229454275384803558374518022675900061399560145595206127211192918105032491008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
CL-USER 7 > (defun infinite () (cons 'a (infinite))) INFINIT
CL-USER 8 > (infinite)
Stack overflow (stack size 80896). 1 (continue) Extend stack by 50%. 2 (abort) Return to level 0. 3 Return to top loop level 0.
Type :b for backtrace or :c <option number> to proceed. Type :bug-form "<subject>" for a bug report template or :? for other options.
CL-USER 9 : 1 > :a
CL-USER 10 >
Just having an upper limit to the stack catches 99% of infinite loops - that would be nice to have.
This has existed for 10s of years AFAIK.
Sven
PS: Of course, the stack size can be set larger to begin with, if necessary. I believe it is even per execution thread.
participants (6)
-
David T. Lewis -
Esteban A. Maringolo -
Henrik Johansen -
Jan Vrany -
stepharo -
Sven Van Caekenberghe