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 ;-)
---- packagedIn "return the packagehistory it is packaged in" containingPackageHistory isNil ifTrue: [containingPackageHistory := self first versionEntity packagedIn == nil ifTrue: [#nil] ifFalse: [(self referenceHistory allPackageHistories select: [:each | each hasUniqueName: self first versionEntity packagedIn historicalUniqueName]) first]]. ^containingPackageHistory ---------------------------- Johan Brichau johan.brichau@uclouvain.be
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>
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---------------------------- Johan Brichau johan.brichau@uclouvain.be
I'm glad it worked out, Johan.
Cheers, Ricky
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Johan Brichau johan.brichau@uclouvain.be
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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.
Sorry for my slow response, too :).
Cheers, Doru
On Nov 6, 2008, at 9:17 AM, Johan Brichau wrote:
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Johan Brichau johan.brichau@uclouvain.be
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"It's not how it is, it is how we see it."
On Nov 8, 2008, at 12:07 PM, Tudor Girba wrote:
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:
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Johan Brichau johan.brichau@uclouvain.be
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
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:
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Johan Brichau johan.brichau@uclouvain.be
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"We cannot reach the flow of things unless we let go."
Yes this is what I thought too. I'm fixing my house and I will work this evening on moose I guess.
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:
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:
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Johan Brichau johan.brichau@uclouvain.be
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"We cannot reach the flow of things unless we let go."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Doru,
Actually, I solved it now because the Penumbra MooseImporter puts unpackaged types in the 'default' package. I'm not sure if it should be the unknown package though. It might be... The problem appears in models produced by MooseBrewer for all types not contained in a compilation unit (i.e. some/all 'stub' famix classes, representing types for which no source code is available in the eclipse project).
cu Johan
On 08 Nov 2008, at 12:07, Tudor Girba wrote:
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.
Sorry for my slow response, too :).
Cheers, Doru
On Nov 6, 2008, at 9:17 AM, Johan Brichau wrote:
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Johan Brichau johan.brichau@uclouvain.be
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---------------------------- Johan Brichau johan.brichau@uclouvain.be
On Nov 6, 2008, at 9:17 AM, Johan Brichau wrote:
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
hi johan I do not understand well the 3rd item?
Stef
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Johan Brichau johan.brichau@uclouvain.be
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 08 Nov 2008, at 13:50, Stéphane Ducasse wrote:
- more stub famix classes and packages are included than those
available and used inside the concerning eclipse project, leading to too much information
hi johan I do not understand well the 3rd item?
I took a closer look at the differences in the models produced by MooseBrewer and Penumbra/MooseImporter for the same versions of AmbientTalk source code. There were many differences in the number of stub classes and packages between the two models of the same project. It seems that MooseBrewer includes a lot more packages and stub famix classes than necessary in the model. Many stub classes were never actually used in the source code, so the model was too large, containing types and packages that had no relation to the java project at all. I'm sure that my Penumbra/MooseImporter features many other problems too (*sigh* :-). Hopefully, I can get round to finding/testing/fixing them soon.
---------------------------- Johan Brichau johan.brichau@uclouvain.be
-
Johan Brichau -
Johan Brichau
-
Richard Wettel -
Stéphane Ducasse -
Tudor Girba