Just one more thing that has been playing on my mind. It is really a
nice feature that the parent element grows when the child is moved past
its boundary, but would be more good if it also shrank when the child
element is moved back towards center.
cheers ben
Guillermo wrote:
>Maybe you can use a -completely separate- pre-parser? :)
>
>It takes the input with the pre processor directives, and answers a new
>processed string which the original parser will handle?.
Yes, I guess so. I'm fighting a bit with PetitParser, wondering if the traditional
style of building parsers wouldn't be faster. But that might be just about trying
something new. I like the tests, the separate lexicon, syntax and semantics
subclassing not so much better than preprocessing, scanning, parsing.
I definitely don't like having 80 productions in a class (growing to 300, not
sure how to grow over the max nr of instVars ). Is there an array or dictionary
based PPCompositeParser?
Stephan
I have been looking at the ROExample "Nesting" examples and expanded
#nesting2 with another level as shown in the code below, such that there
is the outer view, middle "#1" nodes and inner "#2" nodes. However the
initial state of this has much of the middle node1 and inner node2 nodes
overlapping.
How can these be made for the circle layout to leave spacing between the
middle node1 nodes?
cheers -ben
--------------------
| view nodes1 |
view := ROView new.
view add: (ROElement sprite addAll: (nodes1 := ROElement spritesOn:
(1 to: 10))).
nodes1 do: [:n | n addShape: ROLabel].
nodes1 do:
[ :node1 |
( (node1 model) *100+1 to: (node1 model)*100+5 ) do:
[ :x |
node1 add: ( (ROElement spriteOn: x) addShape: ROLabel).
].
ROGridLayout on: node1 elements.
].
ROCircleLayout on: nodes1.
view openInWindow.
Hi,
Is it possible in Roassal to draw nodes in a layout with different
opacities? A simple example would be: drawing a tree with nodes less opaque
the deeper their nesting level is.
Cheers,
Dennis
Guillaume wrote:
>You can use PetitPreprocessor:
>Gofer new
> squeaksource3: 'PetitPreprocessor';
> package: 'PetitPreprocessor';
> load
>
>Now it's just transform a matching regex to a substitution String (MyParser
>preProcess: ('toPreprocess' asRegex) into: 'preProcessed' ) but I plan to
>improve it by providing a PParser to detect a matching and apply its
>transformation block (myParser preProcessor: (matchingParser ==> [:m |
>..... ])).
Thank you. Will try that first
Stephan
Hi
What is the best way to handle pre-processor directives with PetitParser without polluting
the parsing too much? Any suggestions?
unit forms;
interface
{$IFDEF WINDOWS}
uses bla;
{$ENDIF}
{$IFDEF LINUX}
uses bla2;
{$ENDIF}
Diego & Stephan
Hello all,
I sat with Benjamin today to have a look at Glamour performance when
displaying large text files. For reminder, when displaying text in glamour,
the time to display text increases exponentially with the size of the text
being displayed.
Two observations:
1/ Whereas, with the following script the execution time remains equivalent
to that of morphs
MessageTally spyOn: [ (*GLMPluggableTextMorph*
on: [ (StandardFileStream fileNamed: 'testfile-glam-3500.txt') contents ]
text: #value
accept: nil) openInWindow extent: (1273.0(a)738.0) ]
the execution of this script is four times longer:
| browser text|
browser := *GLMTabulator* new.
browser column: #text.
browser transmit to: #text; andShow: [ :a |
a text
title: 'Text with selection';
display: [(StandardFileStream fileNamed: 'testfile-glam-3500.txt')
contents]].
MessageTally spyOn: [browser openOn: 2].
2/ A bit of digging (using time profiler) shows that the garbage collector
is taking 75% of the execution time. [image: Inline image 1]
Doru, will you have an idea what makes garbage collector execute and take
extra seconds when the text is displayed in a glamour browser instead of
individual glmaour widget?
The moose image with the scripts can be found here if you want to have a
look.
http://dl.dropbox.com/u/11804892/glamour-perf-tests.zip
thanx in advance,
Usman
