- Moose-dev - INF Mailman

by Hani ABDEEN

new version of Moose Development FAMIXMethod>>isStub isStub "a fAMIXMethod is stub if it is declared as stub or if it belongs to a stub class" ^super isStub or: [self belongsTo isStub].

16 years, 10 months

2
4
0 0

FAMIXPackage>>isStub

by Hani ABDEEN

a new version of Moose Development: FAMIXPackage>>isStub isStub "a fAMIXPackage isStub if it is declared as stub or if all its classes and the classes extended in it are stubs -Note that in the last case it should contain at less one class or extended class-" ^super isStub or: [(self definedClasses isEmpty and: [self extendedClasses isEmpty]) not and: [(self definedClasses allSatisfy: [:each | each isStub]) and: [self extendedClasses allSatisfy: [:each| each isStub]]]] ----> one related test is fixted: when a package has no class it is not surely a stub.

16 years, 11 months

1
0
0 0

FAMIXNamespace>>isStub

by Hani ABDEEN

a new version of Moose Development: FAMIXNamespace>>isStub isStub "a fAMIXNamespace isStub if it is declared as stub or if all its classes are stubs -Note that in the last case it should contain at less one class-" ^super isStub or: [self classes isNotEmpty and: [self classes allSatisfy: [:each | each isStub]]].

16 years, 11 months

1
0
0 0

FAMIXInvocation>>isStub

by Hani ABDEEN

a new version of Moose Development: FAMIXInvocation>>isStub isStub "a FAMIXInvocation is stub if it has at less one candidate -invoked- methode, if one of the candidate methods is stub, or if the invocation is done by a stub method" ^self candidateList isNil or: [self candidateList isEmpty or: [(self candidateList anySatisfy: [:mtd| mtd isStub]) or: [self invokedBy isStub]]]

16 years, 11 months

1
0
0 0

FAMIXInheritanceDefinition>>isSub

by Hani ABDEEN

I published a new version of Moose Development in which i implemented FAMIXDefinition>>isStub in this way: isStub "a fAMIXInheritanceDefinition is stub if any of the subclass or the superclass is stub" ^self superclass isStub or: [self subclass isStub]

16 years, 11 months

1
0
0 0

FAMIXAccess>>isStub

by Hani ABDEEN

I published a new version of Moose Development in which i implemented FAMIXAccess>>isStub in this way: isStub "a fAMIXAccess is stub if it accesses a stub moose element or if it is done by a stub moose element" ^self accesses isStub or: [self accessedIn isStub].

16 years, 11 months

1
0
0 0

FAMIXAbstractStructuralEntity>>isStub

by Hani ABDEEN

I published a new version of Moose Development in which i implemented FAMIXAbstractStructuralEntity>>isStub in this way: isStub "a fAMIXStructuralEntity is stub if its declared as stub or if it belongs to a stub famix element" ^super isStub or: [self belongsTo notNil and: [self belongsTo isStub]]

16 years, 11 months

1
0
0 0

famoosr 2008

by Tudor Girba

Hi, A new edition of the Workshop on FAMIX and Moose in Reengineering (FAMOOSr 2008) will be collocated with Working Conference on Reverse Engineering (WCRE 2008) to be held in Antwerp. The workshop will last for half a day and it will take place on October 16 or 17. The deadline for submissions is: September 8. More details about the workshop can be found on the official webpage: http://moose.unibe.ch/events/famoosr2008 Cheers, Doru -- www.tudorgirba.com www.tudorgirba.com/blog "Every now and then stop and ask yourself if the war you're fighting is the right one."

16 years, 11 months

1
0
0 0

MooseElement->mooseID?

by Hani ABDEEN

Hi, the mooseID of a mooseElement object, should it be unique : (a) in the scope of all the loaded models in moose, (b) or only in the scope of the mooseElement's mooseModel? bests, hani

16 years, 11 months

3
2
0 0

to get a google code entry

by stéphane ducasse

Hi all Since we cannot get moose may be we should ask for another name. MooseDev? Do you have any other suggestion? Stef

16 years, 11 months

1
0
0 0

SCGStore: adding an account for Jannick

by Alexandre Bergel

hello, Would it be possible to add an account for Jannick on scg store? He is working on Moose. first name: jannick familly name: menanteau Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

16 years, 11 months

2
1
0 0

Some thoughts...

by Alexandre Bergel

Dear moose mailing list, For Pharo, we setup a protocol for including new fixes in the distribution. Maybe this protocol may be adopted for moose. Maybe something similar exists already and that I am not aware of. In that case I apology. http://code.google.com/p/pharo/wiki/HowToContribute Regards, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

16 years, 11 months

1
0
0 0

overriden methods count twice

by Menanteau Jannick

Hi all, I have noted that when I use FAMIXClass>>numberOfMethodsInherited on LAN, result for LAN::PrintServer is 14. But there are 3 methods overriden (canOutput, accept: and output:) I think the good result would be 11. Is it true ?

16 years, 11 months

1
0
0 0

importing from an MSE file does not work

by Richard Wettel

Hi, I stumble (again) into the same problem. When importing from an MSE file, I get a MNU exception for #accessedByList on the FAMIXNamespace UNKNOWN_NAMESPACE. Is this something you are aware of? I run on top of the latest MooseDevelopment (loaded Moose Config). Thanks, Ricky

16 years, 11 months

4
10
0 0

MooseModel copy/deepCopy?

by Hani Abdeen

Hi, How can I have a duplication of a mooseModel (for example the model that represents Mondrian namespace)? exactly like if I imported agin the namespace Mondrian: there is no entity in the duplication that has pointers to entities in the original model. For example, the accesses of a method 'mtd1' into the duplication should not point to classes into the original model. bests, hani

16 years, 11 months

2
1
0 0

How to only import in a MooseModel the selected packages in the MooseBrowser?

by Romain PEIRS

Hi, I would know if there is a mean to only import in a MooseModel the selected packages in the MooseBrowser? For example, when I import the bundle Moose in Moose Browser, I would only have in the MooseModel the packages of the bundle. I hope it was clear. Romain

16 years, 11 months

4
5
0 0

How to load automatically packages on which depend packages which I want to publish?

by Romain PEIRS

Hi, I would know how to load automatically packages on which depend packages which I want to publish? Anyone knows how to do that? Thanks J Romain

16 years, 11 months

3
3
0 0

About a model of changes on top of famix

by Stéphane Ducasse

let us imagine that we would like to see what would happen if we would move a class A from package P1 to P2, without changing the source code and may be been able to undo the change Solution A: We could copy the complete model, modify it. (and keep somewhere an history) Solution B: We could change the model and keep an history of the changes (move A P1 P2). Solution C: I could cache in each model a timestamp similar to what frederic pluquet did and know at which version modification we are. then for a given changes I could get the model by getting entity at the same level or lower. Any thoughts on that. I have the impression that solution B is easier. stef

16 years, 11 months

4
3
0 0

Moose Dojo at ESUG

by stephane ducasse

Hi doru I anounced a Moose Dojo at ESUG. Could you update the moose.unibe.ch web pages. Alex it would be good to improve the description and to announce it in other forums. http://www.esug.org/conferences/16thinternationalsmalltalkjointconference20… Stef

16 years, 12 months

4
7
0 0

Re: famix and fame

by Adrian Kuhn

A word about addTo* methods and slots vs links Fame offers two implementations for properties. If you use links instead of slots, you do not need addTo* methods because the collection returned by a getter is "hot". As far I know the current code generation uses slots, whereas the hand-written code of FM3 uses links. So what is the difference? In short: slots implement the "end" of each property, where as links model the "association" established by the property. For a large project, as eg Moose, I personally suggest to use links instead of slots! Why? Links are less code (not *slot method) Links are less memory (not wrapper objects at 1-end) Links are hot (add and remove on returned collection) Links are more debuggable (no wrapper in the way) @Toon ... this is your call to arms, what are the advantages of slots? :) But first a general issue, why slots or links at all? To automatically update the opposite of an association. A half-only established association is one of the worst bugs in a data-model, it is, to say so, the blink dog of software engineering. Half of the time it works, half of the time not. Hence we decided to make associations a first-level citizen in Fame. Considering Library and Book as an example of a multivalued, ie ( 1 : n ) property, an implementation using slots looks like this Library >> initialize books := FMManySlot new on: self; oppInstVar: #library; youself Library >> books <MSEProperty: #books type: Book opposite: #library> <multivalued> ^books values Library >> books: allBooks books set: allBooks Libary >> booksSlot ^books Library >> addToBooks: aBook aBook libary: self Library >> removeFromBooks: aBook aBook library: nil Book >> initialize library := OneSlot new owner: self; oppInstVar: #books; yourself. Book >> library <MSEProperty: #library type: Library opposite: #books> ^library value Book >> library: newLibrary library set: newLibrary Book >> librarySlot ^library And code to add / remove a book to / from a library like aLibrary addToBooks: newBook aLibrary removeFromBooks: aBook And an implementation using links looks like this Library >> initialize books := FMMultivalueLink on: self opposite: #library Library >> books <MSEProperty: #books type: Book opposite: #library> <multivalued> ^books Library >> books: allBooks books value: allBooks Book >> initialize library := nil Book >> library <MSEProperty: #library type: Library opposite: #books> ^library Book >> library: newLibrary library := FMMultivalueLink on: self update: #books from: self library to newLibrary And code to add / remove a book to / from a library like aLibrary books add: newBook aLibrary books remove: aBook Please note, this is not a violation of the Law of Demeter, since accessing the elements of a container class (ie collection) does not account as "talking" in the sense of the law's "never talk to strangers". As you can see, using links there is no special need for those notorious add / remove methods. cheers, AA > Hi, > > Today, Toon and me worked on Fame and FAMIX in Squeak. We regenerated > FAMIX and the results are: > > - Added addTo* like methods (for example, FAMIXClass>>addToMethods: > aMethod). The reason why it's not just addMethod: is due to us being > unable tofind a simple and robust algorithm for producing English > singular. Also, just taking the type into account is not enough > because of cases like incomingInvocations and outgoingInvocations. > > - Changed the names of parameters to reflect whether they are > collections or not. > > - Made the Smalltalk superclass to be MooseEntity. > > > We also worked on creating the meta-repository for FAMIX and we also > have MSE files with FAMIX models loading. There still some work to be > done to populate the MooseModel. > > I also fixed the loading error related to FMBookMock and fixed some . > I will continue with working on the Moose Finder over the next days. > > Doru > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Value is always contextual."

17 years

6
7
0 0

Symbols not define

by Menanteau Jannick

Hello, I'm beginning with moose and I've a problem with Mondrian I want to generate visualization with this code : view newShape rectangle; height: #numberOfMethods; width: #numberOfAttributes; linearFillColor: #numberOfLinesOfCode within: classes; withBorder. view nodes: classes. view edges: classes from: [:each | each superclass] to: [:each | each]. view treeLayout. I think it's correct because I've found it on http://moose.unibe.ch/tools/mondrian/tour?_s=LrcZtOGEBQIygSJg&_k=RnnrLpmU&_… But I've problem with symbols (like #numberOfMethods) : they are not defined. Maybe there is a special manipulation to do ? I've done this : - open Moose - "Open in Mondrian Easel" - inset this code in the window - "generate view" Thanks to help me

17 years

2
4
0 0

Re: Tests Mondrian

by Alexandre Bergel

Hi Jannick! Glad to hear that you jump on the boat! Best would be to ask the moose mailing list. You may want to register the mailing list for this. I do not have the answer right now. Cheers, Alexandre On 27 Jun 2008, at 14:51, jannick.menanteau.gmail wrote: > J'essai de générer des visualisations dans Mondrian: > > view newShape rectangle; height: #numberOfMethods; width: > #numberOfAttributes; linearFillColor: #numberOfLinesOfCode within: > classes; withBorder. > view nodes: classes. > view edges: classes > from: [:each | each superclass] > to: [:each | each]. > view treeLayout. > > C'est un code trouvé sur http://moose.unibe.ch/tools/mondrian/tour?_s=LrcZtOGEBQIygSJg&_k=RnnrLpmU&_… > > Le problème est que les symboles (#numberOfMethods par exemple) ne > sont pas définis... > Y a-t-il une manipulation spécifique à faire ? > > Voici comment j'ai procédé : > - ouverture de Moose > - "open in Mondrian Easel" > - insertion du code dans la fenêtre au centre bas > - "generate view" > > Merci > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

17 years

1
0
0 0

google code

by Orla Greevy

Hi, did someone set up the google code for Moose? If so can you send the link... Orla ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

17 years

2
4
0 0

group?

by stéphane ducasse

Hi doru in Squeak I started to get some green tests :) Now if you load and try to run testClassSides you get an error because allClasses does not return a model but a collection. classSide ^self isClassSide ifFalse: [self mooseModel allClasses entityNamed: (self mooseName , '_class') asSymbol] ifTrue: [self] can you have a look? Stef

17 years

1
0
0 0

Layering in moose

by stéphane ducasse

Hi Doru There are several methods in MooseFamixModel that depend on MooseFamixExtensions. I suggest to move them there. Do we agree? - la méthode hasSubclasses dans FAMIXClass (Root::Smalltalk::SCG::Moose::FAMIXClass.hasSubclasses()- >numberOfChildren()) - la méthode hasSuperclasses dans FAMIXClass (Root::Smalltalk::SCG::Moose::FAMIXClass.hasSuperclasses()- >numberOfParents() ) - la méthode hasEmptyBody dans FAMIXAbstractBehaviouralEntity (2 invocations: Root ::Smalltalk::SCG::Moose::FAMIXAbstractBehaviouralEntity.hasEmptyBody()- >numberOfAccesses() et Root ::Smalltalk::SCG::Moose::FAMIXAbstractBehaviouralEntity.hasEmptyBody()- >numberOfOutgoingInvocations() ) Then in MooseUI mooseKill <menuItem: 'Kill' nameKey: nil menu: #(#menuBar #tools #mooseUtilities) position: 1> SCG.Moose.MooseModel kill depends on MooeUIExtensions So may be we should move it there. Stef

17 years

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev