Re: [Pharo-project] In Smalltalk you can't loose code... hum
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). Again it will take time but we should have a good (why not 'exquise') infrastructure so that we extend and build new tool easily. Stef
On Sun, Sep 26, 2010 at 2:36 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda@gmail.com] Sent: Sunday, September 26, 2010 11:18 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] In Smalltalk you can't loose code... hum On Sun, Sep 26, 2010 at 2:36 AM, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> 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 Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/9/26 Eliot Miranda <eliot.miranda@gmail.com>:
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.
Yes. I told about potential use of new trailers, where we can implement a model for storing/retrieving source code from any kind of storage. Unfortunately it requires some remodelling of system's source-code management system, to get rid of hard-wired SourceFiles code and add an abstract layer for source management. So we could implement different source managers, where .source and .changes will be just default one. One of my ideas was to use CouchDB for storing everything there. It opens quite interesting opportunities, like being able to browse a history of some particular method up to 1.0 squeak release :) @Stef: add this to pharo todo list :)
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (4)
-
Eliot Miranda -
Igor Stasenko -
Schwab,Wilhelm K -
Stéphane Ducasse