Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

MooseStore Prerequisite
by Mircea Lungu 06 Jun '07

06 Jun '07

Hi Guys, I have seen that MooseDevelopment is set as a prerequisite to MooseStore even if there seems to be no obvious reason for it. I would like to use the model defined in MooseStore also for the Project Observatory but it seems awkward to ask the user to load all moose when all that is actually needed is the MooseStore package... Can you see a solution? :) Mircea.

3 2

properties in Moose
by Richard Wettel 06 Jun '07

06 Jun '07

Hi, Is there a way in Moose to get from the name of a method to the name of the property defined with a pragma inside that method? For example, having #numberOfMethod, how do I get to #NOM? Thanks, Ricky

3 4

[issue73] Chronia is broken in 75 due to changes in NetClientBase
by Tudor Girba 06 Jun '07

06 Jun '07

New submission from Tudor Girba <girba(a)iam.unibe.ch>: The underlying NetClientBase parcel that comes with 7.5 has changed with respect to 7.4.1, and because of that Chronia does not work. ---------- assignedto: girba component: Chronia messages: 109 nosy: girba priority: Bug status: unread title: Chronia is broken in 75 due to changes in NetClientBase ________________________________________________ Moose Bugs <moose-dev(a)iam.unibe.ch> <http://macamis.unibe.ch/trackers/moose/issue73> ________________________________________________

1 0

[issue72] missing opposites in metamodel
by Adrian Dozsa 05 Jun '07

05 Jun '07

New submission from Adrian Dozsa <adi.dozsa(a)gmail.com>: FAMIXGlobalVariable>>metamodelBelongsTo is missing 'opposite: globalVariable' FAMIXAccess>>metamodelAccesses is missing 'opposite: accesedByList' FAMIXAccess>>metamodelAccessedIn is missing 'opposite: access' New: FamixAbstractStructuralEntity>>metamodelAccessedBy ^(EMOF.Property name: #accessedByList opposite: #accesses type: FAMIXAccess multiplicity: #many) isDerived: true; yourself FamixAbstractBehaviouralEntity>>metamodelAccesses ^(EMOF.Property name: #accesses opposite: #accessedIn type: FAMIXAccess multiplicity: #many) isDerived: true; yourself ---------- component: Famix messages: 108 nosy: adi.dozsa priority: Bug status: unread title: missing opposites in metamodel ________________________________________________ Moose Bugs <moose-dev(a)iam.unibe.ch> <http://macamis.unibe.ch/trackers/moose/issue72> ________________________________________________

1 0

Call for Participation for FAMOOSr 2007 in Zurich
by Adrian Kuhn 31 May '07

31 May '07

Dear Receivers, hereby a call for participation to FAMOOSr 2007 in Zurich. Please forward this mail to anyone in your network who may be interested in this venue. Please apologize multiple copies. Early registration is until June 5, 2007 cheers, Tudor Girba and Adrian Kuhn *********************************************************************** CALL FOR PARTICIPATION FOR FAMOOSr 2007 in ZURICH *********************************************************************** FAMOOSr – 1st Workshop on FAMIX and Moose in Reengineering Location co-located with TOOLS Europe 2007 Date June 25 in Zurich, Switzerland ----------------------------------------------------------------------- The increasing amount of data available about software systems poses new challenges for re- and reverse engineering research, as the proposed approaches need to scale. In this context, concerns about meta-modeling and analysis techniques need to be augmented by technical concerns about how to reuse and how to build upon the efforts of previous research. The goal of this one-day workshop is to strengthen the community of researchers and practitioners who are working in re- and reverse engineering, by providing a forum for building future research using or interested in Moose and Famix as shared infrastructure. For more information, please refer to http://smallwiki.unibe.ch/moose/famoosr2007/ !! Workshop program 09:00-09:45 Kick-off presentation. 10:00-10:50 Presentations, 5-10 minutes each. 11:00-11:50 Presentations, 5-10 minutes each. 12:00-12:30 Creating topics for focus groups. 12:30-14:00 Lunch break 14:00-15:00 1st iteration of work in focus groups 15:00-15:30 Preliminary presentation of results 15:30-16:30 2nd iteration of work in focus groups 16:30-17:00 Final presentations and wrap-up !! Registration Special pricing for early registration till June 5, 2007. Registration page http://tools.ethz.ch/register.html -----------------------------------------------------------------------

1 0

problem with my importer.
by bouazzpi＠ensieta.fr 31 May '07

31 May '07

Hi, I'm facing a very strange problem with my Ecore importer : I implement the EMOF.Enumeration and EMOF.EnumerationLiteral this morning and use them in my importer. I wrote some tests and all of them run perfectly. But when I try to replay my test scenario in a workspace : |importer repository| importer := EcoreMetaModelImporter withActiveMetaMetamodel. importer importEcoreMMFile: 'F:\Cours\EclipseWorkbench\essaiEditor2\test.ecore' . repository := importer asRepository. self halt. I encounter an error : "Import error: unknwon EMOF class EMOF.EnumerationLiteral " however, when I inspect my importer's metaRepository, EMOF.Enumeration and EMOF.EnumerationLiteral appear in the metaRepository elements, but not in its pathMap. I don't understand why during the test EMOF.Enumeration and EMOF.EnumerationLiteral are added to the pathMap of the metaRepositrory and not during a execution in the workspace. I 've tried to understand when the pathMap is initialized, but did not find anything that helps me. Any idea of what can happen ? Thank Pierrick. PS : I have published my bundles : Meta-Ecore-Importer 0.1bouazza and Meta-EMOF-Model 0.239e.2bouazza this afternoon.

2 2

Enumeration
by bouazzpi＠ensieta.fr 29 May '07

29 May '07

Hi, I'm still working on the ecore importer with sara. Today, I convert a metamodel conform to Ecore in a model conform to EMOF and then Sara generates the SmallTalk code associated with this model. Concerning the Enumerations, I planned to implement them into the EMOF Model (according to the OMG spec I found at http://www.omg.org/docs/formal/06-01-01.pdf p31 but when I thought at how to convert it in SmallTalk, I found it better to assimilate Enumeration and EnumLiteral to a class (the enumeration) and subclasses (the enumLiterals) because they are nothing but types. Do you think my idea is good, or should I implement Enumeration in the EMOF Model and let Sara deal with them to generate SmallTalk code? Thank you for your advices. Pierrick

2 1

name clash in Hismo
by Richard Wettel 28 May '07

28 May '07

Hi Doru, I have a slight problem with Hismo. I have a bundle with name CodeCity and in that bundle I have several packages, one of which is also called CodeCity. After creating a History from several versions of the system, I realized that somehow Hismo is not able to distinguish between the two. Although in the MooseModels of the versions there are 2 FAMIXPackages that are related to each other (one of them belongsTo the other), after creating a history I end up having one single PackageHistory called CodeCity. Somehow, Hismo flattens the two... I guess this is also because the bundles and packages in Smalltalk are both modeled by the FAMIXPackage in Moose, but I would expect it to take the mooseID into account on this one. Could you please fix this? Thanks, Ricky

2 1

[issue71] Wrong historical identities for FAMIXPackage
by Tudor Girba 28 May '07

28 May '07

New submission from Tudor Girba <girba(a)iam.unibe.ch>: Submitted by Ricky Wettel. I have a bundle with name CodeCity and in that bundle I have several packages, one of which is also called CodeCity. After creating a History from several versions of the system, I realized that somehow Hismo is not able to distinguish between the two. Although in the MooseModels of the versions there are 2 FAMIXPackages that are related to each other (one of them belongsTo the other), after creating a history I end up having one single PackageHistory called CodeCity. Somehow, Hismo flattens the two... I guess this is also because the bundles and packages in Smalltalk are both modeled by the FAMIXPackage in Moose, but I would expect it to take the mooseID into account on this one. ---------- assignedto: girba component: Van messages: 106 nosy: girba priority: Bug status: deferred title: Wrong historical identities for FAMIXPackage ________________________________________________ Moose Bugs <moose-dev(a)iam.unibe.ch> <http://macamis.unibe.ch/trackers/moose/issue71> ________________________________________________

1 0

Stock News !
by Special Elvia 26 May '07

26 May '07

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev