I loaded the latest Mondrian packages into Damien 3.10 dev on OSX in this
order
- announcements
- mondrian
- mondrian paintings
Running all 26 tests gave 16 errors.
MOFormsBuilderTest testAdvancedApi sort-of hangs the image (drawing not
displayed until I Alt-. interrupt). I occasionally see MNU for
MOLabelShape>>width
Am I using an incorrect version/combination?
Thanks ~ Sophie
Hi doru
I would like to know what is the status of isStub in Famix30?
I'm trying to get that working in FAMIX30
I have
FAMIXEntity stub: aBoolean
self isStub: aBoolean
and isStub: is defined only on and EntityState
FAMIXNamedEntity isStub: aBoolean
isStub := aBoolean
Then in
MinimalState isStub: boolean
[boolean == false] assert
I imagine that the code above is only used when there is no property
EntityState isStub: boolean
^self attributeSet: #privateIsStub value: boolean
Sorry if this is a repeat, not sure if my first post came through.
Is it possible with Mondrian to do any of the following:
- generate labels on graph edges e.g. names of association ends in a UML
class diagram?
- generate nodes like class nodes (with name, line, attributes list, etc.)?
- possibly with some layout coding, generate component-port-connector
models: labeled boxes, labeled lines between boxes, labeled mini-boxes on
the edges of the connections
- Are these reasonable usages of current Mondrian capability?
Thanks!
Hi doru
right now isAbstract and isPublic are in the Famix-Smalltalk and I
think that they should be in core.
After we could have isPackageProtected for Java in Famix-Java.
Stef
Is it possible with Mondrian to generate labels on graph edges e.g. names of
association ends in a UML class diagram? And to generate
nodes like class nodes (with name, line, attributes list, etc.)? Are these
reasonable usages of Mondrian?
Thanks!
Hi guys
in Famix30 we would like to have the isStub property to false.
Since marking as a stub is really something that we do on purpose when
for example
an access does not find the instance variable it should get.
Tell me what us think.
Stef and Jannik
I suppose that the following list of pragmas means that I have a
collection of behavior entities
Is is correct?
<MSEProperty: #candidates type: #FAMIXBehaviouralEntity opposite:
#incomingInvocations> <multivalued>
Now it means that I cannot interpret the first pragma in isolation?
I not sure I like that design
Stef
Hi
I would like to know (may be it would be good to have a FAMIX30
document even a draft)
- because this is really frsutrating to work on FAMIX30 in the dark -
what is the mapping between
FAMIX2Invocation and FAMIX3Invocation
in invokes -> signature
Stef
Hi
in FAMIX20 in FAMIXInvocation we have cleaarCandidates
clearCandidates
self candidateList: nil
Now how to I code that in presence of FMMulti*Link
since in FAMIX30 candidates are stored in FMMulti*Link
Could not we rename the protocol value: of FMMultiValue: with contents
because each time I read it
I wonder what is the block?
Thanks
Hi all
in SqMoose I coded the classVar, class instVar and instance var in
presence of merging.
I will do the same in Famix30.
Then I will port that in VWMoose.
Stef
Hi all, me again,
with CookHITS 6.45
I do get in
viewPackagesArchitectureWithHitsOn: view
something like
view interaction popupText: [:entity :popupView | entity name asString]
which gets handled as
popupText: aBlock
self onMouseEnter: [:entity | Mondrian.Popup show: (aBlock value: entity)].
which gives exception dialogs popping up frequently.
Hope that I didn't load some wrong configuration.
This offers indeed very useful views; thanks a lot.
Thomas Schrader
--
mailto thomas j schrader at web de
___________________________________________________________________
Kennen Sie schon die Blockbuster-Aktion von WEB.DE?
Jeden Monat 2 Freifilme sichern unter http://www.blockbuster.web.de
Hi everybody,
with CookFingerprintViews 9.12
I do get in FAMIXPackage>>serializedStaticReferencingPackages
someCollection := someCollection sort: [bla]...
This is IMHO erroneous.
Regards
Thoms Schrader
--
mailto thomas j schrader at web de
____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
Dear Radu and members of the Moose-List,
I am not sure whether my question is specific to moose or iPlasma, but
I think that it is of a general interest. Are dependencies between
Java classes extracted using iPlasma from the .java files? To
illustrate this, let's assume I have these two classes:
public class A {}
public class C { A a;}
The relation "C refers to A" does not seem to be contained in the .mse
file. The attribute 'a' is defined as:
(FAMIX.Attribute
(id: 17)
(name 'a')
(belongsTo (idref: 15))
(hasClassScope false)
(accessControlQualifier package)
(NMAV 0.0)
)
No ref to 'A' therefore.
In Java4Moose, I extended the FAMIXClass with dependentClasses, that
returns a list of FAMIXClass that are statically referenced in the
receiver famix class. I principally did this as an exercise, but it
seems that this information is missing in famix. Doru, you told me at
the famoosr workshop that iPlasma extract static dependency. Where
does this appear?
Regards,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Jannik,
edges: aCollection from: fromBlock to: toBlock defines a one to one
relationship between "fromBlock value: each" and "toBlock value:
each" (if you use a symbol instead of a block, it will just be
performed on each)
This works well for single inheritance, because given a class there is
just one superclass. However, in your case, you want to draw several
edges from one class.
In this case, you can use edges:fromAll:to, or edges:from:toAll:.
These still expect blocks, only the result of an "All block" should be
a collection of entities.
Cheers,
Doru
On Nov 18, 2008, at 10:48 AM, Jannik.laval.inria wrote:
> Hi Doru,
>
> I am using Mondrian, and I have a problem with edges.
>
> When I do
> aView edgesFrom: #superclass.
> I have edges from superClasse to each.
>
> Now, I would like to have classes used by each.
> So I do
> aView edgesFrom:#accesses.
> Maybe it is because accesses is a collection ?
> Can you help me ?
>
> Also, I would like to know what are the type of parameters in
> functions edgesFrom: , edgesFrom:To: and edges:From:To:
>
> Thanks for all
>
> Jannik
--
www.tudorgirba.comwww.tudorgirba.com/blog
"Some battles are better lost than fought."
Hi,
I have updated moose.unibe.ch :
- a less busy look
- up to date Pier version
- updatable publication list (you have to be logged in as
administrator and edit and save the complete list page)
Let me know what you think.
Cheers,
Doru
--
www.tudorgirba.comwww.tudorgirba.com/blog
"There are no old things, there are only old ways of looking at them."
Begin forwarded message:
> From: Radu Marinescu <radu.marinescu(a)cs.upt.ro>
> Date: November 7, 2008 5:48:16 PM CEST
> To: Doru Girba <girba(a)iam.unibe.ch>, Alexandre Bergel <Alexandre.Bergel(a)inria.fr
> >, Stéphane Ducasse <stephane.ducasse(a)inria.fr>, Menanteau Jannick <jannick.menanteau(a)free.fr
> >
> Cc: LOOSE Research Group <lrg(a)cs.upt.ro>
> Subject: iPlasma 6 Released!
>
> Dear all,
>
> I just want to announce that the much promised release of a new
> version of iPlasma eventually happened this evening :)
>
> The new version, can be downloaded from the traditional location:
> http://loose.upt.ro/iplasma/iplasma.zip
>
> ...and it has some good news, especially for the MOOSE community:
>
> 1. the duplicated library classes from exported MSE file are finally
> gone!
>
> 2. the exported MSE file includes now also information about Java
> annotations (both definitions of Annotations and usages). However,
> note that for good results on usages of Java annotations from
> libraries, you have to identify and include in the classpath of
> iPlasma the JARS containing the definitions of those annotations.
>
> 3. for Mac users there is additional good news: the bug that
> appeared due to the latest Java update from Apple has been removed
> (thanks Dan for the help on this !)
>
> In case you want to play with iPlasma beyond generating an MSE
> files, there are more good news:
>
> 4. We added several metrics and detection of problems related
> related to packages (e.g. compute the "Instability Factor" and
> detect breaking of Stable Dependencies Principle and Stable
> Abstractions Principle)
> 5. We included some new visualizations (Method Interaction,
> Attribute Usage, Instability-Abstraction plot and a modified version
> of the System Complexity View where one can see if a class is
> affected or not by design problems)
> 6. There are more details about design problems in the HTML-like
> Detail View
> 7. At any time the current detail can be saved as HTML by pressing
> the "Save" button (placed on top of the Detail View). The HTML file
> will be automatically placed in the "iPlasma6/results" folder.
>
> I hope you will enjoy it and please feel free to report any
> problems. We will do our best to correct them.
>
> cheers,
> radu.
>
> -----
> Use Eclipse? Try inCode!
> www.intooitus.com/inCode.html
>
>
>
>
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(a)uclouvain.be
Hi
I will implement the following and I would like to let you know so
that you can give feedback
when we do not merge a class and its metaclass the instance variable
of a metaclass could have
an instanceScope since it is true that the instance variable is an
instance one.
Now when we merge a class and its metaclass the class instance
variable should have a class scope since
from the base class it is clearly a class scope variable.
For shared this is simple they are shared and have a classScope.
Now from a user point of view I would like that an analysis does not
depend on whether we
merged or not the class and metaclass. So I will put classScope to
instance variable of the metaclass
even when they are not merged with the base class.
This way we always get the following situation
isntance varaible -> instanceScope
class instance variable -> classScope
shared -> classScope + isShared
Let me know what you think since I will implement the following and
write tests.
Stef
I'm looking into the SmalltalkMethodVisitor for Famix3 and in
particular how it builds FamixInvocation entity
However there is a receivingVariable attribute in Famix2::Invocation,
for which I cant find a substitute in FamixInvocation. How should I
deal with this data?
SmalltalkMethodVisitor>>acceptMessageNode:
(...)
aMessageNode receiver isVariable
ifTrue:
[invocation
setReceivingVariable: (self resolve: aMessageNode receiver name)].
(...)
--
Simon
Hi hani
I was checking your code. I do not think that this is correct.
Did you read the email we sent about the topic before summer holidays
on this topic?
AbstractStructuralEntiy>>isStub
"a FAMIXStructuralEntity is stub if its declared as stub or if it
belongs to a stub famix element, or if we do not know really it
belongs to which famix entity (self belongsTo isSymbol -> istrue)"
^super isStub or: [self belongsTo notNil and: [self belongsTo
isSymbol or: [self belongsTo isStub]]]
FAMIXInvocation>>isStub
"a FAMIXInvocation is stub if all its candidate -invoked- methodes,
are stub, or if the invocation is done by a stub method, or if the
invocation has no candidate"
^self candidateList isNil
or: [self candidateList isEmpty
or: [(self candidateList allSatisfy: [:mtd| mtd isStub])
or: [self invokedBy isNil or: [self invokedBy isStub]]]]
Stubbyness is an import property and it is not transitive.
You can have an attribute that is imported and its class is a stub
because the importer leaked.
Now of course this situation does not make sense but this is the state
of the import (we would all prefer that this
imported did not leak but it is in C++ and we do not control it).
Now you need to compute a new property called for example
completelyImported.
So we prefer that you introduce an extra property (related to
stubbyness)
and that thes methods are dealing with this.
So I will remove these two methods from Moose and invite you to define
a completelyImported property and its computation.
If you follow our suggesting we will integrate them in Moose if there
are tests.
Stef and Doru
Hi
I would really like to change the isStub code to reflect what is it
and that hani provide
us completelyImported methods for the model.
Is it ok?
Stef