Hi Jan,

since a while I get a MessageNotUnderstood on PPBrowser open after ConfigurationOfPetitParser loadDevelopment.
Has to do with fonts.
Debugger Stack fueled out can be accessed here: https://dl.dropboxusercontent.com/u/4548797/Debugger-Stack-StrikeFont-2014-12-31-135435.fuel

Regards, Hartmut

Am 16.12.14 14:34, schrieb Jan Kurš:
Hi,

Anyone experience with Athens can help with the first issue? TRLabelShape>>drawOn: seem to be somehow responsible, but I don't see into this :(

Regarding to the second issue, there are some cases, when one really needs a start rule, e.g when computing follow. Yet I updated the code so that it handles missing start rule a bit better.

Please, let me know, if you have some other ideas/suggestions/issues.

Regards,
Jan

On 9 December 2014 at 15:17, Hartmut <krasem...@acm.org <mailto:krasem...@acm.org>> wrote:

    Hi to all,

    I'm working with PetitParser in a Pharo 3 image.
    Until now I had to do without the PPBrowser which I loved in Pharo 2.

    On forum.world.st <http://forum.world.st> I now found the hint by
    Jan Kurs to install all of the Petit suite:

    > "Configuration should be loaded like this:"
    > Gofer new smalltalkhubUser: 'Moose' project: 'PetitParser';
    >     configurationOf: #PetitParser; load.
    >
    > "All the petit parser suite:"
    > ConfigurationOfPetitParser loadDevelopment.

    Apart from the fact that this installed a real lot into my image,
    I notice the following problems
    in PPBrowser:

    1. The map of none of the 18 parsers included, is displayed (it
    becomes red crossed).
        However, this was the most useful part of it

    2. My interrelated parsers consist of a tree of parsers where each
    leave has its own start clause.
        They define related languages. It makes no sense to add a
    /start/ clause to the root.
        However, without such a meaningless /start/ clause, only the
    /source/ is displayed,
        neither /graph, example, first/ or /follow/ of any clause.
        (this can be reproduced when you move PPJsonGrammar>>start to
    PPJsonParser)

    I like the style of having a grammar class above a parser (or
    compiler) class.
    This is as seen in most of the accompanying parsers.
    My preferred petit parser style comprises:
       a) keeping grammar rules (without ==>) in the upper classes of
    the grammar hierarchy tree,
           such that we find the complete grammar there (without the
    /start/ clause).
       b) keeping replacement rules (using ==>) as low as possible the
    grammar hierarchy tree
       c) writing the start clause to the class that is actually
    called. (this gives different entries
           in a grammar allowing for different languages with grammar
    subsets)

    Is there an idea to have 1. and/or 2. resolved?

    Hartmut

-- Hartmut Krasemann

    Königsberger Str. 41 c
    
D 22869 Schenefeld

    Tel. 040.8307097

    Mobil 0171.6451283

    krasem...@acm.org  <mailto:krasem...@acm.org>


--
Hartmut Krasemann

Königsberger Str. 41 c

D 22869 Schenefeld

Tel. 040.8307097

Mobil 0171.6451283

krasem...@acm.org

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to