[Pharo-project] start thinking on summer release of Pharo 1.4

Schwab,Wilhelm K bschwab at anest.ufl.edu
Sun Jun 17 15:10:24 EDT 2012

I have been a vocal critic of configs, largely on grounds of excessive complexity, but I find your message a bit harsh.

Long delays and hangs are BAD, but that can be addressed using background threads.  This is a prime example of why say that sockets should never block the entire image (only calling thread) and should not have anything to say about timeouts - the latter are an app programming/user decision.

The list of configs appearing in the browser is encouraging.  I'd hope to see ODBC listed too, but Glorp is there.  If all of these configs offer and can load a #stable version, that would be huge progress.


From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of phil at highoctane.be [phil at highoctane.be]
Sent: Sunday, June 17, 2012 6:44 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4

Who is his/her right mind would be able to make sense of this without
a lot of preexposure? And who the hell are those people?

And figuring out they need to right click, followed by a load
configuration *and* stable version? Followed by a loooong wait. And if
there is no internet, well, it would freeze for a significant while.

That's the feedback I get from people I try to get into the flow. Lots
of blank stares... along the lines of "What the heck are you doing?"


2012/6/17 Esteban Lorenzano <estebanlm at gmail.com>:
> On Jun 17, 2012, at 5:10 AM, Ben Coman wrote:
>> Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB?
>> I need to know this to continue updating Pharo By Example for 1.4.
> this is an interesting and important issue (much more than codenames, he).
> I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it):
> Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more.
> Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus.
> To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly).
> So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much.
> Frankly,  I don't know what to do now :)
> Esteban

Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:
phil at highoctane.be | Web: http://philippeback.eu | Blog:

High Octane SPRL
rue cour Boisacq 101
1301 Bierges

More information about the Pharo-dev mailing list