[Pharo-project] glamour and pharo
renggli at gmail.com
Mon Jan 2 14:53:44 CET 2012
>> 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.
Ok, then be it a separate open-source project that Pharo does not need
to depend on.
>> 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.
I don't understand what you write, but I guess it boils down to having
namespaces that allows one to load and use different variations of the
same code at once. This would also solve my problem with the
refactoring engine: Pharo could depend on one version, I could use
Seems to me quite a central kind of functionality to make progress.
Again to make the analogy with Linux: This seems to be the virtual
machines that allow one to easy test and run other kernels aside.
More information about the Pharo-project