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
Hi Bijan,
Please ask further questions in the Moose mailing-list, other people
might be interested too.
> I'm trying to understand how PetitParser initializes grammar classes (the
> tutorial doesn't make it clear how to use def: in a class context). I see
> now that mutual recursive productions should work out of the box.
You don't need #def: in the context of PPCompositeParser, the
framework does that for you. See the class comment of
PPCompositeParser for additional information.
> However, while figuring this out, I noticed this following bit:
>
> ...
>
> Â Â Â Â parser := PPUnresolvedParser named: aSymbol.
> Â Â Â Â productionIndexesAndNames do: [ :assoc |
> Â Â Â Â Â Â Â Â self instVarAt: assoc key put: (PPUnresolvedParser named:
> assoc value) ].
> Â Â Â Â parser := self perform: aSymbol.
> ...
>
> It seems that the last line of the snippet should read:
> Â Â Â Â parser def: (self perform: aSymbol).
Yes, you are right. I changed that in the latest version.
However, consider not to loop into the start state. You get a more
reusable model if you use 'parser' simply as a selector of where to
start the grammar (e.g. the method, the method declaration, or the
expression in the example of Smalltalk).
Lukas
>
> This would be consistent with how the rest of the productions initialize
> themselves and wouldn't make the first line of the snippet pointless.
>
> I can't really discern any difference in commenting out line one, leaving
> everything as is, or shifting the last bit to def: So I'm missing something!
>
> Cheers,
> Bijan.
>
--
Lukas Renggli
www.lukas-renggli.ch
Hi,
moosetechnology.org is temporarily down due to a mistake I made in the
DNS settings. It should be back online in 1 day.
Sorry for the trouble :(.
Cheers,
Doru
--
www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."
Hi,
Yet another question on PetitParser :)
All the grammars that I find in PetitParser (e.g., PetitXML,
PetitSmalltalk) are defined in
a single class called PP...Grammar. However, the Java grammar has many rules and
including all of them in a single class seems not the right approach.
For example, now I have a class called PPJavaLexicon, in which I cover the rules
for finding tokens and comments (i.e. the lexical structure [1]).
Then, for example,
I would continue working on types, values, and variables [2]. So, I would
create another class that references PPJavaLexicon and uses the
rules defined there to define the new ones. Something like:
PPJavaTypes>>typeVariable
^ppJavaLexicon identifier
Is this a good approach to split a grammar in more classes,
or would you suggest something different?
Thank you,
Alberto
[1] http://java.sun.com/docs/books/jls/third_edition/html/lexical.html
[2] http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html
Hi Felipe,
The result of opening a browser is a window.
So, you could use something like this:
browser := GLMTabulator new.
...
window := browser openOn: ...
window maximize.
...
window delete.
Could I ask in what context you are using Glamour? Also, a better
forum for discussing these issues is the moose-dev mailing list:
- address: moose-dev(a)iam.unibe.ch
- registration: https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Cheers,
Doru
On 28 Jul 2010, at 21:04, Alexandre Bergel wrote:
> Hi Felipe,
>
> No idea, but this is good to see you here!
>
> Alexandre
>
>
> On 28 Jul 2010, at 18:47, Felipe Ignacio Valverde Campos wrote:
>
>> Hi, i'm beginner on this tools, so i need your help please :)
>> i have some doubts about Glamour, specificaly with GLMTabulator.
>>
>> how can i set the window size ?
>> and how can i close it without pressing the X ?
>>
>> 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.
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
Hi,
As I wrote in my previous e-mail, I am trying to write the Java grammar
for PetitParser. I am following "The Java Language Specification,
Third Edition",
which is the last available book written by Sun with the specification
for the whole
Java language [1]. It covers Java 1.5.
The project, PetitJava, is on SqueakSource [2].
I've just "finished" to implement the literals [3]
and I am trying it with some tests.
I find something strange, thus probably there is something
in PetitParser that I don't get.
As an example, among the primitives in PPJavaGrammar you find:
<snips>
PPJavaGrammar>>octalEscape
^ $\ asParser , ( octalDigit / (octalDigit , octalDigit) /
(zeroToThree , octalDigit , octalDigit) )
PPJavaGrammar>>octalDigit
^PPPredicateObjectParser anyOf: '01234567'
PPJavaGrammar>>zeroToThree
^PPPredicateObjectParser anyOf: '0123'
</snips>
I take some one of the failing tests as an example:
<snips>
PPJavaGrammarTest>>testOctalEscape1
self parse: '\0' rule: #octalEscape
PPJavaGrammarTest>>testOctalEscape2
self parse: '\00' rule: #octalEscape
PPJavaGrammarTest>>testOctalEscape3
self parse: '\000' rule: #octalEscape
</snips>
While the first test passes as I expected,
the second and the third ones do not.
However, they should be recognized as:
$\ , octalDigit , octalDigit
and
$\ , zeroToThree, octalDigit , octalDigit
as stated in the "octalEscape" implementation.
Is there something wrong with my implementation,
or didn't I understand correctly the '/' operator?
Thank you,
Alberto
[1] http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html
[2] http://www.squeaksource.com/PetitJava.html
[3] http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10
