Unfortunately no, I am actually in an other university ... Do you have any idea about this problem ? 2013/12/17 Uko2 [via Smalltalk] <ml-node+s1294792n4730845h60(a)n4.nabble.com> -- View this message in context: http://forum.world.st/PetitParser-PPCompositeParser-Infinite-loop-tp4730844… Sent from the Moose mailing list archive at Nabble.com.

No it's not a mistake, both have exact same definition but the not the same and it's useful because I use those rules in other parts of the grammar and it helps for the comprehension. Yeah I think it create an infinite recursion but normally I can't have this problem with PPCompositeParser .. 2013/12/17 Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr>

You will not have infinite recursion at the instanciation of the parser, but if you have a cycle that does not consume any character it means you have an infinite loop when you parse. Try to interrupt the infinite loop where you fall; you will see the concerned parsers. You should also use the GT-PetitParserDebugger from andrei MCHttpRepository location: 'http://smalltalkhub.com/mc/Moose/GToolkit/main' user: '' password: '' 2013/12/17 Benjamin AREZKI <benjamin.arezki(a)gmail.com> -- *Guillaume Larcheveque*

Le 18/12/2013 11:15, Nicolas Anquetil a écrit : Yes and no. Some parsers can't handle left-recursion in rules (petit parser? LL parsers can't), some parsers don't have any problem with left recursion (LR parsers like SmaCC). The only thing is that most (all) grammars for programming languages are left recursives... In that particluar case, a parser would be unable to make a difference between choosing ClassType or InterfaceType, since both are defined as exactly the same production. Then, depending on the Parser, it would select only the first, or complain that it can't choose between both :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

________________________________ De : moose-dev-bounces(a)iam.unibe.ch [moose-dev-bounces(a)iam.unibe.ch] de la part de Nicolas Anquetil [Nicolas.Anquetil(a)inria.fr] Date d'envoi : mercredi 18 décembre 2013 13:34 À : Moose-related development Objet : [Moose-dev] Re: PetitParser PPCompositeParser, Infinite loop ? On 12/18/2013 11:27 AM, Goubier Thierry wrote: Le 18/12/2013 11:15, Nicolas Anquetil a écrit : ben there is nothing magic about PPCompositeParser, it is a parser like all the other one and if you call rules without consuming any input + have a loop in the rule calls, then there will be a infinite loop Yes and no. Some parsers can't handle left-recursion in rules (petit parser? LL parsers can't), some parsers don't have any problem with left recursion (LR parsers like SmaCC). I meant PPCompositeParser within PetitParser All parsers PPParsers behave more or less the same way when we come to this. If other can't handle correctly left-recursion ther eis no reasonnable reason to hope that PPCompositeParser composite parser will do. Ok, now I understand what you meant Moreover, being a recursive descent parser, PetitParser naturally can't handle left recursivity You have a point :) In this case, you will need to convert the grammar to a right recursive one, for example like this (which is more or less the same thing I believe): ClassOrInterfaceType: ClassType "/ InterfaceType -- this option is useless here as it is equal to ClassType" ClassType: TypeDeclSpecifier TypeDeclSpecifier: TypeName { . TypeDeclSpecifier } TypeName: Identifier TypeArgumentsopt InterfaceType: TypeDeclSpecifier, TypeArgumentsopt Some of the rules are not really needed, but that way it sticks closer to the reference grammar In that particular problem (InterfaceType = ClassType), PetitParser would select the first alternative everytime, since they are both equal, and would never reach InterfaceType ? Regards, Thierry nicolas -- Nicolas Anquetil -- RMod research team (Inria)

Hi! Today with Jan, we started to “paint” grammars using Roassal: https://www.facebook.com/ObjectProfile The code is available in PetitGui. Just send #visualize to a grammar Cheers, Alexandre On Dec 18, 2013, at 9:46 PM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr> wrote: -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nice. And you integrated it in the GTInspector, too :). Just, please call these methods view*, not visualize*. Doru On Wed, Dec 18, 2013 at 11:30 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr>wrote;wrote: -- www.tudorgirba.com "Every thing has its own flow"

I guess it should. Let see about this today! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oh… I’ve just exported the JavaParser, and I have faced similar problem. Here is how I solve it, it is a bit hacky, but it seems to works. 1 - export the PetitDelphi grammar info an svg file, let’s call it delphi.svg 2 - open emacs on it within a terminal: emacs delphi.svg 3 - convert the mac file into the unix format: C-x RET f undecided-unix 4 - Save it: C-c C-X 5 - Open the file with your web browser, it will now indicate you the culprit line 6 - Fix the SVG by removing “<“ and “&” characters Does this makes sense? The proper solution is to use escape character in the SVG. Something we should do… https://dl.dropboxusercontent.com/u/31543901/TMP/Java.svg Alexandre On Dec 19, 2013, at 11:19 AM, Stephan Eggermont &lt;stephan(a)stack.nl&gt; wrote: -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.