Moose-dev November 2014

moose-dev@list.inf.unibe.ch

42 participants
98 discussions

Does Charter handle normal bar graphs currently?
by Chris Cunningham 06 Nov '14

06 Nov '14

I am currently using EyeSee for doing some charting/graphing, and am running into some of its limitations. I'd like to use the newest/bestest, but am stumped how to use it right now. Attached is roughly the graph I want:[image: Inline image 1] except I'd like the bars to be located correctly for the time (as well as the labels). Or, even better, be able to state that I want the days labelled, and either hour tick marks, or optional tick marks. And, of course, be able to specifically call out the color of the bars. Data to build this chart: x := { Dictionary new at: 'COLOR' put: Color gray; at: 'TIME' put: (DateAndTime fromString: '2014-10-30 12:11:28.0'); at: 'SECONDS' put: 4; yourself. Dictionary new at: 'COLOR' put: Color gray; at: 'TIME' put: (DateAndTime fromString: '2014-10-31 12:11:28.0'); at: 'SECONDS' put: 5; yourself. Dictionary new at: 'COLOR' put: Color red; at: 'TIME' put: (DateAndTime fromString: '2014-10-31 12:41:28.0'); at: 'SECONDS' put: 15; yourself. Dictionary new at: 'COLOR' put: Color green; at: 'TIME' put: (DateAndTime fromString: '2014-11-01 12:11:28.0'); at: 'SECONDS' put: 7; yourself. Dictionary new at: 'COLOR' put: Color gray; at: 'TIME' put: (DateAndTime fromString: '2014-11-02 12:11:28.0'); at: 'SECONDS' put: 1; yourself. Dictionary new at: 'COLOR' put: Color gray; at: 'TIME' put: (DateAndTime fromString: '2014-11-03 12:11:28.0'); at: 'SECONDS' put: 4; yourself. }. -cbc

2 8

XML tests failing
by Tudor Girba 06 Nov '14

06 Nov '14

Hi, The Moose job is failing due to two XML parser tests. Can anyone look at this problem: https://ci.inria.fr/moose/job/moose-5.0/3077/testReport/ Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

1 0

Issue 1094 in moose-technology: List presentations should be fast on large collections
by moose-technology＠googlecode.com 03 Nov '14

03 Nov '14

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1094 by chisvasi...(a)gmail.com: List presentations should be fast on large collections https://code.google.com/p/moose-technology/issues/detail?id=1094 Opening a large collection using a list presentation is very slow. The following example shows the problem. Also when inspect just (1 to: 2000000) collect:#asString creating the Items tab takes time. composite := GLMCompositePresentation new. composite list showOnly: 50. composite openOn: ((1 to: 2000000) collect:#asString) Most of the time seems to be spend in GLMTreeMorphModel>>#roots that given that GLMTreeMorphModel>>#amountToFilterBy always returns nil. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 0

TRMultiCompositeShape>>announcer
by Tudor Girba 03 Nov '14

03 Nov '14

Hi, I think we have a problem with announcer from TRMultiCompositeShape. It is implemented as if it should not be called, but TRCanvas>>shapeWithAction: eventClass forPositionInPixels: position calls it. So, we have a problem. I observed the problem when creating edges with RTMondrianViewBuilder. For example: view := RTMondrianViewBuilder new. view shape label text: #asString. view nodes: (1 to: 100). view shape orthoHorizontalLine color: Color veryLightGray. view edgesFrom: [:x | x // 10]. view horizontalTreeLayout layered. view And then click on an edge. Doru -- www.tudorgirba.com "Every thing has its own flow"

2 3

Issue 1092 in moose-technology: Roassal2 examples browser is not working
by moose-technology＠googlecode.com 03 Nov '14

03 Nov '14

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Milestone-5.0 Component-Roassal Component-GlamorousToolkit New issue 1092 by tu...(a)tudorgirba.com: Roassal2 examples browser is not working https://code.google.com/p/moose-technology/issues/detail?id=1092 Just that. It seems that the recent example refactorings broke the browser. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 2

Issue 1093 in moose-technology: FAMIXPharoAnchor DNU in MoosePanel
by moose-technology＠googlecode.com 03 Nov '14

03 Nov '14

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1093 by usman.bh...(a)gmail.com: FAMIXPharoAnchor DNU in MoosePanel https://code.google.com/p/moose-technology/issues/detail?id=1093 In MoosePanel, when browsing an Smalltalk model, we get FAMIXPharoAnchor FAMIXPharoAnchor(Object)>>doesNotUnderstand: #completeText when trying to browse an entity with code. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 1

Issue 1002 in moose-technology: The treemap builder should support multiple types of nodes
by moose-technology＠googlecode.com 02 Nov '14

02 Nov '14

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-Roassal Milestone-5.0 New issue 1002 by tu...(a)tudorgirba.com: The treemap builder should support multiple types of nodes http://code.google.com/p/moose-technology/issues/detail?id=1002 TreeMaps are particularly useful to show leaf nodes within a nested parent nodes tree. For example, they can show classes within packages. They are less useful for showing only one type of nodes, like a class hierarchy given that the weight is only meaningful when applied to the leaf nodes. However, right now, we can specify nodes only with one block, weight with one block only and edges with another one block. This is less convenient. We should extend this to allow multiple sets of nodes. Consider this code: packages := RPackageOrganizer default packages select: [:each | each name beginsWith: 'AST']. classes := packages flatCollect: [:each | each definedClasses ]. ... builder weightBlock: [ :el | el isBehavior ifTrue: [ el linesOfCode + 1] ifFalse: [ 1 ] ]. builder nodes: (packages), (classes). builder nestingFromAssociations: ( (builder nodes select: [ :each | each isBehavior ]) collect: [ :each | (each) -> each package ]). builder drawOn: rawView . It would be better to have it like: builder weight: [ :el | el linesOfCode + 1] ]. builder nodes: classes. builder nodes: packages builder nest: classes in: [ :each | each package ]. builder drawOn: rawView . Note how nesting is defined following the same pattern as edges:from:to:, and how the weight is only applied to the next nodes. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 1

roassal 1 -> 2 todos
by Tudor Girba 01 Nov '14

01 Nov '14

Hi, There are only a couple of things left to do in the migration: - Fix the UML diagram to properly show attributes (we need another transformation to show the name of an attribute) - Reimplement a treemap visualization in Roassal2 and have the SystemNesting ported to it - Reimplement the GLMBrowser>>viewTree visualization Anyone interested in helping? Just a reminder: these are pretty much the main things that are still left to do in order for us to release Moose 5. Once we release it, we can move to Pharo 4 and benefit from a larger exposure and feedback for all the tools built around Moose. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

4 21

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev November 2014