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