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."
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