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
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
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
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
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
> what is FMMultivalueLink?
A subclass of Collection.
> 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.
This is a class-method but not a constructor!
#on:update:from:to: updates the opposite end of a link
#on:opposite: *creates* a new link instance
> I do not understand why at the metamodel level I need to have in the
> runtime objects of the metametamodel.
It is not, metametamodel classes start with 'FM3'.
> 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?
You dont trade.
Space is the same -> a link consist of a collection on one side and
of a naked inst var on the other side.
Speed is the same -> it does the minimal set of operations in order
to update both ends.
> So do I have to code a code generator?
No, Fame offers a ready-to-use code generator.
> Or just replace all the FMMultivalueLink myself?
No need.
> I'm confused I thought that the new FAME was better.
http://tinyurl.com/3yfnp9
> Stef
Hi Doru,
>>> You should best use the instructions from
>>> here: http://moose.unibe.ch/download
>> No, I didn't load MOOSE Config; I chose to use the MooseSuiteLoader
> Please try the Moose Config and load the latest development from
> prerequisites. This should work fine.
Oh, yes you are right - thanks a lot.
And good luck in Antwerp
Thomas
________________________________________________________________________
Schon gehört? Bei WEB.DE gibt' s viele kostenlose Spiele:
http://games.entertainment.web.de/de/entertainment/games/free/index.html
Hi Doru, thanks for answering promptly.
>>> On Aug 6, 2008, at 10:03 PM, Steffen Märcker wrote:
>>> I've followed the download instructions, but installing with via the
>>> "MooseSuiteLoader parcel" and via Store as well failed. Some parcels,
>>> namely Clustering couldn't be loaded. Platform: VW 7.6 NC on Windows
>> On Oct 7, 2008, at 11:31 AM, Thomas Schrader wrote:
>> I had similar problems yesterday (same with full productive 7.5 AND
>> fresh 7.6 nc):
> On Oct 7, 21:39:44 MEST 2008, Tudor Girba wrote
> How did you try to load? You should best use the instructions from here:
> http://moose.unibe.ch/download
No, I didn't load MOOSE Config; I chose to use the MooseSuiteLoader parcel
(http://moose.unibe.ch/download/installfromparcel) because I didn't succeed
choosing the right versions of all the prerequesites which Moose Config asked
me on loading.
> As for the image, it's not really done yet, but we will make one
> available in the following weeks.
Fine, so I can wait till then. I'm not pressed, as my MOOSE-dev image really
works for simple scripting so far, after I worked around the loading issues...
Kind regards
Thomas
________________________________________________________________________
Schon gehört? Bei WEB.DE gibt' s viele kostenlose Spiele:
http://games.entertainment.web.de/de/entertainment/games/free/index.html
Hi all,
after the conference I now tried out Moose for the very first time and it works more or less in our productive 7.5 image.
I got very helpful diagrams from it - it's a great inspiring platform, thanks a lot for your efforts ...
On Aug 6, 2008, at 10:03 PM, Steffen Märcker wrote:
> I've followed the download instructions, but installing with via the
> "MooseSuiteLoader parcel" and via Store as well failed. Some parcels,
> namely Clustering couldn't be loaded. Platform: VW 7.6 NC on Windows
I had similar problems yesterday (same with full productive 7.5 AND fresh 7.6 nc):
Errors on installing Moose Suite by the Loader
************************************************************************
* 1) on loading LinearAlgebra (2.1.78,matter) from HapaxDevelopment
************************************************************************
a Dialog opens: "A problem was detected. Try again"
I saw that some False-Object instead of a Source Object was
asked for its #comment and raised a messageNotUnderstood
So, I tried again...
************************************************************************
* 2) on loading ChroniaDevelopment (0.190, matter) from Clustering
************************************************************************
Warning: Package "Clustering" cannot be loaded.
The following classes cannot be loaded because their superclasses are neither in the image nor in the package being loaded:
DistanceSquare (subclass of Root.Smalltalk.Hapax.SymetricMatrix)
CorrelationVector (subclass of Root.Smalltalk.Hapax.Vector)
ClusteringData (subclass of Root.Smalltalk.Hapax.SymetricMatrix)
VectorItem (subclass of Root.Smalltalk.Hapax.VectorDecorator)
ClusteringVector (subclass of Root.Smalltalk.Hapax.ArrayVector)
So, I tried again...
************************************************************************
* 3) Warning: Package "SmallDudeUtils" cannot be loaded
************************************************************************
The following classes cannot be loaded because their superclasses are neither in the image nor in the package being loaded:
BooleanSymetricMatrix (subclass of Root.Smalltalk.Hapax.SymetricMatrix)
BooleanMatrix (subclass of Root.Smalltalk.Hapax.Matrix)
BooleanVector (subclass of Root.Smalltalk.Hapax.Vector)
************************************************************************
* 4) After trying again it loaded OK
************************************************************************
Now it works, but I cannot use system browsers any more due to steady
"key not found" messages. By example, the icon Image at #matrix16x16
is missing in the 7.5 commercial.
The model doesn't understand some messages like #allDuplicates - is this
a bug or just unfinished work?
************************************************************************
* 5) usage convenience question
************************************************************************
Well, as I'm not using a FAST computer, I shouldn't complain, but is there a possibility to
sort of faster "reuse" the MooseSuite - perhaps as a file out - from one productive image
to another? The whole Suite does not load quicker than half an hour and that's in addition
to our productive application which loads half an hour as well.
If this is not possible, than perhaps somebody had tried sort of automation (ignoring "try
again" dialogs) and nightly building a "refactoring image" with Moose included.
Thanks for any help and progress
ST
________________________________________________________________________
Schon gehört? Bei WEB.DE gibt' s viele kostenlose Spiele:
http://games.entertainment.web.de/de/entertainment/games/free/index.html
