Dear List,
I am currently working on a C importer based on srcML output. I
created an extension of FAMIX3 (I am working with Pharo) since FAMIX3
did not express procedural languages.
Essentially, 4 classes defines this extension:
- CAFunction subclass of FAMIXBehaviouralEntity
- CAInclue subclass of FAMIXAssociation
- CAModule subclass of FAMIXScopingEntity
- CAVariable subclass of FAMIXGlobalVariable
An instance of CAModule is intended to describe a C Module, instance
being generated from a C file. I think this should be the right way
to do.
On the other hand, there are FAMIXFolder and FAMIXFile. Ideally, a C
file should be seen as a file _and_ as a module. The class FAMIXFile
contains useful methods, that I would like to use on a CAModule. But
having one instance of CAModule and one instance of FAMIXFile per .c
file is clearly suboptimal.
My intuitions argues for creating a trait TFAMIXFile, that will be
used by both FAMIXFile and CAModule.
Any comment on this trait?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I just stumble upon the case when adding Famix.SourceAnchor to the
metamodel. It does not make much sense to make SourceAnchor a subclass
of FamixEntity.
Yet a common way to 'get' the Famix metamodel (found here and there in
the code) is to use FAMIXEntity withAllSubclasses (which misses
SourceAnchor)
Yet another way is to use PackageInfo, but then I need to know all
packages in which Famix extensions have been defined.
Any suggestion?
Note: we dont have this problem with MooseModel, because MooseModel
uses MooseEntity withAllSubclasses :)
but I dont want to always have this dependency on Moose when loading
Famix alone
--
Simon
Hi All,
Running HismoTest raises an error. Apparently, FAMIXSourceAnchor seems
to be not properly fame described.
A "MooseModel resetMeta does not help. FAMIXSourceAnchor is a subclass
of MooseEntity, whereas in its annotation states it is a subclass of
Object. I tried to replace Object by MooseEntity but same result.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alex,
I need some new features in sqMondrian:
- to fix a width for MOLabelShape (method width: )
- preserve the height of a MORectangleShape when a MOLabelShape is
inserted in it
- have the property text: working in MORectangleShape
- edges in top of the figure
- fix edges :
this code doesn't work fine:
----
| view |
view := MOViewRenderer new.
view interaction popupText: [:e | e asString].
view nodes: (1 to: 2) forEach: [:each |
view interaction popupText: [:e | e asString].
view nodes: (1 to: 5).
view gridLayout].
view edges: view domain
from: [:ea | ea]
to: [:ea | ea+1]
fromGlobal: false
toGlobal: false.
view open
----
Cheers
---
Jannik Laval
PhD Student - Software Quality - INRIA
Certified Project Management Associate (IPMA)
http://www.jannik-laval.euhttp://rmod.lille.inria.fr
---
Hi All!
I cleaned a bit MOViewRenderer by removing all methods that set event
handlers. In other words, if you were used to write:
view popupText: [:each | ... ].
You now need to do
view interaction popupText: [:each | ... ].
Spring is coming, need to clean a bit.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Jannik,
I fixed the problem you described with the gap. If you now set a
gapSize to 0, you should not get a gap between subnodes and the
encapsulating node.
Let me know whether it is fine.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
With the work of the last few weeks, I am happy to see more and more
tests running green
From 628 tests, 587 are green (I did not run tests for Cook and
others).
I updated the class diagram on the website with the current state,
only retaining Famix-Core package (thus excluding metrics properties)
http://moose.unibe.ch/docs/famix/famix3.0/classdiagram
For the next weeks, from a pure engineering point of view, I think we
should concentrate on streamlining the experience with manipulating,
exporting/importing models, in particular with respect to MSE and its
various format
--
Simon
Can someone explain the difference between the two?
Because currently there are multiple properties with these names, some
in FamixClass, FamixBehaviouralEntity, FamixMethod....
Are they duplicated properties?
--
Simon
Dear All,
I was wondering what should be the correct behavior in Mondrian in VW.
Consider the following scripts:
| view |
view := ViewRenderer new.
view interaction popupText: [:e | 'first level'].
view node: 1.
view node: 2.
view open
the popup appears for the first node only. Is it really the intended
behavior? I would expect the interaction object to be shared between
nodes
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I need the following method from VW to run some tests in SqMoose. Does
anybody have an idea about its licence? Does not seem to be part of
our own extensions :(
It's not especially difficult to reimplement one, anyone can come up
with a Squeak/Pharo equivalent (although it works as is under Pharo,
perhaps there is a better way)
Symbol>>asSortBlock
"Answer a sort block, which evaluates this symbol for both arguments
and compares the resulting values"
| stream |
stream := (String new: self size * 2 + 14) writeStream.
stream
nextPutAll: '[:a :b | a ';
nextPutAll: self;
nextPutAll: ' <=b ';
nextPutAll: self;
nextPut: $].
^Compiler evaluate: stream contents
--
Simon
Hi,
With the version 134 of sqMondrian, the popupText doesn't work fine.
DSM worked before. Now, there is a infinited while when some popups
must appear.
popupText take account only the last popupText. In the example after,
only the text '3rd level' appear, everywhere.
--> in the previous version, it works.
----
| view |
view := MOViewRenderer new.
view interaction popupText: [:e | 'first level'].
view nodes: (1 to: 20) forEach: [:each |
view interaction popupText: [:e | '2nd level'].
view nodes: (1 to: 5) forEach:[:ea |
view interaction popupText: [:e | '3rd level'].
view nodes: (6 to: 10).
view gridLayout].
view gridLayout].
view open
----
Cheers
---
Jannik Laval
PhD Student - Software Quality - INRIA
Certified Project Management Associate (IPMA)
http://www.jannik-laval.euhttp://rmod.lille.inria.fr
---
Hi all,
What is the meaning of FAMIXType ?
I know its subclass is FAMIXClass, but why don't we merge them ?
In FAMIXMethod, the variable parentClass has been changed in parentType.
I think this is less clear.
The problem is that I don't see what is FAMIXType :)
Thanks for your help.
Cheers
Jannik Laval
I ran into the following problem (related to FamixModelExtractionTest
even if it's more general)
(#((1) (3) () ()) flatCollect: [ :each ])
returns
#(1 3 nil nil)
when one expects #(1 3)
flatCollect: is defined in Colllection, I dont want to override it
if possible.
Collection>>flatCollect: aBlock
| stream |
self isEmpty ifTrue: [ ^ self copy ].
stream := (self species new: self size) nsWriteStream.
self do: [ :each | stream nextPutAll: (aBlock value: each) ].
^ stream contents
Can someone find an elegant solution which would "shrink" the
resulting array to its non-nil content?
--
Simon
Hi All,
Just to let you know that the MooseBrowser now contains an import
Pharo package command in addition to the import MSE one.
cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alex,
I have progressed in DSM visualization in pharoMondrian.
Now I need some new features:
- on MOLabelShape, the method fontSize: doesn't work.
- It would be interessant to fix a width to a MOLabelShape.
- When I do subShape, I always have a 2 pixels free space on the right
and the bottom of the shape.
Maybe, we can do this together, next week.
Cheers
Jannik
Dear list
Here is the current version of the Famix3 metamodel, which should
replace the slightly outdated pdf of beta14.
Most importantly, we are asking for reviews, especially to check
whether bidirectional relationships are correct.
--
Simon
Hi All,
What should we do with UtilitiesTest and GroupTest? Some tests are red.
I will fix them over the time...
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi all,
When I would like to import smalltalk code, like this:
---
importer := MooseSqueakClassPackageImporterTask new.
importer importingContext mergeClassAndMetaclass.
importer candidateClass: CandidateListOperator.
importer importerClass: SmalltalkImporter.
importer model: model; addFromPackagesNamed: #( #'Moose-LAN') ; run.
---
I have an exception: message not understood, for the message
#incomingAccesses.
This is in the method FMMultivalueLink>>on: update: from: to:
Thanks for your help.
Cheers
---
Jannik Laval
PhD Student - Software Quality - INRIA
Certified Project Management Associate (IPMA)
http://www.jannik-laval.euhttp://rmod.lille.inria.fr
---
Dear list
With great pleasure I have seen some new activities blossoming around
SqMoose and Famix3 in the last few weeks: porting some projects from
VW (Mondrian, Hismo), using Famix3 (Cook)...
Now it will become increasingly harder to be aware of all changes and
in particular, of current development status for each project.
Since we dont have some kind of continuous integration system right
now, I created a page on the wiki which more or less serves this
purpose:
http://code.google.com/p/moose-technology/wiki/DevLog
I kindly invite any current developer to contribute to this page, so
that we can have a clear picture of where the moose development is
going.
Of course, dont forget the regular issue list for the precise, fully
described issues.
http://code.google.com/p/moose-technology/issues/list
--
Simon
Hi!
I was wondering what is the equivalent of FAMIX2Access>>accessedIn in
Famix 3?
FYI, I am migrating class blueprint in Pharo.
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I just ported it.
Few comments:
- FAMIX 3 is used instead of FAMIX2 (I used MooseEntity instead of
AbstracEntity@VW. AbstractEntity does not exist in Pharo)
- Used Fame Annotation (look at annotation on the class side of Hismo
classes)
The port is not complete however, some test still are still yellow or
red. Maybe someone can help on that.
I also added HismoTest>>testSimple1 to help me understand how to use
histories. The test is yellow, help will be appreciated :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alex,
I guess this mail was aimed at moose-dev :)
Have a look here:
http://moose.unibe.ch/docs/famix/famix3.0/classdiagram
NamedEntity>>parentPackage points to the FAMIXPackage.
NamedEntity>>belongsTo
- points to a ContainerEntity and it describes the language scope
(e.g., FAMIXNamespace)
- however, it is derived (that is why in the diagram it appears with /
in front). In this case this means that it will get overriden in
subclasses to point to something else. This is useful for providing a
polymorphic API for getting to an outer language scope (e.g., from
FAMIXClass to FAMIXNamespace)
Type>>container
- points to the container, and it is not derived.
Type>>belongsTo returns self container
Cheers,
Doru
On 27 Mar 2009, at 23:37, Alexandre Bergel wrote:
> Dear List,
>
> What is the difference between NamedEntity>>parentPackage,
> NamedEntity>>belongsTo and container ?
> I guess one should be for the package, and another one for the
> namespace. But a third?
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
