Hi,

PPBrowser uses Roassal which relies on the Athens canvas which requires FreeType fonts :).

To fix this, you can go to Settings:
- Make Use Free type ... true
- Choose a Free type font as the default one.

Or you can just use the Moose 5.0 image:
http://moosetechnology.org/#install

Or you can use some ready made setup script we have in Moose:
Gofer new
smalltalkhubUser: 'Moose' project: 'GToolkit';
package: 'GT-Setup';
load.
#GTImageSetupCommandLineHandler asClass activateWithoutSaving

Cheers,
Doru



On Wed, Dec 31, 2014 at 2:10 PM, Hartmut <krasemann@acm.org> wrote:
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 <krasemann@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 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���
krasemann@acm.org

-- 
Hartmut Krasemann���
K��nigsberger Str. 41 c
���D 22869 Schenefeld���
Tel. 040.8307097���
Mobil 0171.6451283���
krasemann@acm.org



--
www.tudorgirba.com

"Every thing has its own flow"