8 Nov
2008
8 Nov
'08
2 p.m.
We should implement this as a default solution.
Doru
On Nov 8, 2008, at 1:51 PM, Stéphane Ducasse wrote:
On Nov 8, 2008, at 12:07 PM, Tudor Girba wrote:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"We cannot reach the flow of things unless we let go."
Hi Johan,
The patch you propose is a reasonable one, although probably better
would be to always return an UNKNOWN_PACKAGE package for a class with
nil packagedIn. But, until then, the patch is Ok.
so do you implement that in VWmoose?
Stef
Sorry for my slow response, too :).
Cheers,
Doru
On Nov 6, 2008, at 9:17 AM, Johan Brichau wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Ricky,
Thanks for your prompt answer (and sorry about my slow response).
You are right. Note that these models were created with
MooseBrewer :-(
In tracing the problems I noted a couple of things about
Moosebrewer-
generated moose models:
- stub famix classes have no package information
- packages are not nested
- more stub famix classes and packages are included than those
available and used inside the concerning eclipse project, leading to
too much information
So, I now made the same models using my Penumbra Eclipse importer
and
the visualisation works just fine now. Thanks for pointing me to the
correct problems.
all the best,
Johan
On 28 Oct 2008, at 14:09, Richard Wettel wrote:
--
www.tudorgirba.com
www.tudorgirba.com/blog
"It's not how it is, it is how we see it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Johan,
Your classes are not linked to the packages they are defined in. A
class history is made of a sequence of class versions, each of
which
refers to a FAMIXClass. Calling packagedIn on your FAMIXClass
objects
returns nil, while it should return a FAMIXPackage.
HTH,
Ricky
On Oct 28, 2008, at 11:34 AM, Johan Brichau wrote:
> Hi guys,
>
> I gave a master student the assignment to play with Codecity and
> other
> Moose tools. We have a couple of strange problems for which I hope
> you
> can shed me some light towards a solution.
> I attach the mse files of the Java project (generated by
> MooseBrewer)
> to this email.
>
> The first problem seems to be in the Moose history part. When
> creating
> a history of these models, a bug appears in the
> SCG.Moose.ClassHistory>>packagedIn method. The "self first
> versionEntity packagedIn" seems to be nil and this method cannot
> cope
> with that. I made a blunt code change to get rid of the problem
> (see
> below), but I hardly think this is the right solution.
>
> A second problem is in the visualisation by Codecity. Although
> each
> model produces a nice city, when trying to visualize the
> evolution,
> some versions produce a completely empty city (blank page in the
> codecity browser). Any ideas on what may cause this and are you
> able
> to reproduce the problem? (I am using the latest Codecity and
> Moose
> 3.2.121, both from the SCG store).
>
> Hope somebody can help ;-)
>
> <AmbientTalk-MSE.zip><ATT00001.txt><ATT00002.txt>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----------------------------
Johan Brichau
johan.brichau(a)uclouvain.be
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev