hello people, someone knows how to do this actions (increase/decrease)
on a Mondrian Pane using Glamour, something like this script with the
button action
| browser |
browser := GLMTabulator new.
browser column: #mpanel.
browser actions: [:root|
{GLMAction new
title: 'increase';
action: [ ??? ]; "<-- what can i put here ?"
icon: MenuIcons smallWindowIcon }].
browser transmit to: #mpanel;
andShow: [:a|
a mondrian
painting: [:view | view nodes: (1 to: 10)]].
browser openOn: {}.
i see the MOEasel code like reference, but it's using a MOCanvas and
MORoot... so i don't know how to do same things with Glamour code...
can i get the MOCanvas from "mondrian pane" ?
can i put a MOCanvas on a Glamour pane ?
something else in order to manipulate the size ?
thanks !
--
http://www.dcc.uchile.cl/~fvalverd/public_key.asc
Estudiante de Ingeniería Civil en Computación.
Facultad de Ciencias Físicas y Matemáticas.
Universidad de Chile.
Hi,
As you might know, Pharo 1.1 has just been released.
I updated hudson to build based on this version. Everything looks fine.
Cheers,
Doru
--
www.tudorgirba.com
"It's not how it is, it is how we see it."
Hi,
4 DSM tests fail in the latest version:
http://hudson.moosetechnology.org/job/moose-latest-dev/272/testReport/
I checked a bit, and:
- testAllDirectCycles: it looks like the order of the detected direct
cycles is not quite correct, but the content of these cycles is (so,
in my image allDirectCycles first is packE and packF)
- I could not figure out what the other problems are.
Could we fix these? :)
Cheers,
Doru
--
www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot
be done."
Hi,
I went quickly through the PetitJava implementation and I stumbled
across the keywords implementation. I would propose a simpler solution:
keyword
^ (arrayOfKeywords inject: PPEpsilonParser new not into: [:p :key |
p / key asParser ]) token trimBlanks .
Now the question is if it makes sense to have a separate parser class
equivalent to PPEpsilonParser new not. If yes, what would a good name
be?
Cheers,
Doru
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
Hi,
I committed another small change that has a significant impact on the
speed of Groups and especially the Moose Finder.
We used to have:
RuntimeStorage>>elements
^self asArray
Now we have
RuntimeStorage>>elements
^elements
In other words, we are not returning an Array but the original
OrderedCollection. This makes up for a significant speed improvement
when having large models. Tests are green, but if you encounter
problems, please let me know.
In any case, I noticed that we are actually using the storage of a
group in a wrong way. We should always use the storage which is
already a collection instead of directly using the entities of a group.
Cheers,
Doru
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of
problem understanding."
Hi all
We got a one year engineer position to support the development of a demonstration for Moose.
The constraints linked with the position are that the person should have got his master
in 2009 or 2010. The starting date is 1 of December 2010.
The salary should be around 3500 Euros bruto ~> 2400 Euros before taxes (but after health insurance).
The job will probably consist in
- getting Moose running into a web browser
- having a better reporting system.
- building a dashboard
- porting part of codecity
By september we should decide if we take this year in 2010 or 2011 (for decembre 2011 the person should have got a master
in 2010 or 2011).
Please send your cv.
Stef
On 8/4/10 5:49 PM, Lukas Renggli wrote:
> I think this parser is called PPFailingParser. It is useful to
> generate custom error messages. It always fails without consuming
> anything.
>
> However for the given example I would use
>
> keywords reduce: [ :a :b | a asParser / b asParser ]
Thanks to both of you for the suggestions,
now the keyword parser (and similarly the separator)
is implemented using:
keywordParsers := keywords keysSortedSafely
collect: [:eachKey | keywords at: eachKey ].
^ (keywordParsers reduce: [ :a :b | a / b ]) token trimBlanks
Since I already have a dictionary "keywords" with each keyword
as a key, and the corresponding parser (not tokenized)
as a value.
Should these parsers be caseInsensitive?
I thought keywords are case sensitive.
Maybe that was another story?
Ciao,
Alberto
On 8/3/10 2:14 PM, Lukas Renggli wrote:
> Hi Alberto,
>
> This is great news. Maybe you also want to post the repository URL? :-)
Sure, please don't be too much horrified by the quality of the code:
http://www.squeaksource.com/PetitJava.html
> For what you noticed on bogus grammar specifications check out the
> work of Vadim Zaytsev (http://mobile.twitter.com/grammarware). Among
> others he analized various Java Language Specifications.
That's interesting, thank you!
> Note that cycles are present in most grammars and perfecly fine. The
> only problematic cycles are the left-recursive ones for recursive
> descent parsers like ANTLR or PetitParser. Even then you can simply
> fix the problem by adding a memoizer into the offending cycle, but
> that yields a very slow grammar. You can find offending cycles with
> the message #cycleSets from the PetitAnalyzer package.
I tried using the "cycle" tab in the PetitParser GUI, which -I think-
does the same thing. Knowing how to call it programmatically is even
better ;)
Alberto
On 8/3/10 10:22 AM, Lukas Renggli wrote:
> Hi Bijan,
>
> Please ask further questions in the Moose mailing-list, other people
> might be interested too.
>
Thanks for sharing it:
I would be definitively happy to read
any discussion related to PetitParser! :)
Btw, it seems that the Java grammar (i.e. PetitJava) is coming.
Just to share my experience, I first tried to implement it
following the Java Language Specification book, Chapter 18.
Even though such chapter should sum up the whole syntax, it is not
completely consistent with the rest of the book (which details
all the rules with explanations and examples), and presents some
errors. Thus, after a brief trial, I moved to implement
the grammar according to the more detailed version.
Alas, such chapters are not perfect, too!
I found out a "corrected" version in a web site [1].
When finally I managed to implement it, it turned out that such
specifications contain various cycles. I tried to fix them, but
that would have required much time.
So, I decided to take the ANTLR version of the java grammar
(which has been tested successfully over a comprehensive regression
test suite) that would contain no dangerous cycles (since it is LL(1))
for PetitParser [2].
Now that grammar is implemented, and it correctly parses the
compilation units I tried. It still needs work (first of all, more
tests. Then, a parser), but it's coming.
From this experience, I would say that the first translator from
grammar-in-another-specification to PetitParser, should be from
ANTLR grammars. The fact that they are LL(1) should avoid cycles
(please correct me, if I am wrong), and there is a very big number
of grammars written for ANTLR.
Ciao,
Alberto
[1]
http://www.cmis.brighton.ac.uk/staff/rnb/bosware/javaSyntax/Java1_6GrammarC…
[2] http://openjdk.java.net/projects/compiler-grammar/antlrworks/Java.g