Hi Moose-Dev-Team,
i´m currently trying to install Moose with the Moose Suite Loader in
Visual Works 7.5. When i try to download the suite, the first dialog
tells me "currently disconnected, do you want to reconnect?" so sure i
want, so clicking yes leads me to the next problem that tells me "A
problem was detected. Please try again".
The status window in VisualWorks tells me:
"
visualnc.im created at April 17, 2007 10:52:24 amERROR: current
transaction is aborted, commands ignored until end of transaction block
ERROR: current transaction is aborted, commands ignored until end of
transaction block
ERROR: current transaction is aborted, commands ignored until end of
transaction block
ERROR: current transaction is aborted, commands ignored until end of
transaction block
...
"
I hope you can help me to install the Moose Suite because i want to use
it in my diplom-thesis about software-metrics. I wanted to use the
MooseSuite in a chapter about visualizing metrics in the software
development process.
Thanks in advice!
Greetings
Timo Gienger
Hey Doru,
I did not manage to achieve this, can you take care?
We want to have
- sendToBack
- bringToFront
- sendBackword
- bringForward
in the context menu of Mondrian figure.
(as in Excel par example)
cheers,
AA
Hi,
In the latest version 1.313, DynaMoose seems to have lost its tests.
Is this by mistake, or is it intended?
Cheers,
Doru
--
www.iam.unibe.ch/~girbawww.iam.unibe.ch/~girba/blog/
"The coherence of a trip is given by the clearness of the goal."
There was discussion if it might be possible to omit the list of
invocation candidates and just give the "most common candidate" and
derive all others.
Please find below an example where this does not work for statically
types languages.
The client class invokes m() on an instance of B. m is implement in
A (B's superclass) and C and D (B's subclasses), but also in E (a
sibling of B). Lets assume we just store the "most common candidate"
A.m and derive candidates looking at subclasses, then we get the
false positive E.m!
Another case (which applies to dynamic languages too) is when m() is
invoked using a super send somewhere in D, and we just store A.m()
and we derive it now, again D.m and E.m and C.m are false positive.
So at least you need information about
receiver type
signature (not yet 1st class in FAMIX!)
kind of lookup (self, super, whatever...)
whereas the "most specific candidate" encodes implementing type and
signature as string.
So for now, maybe best is to just store all candidates in any case.
cheers,
Toon and AA
Dear Moosers,
I was pondering over Famix and found that it only uses 20% of EMOF's
features. As it seems, the E in EMOF is not really standing for
essential :)
What I came up with when porting MSE to Java, is a much simpler mmmodel.
I documented it on the wiki
http://smallwiki.unibe.ch/moose/mse/msemmmodel/
would be nice to make this the new mmmodel of moose and get rid of
all the EMOF bloat.
by the way, a Java implementation is in its first draft, if you are
interested contact me.
cheers,
AA