- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Responsible development

by Benjamin

On 02 Dec 2013, at 20:14, StÃ©phane Ducasse <stephane.ducasse(a)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(a)me.com> wrote: >> >>> >>> On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean(a)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. >>>> >>> >>> >> >

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by StÃ©phane Ducasse

> 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(a)me.com> wrote: > >> >> On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean(a)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. >>> >> >> >

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by StÃ©phane Ducasse

>> > > 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. >> > >

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by Benjamin

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(a)me.com> wrote: > > On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean(a)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. >> > >

Dec. 2, 2013

Re: [Pharo-dev] transcript is plain bad

by Esteban Lorenzano

yes, the transcript is ThreadSafeTranscript On Mon, Dec 2, 2013 at 8:00 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Buy the way, is absence of Transcript class - ok? > > I know how it all works now, but is it ok? :) > > uko > > > On 02 Dec 2013, at 19:58, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > yes, please :) > > > On Mon, Dec 2, 2013 at 7:56 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> >> > The return of the toothpick is near. o/ >> >> No I will finish my logger :) >> >> Stef >> >> > >

Dec. 2, 2013

Re: [Pharo-dev] transcript is plain bad

by Yuriy Tymchuk

Buy the way, is absence of Transcript class - ok? I know how it all works now, but is it ok? :) uko On 02 Dec 2013, at 19:58, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yes, please :) > > > On Mon, Dec 2, 2013 at 7:56 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > The return of the toothpick is near. o/ > > No I will finish my logger :) > > Stef > >

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by Yuriy Tymchuk

On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean(a)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. >

Dec. 2, 2013

Re: [Pharo-dev] transcript is plain bad

by Esteban Lorenzano

yes, please :) On Mon, Dec 2, 2013 at 7:56 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > > The return of the toothpick is near. o/ > > No I will finish my logger :) > > Stef > >

Dec. 2, 2013

Re: [Pharo-dev] transcript is plain bad

by StÃ©phane Ducasse

> The return of the toothpick is near. o/ No I will finish my logger :) Stef

Dec. 2, 2013

Re: [Pharo-dev] transcript is plain bad

by phil＠highoctane.be

The return of the toothpick is near. o/ On Mon, Dec 2, 2013 at 6:54 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > I can tell that it does not work when loading partial code because all the > compiler warnings make sure that you > cannot see anythingâ¦. > I should have pushed my logger more. :( >

Dec. 2, 2013