Hi!
When tracing the execution in GT-debugger the text selection does not always reflect the real position of the program counter. Consider the following screenshot:
I have simply pressed the step-into button, nothing more. The selection is not meaningful.
Am I the only one to have noticed this?
It would be great to have it fixed…
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi guys,
I’m not experienced in OpenGL, but I’ve noticed that both Roassal3D and Woden occupy a high level process and are not yielding Processor to anyone else. For example code highlight, spotter, and other lower priority processes are not working as soon as you open a 3D visualization. On the other hand this doesn’t happen while using CodeCity (and it also uses OpenGL). Is it very complicated to make Roassal3D and Woden to respect other processes?
Uko
Hi!
We did a number of improvements of Grapher for Thomas. I am sharing them since some of you may find it relevant.
**************************************
*** Tip: need to shift the Y-axis ***
b := RTGrapher new.
ds := RTStackedDataSet new.
ds barShape color: Color red.
ds points: #(5 1 20 8).
b add: ds.
b axisX noLabel; noTick. b axisY noDecimal.
b build.
The Y-Axis can be shifted vertically using labelConversion: and a minor translation of the value, as in:
b := RTGrapher new.
ds := RTStackedDataSet new.
ds barShape color: Color red.
ds points: #(5 1 20 8).
ds y: [ :v | v - 10 ].
b add: ds.
b axisX noLabel; noTick. b axisY noDecimal.
b axisY labelConversion: [ :v | v + 10 ].
b build.
**************************************
*** Improvement 1: Centered labels for bar charts ***
-=-=-=-=-=-=-=-=-=-=-=-=
b := RTGrapher new.
ds := RTStackedDataSet new.
ds barShape color: Color red.
ds points: #(5 1 20 8).
ds y: [ :v | v - 10 ].
ds barChartWithBarCenteredTitle: [ :value | '##', value asString ].
b add: ds.
b axisX noLabel; noTick. b axisY noDecimal.
b axisY labelConversion: [ :v | v + 10 ].
b build.
-=-=-=-=-=-=-=-=-=-=-=-=
**************************************
*** Improvement 2: Average for X values ***
b := RTGrapher new.
ds := RTDataSet new.
ds dotShape color: Color red.
ds points: #(5 1 20 8).
b add: ds.
b addDecorator: (RTHorizontalAverageDecorator new withLabel; labelConvertion: [ :aValue | 'average = ', aValue asFloat asString ]).
b build.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi, From time to time I see a bug in GLMTreeMorphNodeModel>>pathIn:
It happens like this:
1) PPSmalltalkGrammar new inspect.
2) Click to the tree view and do some clicking here and there, expanding
and collapsing nodes.
3) After some time, pharo freezes in a enldess recursion call. You can see
it in the attached screenshot.
This behaviour is there for quite a time (at least half a year, as far as I
remeber).
Cheers,
Jan
PS: Where shall I report bugs like this? GoogleCode or FogBugz?
Hi all,
Today and tomorrow, a small group of persons will be doing a
workshop/hackathon about Pharo and Agile Visualization at our local
hackerspace. Details on the event are on:
http://hackbo.co/hackboweb/eventos/evento/375
I will be sharing teaching materials, first impressions and questions
with you about the experience, while is happening and after that.
Thanks,
Offray
Hi!
We have exposed the SVG examples in the Roassal example browser.
Some of you may be interested in this
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alex,
unfortunately changes in TRCompositeShape created a regression, because now
TRRemoveCallbacks are executed multiple times.
the commit is Trachel-AlexandreBergel.266
Interestingly there is TRCompositeShapeTest>>testCallback01 which works,
but it doesn't use RTElement.
Here's a test case:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|v e executed|
v := RTView new.
e := RTElement new.
e + (RTBox new) + (RTEllipse new).
executed := 0.
e trachelShape addCallback: (TRRemoveCallback new block: [ :shape |
executed := executed + 1 ]).
v add: e.
TestAsserter new assert: executed equals: 0.
e remove.
TestAsserter new assert: executed equals: 1.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now since you have discussed with Jan that the new behavior makes sense in
some circumstances, it would be better to have both behaviors.
So I would propose to make a distinction for RemoveCallback - to not
triggered them from TRCompositeShape, because it is not reentrant.
Thus when executed on composite shape, only non-removing callbacks would be
executed.
Additionally it seems very random that CompositeShape uses it's first
subshape for callbacks; what is so special about the first one? Why can't
composite shape hold it's own callbacks, or have an explicit way to specify
which one to use (first, second, none, ..)?
Since Composite Shape is recurring problematic theme, perhaps there should
be some wider discussion to collect all the use cases?
What do you think?
Peter