Stef, About the CHB (you just have to use Dolphin's for a while to see what I mean). Most of the substantive differences are probably in deference to speed?? Maybe when Cog is mainstream, we can just "let it go." Dolphin's CHB presents the entire class hierarchy rather than showing little pieces of it here and there, which has always been my experience with Squeak's CHB.
About moving code away from the change log, I am simply worried about all of the complexities that can arise. I largely don't care how the system works provide it works *really* well<g> and that it has some redundancy in case I manage to fry an image, and moving code away from the log strikes me as real time sink to get right, so I am urging caution with change where code is stored. I fully supportive of a new packaging system that has concrete packages and frees up method categories. Does that help? Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of Stéphane Ducasse [[email protected]] Sent: Sunday, September 26, 2010 2:51 PM To: [email protected] Subject: Re: [Pharo-project] In Smalltalk you can't loose code... hum I do not know exactly what you mean. We want a good, working and flexible system. We just a problem of time. Stef On Sep 26, 2010, at 7:11 PM, Schwab,Wilhelm K wrote: > Keeping things out of the change log? Does that imply that all code must be > packaged? It more or less is already, though not always meaningfully. When > repackaging a class or method, do you plan to take the code out of the old > package's log and put it in the new one? Dolphin uses "real" packages, but > it is possible to have unpackaged code - I'm not sure if that's a good thing > or not. One day, I would like to see Pharo have a *hierarchy* browser as > good as Dolphin's. I think it could be built absent an ability to have > unpackaged classes, but I would not want to see it sabotaged by design. > Probably a bigger risk would be having work lost by gaps in the packaging > system when a catch-all change log would have held onto it. > > > > > ________________________________________ > From: [email protected] > [[email protected]] On Behalf Of Eliot Miranda > [[email protected]] > Sent: Sunday, September 26, 2010 11:18 AM > To: [email protected] > Subject: Re: [Pharo-project] In Smalltalk you can't loose code... hum > > On Sun, Sep 26, 2010 at 2:36 AM, Stéphane Ducasse > <[email protected]<mailto:[email protected]>> wrote: >> >>> >>> Because in the script manager has a save capability, would it be difficult >>> to write the changes into the changes files ? >> >> the problem is that the change files logic is old and it works 'well' for >> what it should but extending it will break other part. >> This is why slowly we will have to think to get something better. >> >> Do you mean improving the change scanner parsing or throwing away and going >> for something different? >> > > Hi eliot > > our vision is that we would like to have > - all the code of all the squeak and pharo version in a queryable > service available from the web. > for that we want a source code metamodel a la ginsu or famix > Use this metamodel to aggregate several meta models: pseudo class/rb > make sure that when possible this model as a compative API with the one > of classes and friends => tools reuse > Veronica is working on that. > Hernan will probably join. > May be Colin should join. We could have a nice momentum. > > - for the changes we would like to have something else than a chunk > format > because invoking the parser to know if we are manipulating a class > definition is bad (with token at: 2 do that > and token at: 3 do that). > > xml works for VisualWorks; it's the obvious choice. The great thing is that > if you look at the VisualWorks schema you can learn from their mistakes. > IIRC the schema for methods is broken because the selector is not a property > (? I don't know xml terminology) of a method, e.g. in VW you see > > <method>this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> > > but this would be much mire useful: > > <method selector="this:is:a:selector:">this: hic is: hic a: hic selector: hic > ^self tooMuchBeer</method> > > > > Again it will take time but we should have a good (why not 'exquise') > infrastructure so that we extend and build new tool > easily. > > Its not a lot of work. ALso VW has a simple scheme for supporting both old > chunk format and "new" xml format. > > BTW, now we have Igor's method trailers we can start playing with more than > two source files, e.g. /not/ appending a Monticello package's source to the > changes file, but merely adding it to a special directory, e.g. sources. > > Stef > _______________________________________________ > Pharo-project mailing list > [email protected]<mailto:[email protected]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
