Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

Start a nNew thread

Where to get the latest stable Moose release?

by Mariano Martinez Peck

If possible on top of Pharo 1.1 dev stable and with DistributionMaps. Thanks Mariano

14 years, 10 months

arki model changes

by Tudor Girba

Hi, I changed a bit the model of Arki: - I introduced Stakeholder as first class - I introduced a ConcernStatus hierarchy to be able to distinguish between: success, failure, error and neutral - With this occasion I also strengthen a tiny bit the error handling - I removed statusValue I will probably still change it a bit, but not dramatically. Please let me know if you have any problems with it. Cheers, Doru -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

14 years, 10 months

moose images for cog vm

by Tudor Girba

Hi, Given the nice recent improvements of the Cog VM, the hudson.moosetechnology.org continuous integration server now produces Moose images that work with this VM: http://hudson.moosetechnology.org/job/moose-latest-dev-for-cog/ Cheers, Doru -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

14 years, 10 months

Vocabulary: common designator for Namespace and Package?

by Simon Denier

Hi I'm looking for a good name which covers both package and namespace concepts. 'ScopingEntity' sounds a bit too verbose. The reason is that today, we have queries like clientClassesOutOfMyPackage, clientClassesOutOfMyNamespace. There are strong similarities between such queries so that it can actually be written once and reused multiple times. Tomorrow, I want such queries to be defined in a trait and injected in both FamixPackage and FamixNamespace. But, I want a single good name to name both Namespace and Package. Container? -- Simon

14 years, 10 months

Fwd: Moose Test report

by Simon Denier

Begin forwarded message: > (19 August 2010 6:08:23 am) -- BEGIN: ConfigurationOfMoose > (19 August 2010 6:08:23 am) -- loading > (19 August 2010 6:11:27 am) -- **Warning/Halt when loading of ConfigurationOfMoose > ** Warning: This package depends on the following classes: > MOAbstractLayout > You must resolve these dependencies before you will be able to load these definitions: > MOGraphVizLayout Fixed: change MOGraphVizLayout superclass to MOLayout following Alex's change

14 years, 10 months

MooseGroups'concatenation - side effect

by Cyrille Delaunay

Hello, I got some problems by concatenating some mooseGroups together. You can evaluate this script in a workspace (it correspond to what I did in my code): |mooseModel| Transcript open. MooseScripts createLightModelForLAN. mooseModel := MooseModel root allModels detect: [:aMooseModel | aMooseModel name ='lightLAN']. "at the begening, all famixClasses from this model have methods" Transcript show: (mooseModel allModelClasses select: [:each | each methods isEmpty]) size asString, String cr. "here we do several concatenations with methods from all FAMIXClasses:" mooseModel allModelClasses do: [:aFamixClass | aFamixClass methods , aFamixClass inheritedMethods ]. "let see the new result: " Transcript show: (mooseModel allModelClasses select: [:each | each methods isEmpty]) size asString, String cr. You can see that after the concatenations, some FAMIXClasses have lost their methods. Is it a real problem or is it me that is missing something obvious?

14 years, 10 months

may be any useful: compute C, C++, Javascript, python metrics

by Stéphane Ducasse

http://pypi.python.org/pypi/metrics/

14 years, 10 months

Method invocation for Smalltalk code in Moose

by Alexandre Bergel

Hi! I am analyzing Mondrian in Moose. One thing that I am bumping into, is that wrong dependencies are inferred whereas I am sure that they do not exist. This is not a new, we have to type in Smalltalk. For example: MOEdge>>fromPositions ^ shape fromPositions #fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge, and MOLineShape. In the case of MOEdge>>fromPositions, I am sure that it does not invoke MOAbstractLayout>>fromPositions I guess that everyone analyzing smalltalk code bumped into this very situation. My question is how do we do in that case? One easy solution, is to annotate Mondrian with an adequate pragma: MOEdge>>fromPositions <invoke: #fromPositions of: MOLineShape> ^ shape fromPositions We can decline this pragma into: <doesNotInvoke: #selector of: AClass> <invoke: #fromPositions of: #(MOLineShape MOEdge)> Simon told me Cyrille has worked on this problem. I am currently trying to use RoelTyper. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 10 months

RoelTyper

by Alexandre Bergel

Hi Roel! I hope you're fine. I tried to use RoelTyper to have more accurate method invocations in Moose. I use Mondrian as my case study. I tried in a workspace (TypeCollector typeInstvar: #shape ofClass: MOGraphElement ) types => an OrderedCollection(SmallInteger) This is surprising since I expect #shape to reference to an instance of a subtype of MOShape. I did: (TypeCollector typeInstvar: #shape ofClass: MOGraphElement ) interface => an IdentitySet(#shapeBoundsAt:ifPresent: #computeBoundsFor: #isCached #copy #defaultBounds #absoluteBoundsFor: #extentFor: #apply:bounds: #isFormsShape) #shapeBoundsAt:ifPresent:, #computeBoundsFor: are defined in MOShape and not SmallInteger. I probably miss something obvious here... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 10 months

Extending the core of Mondrian

by Alexandre Bergel

Hi! The class MOAbstractLayout is in the category Layout. However, I believe it belongs to the Core since the Core cannot work without this class. MOAbstractLayout defines applyOn:, which is invoked by MORoot>>applyLayout. I will also rename MOAbstractLayout into MOLayout to keep the name short and consistent with MOShape (and not MOAbstractShape). If someone is against this, let me know. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 10 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