Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

FAMIXAbstractStructuralEntity::belongsTo
by Hani ABDEEN 17 Oct '08

17 Oct '08

Hi, Why the instance variable #belongsTo is initialized in FAMIXAbstractLocalEntity>>initialize to a symbol value (belongsTo := #?)? what that means? why it is not initialized to a nil exactly like in any other subclass of FAMIXAbstractStructuralEntity where this instance variable is not initialized to any value? Thanks, Hani

3 6

Is FAME really GPL
by stephane ducasse 16 Oct '08

16 Oct '08

Hi adrian I read the fame polygot paper and you mention that it is GPL? Is it a typo or really the case? I really hope that else we cannot use it for moose and pharo and our other projects. Stef

2 2

flatCollect: reintroduced
by Stéphane Ducasse 15 Oct '08

15 Oct '08

Hi all I reintroduced flatCollect: fixing also collectUnion: I deprecated collectUnion: and replaced all the occurence of collectUnion: in mooseDevelopment and friends let me know if this is ok for you. Stef

3 3

Reference implementation for Famix 3.0?
by Simon Denier 13 Oct '08

13 Oct '08

I'm confused Where is the reference implementation for Famix 3.0 right now? Because when I look at those documents http://moose.unibe.ch/docs/famix/famix3.0?_s=qCdqiYvltMRJXWPd&_k=KPeddYEX&_… Famix 3.0 beta 14 it does not match with what I found in the Squeak package. Namely, there is no incomingInvocations in the FAMIXEntity class. Also some methods such as Access>>isRead are not implemented. However, when I look at the generated code with Fame for Java and the mse file included (FAMIX30.fm3.mse), the attribute incomingInvocations is defined. However (another problem?), it is declared as an opposite to Invocation>>candidates, but this one declares BehaviouralEntity>>incomingInvocations as the opposite. So, I'm really confused. -- Simon Denier, PhD Postdoc, Ptidej Team DIRO, Université de Montréal

5 12

About classVar in presence of metaclass /class merging
by stephane ducasse 12 Oct '08

12 Oct '08

Hi all I'm fixing the classVar/sharedVar import in SqMoose and after I will do it in VW. Now I have a question: when we make the distinction between a class and its metaclass this is easy. when we merge a class and its metaclass: a metaclass instVar will become a "class variable" But we really need a way to make the distinction between a sharedvariable and merged class inst var. so I would like to have isShared in attribute or SmalltalkFamix extension: how do I do that in Famix20? Famix30? Then if I have the same variable name at the instance and class side when I merge I have a conflict with name and the importer will break. So I could modify the importer to have another mapping and let in the resulting model two attributes with the same name but different scope or I could modify the name of the mapped class inst var with something like CL-x (would means I was a class var but I was merged). Of course this solution is uglier but easier to implement. Stef

3 7

Question on Mondrian
by Alexandre Bergel 12 Oct '08

12 Oct '08

Dear List, I was wondering why the following script does not have red and 5 pixels wide edges: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | domain | domain := 1 to: 30. view newShape rectangle; withBorder; line; lineWidth: 5; lineColor: ColorValue red. view nodes: domain. view edgesFrom: [:v | v * v]. view circleLayout -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I am probably doing something wrong, but haven't see what. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 4

question about class variables
by Stéphane Ducasse 12 Oct '08

12 Oct '08

Hi I was thinking that a classVar should always belongs to its class TheRoot class@TheSharedClassVar belongsTo -> TheRoot and not the TheRoot class. TheRoot@TheSharedClassVar belongsTo TheRoot I will implement it like that. Tell mewhat you think else we could have a mess. Stef

2 1

some points
by Stéphane Ducasse 10 Oct '08

10 Oct '08

Hi all In SqMoose we added the following testMooseNameOfCompiledMethod "self debug: #testMooseNameOfCompiledMethod" self assert: (TheRoot class>>#accessInstanceVariable) mooseName = #'Smalltalk::TheRoot_class.accessInstanceVariable()'. self assert: (TheRoot>>#accessingClass) mooseName = #'Smalltalk::TheRoot.accessingClass()'. "May be we could fix that too. using another notation so that we could use the notation create method name too" self should: [ (TheRoot>>#zork) mooseName ] raise: Error. testMooseNameOfInstanceVariable self assert: (TheRoot@#x) = #'Smalltalk::TheRoot.x'. "contrary to compiled method notation we do not garanty that the class has an iv" "we could! Now do we want" self assert: (TheRoot@#foo) = #'Smalltalk::TheRoot.foo'. self assert: (TheRoot class@#mx) = #'Smalltalk::TheRoot_class.mx' testMooseNameOfClassVariable "self debug: #testMooseNameOfClassVariable" self assert: (TheRoot@#TheSharedVariable) = #'Smalltalk::TheRoot.TheSharedVariable'. "contrary to compiled method notation we do not garanty that the class has an iv" "we could! Now do we want? We could also have @@ for class variables." "now the name of shared variable is always its class and not its metaclass" self assert: (TheRoot class @#TheSharedVariable) = #'Smalltalk::TheRoot.TheSharedVariable'. Now for compiled methods we could have a different way of doing it to be able to build any names. stef

1 0

Another question
by stéphane ducasse 09 Oct '08

09 Oct '08

Hi I was reading MooseElement>>mooseID "Returns an unique identifier of this entity. This method is mandatory, and must return an Integer that unqiuely identifies this entity within the entire Moose environ- ment. The return value must not be nil, and must never change." nil = mooseID ifTrue: [mooseID := MooseModel freshID]. ^mooseID and I wonder why this is MooseModel freshID since freshID is only implemented on MooseElement class>>freshID Stef

3 4

certainly a stupid question
by Stéphane Ducasse 09 Oct '08

09 Oct '08

Hi what is FMMultivalueLink? parentClass: aType parentClass := FMMultivalueLink on: self update: #attributes from: self parentClass to: aType parentClass set: aType I'm probably too stupid to understand but let us try. I do not understand why at the metamodel level I need to have in the runtime objects of the metametamodel. Long long time ago I did a stupid code generator that took a stupid MMModel and generated plain code for the metamodel. Why this is not like that with FAMIX30 in the latest version? why do we trade space **and** speed for a meta stuff? So do I have to code a code generator? Or just replace all the FMMultivalueLink myself? I'm confused I thought that the new FAME was better. Stef

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev