From: Andrius V. <an...@ve...> - 2012-01-25 14:39:58
|
Hello, Thanks for the comments. We have added the support for cyclic parents - CZT parsing no longer crashes with StackOverflowError. Code is in SVN. As Leo has mentioned, the problem used to occur with LatexMarkupParser - it requires parent LatexMarkupFunctions to be built before current section's LatexMarkupFunction can be produced. This requires parent sections to be parsed, and with cyclic parents gets into a loop. The same issue happens when creating InfoTables (e.g. OpTable, ThmTable, etc.) during parsing - they require parent InfoTables to be built. The implementation adds a cycle blocker (see net.sourceforge.czt.parser.util.CyclicParseManager). It keeps the "active" section stack, and an already "active" section can no longer be visited. For example, say we are parsing a cycle A -> B -> C -> A. After parent calls from A and B, we get a situation when C is being parsed, with "active" sections A and B. Now when C is querying for parents to continue, A is excluded as being active, so C is parsed as if having no parent at all. This allows all sections to be parsed - if C did have some dependencies on A, e.g. Latex Markup definitions, parsing of C would fail. Note that the cyclic relationships are reported as parse warnings. So in the above case, the user would have some idea about why C parsing has failed - it would indicate that there is a parent loop. The typechecker also checks for parent cycles, and if found, reports them as typechecker errors. There is a utility class to resolve parent relationships for parsed specifications - net.sourceforge.czt.parser.util.SectParentResolver. We have also added several test cases of cyclic parents, which are run for all parsers and typecheckers. Best regards, Andrius Velykis On Wed, Jan 18, 2012 at 17:19, Leo Freitas <leo...@ne...> wrote: > Hi guys, > > Many thanks for this. Our implementation is already in line with this, so will commit soon. > > One technicality though: because LatexMarkupFunction is calculated earlier (e.g., as a lexer), > and teh information tables (e.g., optable, joker, thm, proofs, definition, etc) occur later on unicode > stream, and we want a solution that is markup independent, the treatment in the parser is to some > extent repeated for these two parts of the process - I don't think there is any performance penalty > for this (e.g., the process is already quite like that anyway - LMF first; tables later). > > Best, > Leo > > > On 17 Jan 2012, at 21:38, Tim Miller wrote: > >> It definitely belongs in the typechecker. There is a note in the >> "inheriting section" section of the Z standard that says: >> >> "NOTE 1 Ancestors need not be immediate parents, and a section cannot be >> amongst its own ancestors (no cycles in the parent relation)." >> >> It is not part of the type rule though, so I must have missed it when I >> implemented the type rules. >> >> Cheers, >> Tim >> >> On 18/01/12 07:06, Mark Utting wrote: >>> Leo >>> >>> Doing it in the typechecker sounds best to me. >>> >>> 1. You might be able to give better error messages there. >>> 2. It will/should work on unicode input, not just latex input. >>> >>> Cheers >>> Mark >>> >>> On 18 January 2012 02:07, Leo Freitas <leo...@ne... >>> <mailto:leo...@ne...>> wrote: >>> >>> Hi, >>> >>> We are trying to solve the problem (e.g., stack overflow) involving >>> cyclic parents of sections. >>> The error occurs when calculating the latex markup function of >>> parents during parsing. >>> >>> Our change/solution avoids the error, and enables sections with >>> cyclic parents to be parsed. >>> Next, the typechecker ensures that the cycle is an error (e.g., note >>> 1, p. 5, 13.2.2.1). >>> >>> So the question is, should the error be flagged by the parser or the >>> typechecker? >>> Looking at the standard, this we couldn't find where it would be. At >>> the moment, >>> we have it at the typechecker. >>> >>> Comments? >>> >>> Leo & Andrius >>> ------------------------------------------------------------------------------ >>> Keep Your Developer Skills Current with LearnDevNow! >>> The most comprehensive online learning library for Microsoft developers >>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >>> Metro Style Apps, more. Free future releases when you subscribe now! >>> http://p.sf.net/sfu/learndevnow-d2d >>> _______________________________________________ >>> CZT-Devel mailing list >>> CZT...@li... <mailto:CZT...@li...> >>> https://lists.sourceforge.net/lists/listinfo/czt-devel >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Keep Your Developer Skills Current with LearnDevNow! >>> The most comprehensive online learning library for Microsoft developers >>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >>> Metro Style Apps, more. Free future releases when you subscribe now! >>> http://p.sf.net/sfu/learndevnow-d2d >>> >>> >>> >>> _______________________________________________ >>> CZT-Devel mailing list >>> CZT...@li... >>> https://lists.sourceforge.net/lists/listinfo/czt-devel >> >> >> ------------------------------------------------------------------------------ >> Keep Your Developer Skills Current with LearnDevNow! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-d2d >> _______________________________________________ >> CZT-Devel mailing list >> CZT...@li... >> https://lists.sourceforge.net/lists/listinfo/czt-devel > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > CZT-Devel mailing list > CZT...@li... > https://lists.sourceforge.net/lists/listinfo/czt-devel |