Hi guys
As I mentioned during the moose workshop we would like to get your
evaluation of our ideas.
I would really like if you could perform the experiment described at:
http://lseg.free.fr/PackageBlueprints/
Stef
Hey Sara,
the issue is fixed, now you can say
SCG.Moose asMetaDescription classes
and get all meta-descriptions of all classes without the annoying
initialize loop.
PS: next week I am in Berlin, I might not have time to fix bugs, but
I am usually available via mail.
cheers,
AA
On 27 Jul 2007, at 15:32 , sellossa(a)ensieta.fr wrote:
> hello,
>
> why, when I do: SCG.Moose asMetaDescription, I get sthing different
> from when I do: SCG.Moose allClasses do: #asMetaDescription.
> ^SCG.Moose asMetaDescription
>
> Stef find it terrible!
>
> sara
Hi,
I have a Smalltalk code with meta description (metamodel* methods). My
goal is to get the meta model associated to the code.
the problem: In my code, for each Class, only the attributes and the
operations are meta-described (thanks to the class methods :
metamodelAttribute1, metamodelOperation1 and so on....). But I have not
found the way to obtain the EMOF Class that describes my class.
Is it possible to get a repository that contains all Emof entities that
correspond to the elements of my smalltalk code?
Today, I tried to do this with FAMIXModel. e.g, I called the class
methods 'metamodelAttribute' 'in FAMIXClass and I got an EMOF entity whose
'owner' was nil!
Moreover, in VisualLauncher class, you define the method
mooseStrictFamixMetaModel. In this method, you do:
'package := (Meta.System reference metamodel elementNamed: 'FAMIX')' but
it returns nil
thank you for your help!
sara
Hi
how do I know which are the metamodels that are loaded in visualworks?
Is there a repository for metamodels? I thought marc stetller
implemented one
but it was never up to the point to be integrated in Moose.
Stef
Hi,
First of all, thanks for reporting this. I have fixed the problem in
MooseDevelopment 3.2.42.
Second of all, I would like to ask you to use also the Bug Tracking
System for such reports:
http://macamis.unibe.ch/trackers/moose/
It makes it much easier for us to track what needs to be done.
Even better is to also provide a test that fails :).
Cheers,
Doru
From: tverwaes(a)infogroep.be
Subject: [Moose-dev] Re: MooseModel and namespaces
Date: July 18, 2007 10:19:36 PM GMT+02:00
To: moose-dev(a)iam.unibe.ch
I have exactly the same effect with any namespace I import (for
namespaces imported as side-info as well as namespace which I am
importing). It would be nicer if they would actually be nested since
one of the clustering algorithms uses the recursiveClasses (which
currently gives back exactly the same as classes), and which would
automatically be nested in the cluster browser...
Reproducing just comes down to loading whatever namespace which has
subnamespaces (SCG?) and inspecting it :)
Toon
On (18/07/07 09:15), Adrian Kuhn wrote:
> From: Adrian Kuhn <akuhn(a)gmx.ch>
> To: sellossa(a)ensieta.fr
> Cc: Moose-dev Bugs <moose-dev(a)iam.unibe.ch>
> Subject: [Moose-dev] Re: MooseModel and namespaces
> Date: Wed, 18 Jul 2007 09:15:07 +0200
>
> Hey Sara,
> please provide a sample mse file, such that we can try to reproduce
> the bug.
>
> AA
>
> On 17 Jul 2007, at 22:51 , sellossa(a)ensieta.fr wrote:
>
>
>> Hi!
>>
>> I have a question concerning the structure of a MooseModel.
>>
>> Imagine that we have a project with three Namespaces: Namespace A,
>> NamespaceB, NamespaceC. In my project, NamespaceA contains
>> NamespaceB and
>> NamespaceC.
>> Then, I import the project in Moose and I get a MooseModel with my
>> three
>> namespaces.
>>
>> When I inspect NamespaceB and NamespaceC, I can see (thanks to the
>> attribute 'belongsTo') that they both belong to NamespaceA
>> Nevertheless, when I inspect NamespaceA, I realise that attribute
>> 'namespaces' is an empty OrderedCollection.
>>
>> Is it normal? Because I think that 'namespaces ' should contain
>> NamespaceB
>> and NamespaceC, isn't it?
>>
>> thanks
>>
>> Sara
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.iam.unibe.ch/~girbawww.iam.unibe.ch/~girba/blog/
"The coherence of a trip is given by the clearness of the goal."
Hi,
I noticed this morning that the test testSize of the EssentialMOFTest test
case is broken :
I looked for the reason of this : there were two problems
- My friend sara accidentaly declared one of her test case in the EMOF
nameSpace
-the method EMOF.Element>>createMetaClass now includes : "class
addComment: self commentMetaClass" witch add a EMOF.Comment 'The root of
the EMOF implementation' to all the element of the EMOF metamodel because
of the inheritance ...
Am I the only one to face this small problem ?
Do you want I to fix it ?
