[Pharo-dev] Responsible development

Yuriy Tymchuk yuriy.tymchuk at me.com
Mon Dec 2 10:49:32 EST 2013


On 02 Dec 2013, at 16:40, Stéphane Ducasse <stephane.ducasse at 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
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 





More information about the Pharo-dev mailing list