[Pharo-project] glamour and pharo

Lukas Renggli renggli at gmail.com
Mon Jan 2 08:18:59 EST 2012

>> and fork from Pharo 1.3? I guess this is only
>> way, because with the inclusion of RB into Pharo 1.4 people that want
>> to use the original version and everything that depends on it (maybe
>> this is just me?) are locked out.
> Not totally true :). I could merge the code each time you publish a new version but this is tedious.
> So how do we collaborate? :).
> First I will update the RB version.

I looked at the ConfigurationOfRefactoringEngine today, and I could
not figure out how to update it:

- There is now a package Refactoring-Pharo-Platform that should be
loaded together with Refactoring-Core.

- There seems to be some code moved between the packages in Pharo 1.4,
so I don't see how the head can be merged with that code.

- There are parts for GemStone and Squeak in the configuration, that I
don't know how to deal with.

> You see it works with zinc and zinc is even more central because sometimes I cannot update the system anymore :).

Zinc is something else. Zinc is a clean replacement for HTTPSocket. It
is backward compatible by providing the old and ugly HTTPSocket

The refactoring engine is something entirely new that you think you
might want to use in the future for remote images. Now that sounds to
me more like a research project that should be done aside, without
inflicting on the current development. As discussed previously, I
don't think that the refactoring engine provides the right model for
this task; but should it turn out otherwise, why not adapt it at that
time? Also I don't see why Pharo would want to have remote editing
functionality in all images. Shouldn't that better be a completely
separate project?

This leads me to the question: Did anybody ever sketch an architecture
of where Pharo should be heading to? I created a simplified one based
on my own understanding of the current proposals: http://bit.ly/vpnAf1
(Google Docs).

I think Pharo should concentrate only one the blue squares, eventually
only on the dark-blue one. Everything else should be a distribution on
top. Kernel developers might want/need to use a distribution on top of
the kernel themselves. Although it has been argued in the past that
this doesn't work, I don't see a reason why not. In any other open
source project (i.e. a Linux kernel hacker might as well use Emacs or
Gnome, even if they are not part of the kernel) people work like this,
why not in Pharo too?


Lukas Renggli

More information about the Pharo-dev mailing list