April 2011 - Moose-dev

by Alexandre Bergel

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

12 years, 4 months

3
2
0 / 0

Re: Issue 596 in moose-technology: Name of the project not set when importing from Smalltalk

by moose-technology＠googlecode.com

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?

12 years, 4 months

1
4
0 / 0

Issue 604 in moose-technology: VerveineJ should export in UTF-8

by moose-technology＠googlecode.com

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.

12 years, 4 months

1
4
0 / 0

Issue 581 in moose-technology: Computing text size

by moose-technology＠googlecode.com

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

12 years, 4 months

1
4
0 / 0

verveinej out of memory

by Tudor Girba

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

12 years, 4 months

3
6
0 / 0

Issue 554 in moose-technology: DSM has flags for refactoring

by moose-technology＠googlecode.com

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

12 years, 4 months

1
3
0 / 0

Issue 553 in moose-technology: DSM should be split

by moose-technology＠googlecode.com

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.

12 years, 4 months

1
5
0 / 0

Issue 595 in moose-technology: [Glamour] Transmission>>from: is said to take a port

by moose-technology＠googlecode.com

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

12 years, 4 months

1
2
0 / 0

FAMIXPackage>>methods and MooseChef

by Tudor Girba

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

12 years, 4 months

1
0
0 / 0

Limitation of Mondrian?

by Alexandre Bergel

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

12 years, 4 months

2
1
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev April 2011