Hello,
I search a visualization that help me easily to see the evolution of
entities. Something like what you can see in the attached file.
I do not remember what is the name of a such style of visualization
but I just remember that Doru showed me a visualization very similar
on Mondrian but I do not remember what was the name of the methode...
can some one help me to know if a such visualization is implemented
somewhere?
thanks,
Hani
Hi hernan
I will describe the current situation and point to where we need help.
There are two versions of Moose: VWMoose and SQMoose
We are porting VWMoose to SQMoose.
Now in VW
the metamodel FAMIX2.0 is described using the META framework
in Sq
we will be migrating to FAMIX30 which is described using FAME
(already done)
We have FAMIX20 (not totally described in FAME)
Now to support the migration
I'm finishing the importer from Sq -> FAMIX20
So that I can do the importer Sq -> FAMIX30.
I'm currently working
on supporting classVariables reification.
I'm working on the merging of class and metaclass (I'm rewriting some
tests to check name clashes).
For that I started to migrate some methods defined on CodeFoo:
flatCollect, CollectAsSet:....
Now here are a list of points to help:
- fix the Visitor named VWVisitorParseTree since it was based on the
default
VWAST while the importer in VW was using RBVisitor
-> we should migrate the code to RBVisitor
- check the tests
- back port the shortcut we introduced in SqMoose to VWMoose
(normally alex and simon should do that)
the idea is to have
(TheRoot>>#foo) mooseName : may be we should also have
TheRoot m: #foo that returns a moose Name
TheRoot@#AClassVar
to build a method name and a class name
- We need a UI. The idea is to use FAME metadescription and
interpret to build automatically UI (maybe using OB).
- check the pragma to see if this is working
- Migrate FAMIX20 behavior to SQMoose FAMIX20 and FAMIX30.
Now if nobody does it then it will not be there.
- Define FAMIX30 in VW.
Check what should be done to make VWMoose working on top of FAMIX30
- Define Cook extension on top of FAMIX30.
- Start to migrate the other packages of VWMoose
- dynamix
- Check mondrian extension
-
On Oct 19, 2008, at 9:51 AM, Hernán Morales Durand wrote:
> Stephane tu as une liste ToDo ou quelque documentation pour aider
> dans Moose ?
> Bonne journée
>
> Hernán
>
> 2008/10/10 stephane ducasse <stephane.ducasse(a)free.fr>
> hernan
> we are currently porting moose to squeak.
> After we will have DSM, package blueprint, dsitribution map, (check
> our papers).
>
> http://stephane.ducasse.free.fr/Publications.html
>
> Stef
>
>
>
> On Oct 9, 2008, at 5:36 PM, Hernán Morales Durand wrote:
>
>
> 2008/10/9 Lukas Renggli <renggli(a)gmail.com>
> Cool, user interface.
>
> However, you do not detect two other important static dependencies:
>
> - Package A subclasses a class of package B.
> - Package A extends a class of package B.
>
> Yes, I was aware of loose methods (I'm interpreting extends here
> means LM) and hierarchy references, and my idea was to add an
> OBColumn next to the code pane like
>
> http://mail.wiresong.ca/pipermail/ob-dev/attachments/20080923/e19a0b11/atta…
>
> but it seems OmniBrowser do not allow this easily (creating a new
> column in a subclass of the traditional Standard Browser is even
> harder). You'll notice if I'm succeded in the next version :)
>
>
> We are using a similar tool to package Seaside. Unfortunately it has
> no GUI, but we are using GraphViz zu visualize the dependencies [1].
>
> That is the original idea. I have never tried GraphViz, but from the
> image in the link I can see GraphViz is able to ensure disjointness
> between nodes but the image looks confusing, tangled, from an user's
> perception view. It seems like the layout adjustement algorithm were
> unable to preserve symmetries from an input (or breaks down the
> topology for the sake of preserving a proximity model).
>
> Is there a link explaining how to use GraphVIz from Squeak? I
> presume if graphs could be showed inside the Squeak image, the whole
> and details view problem could be solved, achieving simultaneity and
> uniqueness (that means, facilities like the fish-eye view enabling
> different magnification ratios).
>
>
> Have a look at Package-Dependencies in
> <http://source.lukas-renggli.ch/unsorted>. It automatically calculates
> cycles and is able to hide transitive dependencies. It would be
> interesting to extend it further to also take selectors into account,
> that are only implemented in a single package.
>
> I will take a look at it.
> Cheers.
>
> Hernán
>
>
>
> There are other tools available: MudPie [2] and Moose [3].
>
> Cheers,
> Lukas
>
> [1] http://www.lukas-renggli.ch/dropbox/seaside-2.9/seaside.png
> [2] http://map.squeak.org/package/617dbc24-e029-4d8c-a941-68db8c867952
> [3] http://moose.unibe.ch/
>
> On 10/9/08, David T. Lewis <lewis(a)mail.msen.com> wrote:
> > On Wed, Oct 08, 2008 at 03:17:40PM -0300, Hern??n Morales Durand
> wrote:
> > > Dear Squeakers,
> > > If you ever wondered how to observe dependencies between
> packages in the
> > > image, now you can use this new Dependency Browser.
> Instructions for using
> > > it are in the following pages:
> > >
> > > Castellano : http://cs.hernanmorales.com.ar/DBrowser-es.php
> >
> > > Fran??ais : http://cs.hernanmorales.com.ar/DBrowser-fr.php
> >
> > > English : http://cs.hernanmorales.com.ar/DBrowser-en.php
> > >
> > > Regards.
> > >
> >
> > > Hern??n
> >
> > I have not installed this to try it yet, but the DependencyWalker
> looks
> > like a really interesting idea!
> >
> > Dave
> >
> >
> >
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
>
>
>
>
>
Hello,
Really after one hour of thinking that somewhere there is a bug I
found the selectors
InheritanceDefinition>>superClass
and
InheritanceDefinition>>subClass
which are not accessors and they are different of:
InheritanceDefinition>>superclass
and
InheritanceDefinition>>subclass.
Could you please illustrate why we need the selectors #superClass and
#subClass when we have the accessors #superclass and #subclass?
Specially, could you explain why both return a group that will always
contain one, and only one, element?
thanks,
hani
Hi adrian
I was wondering which meta models you have expressed in FAME?
we have FAMIX30. Now did you give a try to model EMOF?
Now do you think that it would be possible to redo the import
of EMOF sara and pierrick did but using FAME?
Of course we would have the same limits with multiple inheritance.
Stef
Hi,
Why the instance variable #belongsTo is initialized in
FAMIXAbstractLocalEntity>>initialize to a symbol value (belongsTo :=
#?)?
what that means?
why it is not initialized to a nil exactly like in any other subclass
of FAMIXAbstractStructuralEntity where this instance variable is not
initialized to any value?
Thanks,
Hani
Hi adrian
I read the fame polygot paper and you mention that it is GPL? Is it a
typo or really the case?
I really hope that else we cannot use it for moose and pharo and our
other projects.
Stef
Hi all
I reintroduced flatCollect: fixing also collectUnion:
I deprecated collectUnion: and replaced all the occurence of
collectUnion: in mooseDevelopment and friends
let me know if this is ok for you.
Stef
I'm confused
Where is the reference implementation for Famix 3.0 right now?
Because when I look at those documents
http://moose.unibe.ch/docs/famix/famix3.0?_s=qCdqiYvltMRJXWPd&_k=KPeddYEX&_…
Famix 3.0 beta 14
it does not match with what I found in the Squeak package. Namely,
there is no incomingInvocations in the FAMIXEntity class. Also some
methods such as Access>>isRead are not implemented.
However, when I look at the generated code with Fame for Java and the
mse file included (FAMIX30.fm3.mse), the attribute incomingInvocations
is defined. However (another problem?), it is declared as an opposite
to Invocation>>candidates, but this one declares
BehaviouralEntity>>incomingInvocations as the opposite.
So, I'm really confused.
--
Simon Denier, PhD
Postdoc, Ptidej Team
DIRO, Université de Montréal
