[Pharo-project] glamour and pharo

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Jan 2 08:37:04 EST 2012

On Jan 2, 2012, at 2:18 PM, Lukas Renggli wrote:

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

I will look at it once we beat the event crashing bug because I hate it.
BTW something I would like is

	- we have a core
	- when working on coreA, we load all the system in another core 
	- from this other core we hack with rb and other tools the coreA
	- we publish changes to coreA
	- without having to touch core and we produce coreA without interference

Because I loaded RB in Core because we crawl in mud all the time and I do everything by hand. 
Now the problem is that also we cannot scope the changes.

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

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

Me too :)

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

Now see above this is not research. I cannot publish anything on that. 

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

Lukas we want only one compiler but we should be able to edit its code.
RIght now marcus has the old compiler as a fallback and this is annoying.
We should be able to run two compilers side by side (this is why Opal should be parametrized by environment (smalltalk) but also 
object environment (nil true….) so that we can bootstrap it with itself. 

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

We should because we know where we want to go. 

> 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
> -- 
> Lukas Renggli
> www.lukas-renggli.ch

More information about the Pharo-dev mailing list