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