Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

How can I reset a FMMulti*Link
by stéphane ducasse 20 Nov '08

20 Nov '08

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

2 1

InvocationTest passes in FAMIX30 :)
by Stéphane Ducasse 20 Nov '08

20 Nov '08

hehehe. Stef

2 1

classVar, class inst var and...
by Stéphane Ducasse 20 Nov '08

20 Nov '08

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

2 1

[Cook] popupText: is called with two-argument-block
by Thomas Schrader 20 Nov '08

20 Nov '08

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

3 2

[Cook] Collection>>sort: gives a Sorter, not another Collection
by Thomas Schrader 19 Nov '08

19 Nov '08

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

1 0

Dependency between Java classes
by Alexandre Bergel 18 Nov '08

18 Nov '08

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 3

Re: Moose edges
by Tudor Girba 18 Nov '08

18 Nov '08

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.com www.tudorgirba.com/blog "Some battles are better lost than fought."

5 5

moose.unibe.ch facelift
by Tudor Girba 11 Nov '08

11 Nov '08

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.com www.tudorgirba.com/blog "There are no old things, there are only old ways of looking at them."

3 2

Fwd: iPlasma 6 Released!
by Stéphane Ducasse 10 Nov '08

10 Nov '08

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

6 12

some problems using Codecity
by Johan Brichau 10 Nov '08

10 Nov '08

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

5 10

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev