Moose-dev November 2007

moose-dev@list.inf.unibe.ch

25 participants
45 discussions

Feature request Mondrian: #sendToBack, #bringToFront, etc...
by Adrian Kuhn 15 Nov '07

15 Nov '07

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

2 1

just a meta wish...
by stephane ducasse 14 Nov '07

14 Nov '07

Hi guys we have been discussing with alex here about our visibility since other groups at inria are using Gforge and are counting their donwloads. I think that we cannot do too much because I do not see how it would make sense to use svn for developing Moose. Now I see several paths to help moose while helping us (stef at inria) internally: I think tat this is really important to refer to the moose articles in the paper and PhD thesis. Oscar Nierstrasz, Stéphane Ducasse and Tudor Gîrba, The Story of Moose: an Agile Reengineering Environment, In Proceedings of the European Software Engineering Conference (ESEC/FSE 2005), New York NY, ACM Press, pp. 1-10, 2005, Invited paper, PDF , DOI Stéphane Ducasse, Tudor Gîrba, Michele Lanza and Serge Demeyer, Moose: a Collaborative and Extensible Reengineering Environment, In Tools for Software Maintenance and Reengineering, Milano, Franco Angeli, pp. 55-71, 2005, PDF Stef

2 1

dynamoose tests
by Tudor Girba 07 Nov '07

07 Nov '07

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/~girba www.iam.unibe.ch/~girba/blog/ "The coherence of a trip is given by the clearness of the goal."

3 3

Can we derive invocation candidates?
by Adrian Kuhn 06 Nov '07

06 Nov '07

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

1 1

FAMIX 3.0 draft v0.8
by Toon Verwaest 02 Nov '07

02 Nov '07

Hi, Find in attachment the first open draft version of the FAMIX 3.0 metamodel. Review and comments welcomed! cheers, Toon

8 20

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev November 2007