But control flow is not enough to reason about the code one needs the full AST

control flow givres you:

- complexity

- some clone detection technique

- what else ???

nicolas


On 22/02/2018 20:01, Stéphane Ducasse wrote:
Hi doru

it was just to look at how it was done. 
I spent today building a first super simple ControlFlowGraph for Pharo and the idea is to have this generic 
for other languages. 

Stef

On 22 Feb 2018, at 10:51, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

I am not sure I understand the use cases for why you would need FAST-pharo. I mean, what does RB not already offer? Could you detail them?

Cheers,
Doru


On Feb 22, 2018, at 10:24 AM, Nicolas Anquetil <Nicolas.Anquetil@inria.fr> wrote:

I beleive steph would like to have FAST-pharo, because FAST-core alone does not do much, it's only the infrastructure.

I am working on making FAST-pharo loadable and passing all the tests

nicolas


On 21/02/2018 10:19, Cyril Ferlicot wrote:
On Wed, Feb 21, 2018 at 8:54 AM, Stéphane Ducasse
<stephane.ducasse@inria.fr> wrote:
Hi Stef,

You may want to use the CI image
https://ci.inria.fr/moose/job/FAST-On-Moose/


I cannot execute this image with the launcher.
And I cannot execute on my mac.


Hi!

At Synectique we depend on it with this snippet:

project: 'FASTCore'
 with: [ spec
   className: #ConfigurationOfFASTCore;
   versionString: #development;
   repository: 'http://smalltalkhub.com/mc/Moose/FASTCore/main/' ].

So, I think this should work:

Metacello new
 repository: 'http://smalltalkhub.com/mc/Moose/FASTCore/main/';
 configuration: 'FASTCore';
 version: #development;
 load

For the state of FAST: Fast meta model was not valid because it had
multiple opposites for some properties and in Moose 6 or 6.1 (I don't
remember) a model validation was added because MooseQuery require a
valide meta model.

With Nicolas we worked on it to make FASTCore valid. There was at the
top of the hierarchy a method #parentNode and multiple properties
defining it as opposite, which is not valid for FAME.

What we did is that instead of pointing #parentNode for multiple
properties, we created, for each property, a new opposite property in
the right subclass of FASTEntity and we reimplemented #parentNode to
point this new property. At the end, we replaced the #parentNode at
the top of the hierarchy by a subclass responsibility. To keep it was
only for backward compatibility.

We validated the changes with the tests of one of Synectique
meta-model. Maybe the implementations for the other languages are
still not valid but I did not had the knowledge nor the time to check
it :(



--
Nicolas Anquetil
RMod team -- Inria Lille

_______________________________________________
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"We can create beautiful models in a vacuum.
But, to get them effective we have to deal with the inconvenience of reality."

_______________________________________________
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev

--------------------------------------------
Stéphane Ducasse
03 59 35 87 52
Assistant: Julie Jonas 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France



_______________________________________________
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev

-- 
Nicolas Anquetil
RMod team -- Inria Lille