Hi,
is it possible to add such a parser that would consume input, but wouldn't
return anything?
Right now I do things like...
MyParser>>rule
^ ($[ asParser, anotherRule, $] asParser) ==> [ :nodes | nodes second ]
Of course when the rules are more complex, so is the block; however it
seems that this is how it's done in the example parsers...
So, would it be possible to add some kind of Null/Void/Ignore/Throwaway
parser, that would consume the input, but would be omitted from the result?
so the above method could be written as
MyParser>>rule
^ $[ asNullPaser, anotherRule, $] asNullParser
or
MyParser>>rule
^ $[ asParser ignore, anotherRule, $[ asParser ignore
or something else.
Thanks,
Peter
Hi,
It would be nice if the moose5.1 (https://ci.inria.fr/moose/job/moose-5.1/) image has no failing tests.
2 tests are failing :
>>><javascript:showStackTrace('test-GT.Tests.Spotter.GTSpotterProcessorsForExamplesTest.testEachProcessor','GT.Tests.Spotter/GTSpotterProcessorsForExamplesTest/testEachProcessor//summary')> GT.Tests.Spotter.GTSpotterProcessorsForExamplesTest.testEachProcessor<https://ci.inria.fr/moose/job/moose-5.1/lastCompletedBuild/testReport/GT.Te…>
1 mn 43 s
44<https://ci.inria.fr/moose/>
>>><javascript:showStackTrace('test-GT.Tests.Inspector.GTInspectorExamplesTest.testAllExamples','GT.Tests.Inspector/GTInspectorExamplesTest/testAllExamples//summary')> GT.Tests.Inspector.GTInspectorExamplesTest.testAllExamples<https://ci.inria.fr/moose/job/moose-5.1/lastCompletedBuild/testReport/GT.Te…>
10 mn
45<https://ci.inria.fr/moose/>
The second has a duration of 10mins which is very long. Does it mandatory do run it and does it possible to split it ?
A way to solve them is to change in RTGrapherExample>>exampleSeismDepthAndMag and exampleSeisms, http://earthquake.usgs.gov/earthquakes/feed/v0.1/summary/2.5_month.csv by http://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/2.5_month.csv
But as it is in Roassal repo I cannot commit it... and one will have to change the configuration of Moose5.1...
By the way, does the GT* tests can be done in a GT job, e.g.: https://ci.inria.fr/moose/job/gtoolkit5 or https://ci.inria.fr/moose/job/gtoolkit/?
Cheers,
Vincent
________________________________
Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Why the restriction that columns be equal? Several times I've wished that I
could set the width of each column. IMHO it would be a very useful feature
to at least default to equal with the ability to drag, if not ideally some
smart width calculation based on the width of the information displayed.
-----
Cheers,
Sean
--
View this message in context: http://forum.world.st/GT-Inspector-Set-Presenter-Width-tp4834858.html
Sent from the Moose mailing list archive at Nabble.com.
Hola todos,
These days I am working on compete with R. I am taking the datasets and
examples from
http://cran.r-project.org/doc/contrib/Zhao_R_and_data_mining.pdf and make
it with Roassal even better ! Or almost... ;)
First chapter first pages, the histograms... In Roassal they were not
working so well.
So lately I restructured the RTDistribution package. This, by default make
a classical frequency distribution, with an optimized number of classes.
The method #strategyBlock: allows to change the strategy for the
distribution.
I also worked on the RTHistogramSet and method #histogram of
SequenceableCollection to improve a bit the looking. There is still here
some work to do but at least the histogram works well and looks fine.
We worked with Alejandro on the algorithm of frequency distribution to make
it efficient compared to the classic one (Only one iteration on datas
during the algo itself).
Here are some examples, don't hesitate to try a bit and give me feedbacks
if any bugs, so I can move on the next graphs ;)
#(5 3 8 6 5 4 2 9 1 2) histogram.
#(1 2 3) histogram.
#(555 1 1 2) histogram.
((1 to: 1000) collect: [:i | i atRandom ]) histogram.
Also, I found this page and thought it was really nice animations !!
http://bost.ocks.org/mike/algorithms/
cheers,
Pierre
Hi,
I am having trouble with opening a specific path in tree presentation
(using MorphTreeMorph) when filtering nodes.
What I am trying to achieve is that if a node is searched in a tree at
level 4, all the parent nodes are opened to show the node searched (hence
the user the does not need to open the nodes manually).
In Glamour, when combined with filtering, expanding up to the root of the
search node works when the parent node is already expanded, otherwise the
nodes are not expanded. At the end of the mail, there are two snippets to
reproduce the behavior.
MorphTreeMorph>>addMorphsTo: from: withExpandedItems: atLevel: is the
method responsible for this behavior in Glamour and it seems that nodes are
only expanded (to show their children) if they were expanded beforehand. Is
there a way to do otherwise in MorphTreeMorph (open paths with non-expanded
nodes)?
tx.
Usman
Code snippets in Glamour (Pharo 4.0):
| tabulator |
tabulator := GLMTabulator new column: [ :c | c row: #one ]; yourself.
tabulator transmit to: #one; andShow: [:a |
a tree
title: 'Show filter paths';
rootsExpanded;
children: [:item :x : level |
(item < 5 and: [ level < 6 ])
ifTrue: [ {item + 1}]
ifFalse:[#() ]];
filterOn: [:text :each | text = each asString]].
tabulator openOn: (1 to: 1) "searching for 3 does not open the path to 3
?!?!?!"
| tabulator | tabulator := GLMTabulator new column: [ :c | c row: #one ];
yourself. tabulator transmit to: #one; andShow: [:a | a tree title: 'Show
filter paths'; rootsExpanded; children: [:item :x : level | (item < 3 and:
[ level < 5 ]) "to stop adding infinite children" ifTrue: [ level = 4 "plug
a node 5 deep down and see if we can find the path" ifTrue: [(1 to: 5)]
ifFalse: [ (1 to: item * 2) ] ] ifFalse:[#() ]]; filterOn: [:text :each |
text = each asString]]. tabulator openOn: (1 to: 2) "searching for 5
correctly opens the path up to 5"
In Moose, I have some problems with my sourceAnchors.
Because of these problems (bugs), sourceText does not work for these
entities
Unfortunatelly, when I try to inspect these faulty entities in
GTInspector (for debugging) it does not work because the first thing it
tries to do is compute all panes, including the one for sourceText which
is buggy :-(
Possible solutions:
- GTInspector's panes would gracefully fail and allow the inspector to
be displayed nevertheless
- Compute a pane when it is visible and only at that moment (but anyway,
failing gracefully would be nice. It is always better to be graceful)
nicolas
For some function, the Roassal Grapher is not really good.
Try this for example:
b := RTGrapher new.
b extent: 600 @ 200.
ds := RTDataSet new.
ds dotShape ellipse size: 0.
ds points: (-2.0 to: 10.0 by: 0.001).
ds connectColor: Color red.
ds x: #yourself.
ds y: [ :x | (x exp) sin ].
b add: ds.
b axisXWithNumberOfTicks: 3.
b axisYWithNumberOfTicks: 4.
b build.
b view
This is well known problem when someone use n-equally space joint in a grapher.
There is some explanation here:
http://maurizzzio.github.io/function-plot/
The solution need to implement an interval arithmetic library apparently.
Nicolas implement an arbitrary-precision float library available in
SciSmalltalk, but I not sure this is enough for a grapher.
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/
Dear All,
Here is a preview of what we will demonstrate at ESUG.
Best is to see it live try this:
-=-=-=-=-=-=-=-=-=-=-=-=
b := RTBundleBuilder new.
b from: {TRObject. TRTest} using: #subclasses.
b edges shape line color: Color black.
b bezier color: (Color blue alpha: 0.5).
b useBezierlineWith: #dependentClasses.
b build.
lb := RTLegendBuilder new.
lb view: b view; right.
lb addText: 'RTBundleBuilder: TRObject and TRTest subclasses'.
lb addColor: Color black text: 'Hierarchy'.
lb addColor: (Color r: 0 g: 120 b: 0 range: 255) text: 'Dependent classes'.
lb addColor: Color red text: 'Senders'.
lb build.
b view
-=-=-=-=-=-=-=-=-=-=-=-=
A very short video is available on: https://vimeo.com/131891902 <https://vimeo.com/131891902>
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
With Vincent, we are reviving Fuel export/import for Moose.
Name: ConfigurationOfFuelMooseExtension-usmanbhatti.28
Author: usmanbhatti
Time: 22 May 2015, 1:55:11.568166 pm
UUID: 297195bb-ea59-4cb5-8ea4-ba1195b39842
Ancestors: ConfigurationOfFuelMooseExtension-MarianoMartinezPeck.27
Add new baseline to work on pharo 3.0 and symbolic dev version
usman & vincent
Hi,
I gave last week a talk at NDC Oslo on "Don't demo facts. Demo stories!".
While the talk is less technical, I did exemplified the message by demoing
Spotter in comparison with the search support from Eclipse.
There are several things I would like to emphasize.
I compared our solution with an "industry standard" one. We often think our
system as being niche and perhaps not mature enough. We need to change that
perception about our work. We build state of the art.
One thing that I did not mention explicitly in the talk is the size of the
implementation. The Spotter implementation is 3500 lines of code -- and
that it is so large because it currently comes with its own widgets.
Furthermore, the extensions average 8 lines per custom processor (including
the method header and the pragma). This is orders of magnitude smaller than
what is typically out there, and it is precisely the reason why we can
compete even if we are fewer.
But, to get out there and compete we have to set that high goal for
ourselves. For example, with GT we do not want to compete. We want to
outcompete. So can you.
While details are important, high goals require us to get away from those
details. Only polishing details will tend to limit you to incremental
improvements. We need to jump from time to time. But, these jumps are hard.
On the one hand, it is hard to find the right jump and convince people to
jump with you. On the other hand, they are hard to predict. For example,
Spotter would have not been predictable one year ago.
Yet, dry goals are not enough to keep us going. We need stories that make
us dream. And the beauty is that Pharo breaths such a story. We should not
limit ourselves to that story only. For example, with GT we want to
reinvent the developer experience by making the developer be able to mold
visual tools to her context because that is the only effective way to build
sustainable systems. This little point of view will turn the IDE upside
down, and this is only possible in a system like Pharo.
Choose your high goal and tell its story through the system that you build.
And remember that Pharo already offers a beautiful story to start from.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
