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
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
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"
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
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
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
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"
Hello,
I am a bit puzzled by the behavior of Roassal2 using RTGraphBuilder.
Inspired by the Agile Visualization Book, I tried some scripts, but I
ran into some problems regarding edges.
I used this simple script to connect some random dots:
nodes := #(one two three four five).
b := RTGraphBuilder new.
b edges
color: Color red;
connectFrom: [ :e | nodes atRandom ].
b nodes color: Color gray.
b layout grid.
b addAll: nodes.
b
It worked to draw the dots, but it didn't displayed any edge. The weird
thing is that if I put integers or characters inside nodes, it works
correctly.
Example -- this works:
nodes := #(1 2 3 4 5 6).
b := RTGraphBuilder new.
b edges
color: Color red;
connectFrom: [ :e | nodes atRandom ].
b nodes color: Color gray.
b layout grid.
b addAll: nodes.
b
Am I doing something wrong?
Thanks,
Tommaso
In latest moose image do:
RTNameCloud new example1
Apparently, there are some extension methods of Roassal 1 that need to be
ported to Roassal 2. It would be good to make sure that Roassal 1 can be
loaded without any conflicts when porting these to Roassal 2 because
Roassal 1 is still being used.
I can open a bug report.
usman
Hi all,
To make it easier to integrate GTools into Pharo we split the three
configurations that were used (ConfigurationOfGlamour,
ConfigurationOfGTInspector, ConfigurationOfGTPlayground) into two.
Now there are:
ConfigurationOfGlamourCore,
ConfigurationOfGTInspectorCore,
ConfigurationOfGTPlaygroundCore
These only load the features that are integrated into Pharo.
There are also ConfigurationOfGlamour, ConfigurationOfGTInspector and
ConfigurationOfGTPlayground that are based on the previous ones, load all
the other features, and are supposed to be loaded into Moose. From a user
of this configuration there should be no visible changes.
We also simplified a lot ConfigurationOfGlamour and fixed some bugs in
ConfigurationOfPetitParser.
Let us know if you encounter any problems.
Cheers,
Andrei
Hi!
Andrei and I have just updated all the Roassal examples to be GT compliant. The result is __really__ cool.
You can even edit the example (it does not save the code, which is a feature) and see the example.
Here are some screenshots:
Really really cool! This is a whole new experience to browse Roassal example!
Cheers,
Andrei & Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi guys
We will organize at Lille the 29 and 30 of January PharoDays.
Now to help us building a budget I would like to know if you already
know that you plan to attend the conference.
Could you fill up the doodle
http://doodle.com/icxtazwfq76caxf8
Stef
Hi guys
here is a list of package in VWMoose that could be interesting to get ported to MoosePharo.
Do you have some wishes (not sure that I will have the time).
I put a star infront of the ones I would be interested
LinearAlgebra (*)
ArrayMatrix
Vector
ColumMatrix
SparseMatrix
this comes with tests
BooleanVector
MappedMatrix
NameMapping
Clustering (*)
CorrelationSquare
Dendogram
ClusterEngine
TimeWarpingEngine
InformationRetrieval
Stemmer
HapaxVectorSpace
HapaxSemantic
HapaxTrendDetection
FormalConceptAnalysis (*)
EMOF
Stef
doru et al.
did you experience the following with glamour
we have three panes
select an item in pane 1
update pane 2
update pane 3
mouse over pane 3
scrolling fast the pane 3
change the selection in pane 1
Stef
Hello,
To FlowLayout users, I am modifying RTAbstractFlowLayout and subclasses for
Roassal2 and I would appreciate to hear your opinions on some modifications:
First I changed the Flow layout maxWith value at the initialization to take
account of the global area of elements and gapsize. (see screen1, RTObject
https://www.dropbox.com/s/7hlsmiklqefb7cn/screen1.png?dl=0 )
Then I fixed the align Bottom, so the elements do not collide each others.
The only remaining difference is the first line is the less filled. It is
due to creating the layout from bottom to up. (The order of elements still
remain the same from the left top corner to the right down.) (see screen2
https://www.dropbox.com/s/7kr3gy4e3gwvvgl/screen2.png?dl=0) Does this
difference have any importance ?
Finally i am adding a HorizontalFlow layout. (right queued or left queued,
using align bottom) See the screen3 (
https://www.dropbox.com/s/nmgq8cg0f4p3m6u/screen3.png?dl=0), the alignement
is vertical, do you think it’s usefull ? Should I make a horizontal
alignement (In that case it would only be a increasement of maxWidth…) ?
Thank you !
Pierre Chanson
Hi,
We are quite actively working on GT.
First of all, thanks everyone for the feedback. We take it quite seriously
and we do our best to take it into account. Please keep the discussions
flowing.
I summarized some of the things that happened recently in the playground
and inspector here:
http://www.humane-assessment.com/blog/gt-developments-endless-playground-me…
Let us know what you think.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Hi,
This is just to let you know that the ConfigurationOfMoose 5.0-baseline
(and OfGlamour) no longer loads Roassal1.
There are still red tests, but the vast majority of the code is now cleaned
of Roassal1 dependencies. It would be useful if you could give a hand in
identifying the last problems.
Please keep the communication through the mailing list.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"