Responsible development
Locked
123
123
 
|
Hi guys, I have some thoughts about how we develop for Pharo.
I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. Uko |
Re: Responsible development
|
|
Well, +1
We should, in a way, form a sort of “Pharo UI Team” that keeps pushing and fixing Nautilus & co. On Dec 2, 2013, at 2:02 PM, Yuriy Tymchuk <[hidden email]> wrote: > Hi guys, I have some thoughts about how we develop for Pharo. > > I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. > > Uko |
|
|
In reply to this post by Uko2
On 02 Dec 2013, at 14:03, Yuriy Tymchuk <[hidden email]> wrote: > Hi guys, I have some thoughts about how we develop for Pharo. > > I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. > this is the same as saying “I have an idea for developing pharo: We should stop introducing bugs”. So: yes. Please do. ;-) Marcus |
Re: Responsible development
|
|
In reply to this post by Uko2
Sidenote about this.
I don't know about this particular problem you faced with Nautilus. But the issue is "unfixable", IMHO, because everything runs in the same process. So there is no way to stop the current active process if it is REALLY stuck (100% CPU, 1 CORE). If it gets into an infinite unbreakable loop, or indefinitely blocking on I/O, then the entire VM gets unresponsive. For that reason I think that nothing should run in the UI Thread (which in Pharo is the main thread), except for event handling and rendering. Or... the VM should notice abnormal processes eating a lot of resources and warn the user. That's one nice feature of Smalltalk/X, every windows runs its own thread, with its own event queue, etc. You can kill it safely, without trowing away the whole image. Regards! Esteban A. Maringolo 2013/12/2 Yuriy Tymchuk <[hidden email]>: > Hi guys, I have some thoughts about how we develop for Pharo. > > I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. > > Uko |
|
|
yes, tocayo, you are right... but there is a design problem since ever and fix that will not be easy. Also, there is the notion of "main thread" internal to pharo, and the "main thread" relative to the OS. And AFAIK, the vm runs in the main thread (in mac there is a line to uncomment for moving out main thread, but they were a problem with certain callbacks who prevent me to use it... but well, we should review that too).
Esteban On Mon, Dec 2, 2013 at 2:21 PM, Esteban A. Maringolo <[hidden email]> wrote: Sidenote about this. |
|
|
In reply to this post by Esteban A. Maringolo
Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial.
Uko On 02 Dec 2013, at 14:21, Esteban A. Maringolo <[hidden email]> wrote: > Sidenote about this. > > I don't know about this particular problem you faced with Nautilus. > But the issue is "unfixable", IMHO, because everything runs in the > same process. > > So there is no way to stop the current active process if it is REALLY > stuck (100% CPU, 1 CORE). If it gets into an infinite unbreakable > loop, or indefinitely blocking on I/O, then the entire VM gets > unresponsive. > > For that reason I think that nothing should run in the UI Thread > (which in Pharo is the main thread), except for event handling and > rendering. Or... the VM should notice abnormal processes eating a lot > of resources and warn the user. > > That's one nice feature of Smalltalk/X, every windows runs its own > thread, with its own event queue, etc. You can kill it safely, without > trowing away the whole image. > > Regards! > > Esteban A. Maringolo > > > 2013/12/2 Yuriy Tymchuk <[hidden email]>: >> Hi guys, I have some thoughts about how we develop for Pharo. >> >> I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo. >> >> Uko > |
Re: Responsible development
|
|
In reply to this post by EstebanLM
2013/12/2 Esteban Lorenzano <[hidden email]>:
> yes, tocayo, you are right... but there is a design problem since ever and > fix that will not be easy. > > Also, there is the notion of "main thread" internal to pharo, and the "main > thread" relative to the OS. And AFAIK, the vm runs in the main thread (in > mac there is a line to uncomment for moving out main thread, but they were a > problem with certain callbacks who prevent me to use it... but well, we > should review that too). I know it's not easy, in fact I think it is hard. But I wanted to point this out. :) I barely know about how Windows processes work, so I can't speak about how to do it in Windows, Linux or MacOS. Regards! Esteban A. Maringolo |
|
In reply to this post by Uko2
I do feel that this issue fall more under the jurisdiction of Exception Handling, where if something bad happens to your system the whole thing does not collapse on itself but rather reports the error and carries on. Pharo processes are not OS processes, correct me if I am wrong but they dont have their own memory or can get their own core and generally are not separate entities. They are not even real threads. So I doubt how much of a protection they will offer. But agree with your its a design issue that sooner or later will have to be addressed. If the systems is very complex , then later is more likely.
On Mon, Dec 2, 2013 at 3:32 PM, Yuriy Tymchuk <[hidden email]> wrote: Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. |
Re: Responsible development
|
|
In reply to this post by Uko2
2013/12/2 Yuriy Tymchuk <[hidden email]>:
> Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. Unless you program everything based on callbacks, then even if you fork explicitly (new Processes) or by means of Futures, Promises, etc... at one point you'll have to wait (it is, block) every time you need to update the UI. The good practice is to spend the least time possible running thing in the UI thread. But given the fact the VM is single process in terms of host OS, callbacks won't provide much resilience either. Regards, Esteban A. Maringolo ps: As an concrete example, Android will kill any process taking more than 5 seconds in the main thread. So EVERYTHING except events, painting and layout, must take less than that, and if you do I/O or computation, you have to use threads. Ref: http://developer.android.com/guide/components/processes-and-threads.html |
|
|
Same story with Swing UI in Java if you want decent performance.
Phil On Mon, Dec 2, 2013 at 3:10 PM, Esteban A. Maringolo <[hidden email]> wrote: 2013/12/2 Yuriy Tymchuk <[hidden email]>: |
|
|
In reply to this post by Esteban A. Maringolo
User interrupt (cmd + .) was not working? -- Pavel 2013/12/2 Esteban A. Maringolo <[hidden email]> Sidenote about this. |
Re: Responsible development
|
|
In reply to this post by philippeback
Hi Phil,
Yes, the SwingWorker in Swing is similar to the AsyncTask in Android, but they are "one shot async tasks". In the other hand, the WebWorker in HTTP5 or Handler in Android, what they do is to post messages to the message queue of the UI thread. Regards, Esteban A. Maringolo 2013/12/2 [hidden email] <[hidden email]>: > Same story with Swing UI in Java if you want decent performance. > > http://en.wikipedia.org/wiki/SwingWorker > > Phil > > > > On Mon, Dec 2, 2013 at 3:10 PM, Esteban A. Maringolo <[hidden email]> > wrote: >> >> 2013/12/2 Yuriy Tymchuk <[hidden email]>: >> > Yes, This is a nice idea, but I was telling about the other thing. It’s >> > really simple to start a new process in Pharo. Maybe we should introduce >> > common practices in pharo? When I was following Obj-C course, one of the >> > fundamental thing that was taught: do time consuming tasks in the other >> > process. So I want to write a chapter on the concurrent programming in >> > Pharo, but is question is: am I missing something? Because this looks quite >> > trivial. >> >> Unless you program everything based on callbacks, then even if you >> fork explicitly (new Processes) or by means of Futures, Promises, >> etc... at one point you'll have to wait (it is, block) every time you >> need to update the UI. >> >> The good practice is to spend the least time possible running thing in >> the UI thread. >> >> But given the fact the VM is single process in terms of host OS, >> callbacks won't provide much resilience either. >> >> Regards, >> >> Esteban A. Maringolo >> >> ps: As an concrete example, Android will kill any process taking more >> than 5 seconds in the main thread. So EVERYTHING except events, >> painting and layout, must take less than that, and if you do I/O or >> computation, you have to use threads. >> Ref: >> http://developer.android.com/guide/components/processes-and-threads.html >> > |
Re: Responsible development
|
|
In reply to this post by Pavel Krivanek-3
2013/12/2 Pavel Krivanek <[hidden email]>:
> User interrupt (cmd + .) was not working? Most of the times for simple things it does, but sometimes it doesn't. Regards, Esteban A. Maringolo |
|
|
In reply to this post by Uko2
> Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. forking processes is not a solution. because you can have shared resources problems and updates and …. > So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. > > Uko > |
|
|
In reply to this post by Esteban A. Maringolo
As Clement explained to be, the Cmd + . combo is only tested on VM bytecode "backjumps".
So, if the bytecode is stuck with no backjumps, it is definitely stuck. I'd like to see where this occurs in the VM (maybe in the hope I could have a slow, but interruptible VM at all times) - this could take the form of a setting that gets turned on. Phil
On Mon, Dec 2, 2013 at 3:30 PM, Esteban A. Maringolo <[hidden email]> wrote: 2013/12/2 Pavel Krivanek <[hidden email]>: |
|
|
In reply to this post by Stéphane Ducasse
On 02/12/13 14:32, Stéphane Ducasse wrote:
> >> Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. > > > forking processes is not a solution. because you can have shared resources problems and updates and …. Yes, you risk races which could be tricky to find/debug. I'm **very** interested what's the solution you propose here? Jan > >> So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. >> >> Uko >> > > > |
|
Administrator
|
In reply to this post by Uko2
That would be fantastic. This thread is very interesting! And, I just want to remind everyone that Pharo 3.0 is unreleased... Do not expect it to be stable, although it is remarkably so for the amount of deep changes that have been made. Maybe that has lulled us into a false sense of security/expectation. Remember, caveat emptor until it is released, when there obviously shouldn't be any changes which might introduce this kind of bug.
Cheers,
Sean |
|
|
On 02 Dec 2013, at 16:24, Sean P. DeNigris <[hidden email]> wrote: > Uko2 wrote >> Shouldn’t we develop our tools in a more friendly way? > > That would be fantastic. This thread is very interesting! > > And, I just want to remind everyone that Pharo 3.0 is unreleased... Do not > expect it to be stable, It’s not about stability of pharo 3, it about concurrency. And it’s the same problem in 1.2, 1.3, 1.4, 2.0. I can write ruby code while running tests, but I cannot do that in Pharo. This thread doesn’t seem to have any reason, so I should just apologise for creating it because of frustration and ask everyone to stop discussing this :) > although it is remarkably so for the amount of deep > changes that have been made. Maybe that has lulled us into a false sense of > security/expectation. Remember, caveat emptor until it is released, when > there obviously shouldn't be any changes which might introduce this kind of > bug. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726749.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
|
|
In reply to this post by Jan Vrany
First, if you break your tools and do a loop in traditional world then you live with it.
Second, if you see what guillermo is doing: running multiple core side by side (this is a first step because there is no supervisor and we are in shared memory) but this could be a solution. Third " I was doing something in in Nautilus, and it started rising errors, which is ok (well, it’s not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldn’t we develop our tools in a more friendly way? When my finder freezes I don’t have to restart OS X, but when Nautilus freezes I have to restart Pharo." such kind of reports are useless. I do not count the number of time my mac application crash on me including the finder. I would not say that pharo is less stable that Mac OS from my perspective. Especially when I see the knid of changes we are doing. Fourth we are in alpha and nautilus was massively changed. I expect a lot more bugs, because such browser is complex. Stef >>> Yes, This is a nice idea, but I was telling about the other thing. It’s really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. >> >> >> forking processes is not a solution. because you can have shared resources problems and updates and …. > > Yes, you risk races which could be tricky to find/debug. > > I'm **very** interested what's the solution you propose here? > > Jan > >> >>> So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. >>> >>> Uko >>> >> >> >> > > |
|
|
In reply to this post by Uko2
>>
>> >> And, I just want to remind everyone that Pharo 3.0 is unreleased... Do not >> expect it to be stable, > > It’s not about stability of pharo 3, it about concurrency. And it’s the same problem in 1.2, 1.3, 1.4, 2.0. I can write ruby code while running tests, but I cannot do that in Pharo. Of course you can do that in Pharo. AutoTest was a trial to do that. Now for example you can load code in a background process now if you modify objects that may be impacted by changes then you can get in trouble. In ruby do you run them in a patched kernel version or in the same environment? I would like to have isolated memory and several kernels running side by side but this is not something that we can achieve in a couple of days. > This thread doesn’t seem to have any reason, so I should just apologise for creating it because of frustration and ask everyone to stop discussing this :) Yury you should be more precise in your point > >> although it is remarkably so for the amount of deep >> changes that have been made. Maybe that has lulled us into a false sense of >> security/expectation. Remember, caveat emptor until it is released, when >> there obviously shouldn't be any changes which might introduce this kind of >> bug. >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726749.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |