Hi, Stepping into this conversation :)
...and just to point one thing: IMHO, Pharo can never be just what Lukas propose: just a kernel, like linux, allowing different distributions. I think Pharo needs to be Kernel+Development Tools. Now, real objective is to make dev tools modules that you can load/unload, so you can have Kernel+Morphic Tools, Kernel+Glamoroust, Kernel+OB, etc. So, questions arise: 1) How do we achieve the objective of being real modular? 2) Which "dev tools" will be "blessed" (and maintained in the long way) by Pharo? I think right now we are trying to solve (1), so it has sense to want the simplest dev tools possible (That's how I interpret Stef requirements of not-on-top-of-yet-another-package)... But that will work for some time, once we have a modular kernel, Pharo needs powerful tools. It will be Glamouroust? I really don't know... I like it, but what I would like is to discuss what Glamour needs to be the tool we need, because other way, we will end with yet-another-tool-builder, and yet-another-discussion about which one adopt. What needs to be done in glamour to reach our goals? well... that's another discussion (and I'm agree, right now It can't be integrated as Pharo main distribution, but it could once Glamoroust is ready)... but this is my list: 1) drag&drop support 2) better menu handling/building (is too unflexible, now) well... I can keep talking about glamoroust tools, but non-sense right now :) best, Esteban El 02/01/2012, a las 10:37a.m., Stéphane Ducasse escribió: > > 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? > > Probably. > >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > >
