Loading ...
Sorry, an error occurred while loading the content.

Re: New Sandbox - Loop Detection in Data

Expand Messages
  • thpr
    Note: the appropriate sandbox is detectloop . For some reason, I m getting weird errors from loopdetect TP.
    Message 1 of 2 , Feb 1, 2013
    View Source
    • 0 Attachment
      Note: the appropriate sandbox is "detectloop". For some reason, I'm getting weird errors from "loopdetect"


      --- In pcgen_developers@yahoogroups.com, "thpr" wrote:
      > I have checked in a new sandbox that is doing an additional set of validation on data loaded into PCGen.
      > This is currently checking data to see if there are "loops".
      > The following data would produce a loop:
      > Feat LST:
      > MyFeat <> TEMPLATE:MyTemplate
      > Template LST:
      > MyTemplate <> ABILITY:FEAT|VIRTUAL|MyFeat
      > A Few notes:
      > - Currently this does analysis for direct "Granting" tokens ONLY. Anything from a %LIST (grant as a result of a CHOOSE) is ignored. It is also ignoring all Prerequisites, so it can produce false positives. I'm also not 100% sure it's complete on token grants, but it covers a lot of them as a proof of concept.
      > - Nothing is done with BONUSes, so anything that does BONUS:SKILLRANK... which effectively grants the Skill will not be caught. This will become easier with a BONUS system rebuild, which is currently gated by the BONUS output token (and my focus on Ability cloning)
      > - Nothing is done with formulas, so there are some pretty weird chains of events that can effectively produce a grant based on a formula; that is not handled today since we need to have a more intelligent parsing of the formula to handle that properly (refer to the code team meeting some time ago on the formula parser topic)
      > I'm interested in some feedback. Currently this tags the tokens as "granting" and forces them to identify what is potentially granted. This makes it extendable entirely within the token, but also has the effect of putting a bit of a burden on the token builder to identify it as "granting". This seemed easiest as a first implementation since there is not a consistent method of storing "grants" in the CDOMObjects.
      > This also pulls in some of the graph code, which I've pulled in from the (now seemingly ancient) cdom branch. I've pulled in as little as is necessary but didn't delete interfaces if they weren't used. So it could be a bit thinner if desired.
      > TP.
    Your message has been successfully submitted and would be delivered to recipients shortly.