I would like to get the SqueakModelExtractor working but for that I need FAMIX 3.0 How can I make progress? I really want to get moose on pharos because I want to build stuff on moose to analyze pharo.
Stef
Hi Stef,
I looked at FAMIX. As I said before, the tg.5 version was already fine. I now regenerated it together with Toon so that it takes into account some internal implementation detail (the *Slot selectors that are just used internally). I also republished a newer version of Moose- All.
We still did not generate the add*: selectors for adding elements in collections, but Toon said he will do this shortly, so we will regenerate afterwards. Until then, instead of adding in the collection, you can just set the opposite link and this will populate the element in the collection due to the Slot implementation.
For example, see:
FAMIXTest>>testSlot
| c m | c := FAMIXClass new. m := FAMIXMethod new. m parentClass: c. self assert: (c methods first = m)
Cheers, Doru
On Jun 12, 2008, at 7:54 PM, stéphane ducasse wrote:
I would like to get the SqueakModelExtractor working but for that I need FAMIX 3.0 How can I make progress? I really want to get moose on pharos because I want to build stuff on moose to analyze pharo.
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"What we can governs what we wish."
ok
We still did not generate the add*: selectors for adding elements in collections, but Toon said he will do this shortly, so we will regenerate afterwards. Until then, instead of adding in the collection, you can just set the opposite link and this will populate the element in the collection due to the Slot implementation.
Is Slot part of FAME? what is the dependency with moose?
For example, see:
FAMIXTest>>testSlot
| c m | c := FAMIXClass new. m := FAMIXMethod new. m parentClass: c. self assert: (c methods first = m)
Cheers, Doru
Indeed, Slots are implemented in Fame, and the CodeGenerator uses that instead of direct references or collections. That is why FAMIX uses Slots.
Doru
On Jun 12, 2008, at 9:29 PM, Stéphane Ducasse wrote:
ok
We still did not generate the add*: selectors for adding elements in collections, but Toon said he will do this shortly, so we will regenerate afterwards. Until then, instead of adding in the collection, you can just set the opposite link and this will populate the element in the collection due to the Slot implementation.
Is Slot part of FAME? what is the dependency with moose?
For example, see:
FAMIXTest>>testSlot
| c m | c := FAMIXClass new. m := FAMIXMethod new. m parentClass: c. self assert: (c methods first = m)
Cheers, Doru
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"Every thing has its own flow."
Indeed, Slots are implemented in Fame, and the CodeGenerator uses that instead of direct references or collections. That is why FAMIX uses Slots.
But a Slot is at the metalevel? Does it generate code at the FAMIX class implementation level?
Why cant we simply generate the code and get done? Why do we want to have to have such dependency with Fame? Stef
Slot is not meta-level. It's just an implementation of Slots at Smalltalk level.
For example, in FAMIXClass>>initialize you get:
methods := FMManySlot new owner: self; oppInstVar: #parentClass; yourself.
Which will take care to populate the parentClass instance variable when you add a method. In any case, you can just treat it as a collection and everything should work just fine.
Perhaps, this is not necessarily needed, but I would say we could give it a try.
Slots are not Fame specific. They just happen to be packaged in Fame. But as Moose already depends on Fame, I think this dependency is not really a problem.
Doru
On Jun 12, 2008, at 9:46 PM, Stéphane Ducasse wrote:
Indeed, Slots are implemented in Fame, and the CodeGenerator uses that instead of direct references or collections. That is why FAMIX uses Slots.
But a Slot is at the metalevel? Does it generate code at the FAMIX class implementation level?
Why cant we simply generate the code and get done? Why do we want to have to have such dependency with Fame? Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"Every thing has its own flow."
Ok I checked the code and there is no magical invocation involved so this looks ok. I'm just a bit pissed off that nothing is that transparent and learning everything while porting it is terrible for me.
stef
On Jun 12, 2008, at 9:53 PM, Tudor Girba wrote:
Slot is not meta-level. It's just an implementation of Slots at Smalltalk level.
For example, in FAMIXClass>>initialize you get:
methods := FMManySlot new owner: self; oppInstVar: #parentClass; yourself.
Which will take care to populate the parentClass instance variable when you add a method. In any case, you can just treat it as a collection and everything should work just fine.
Perhaps, this is not necessarily needed, but I would say we could give it a try.
Slots are not Fame specific. They just happen to be packaged in Fame. But as Moose already depends on Fame, I think this dependency is not really a problem.
Doru
On Jun 12, 2008, at 9:46 PM, Stéphane Ducasse wrote:
Indeed, Slots are implemented in Fame, and the CodeGenerator uses that instead of direct references or collections. That is why FAMIX uses Slots.
But a Slot is at the metalevel? Does it generate code at the FAMIX class implementation level?
Why cant we simply generate the code and get done? Why do we want to have to have such dependency with Fame? Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com www.tudorgirba.com/blog
"Every thing has its own flow."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
stéphane ducasse -
Stéphane Ducasse -
Tudor Girba