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
