Moose-dev April 2011

moose-dev@list.inf.unibe.ch

29 participants
180 discussions

documentation effort of Mondrian
by Alexandre Bergel 03 May '11

03 May '11

Hi! I recently documented the source code of Mondrian. This means adding class comments and methods comments. Before the effort, only 14% of the methods were commented. Below a screenshot of the DocumentationBlueprint, a visualization intended to help me document. The MOShape class hierarchy is here presented. After the effort, 24% of the methods are commented. Here is another screen, after 3 days of work. Here is the legend: 'big box = class' . 'edge = inheritance link' . 'small box = method' . 'small box height = number of lines of code' . 'small box width = number of collaborating classes' . 'red border = non commented' . Comments are welcome Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 2

Re: Issue 596 in moose-technology: Name of the project not set when importing from Smalltalk
by moose-technology＠googlecode.com 03 May '11

03 May '11

Updates: Summary: Name of the project not set when importing from Smalltalk Labels: Component-Finder Comment #2 on issue 596 by tudor.gi...(a)gmail.com: Name of the project not set when importing from Smalltalk http://code.google.com/p/moose-technology/issues/detail?id=596 I took a look and it seems to be related to TextMorph, or at least the way it is setup. If you accept the text, it the name is properly set. I do not know how to setup the TextMorph not to require an accept. Cyrille?

1 4

Issue 604 in moose-technology: VerveineJ should export in UTF-8
by moose-technology＠googlecode.com 01 May '11

01 May '11

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-VerveineJ New issue 604 by tudor.gi...(a)gmail.com: VerveineJ should export in UTF-8 http://code.google.com/p/moose-technology/issues/detail?id=604 The MSE file format should be always in UTF-8.

1 4

Issue 581 in moose-technology: Computing text size
by moose-technology＠googlecode.com 01 May '11

01 May '11

Status: New Owner: ---- Labels: Type-Defect Priority-High New issue 581 by alexandr...(a)gmail.com: Computing text size http://code.google.com/p/moose-technology/issues/detail?id=581 Execute in a workspace: (UMLClassDiagram render: Collection withAllSubclasses) open There is too much white space

1 4

verveinej out of memory
by Tudor Girba 01 May '11

01 May '11

Hi, I am testing VerveineJ and I am getting "Exception in thread "main" java.lang.OutOfMemoryError: Java heap space". To reproduce: 1. download https://github.com/Silverpeas/Silverpeas-Core/zipball/master 2. run ./verveinej.sh -Xmx2000m PATH_TO_SILVERPEAS Nicolas, is there anything to do to get this working? Cheers, Doru -- www.tudorgirba.com "What we can governs what we wish."

3 6

Issue 554 in moose-technology: DSM has flags for refactoring
by moose-technology＠googlecode.com 01 May '11

01 May '11

Status: New Owner: jannik.l...(a)gmail.com Labels: Type-Defect Priority-Medium Milestone-4.4 New issue 554 by jannik.l...(a)gmail.com: DSM has flags for refactoring http://code.google.com/p/moose-technology/issues/detail?id=554 some flags in DSM I should verify for 4.4

1 3

Issue 553 in moose-technology: DSM should be split
by moose-technology＠googlecode.com 01 May '11

01 May '11

Status: New Owner: ---- CC: jannik.l...(a)gmail.com Labels: Type-Engineering Priority-Medium Component-DSM Milestone-4.4 New issue 553 by tudor.gi...(a)gmail.com: DSM should be split http://code.google.com/p/moose-technology/issues/detail?id=553 It should be split into generic algorithms (moved to Moose-Algos) and FAMIX specific applications.

1 5

Issue 595 in moose-technology: [Glamour] Transmission>>from: is said to take a port
by moose-technology＠googlecode.com 01 May '11

01 May '11

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 595 by damien.c...(a)gmail.com: [Glamour] Transmission>>from: is said to take a port http://code.google.com/p/moose-technology/issues/detail?id=595 The method GLMTransmission>>from: takes a parameter 'aPort'. However, this method is most of the time used with a pane symbol instead of a port. This is confusing as the Moose book says " For specifying a transmission origin that points to a #selection port of a pane, you simply use from:. " In this case it is clear that the port is #selection and it is the default. The reader is then waiting for an implementation similar to: GLMTransmission>>from: aPaneSymbol ^ self from: aPaneSymbol port: #selection

1 2

FAMIXPackage>>methods and MooseChef
by Tudor Girba 01 May '11

01 May '11

Hi, I am continuing to review MooseChef and I stumbled across the definition of query**Invocations defined in TScopingEntityQueries: TScopingEntityQueries>>queryAllOutgoingInvocations ^ self createOutgoingInvocationQueryResultWith: (self methods flatCollect: [ :m | m outgoingInvocations ]) This depends on #methods. However, in FAMIXPackage, methods only returns the extended methods defined in the package: FAMIXPackage>>methods ^ self privateState cacheAt: #methods ifAbsentPut: [ childNamedEntities select: [ :child | child isKindOf: FAMIXBehaviouralEntity ]] This has a different semantics from the one defined in Namespace: FAMIXNamespace>>methods ^ self privateState cacheAt: #methods ifAbsentPut: [ self classes flatCollect: #methods ] So. I propose that FAMIXPackage>>methods is changed to classExtensionMethods and methods is computed like in Namespace + classExtensionMethods. Anyone else depending on methods with the semantics of classExtensionMethods? Cheers, Doru -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

1 0

Limitation of Mondrian?
by Alexandre Bergel 30 Apr '11

30 Apr '11

Hi! I often bump into a problem having the following gist: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= view nodes: #( $a $b $a). view edgesFromAssociations: { $a -> $b . $b -> $a} -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= How can I express the the second $a and not the first when defining edges? I have the impression this limitation comes from the fact that two different nodes have the same model behind ($a), and there is no way to distinguish between them. An easy and backward compatible solution would be to permit to provide nodes: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= nodes := view nodes: #( $a $b $a). view edgesFromAssociations: { nodes first -> nodes second . nodes second -> nodes third } -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Opinion? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
18
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev April 2011