Responsible development
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
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 <yuriy.tymchuk@me.com> 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
On 02 Dec 2013, at 14:03, Yuriy Tymchuk <yuriy.tymchuk@me.com> 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
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 <yuriy.tymchuk@me.com>:
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 <emaringolo@gmail.com>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 <yuriy.tymchuk@me.com>:
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
2013/12/2 Esteban Lorenzano <estebanlm@gmail.com>:
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
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 <emaringolo@gmail.com> 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 <yuriy.tymchuk@me.com>:
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
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 <yuriy.tymchuk@me.com> 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.
Uko
On 02 Dec 2013, at 14:21, Esteban A. Maringolo <emaringolo@gmail.com> 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 <yuriy.tymchuk@me.com>:
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
2013/12/2 Yuriy Tymchuk <yuriy.tymchuk@me.com>:
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. http://en.wikipedia.org/wiki/SwingWorker Phil On Mon, Dec 2, 2013 at 3:10 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
2013/12/2 Yuriy Tymchuk <yuriy.tymchuk@me.com>:
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
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 phil@highoctane.be <phil@highoctane.be>:
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 <emaringolo@gmail.com> wrote:
2013/12/2 Yuriy Tymchuk <yuriy.tymchuk@me.com>:
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
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
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
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
On 02 Dec 2013, at 16:40, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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
Iâm not complaining that new tools are bad. Iâm gust telling that Iâd prefer other ones in first place. E.i. old class browser running in a separate thread instead of nautilus, tools for traits instead of slots etc⦠Iâm not saying that slots are bad, no they are amazing. But traits are powerful to but not widely used because we lack tools. The same bothers me with slots. Because we will need a tools for that, and example with traits shows that we are not that good in it. Once again, this is just my vision, and it seems to me that we are building skyscraper on soil instead of creating a concrete base for it. Although you have more experience so maybe itâs better the way it is. uko
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
Iâm not complaining that new tools are bad. Iâm gust telling that Iâd prefer other ones in first place. E.i. old class browser running in a separate thread instead of nautilus,
But it was never like that. The old browser is just worse code but the logic is the same.
tools for traits instead of slots I do not understand what you mean because this is totally orthogonal.
etc⦠Iâm not saying that slots are bad, no they are amazing. But traits are powerful to but not widely used because we lack tools.
Yes but not only :) You see in PHP and perl they use them too.
The same bothers me with slots. Because we will need a tools for that, and example with traits shows that we are not that good in it.
Why? because we lack a nice metamodel (and we started to build ring for that and it needs another iterations) and a flexible way to build tool and not spaghetti code, this is why we invested in Spec. So
Once again, this is just my vision, and it seems to me that we are building skyscraper on soil instead of creating a concrete base for it.
LOL We are doing infrastructure work since years. Just open your eyes to realise it. FileSystem, OPAL (imagine a new compiler) New DebuggerModel, Announcement, AtomicQueue, Cleaning morphic, Spec, Zinc Better handling of rectangle Better handling of layoutFrame Better better better Do you want more look at the list of things we did: it is MASSIVE MASSIVE and nearly only targeted at building a strong and robust infrastructure. We just spent some time on look but nothing compared to the rest.
Although you have more experience so maybe itâs better the way it is.
uko
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
On 02 Dec 2013, at 17:11, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Iâm not complaining that new tools are bad. Iâm gust telling that Iâd prefer other ones in first place. E.i. old class browser running in a separate thread instead of nautilus,
But it was never like that. The old browser is just worse code but the logic is the same.
Yes, so time was spent to make Nautilus. It could be spent to work on concurrency. Now itâs useless to discuss whether itâs good or not to go one way or the other. We can always find good and always find bad. Sorry for disturbing, Iâm getting back to work to make Pharo better :) uko
tools for traits instead of slots I do not understand what you mean because this is totally orthogonal.
etc⦠Iâm not saying that slots are bad, no they are amazing. But traits are powerful to but not widely used because we lack tools.
Yes but not only :) You see in PHP and perl they use them too.
The same bothers me with slots. Because we will need a tools for that, and example with traits shows that we are not that good in it.
Why? because we lack a nice metamodel (and we started to build ring for that and it needs another iterations) and a flexible way to build tool and not spaghetti code, this is why we invested in Spec. So
Once again, this is just my vision, and it seems to me that we are building skyscraper on soil instead of creating a concrete base for it.
LOL We are doing infrastructure work since years. Just open your eyes to realise it.
FileSystem, OPAL (imagine a new compiler) New DebuggerModel, Announcement, AtomicQueue, Cleaning morphic, Spec, Zinc Better handling of rectangle Better handling of layoutFrame Better better better
Do you want more look at the list of things we did: it is MASSIVE MASSIVE and nearly only targeted at building a strong and robust infrastructure. We just spent some time on look but nothing compared to the rest.
Although you have more experience so maybe itâs better the way it is.
uko
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
Yes, so time was spent to make Nautilus. It could be spent to work on concurrency.
Concurrency is not magic. You have a strange belief. Pharo has nearly the same model than Java or any language with semaphore, and others basic concurrency constructs. Concurrency is not the panacea. It implies duplication or synchronisation points. What you are calling concurrency is robust and isolated execution. This is not the same and it is difficult to achieve especially with an open-source written in itself and reflective.
Now itâs useless to discuss whether itâs good or not to go one way or the other.
No I give you chance to educate you and learn. I'm not spending time for the sake of arguing but I invest in you :) Else I would not even reply.
We can always find good and always find bad. Sorry for disturbing, Iâm getting back to work to make Pharo better :)
Yes. I'm not satisfied to what we have but we have it.
And we should all work to *make it better*, in one way or another! In the end we will be satisfied with what we have! ;-) Keep up the good work! Cheers, R On Dec 2, 2013, at 5:47 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I'm not satisfied to what we have but we have it.
Amen On 02 Dec 2013, at 18:06, Roberto Minelli <roberto.minelli@usi.ch> wrote:
And we should all work to *make it better*, in one way or another! In the end we will be satisfied with what we have! ;-)
Keep up the good work!
Cheers, R
On Dec 2, 2013, at 5:47 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I'm not satisfied to what we have but we have it.
Traits do work nicely. What's your pain with them? (apart from the fact that the categorization in 2.0 is somewhat buggy)... Phil On Mon, Dec 2, 2013 at 5:11 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
Iâm not complaining that new tools are bad. Iâm gust telling that Iâd prefer other ones in first place. E.i. old class browser running in a separate thread instead of nautilus,
But it was never like that. The old browser is just worse code but the logic is the same.
tools for traits instead of slots I do not understand what you mean because this is totally orthogonal.
etc⦠Iâm not saying that slots are bad, no they are amazing. But traits are powerful to but not widely used because we lack tools.
Yes but not only :) You see in PHP and perl they use them too.
The same bothers me with slots. Because we will need a tools for that, and example with traits shows that we are not that good in it.
Why? because we lack a nice metamodel (and we started to build ring for that and it needs another iterations) and a flexible way to build tool and not spaghetti code, this is why we invested in Spec. So
Once again, this is just my vision, and it seems to me that we are building skyscraper on soil instead of creating a concrete base for it.
LOL We are doing infrastructure work since years. Just open your eyes to realise it.
FileSystem, OPAL (imagine a new compiler) New DebuggerModel, Announcement, AtomicQueue, Cleaning morphic, Spec, Zinc Better handling of rectangle Better handling of layoutFrame Better better better
Do you want more look at the list of things we did: it is MASSIVE MASSIVE and nearly only targeted at building a strong and robust infrastructure. We just spent some time on look but nothing compared to the rest.
Although you have more experience so maybe itâs better the way it is.
uko
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
User interrupt (cmd + .) was not working? -- Pavel 2013/12/2 Esteban A. Maringolo <emaringolo@gmail.com>
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 <yuriy.tymchuk@me.com>:
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
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 <emaringolo@gmail.com>wrote:
2013/12/2 Pavel Krivanek <pavel.krivanek@gmail.com>:
User interrupt (cmd + .) was not working?
Most of the times for simple things it does, but sometimes it doesn't.
Regards,
Esteban A. Maringolo
On Mon, Dec 2, 2013 at 6:47 AM, phil@highoctane.be <phil@highoctane.be>wrote:
As Clement explained to be, the Cmd + . combo is only tested on VM bytecode "backjumps".
It is also tested on every non-primitive send.
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.
You can always send SIGUSR1 to the VM on linux and Mac OS. You'll need to open the console to see the output unless you run the VM from a terminal. But you can find out what it's doing.
Phil
On Mon, Dec 2, 2013 at 3:30 PM, Esteban A. Maringolo <emaringolo@gmail.com
wrote:
2013/12/2 Pavel Krivanek <pavel.krivanek@gmail.com>:
User interrupt (cmd + .) was not working?
Most of the times for simple things it does, but sometimes it doesn't.
Regards,
Esteban A. Maringolo
-- best, Eliot
Hey, nice. I'll try that. On Mon, Dec 2, 2013 at 8:25 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Mon, Dec 2, 2013 at 6:47 AM, phil@highoctane.be <phil@highoctane.be>wrote:
As Clement explained to be, the Cmd + . combo is only tested on VM bytecode "backjumps".
It is also tested on every non-primitive send.
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.
You can always send SIGUSR1 to the VM on linux and Mac OS. You'll need to open the console to see the output unless you run the VM from a terminal. But you can find out what it's doing.
Phil
On Mon, Dec 2, 2013 at 3:30 PM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
2013/12/2 Pavel Krivanek <pavel.krivanek@gmail.com>:
User interrupt (cmd + .) was not working?
Most of the times for simple things it does, but sometimes it doesn't.
Regards,
Esteban A. Maringolo
-- best, Eliot
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, 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.
On 02 Dec 2013, at 16:24, Sean P. DeNigris <sean@clipperadams.com> 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.
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.
Run 2 images and Monticello. --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Mon, Dec 2, 2013 at 4:35 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 02 Dec 2013, at 16:24, Sean P. DeNigris <sean@clipperadams.com> 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.
Uko2 wrote
Itâs not about stability of pharo 3, it about concurrency... This thread doesnât seem to have any reason
Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean@clipperadams.com> wrote:
Uko2 wrote
Itâs not about stability of pharo 3, it about concurrency... This thread doesnât seem to have any reason
Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread.
Even if everything runs in one thread it doesnât mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard. Letâs take moose for example. While it is importing a model everything freezes. Is there a reason for that? I donât see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too. uko
----- Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread. I will do an experiment and fork each Nautilus opening to see if it can save my ass :P Ben On 02 Dec 2013, at 19:59, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean@clipperadams.com> wrote:
Uko2 wrote
Itâs not about stability of pharo 3, it about concurrency... This thread doesnât seem to have any reason
Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread.
Even if everything runs in one thread it doesnât mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard.
Letâs take moose for example. While it is importing a model everything freezes. Is there a reason for that? I donât see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too.
uko
----- Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Ben
On 02 Dec 2013, at 19:59, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean@clipperadams.com> wrote:
Uko2 wrote
Itâs not about stability of pharo 3, it about concurrency... This thread doesnât seem to have any reason
Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread.
Even if everything runs in one thread it doesnât mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard.
Letâs take moose for example. While it is importing a model everything freezes. Is there a reason for that? I donât see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too.
uko
----- Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 02 Dec 2013, at 20:14, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Why ?
Ben
On 02 Dec 2013, at 19:59, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean@clipperadams.com> wrote:
Uko2 wrote
Itâs not about stability of pharo 3, it about concurrency... This thread doesnât seem to have any reason
Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread.
Even if everything runs in one thread it doesnât mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard.
Letâs take moose for example. While it is importing a model everything freezes. Is there a reason for that? I donât see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too.
uko
----- Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Why ?
Because you do not know when you invariants should hold. Normally you expect them to hold once the system is loaded. Because loading for example act as an atomic action when you modify the system. Now if your thread can see and modify different versions of the state be prepared to have really strange and difficult bugs to find. I prefer to have cache than to have forked processes around. Stef
On 02 Dec 2013, at 20:27, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Why ?
Because you do not know when you invariants should hold. Normally you expect them to hold once the system is loaded. Because loading for example act as an atomic action when you modify the system. Now if your thread can see and modify different versions of the state be prepared to have really strange and difficult bugs to find.
I prefer to have cache than to have forked processes around.
Cache will not help you killing Nautilus when it freezes your image (why cache by the way ?) Ben
Stef
On Dec 2, 2013, at 8:37 PM, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
On 02 Dec 2013, at 20:27, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Why ?
Because you do not know when you invariants should hold. Normally you expect them to hold once the system is loaded. Because loading for example act as an atomic action when you modify the system. Now if your thread can see and modify different versions of the state be prepared to have really strange and difficult bugs to find.
I prefer to have cache than to have forked processes around.
Cache will not help you killing Nautilus when it freezes your image
fork neither.
(why cache by the way ?)
I thought the discussion was about speeding up nautilus when performing start up actions.
Ben
Stef
The main issue I do face when doing Pharo dev at the moment is that there is always this feeling of risking getting locked out of the image. It happens every once in a while for weird reasons. Now, with configurations, Monticello and some changes file drag and drops, it is tolerable. But there is that fear of getting the image to freeze. The Cmd + . not working at all times add to that impression. Things like Oz and a remote browser to an image may alleviate that at one point in the future. Now, Xcode also freezes at times, and good luck for finding what's wrong. The ability to regain control is really what could be a great plus to the platform. As far as I am concerned, as a developer, I hate not having control on what's going on when coding. That may be a psychological trait. And yes, OO isn't about understanding it all before doing anything. But facing a frozen image with no way to get it back is really deeply frustrating. Especially with no way to understand why it went dark. That's where Oz is very interesting (as is Spoon with the remote browser - no matter how unfinished that is). So, I end up saving my image like XXX_yyyymmdd_hhmm with one workspace a day (workspaceProjectYYYYMMDD). This takes a lot of disk space, but that is cheap now. It all is rooted in the fear of getting a freeze. Phil --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Tue, Dec 3, 2013 at 10:01 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
On Dec 2, 2013, at 8:37 PM, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
On 02 Dec 2013, at 20:27, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Why ?
Because you do not know when you invariants should hold. Normally you expect them to hold once the system is loaded. Because loading for example act as an atomic action when you modify the system. Now if your thread can see and modify different versions of the state be prepared to have really strange and difficult bugs to find.
I prefer to have cache than to have forked processes around.
Cache will not help you killing Nautilus when it freezes your image
fork neither.
(why cache by the way ?)
I thought the discussion was about speeding up nautilus when performing start up actions.
Ben
Stef
On 03 Dec 2013, at 10:01, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 2, 2013, at 8:37 PM, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
On 02 Dec 2013, at 20:27, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Why ?
Because you do not know when you invariants should hold. Normally you expect them to hold once the system is loaded. Because loading for example act as an atomic action when you modify the system. Now if your thread can see and modify different versions of the state be prepared to have really strange and difficult bugs to find.
I prefer to have cache than to have forked processes around.
Cache will not help you killing Nautilus when it freezes your image
fork neither.
It should not freeze your image anymore, only its own thread Ben
(why cache by the way ?)
I thought the discussion was about speeding up nautilus when performing start up actions.
Ben
Stef
On 03 Dec 2013, at 11:08, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
On 03 Dec 2013, at 10:01, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 2, 2013, at 8:37 PM, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
On 02 Dec 2013, at 20:27, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Why ?
Because you do not know when you invariants should hold. Normally you expect them to hold once the system is loaded. Because loading for example act as an atomic action when you modify the system. Now if your thread can see and modify different versions of the state be prepared to have really strange and difficult bugs to find.
I prefer to have cache than to have forked processes around.
Cache will not help you killing Nautilus when it freezes your image
fork neither.
It should not freeze your image anymore, only its own thread
Wow, that was fast
Ben
(why cache by the way ?)
I thought the discussion was about speeding up nautilus when performing start up actions.
Ben
Stef
looks like your post to the mailing list was not as pointless as you thought ;) Great work Benjamin On Tue, Dec 3, 2013 at 12:38 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 03 Dec 2013, at 11:08, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
On 03 Dec 2013, at 10:01, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 2, 2013, at 8:37 PM, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
On 02 Dec 2013, at 20:27, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P
:)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Why ?
Because you do not know when you invariants should hold. Normally you expect them to hold once the system is loaded. Because loading for example act as an atomic action when you modify the system. Now if your thread can see and modify different versions of the state be prepared to have really strange and difficult bugs to find.
I prefer to have cache than to have forked processes around.
Cache will not help you killing Nautilus when it freezes your image
fork neither.
It should not freeze your image anymore, only its own thread
Wow, that was fast
Ben
(why cache by the way ?)
I thought the discussion was about speeding up nautilus when performing start up actions.
Ben
Stef
I did not say I did it :) Sorry for the misunderstanding. I was saying that theoretically it should not freeze the UI thread if you fork. But then it also mean you should freeze the UI thread from time to time while doing critical operations So itâs actually a bit tricky to implement Ben On 03 Dec 2013, at 11:40, kilon alios <kilon.alios@gmail.com> wrote:
looks like your post to the mailing list was not as pointless as you thought ;)
Great work Benjamin
On Tue, Dec 3, 2013 at 12:38 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 03 Dec 2013, at 11:08, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
On 03 Dec 2013, at 10:01, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Dec 2, 2013, at 8:37 PM, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
On 02 Dec 2013, at 20:27, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Why ?
Because you do not know when you invariants should hold. Normally you expect them to hold once the system is loaded. Because loading for example act as an atomic action when you modify the system. Now if your thread can see and modify different versions of the state be prepared to have really strange and difficult bugs to find.
I prefer to have cache than to have forked processes around.
Cache will not help you killing Nautilus when it freezes your image
fork neither.
It should not freeze your image anymore, only its own thread
Wow, that was fast
Ben
(why cache by the way ?)
I thought the discussion was about speeding up nautilus when performing start up actions.
Ben
Stef
fork neither.
It should not freeze your image anymore, only its own thread
I'm not convinced. Because if you get a thread per nautilus to me it just introduces potentially more problems. Just forking a process in general does not solve problem. Also debugging can be harder when you have different threads executing the same code. Not freezing is just that you do not damage the main ui thread.
Ben
(why cache by the way ?)
I thought the discussion was about speeding up nautilus when performing start up actions.
Ben
Stef
there is also performance concerns. I remember once there was that code for a fractal or something that let you define how many threads it would use. 1 thread was very slow , 5-6 threads very fast but more threads actually made code slower and slower the more threads I was adding. And those were REAL threads (meaning the could take advantage of multiple cores = real concurency) , not greenlets as the ones used by pharo and python. So there is always a catch. Concurrency is known to cause headache with the exception of Clojure and Erlang both seem to make their users very happy with their concurrency features. But both of these languages were based on concurrency and not added it in as another feature to have. These things are not easy to implement. I come from python , super popular language, tons of developer and loads of people complaining how concurrency is done. On Mon, Dec 2, 2013 at 9:14 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P
:)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Ben
On 02 Dec 2013, at 19:59, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean@clipperadams.com> wrote:
Uko2 wrote
Itâs not about stability of pharo 3, it about concurrency... This thread doesnât seem to have any reason
Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread.
Even if everything runs in one thread it doesnât mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard.
Letâs take moose for example. While it is importing a model everything freezes. Is there a reason for that? I donât see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too.
uko
----- Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.
In clojure they have STM so they can somehow control concurrent effect with readonly structure (I forgot). I thought that it would be interesting to see what would be an STM for Pharo but this is a real phdsssss topic. On Dec 2, 2013, at 8:25 PM, kilon alios <kilon.alios@gmail.com> wrote:
there is also performance concerns. I remember once there was that code for a fractal or something that let you define how many threads it would use. 1 thread was very slow , 5-6 threads very fast but more threads actually made code slower and slower the more threads I was adding. And those were REAL threads (meaning the could take advantage of multiple cores = real concurency) , not greenlets as the ones used by pharo and python.
So there is always a catch. Concurrency is known to cause headache with the exception of Clojure and Erlang both seem to make their users very happy with their concurrency features. But both of these languages were based on concurrency and not added it in as another feature to have. These things are not easy to implement.
I come from python , super popular language, tons of developer and loads of people complaining how concurrency is done.
On Mon, Dec 2, 2013 at 9:14 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Ben
On 02 Dec 2013, at 19:59, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean@clipperadams.com> wrote:
Uko2 wrote
Itâs not about stability of pharo 3, it about concurrency... This thread doesnât seem to have any reason
Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread.
Even if everything runs in one thread it doesnât mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard.
Letâs take moose for example. While it is importing a model everything freezes. Is there a reason for that? I donât see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too.
uko
----- Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 02 Dec 2013, at 19:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
In clojure they have STM so they can somehow control concurrent effect with readonly structure (I forgot). I thought that it would be interesting to see what would be an STM for Pharo but this is a real phdsssss topic.
On Dec 2, 2013, at 8:25 PM, kilon alios <kilon.alios@gmail.com> wrote:
there is also performance concerns. I remember once there was that code for a fractal or something that let you define how many threads it would use. 1 thread was very slow , 5-6 threads very fast but more threads actually made code slower and slower the more threads I was adding. And those were REAL threads (meaning the could take advantage of multiple cores = real concurency) , not greenlets as the ones used by pharo and python.
So there is always a catch. Concurrency is known to cause headache with the exception of Clojure and Erlang both seem to make their users very happy with their concurrency features. But both of these languages were based on concurrency and not added it in as another feature to have. These things are not easy to implement.
Both clojure and erlang have immutable state as the default. It is not concurrency that is hard. It is shared mutable state that kills you. frank
I come from python , super popular language, tons of developer and loads of people complaining how concurrency is done.
On Mon, Dec 2, 2013 at 9:14 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P :)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Ben
On 02 Dec 2013, at 19:59, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean@clipperadams.com> wrote:
Uko2 wrote
Itâs not about stability of pharo 3, it about concurrency... This thread doesnât seem to have any reason
Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread.
Even if everything runs in one thread it doesnât mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard.
Letâs take moose for example. While it is importing a model everything freezes. Is there a reason for that? I donât see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too.
uko
----- Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Of course, and obviously in Squeak/Pharo, code itself is kind of mutable state... (you modify some methodDictionary, subclasses etc...). So applying concurrency to tools handling that shared mutable state is... HARD. 2013/12/2 Frank Shearar <frank.shearar@gmail.com>
On 02 Dec 2013, at 19:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
In clojure they have STM so they can somehow control concurrent effect with readonly structure (I forgot). I thought that it would be interesting to see what would be an STM for Pharo but this is a real phdsssss topic.
On Dec 2, 2013, at 8:25 PM, kilon alios <kilon.alios@gmail.com> wrote:
there is also performance concerns. I remember once there was that code for a fractal or something that let you define how many threads it would use. 1 thread was very slow , 5-6 threads very fast but more threads actually made code slower and slower the more threads I was adding. And those were REAL threads (meaning the could take advantage of multiple cores = real concurency) , not greenlets as the ones used by pharo and python.
So there is always a catch. Concurrency is known to cause headache with the exception of Clojure and Erlang both seem to make their users very happy with their concurrency features. But both of these languages were based on concurrency and not added it in as another feature to have. These things are not easy to implement.
Both clojure and erlang have immutable state as the default. It is not concurrency that is hard. It is shared mutable state that kills you.
frank
I come from python , super popular language, tons of developer and loads of people complaining how concurrency is done.
On Mon, Dec 2, 2013 at 9:14 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
We try now to have responsive UIs in the sense the tools like Nautilus try to run things in a separate thread.
I will do an experiment and fork each Nautilus opening to see if it can save my ass :P
:)
personnally I would be really against because just forking is just a way to have a lot more mess in the future.
Ben
On 02 Dec 2013, at 19:59, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean@clipperadams.com> wrote:
Uko2 wrote
Itâs not about stability of pharo 3, it about concurrency... This thread doesnât seem to have any reason
Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread.
Even if everything runs in one thread it doesnât mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard.
Letâs take moose for example. While it is importing a model everything freezes. Is there a reason for that? I donât see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too.
uko
----- Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>.
Even if everything runs in one thread it doesnât mean that you need to block something. ? You run in one thread then either it runs or it does not :) When loading Moose in one process it will load model and not process UI. I see that you do not really grasp concurrency.
And I know that example with Nautilus or even with test runner may be to hard.
Letâs take moose for example. While it is importing a model everything freezes. Is there a reason for that? I donât see any.
It just depends if you want to let the user do something in parallel or not. For moose this is easy to fork the loading. Now for pharo since what you load can modify the running system this is a different story.
In my opinion the problem is that we are not used to run non-instant operations in a separate process,
No :) The problem is that we do not have a nice way to protect the system from being executed and modified at the same time. Imagine that we would load the code in a separate structure in the parallel process and that once the code is loaded but not installed you have a fast way to install it. Then we could do loading on the side. You see the key aspect. Your UI in objective-C were not done to load Objective-C code that could modify the objective-C runtime!!! So if you want to build a simple user interface loading videos you can do it in a parallel process just using fork and paying a bit of attention.
because I do a lot of mistakes like this too.
uko
----- Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi Yuriy, Loading a Moose model actually happens in a separate thread and you should be able to do other things in the meantime. However, it is true that the image becomes less responsive when doing that. Did you experience anything different? Doru -- www.tudorgirba.com "Every thing has its own flow."
On 02.12.2013, at 19:59, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean@clipperadams.com> wrote:
Uko2 wrote
Itâs not about stability of pharo 3, it about concurrency... This thread doesnât seem to have any reason
Nothing is wasted. I appreciate your ideas. I never thought of these benefits; I always took it for granted to run in one thread.
Even if everything runs in one thread it doesnât mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard.
Letâs take moose for example. While it is importing a model everything freezes. Is there a reason for that? I donât see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too.
uko
----- Cheers, Sean -- View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (16)
-
Benjamin -
Eliot Miranda -
Esteban A. Maringolo -
Esteban Lorenzano -
Frank Shearar -
Jan Vrany -
kilon alios -
Marcus Denker -
Nicolas Cellier -
Pavel Krivanek -
phil＠highoctane.be -
Roberto Minelli -
Sean P. DeNigris -
Stéphane Ducasse -
Tudor Girba -
Yuriy Tymchuk