Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Start a nNew thread

why methods is not a set in FamixClass

by stephane ducasse

or an OrderedSet? Stef

17 years, 4 months

Could I get a list of bugs to smash in moose?

by stephane ducasse

Hi I would like to give a try to do something else than latex. Is there a list of bugs that I can work on? Adrian you mentioned __state__ to finish and I know that Task was left not totally finished. Could you put your todo with the probability that you will work on them? Stef

17 years, 4 months

Creating and filling a model?

by Bergel, Alexandre

Dear Moose mailing list, I am not sure whether the late hours is making me miss something obvious, but how can I create an instance of a model, and populate it with instances of Famix class ? Cheers, Alexanre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

17 years, 4 months

could we have an email in the mailingl; st when a new moose dev is published

by stephane ducasse

with an indication of the changes? Stef

17 years, 4 months

Loading a model through the GUI

by Bergel, Alexandre

Dear MOOSEers, As an exercise, I am parsing Java files and loading the corresponding Java classes in a moose model. Whereas it seems that I fill the model well, I got a rollback when using the Moose GUI façade. I spend some time on it, but I failed in trying to debug it. It seems that a famix element should know about the model it is part of. But I do not know how to set it. the error comes from the method: FAMIXAbstractStruture >>incomingAccesses ^self entityGroups at: #incomingAccesses ifAbsentPut: [self mooseModel allAccesses select: [:each | each accesses = self]]. self mooseModel returns nil If you want to try, you can load the package JavaSupport4Moose in the SCGStore. I attached a short java file to try this. Once the package loaded, click on the "..." button in the Moose GUI. The test Java4MOOSETest>>testReadingJavaFile is green cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

17 years, 4 months

Design question

by Bergel, Alexandre

Was wondering how comes that the class Importer inherits from collection? Is an importer really a collection? Again, sorry in case of a naive question Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

17 years, 4 months

Design question

by Alexandre Bergel

17 years, 4 months

What are model methods and model classes?

by Bergel, Alexandre

Sorry if my question illustrates my ignore in Moose :-) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

17 years, 4 months

what will be the status of Access vs reference in FAMIX3.0

by stephane ducasse

Hi guys I would like to know how we will migrate to FAMIX20 to 30 because I would like also to extract references (if I remember we will have access and references). And I'm right now chasing a bug in references extraction. Stef

17 years, 4 months

wide classes

by Tudor Girba

Hi, I totally agree that the "base programmer" needs to be supported, but on the other hand we should offer the tools to extend Moose. It is just that I do not understand exactly what the advantages/ disadvantages are, and I propose to start a discussion on that. I do not understand exactly the solution, but here is what I understood as the reasons for wide classes: 1. extend the state of a class from another package 2. save memory by only allocating a instance variable slot when it is used 3. (speed?) 1. In VW we can extend the methods and that allowed us to have a nice extensible architecture. In the same way, we should be able to extend the state as well, for example for caching results performed by a method extension. That is why currently, we have __state__ in each entity that has dictionaries for storing such results, and we wrap the calls to __state__ in setters and getters. For example, in DynaMoose we have: FAMIXClass>>instances ^self __state__ attributeGet: #instances initializer: [ OrderedCollection new ] FAMIXClass>>instances: aCollection ^self __state__ attributeSet: #instances value: aCollection The symbol is only used here. All tools work nicely with that (actually, in VW looking for senders of a method will also get you the usages of the symbol). This mechanism is crucial for extending the meta-model. The wide classes solution would pose the same overhead on the programmer. 2. The second reason for the wide classes is to reduce the memory footprint, because you will only get a slot if you use it. The current solution will create a dictionary for all instance variables extensions and an entry for each of them. I would be curious to see what the difference is. 3. Speed. I am definitely not sure about this point, but wide classes should be faster than looking into a dictionary. But, I do not believe this has a real impact over the overall performance, in particular given that the dictionary are rather small. Of course, you can just bash anything I wrote here :) Doru -- www.tudorgirba.com www.tudorgirba.com/blog "There are no old things, there are only old ways of looking at them."

17 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev