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