Loading a model through the GUI
by Bergel, Alexandre
Dear MOOSEers,
As an exercise, I am parsing Java files and loading the corresponding
Java classes in a moose model.
Whereas it seems that I fill the model well, I got a rollback when
using the Moose GUI façade.
I spend some time on it, but I failed in trying to debug it.
It seems that a famix element should know about the model it is part
of. But I do not know how to set it.
the error comes from the method:
FAMIXAbstractStruture >>incomingAccesses
^self entityGroups at: #incomingAccesses ifAbsentPut: [self
mooseModel allAccesses select: [:each | each accesses = self]].
self mooseModel returns nil
If you want to try, you can load the package JavaSupport4Moose in the
SCGStore.
I attached a short java file to try this. Once the package loaded,
click on the "..." button in the Moose GUI.
The test Java4MOOSETest>>testReadingJavaFile is green
cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
15 years, 10 months
Design question
by Bergel, Alexandre
Was wondering how comes that the class Importer inherits from
collection? Is an importer really a collection?
Again, sorry in case of a naive question
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
15 years, 10 months
Design question
by Alexandre Bergel
Was wondering how comes that the class Importer inherits from
collection? Is an importer really a collection?
Again, sorry in case of a naive question
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
15 years, 10 months
What are model methods and model classes?
by Bergel, Alexandre
Sorry if my question illustrates my ignore in Moose :-)
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
15 years, 10 months
what will be the status of Access vs reference in FAMIX3.0
by stephane ducasse
Hi guys
I would like to know how we will migrate to FAMIX20 to 30
because I would like also to extract references (if I remember we
will have access and references).
And I'm right now chasing a bug in references extraction.
Stef
15 years, 10 months
wide classes
by Tudor Girba
Hi,
I totally agree that the "base programmer" needs to be supported, but
on the other hand we should offer the tools to extend Moose. It is
just that I do not understand exactly what the advantages/
disadvantages are, and I propose to start a discussion on that.
I do not understand exactly the solution, but here is what I
understood as the reasons for wide classes:
1. extend the state of a class from another package
2. save memory by only allocating a instance variable slot when it is
used
3. (speed?)
1. In VW we can extend the methods and that allowed us to have a nice
extensible architecture. In the same way, we should be able to extend
the state as well, for example for caching results performed by a
method extension.
That is why currently, we have __state__ in each entity that has
dictionaries for storing such results, and we wrap the calls to
__state__ in setters and getters. For example, in DynaMoose we have:
FAMIXClass>>instances
^self __state__ attributeGet: #instances initializer:
[ OrderedCollection new ]
FAMIXClass>>instances: aCollection
^self __state__ attributeSet: #instances value: aCollection
The symbol is only used here. All tools work nicely with that
(actually, in VW looking for senders of a method will also get you
the usages of the symbol). This mechanism is crucial for extending
the meta-model.
The wide classes solution would pose the same overhead on the
programmer.
2. The second reason for the wide classes is to reduce the memory
footprint, because you will only get a slot if you use it.
The current solution will create a dictionary for all instance
variables extensions and an entry for each of them. I would be
curious to see what the difference is.
3. Speed. I am definitely not sure about this point, but wide classes
should be faster than looking into a dictionary. But, I do not
believe this has a real impact over the overall performance, in
particular given that the dictionary are rather small.
Of course, you can just bash anything I wrote here :)
Doru
--
www.tudorgirba.com
www.tudorgirba.com/blog
"There are no old things, there are only old ways of looking at them."
15 years, 10 months
moose.unibe.ch-bug
by Toon Verwaest
The searchbox doesn't appear to work in firefox
cheers
15 years, 10 months
A bug to smash in moose
by Sandro De Zanet
Hello everyone
I generated a mse file (see attachment) which should generate 14 methods
in the class ' Superclass', but here are 17 methods shown in the moose
browser (some methods are duplicated).
The file seems ok, so I think there is a bug in moose, reading the file.
Cheers
Sandro
(Moose.Model (name 'frittelitest') (entity
(FAMIX.Method (id: 1)
(name 'foo')
(belongsTo (idref: 14))
(signature 'foo'))
(FAMIX.Method (id: 2)
(name 'put')
(belongsTo (idref: 14))
(signature 'put'))
(FAMIX.Method (id: 3)
(name 'size')
(belongsTo (idref: 14))
(signature 'size'))
(FAMIX.Method (id: 4)
(name 'main')
(belongsTo (idref: 15))
(signature 'main'))
(FAMIX.Method (id: 5)
(name 'isEmpty')
(belongsTo (idref: 14))
(signature 'isEmpty'))
(FAMIX.Method (id: 6)
(name 'foo')
(belongsTo (idref: 14))
(signature 'foo'))
(FAMIX.Method (id: 7)
(name 'containsValue')
(belongsTo (idref: 14))
(signature 'containsValue'))
(FAMIX.Method (id: 8)
(name 'entrySet')
(belongsTo (idref: 14))
(signature 'entrySet'))
(FAMIX.Method (id: 9)
(name 'putAll')
(belongsTo (idref: 14))
(signature 'putAll'))
(FAMIX.Method (id: 10)
(name 'remove')
(belongsTo (idref: 14))
(signature 'remove'))
(FAMIX.Method (id: 11)
(name 'containsKey')
(belongsTo (idref: 14))
(signature 'containsKey'))
(FAMIX.Method (id: 12)
(name 'get')
(belongsTo (idref: 14))
(signature 'get'))
(FAMIX.Namespace (id: 13)
(name 'frittelitest')
(class (idref: 14) (idref: 16) (idref: 15)))
(FAMIX.Class (id: 14)
(name 'Superclass')
(NOA 0)
(NOM 14)
(method (idref: 1) (idref: 6) (idref: 19) (idref: 11) (idref: 7) (idref: 8) (idref: 12) (idref: 5) (idref: 17) (idref: 2) (idref: 9) (idref: 10) (idref: 3) (idref: 20)))
(FAMIX.Class (id: 16)
(name 'Subclass')
(NOA 0)
(NOM 1)
(method (idref: 18)))
(FAMIX.Class (id: 15)
(name 'Main')
(NOA 0)
(NOM 1)
(method (idref: 4)))
(FAMIX.Method (id: 17)
(name 'keySet')
(belongsTo (idref: 14))
(signature 'keySet'))
(FAMIX.Method (id: 18)
(name 'foo')
(belongsTo (idref: 16))
(signature 'foo'))
(FAMIX.Method (id: 19)
(name 'clear')
(belongsTo (idref: 14))
(signature 'clear'))
(FAMIX.Method (id: 20)
(name 'values')
(belongsTo (idref: 14))
(signature 'values'))))
15 years, 10 months
