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 21 Aug '10

21 Aug '10

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

3 3

arki model changes
by Tudor Girba 20 Aug '10

20 Aug '10

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."

2 3

moose images for cog vm
by Tudor Girba 19 Aug '10

19 Aug '10

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."

2 2

Vocabulary: common designator for Namespace and Package?
by Simon Denier 19 Aug '10

19 Aug '10

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

3 3

Fwd: Moose Test report
by Simon Denier 19 Aug '10

19 Aug '10

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

2 1

MooseGroups'concatenation - side effect
by Cyrille Delaunay 19 Aug '10

19 Aug '10

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?

3 2

may be any useful: compute C, C++, Javascript, python metrics
by Stéphane Ducasse 19 Aug '10

19 Aug '10

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

1 0

Method invocation for Smalltalk code in Moose
by Alexandre Bergel 19 Aug '10

19 Aug '10

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

5 10

RoelTyper
by Alexandre Bergel 19 Aug '10

19 Aug '10

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 3

Extending the core of Mondrian
by Alexandre Bergel 18 Aug '10

18 Aug '10

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev