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

Code Team meeting, Friday Nov 13

Expand Messages
  • James Dempsey
    Hi, The next Code team meeting will be Friday, November 13 at 6 PM EST See
    Message 1 of 5 , Nov 11, 2009
    • 0 Attachment
      Hi,

      The next Code team meeting will be Friday, November 13 at 6 PM EST

      See http://www.timeanddate.com/worldclock/fixedtime.html?day=14&month=11&year=2009&hour=10&min=0&sec=0&p1=57
      for your local time.

      We will be chatting in channel #pcgen on IRC <irc.freenode.net>.

      If you have any agenda items you would like to be included please post
      here before the meeting.

      Cheers,
      James Dempsey
      PCGen Code SB
    • thpr
      ... My primary item was the output sheets/output tokens topic I started here: http://tech.groups.yahoo.com/group/pcgen_developers/message/465 TP.
      Message 2 of 5 , Nov 13, 2009
      • 0 Attachment
        --- In pcgen_developers@yahoogroups.com, James Dempsey <jdempsey@...> wrote:
        > We will be chatting in channel #pcgen on IRC <irc.freenode.net>.
        >
        > If you have any agenda items you would like to be included please post
        > here before the meeting.

        My primary item was the output sheets/output tokens topic I started here:

        http://tech.groups.yahoo.com/group/pcgen_developers/message/465

        TP.
      • James Dempsey
        Hi, On 14/11/2009 9:48 AM thpr wrote ... Thanks Tom. So the agenda will be 1. Status update (including readiness for 5.16.2) 2. New UI demo - path getting
        Message 3 of 5 , Nov 13, 2009
        • 0 Attachment
          Hi,

          On 14/11/2009 9:48 AM thpr wrote
          > --- In pcgen_developers@yahoogroups.com, James Dempsey <jdempsey@...> wrote:
          >
          >> We will be chatting in channel #pcgen on IRC <irc.freenode.net>.
          >>
          >> If you have any agenda items you would like to be included please post
          >> here before the meeting.
          >>
          >
          > My primary item was the output sheets/output tokens topic I started here:
          >
          > http://tech.groups.yahoo.com/group/pcgen_developers/message/465
          >
          >
          Thanks Tom. So the agenda will be

          1. Status update (including readiness for 5.16.2)
          2. New UI demo - path getting something out before Christmas
          3. Output sheets/output tokens
          4. Other business

          Meeting starts on the hour ( 5 minutes from when I sent this).

          Cheers,
          James.
        • karianna03
          Log?
          Message 4 of 5 , Nov 17, 2009
          • 0 Attachment
            Log?

            --- In pcgen_developers@yahoogroups.com, James Dempsey <jdempsey@...> wrote:
            >
            > Hi,
            >
            > On 14/11/2009 9:48 AM thpr wrote
            > > --- In pcgen_developers@yahoogroups.com, James Dempsey <jdempsey@> wrote:
            > >
            > >> We will be chatting in channel #pcgen on IRC <irc.freenode.net>.
            > >>
            > >> If you have any agenda items you would like to be included please post
            > >> here before the meeting.
            > >>
            > >
            > > My primary item was the output sheets/output tokens topic I started here:
            > >
            > > http://tech.groups.yahoo.com/group/pcgen_developers/message/465
            > >
            > >
            > Thanks Tom. So the agenda will be
            >
            > 1. Status update (including readiness for 5.16.2)
            > 2. New UI demo - path getting something out before Christmas
            > 3. Output sheets/output tokens
            > 4. Other business
            >
            > Meeting starts on the hour ( 5 minutes from when I sent this).
            >
            > Cheers,
            > James.
            >
          • James Dempsey
            (10:01:37 AM) James[Code_SB]: Alright, I have 10am in Canberra so time to start (10:01:49 AM) James[Code_SB]: Welcome everyone to the PCGen code meeting
            Message 5 of 5 , Nov 17, 2009
            • 0 Attachment
              (10:01:37 AM) James[Code_SB]: Alright, I have 10am in Canberra so time
              to start
              (10:01:49 AM) James[Code_SB]: Welcome everyone to the PCGen code meeting
              (10:02:18 AM) James[Code_SB]: The agenda for todays meeting is
              (10:02:20 AM) James[Code_SB]: 1. Status update (including readiness for
              5.16.2)
              (10:02:20 AM) James[Code_SB]: 2. New UI demo - path getting something
              out before Christmas
              (10:02:20 AM) James[Code_SB]: 3. Output sheets/output tokens
              (10:02:20 AM) James[Code_SB]: 4. Other business
              (10:02:52 AM) James[Code_SB]: Any objections or extra suggestions?
              (10:03:08 AM) [Arch_SB]thpr: Not unless Nuance shows up
              (10:03:19 AM) James[Code_SB]: ok
              (10:03:37 AM) James[Code_SB]: 1. Status update (including readiness for
              5.16.2)
              (10:03:44 AM) James[Code_SB]: I'll start
              (10:04:26 AM) James[Code_SB]: I've been doing a bit of bug fixing for
              5.16 and think all the essential ones (bar one) have been dealt with
              (10:05:16 AM) James[Code_SB]: Currently stuck on the purchase points
              issue and while I have a fix done I need to go back and look at how it
              affects older characters and if it makes sense for them. So that has
              slowed me down a bit.
              (10:05:52 AM) James[Code_SB]: Tom, did you want to go next?
              (10:06:36 AM) [Arch_SB]thpr: Sure
              (10:06:56 AM) [Arch_SB]thpr: My machine is currently running the unit
              tests for the SPELLLEVEL issue
              (10:07:05 AM) [Arch_SB]thpr: so that should be fixed here in about 15
              mins once it finishes
              (10:07:34 AM) [Arch_SB]thpr: (for 5.16.2)
              (10:07:58 AM) James[Code_SB]: We have one unit test failure in the trunk
              currently - looks like a data change we need to do an update for
              (10:08:14 AM) [Arch_SB]thpr: oh, I hadn't noticed that
              (10:08:18 AM) [Arch_SB]thpr: because my fix is in the 5.16 branch
              (10:08:25 AM) [Arch_SB]thpr: which appears clean so far
              (10:08:34 AM) TirGwaith: James, what data change (which unit test)?
              (10:10:19 AM) [Arch_SB]thpr: umm, where are the autobuilds now? The
              pcgen.org shows a 23 Jul set of tests
              (10:10:22 AM) James[Code_SB]: See
              http://pcgen.sourceforge.net/autobuilds/junit-report.html looks like a
              MSRD abilities change, but I haven't looked further into it yet
              (10:10:30 AM) [Arch_SB]thpr: great timing James
              (10:10:40 AM) [Admin]Drew: might be a change I made...
              (10:10:48 AM) [Arch_SB]thpr: We should delete the old results from pcgen.org
              (10:10:54 AM) James[Code_SB]: Yep I'll do that
              (10:10:56 AM) [Arch_SB]thpr: so people don't continue to look at them
              (10:11:16 AM) TirGwaith: Drew, I'm checking into it now.
              (10:11:58 AM) [Arch_SB]thpr: ok, back to my report I guess
              (10:12:06 AM) TirGwaith: sorry for the sidetrack
              (10:12:20 AM) [Arch_SB]thpr: Tir: no worries.
              (10:12:45 AM) [Arch_SB]thpr: I think I took an action from one of the
              previous meetings to work on the formula compiler (lost track if that
              was 1 or 2 meetings ago)
              (10:13:10 AM) [Arch_SB]thpr: I did update that code in the sandbox and
              it can now parse pretty much every formula in our data
              (10:13:24 AM) James[Code_SB]: Nice
              (10:13:32 AM) [Arch_SB]thpr: I also found some data bugs while
              developing, and opened some work for the data team
              (10:14:00 AM) [Arch_SB]thpr: I think Drew may have addressed some of
              them already
              (10:14:21 AM) [Arch_SB]thpr: but that is now ready for further
              evaluation to see if we want to use that to process formulas during LST load
              (10:14:59 AM) [Arch_SB]thpr: not much more work on the facet side since
              last time, so nothing to report there
              (10:15:06 AM) [Arch_SB]thpr: that's it from me
              (10:15:37 AM) *cpmeister [/n=cpmeiste@.../] entered
              the room.*
              (10:15:44 AM) James[Code_SB]: Hi Connor
              (10:15:50 AM) cpmeister: hi all!
              (10:15:52 AM) [Arch_SB]thpr: Hey Connor
              (10:16:48 AM) James[Code_SB]: Mark did you want to go next
              (10:16:54 AM) MotorViper: OK
              (10:17:04 AM) James[Code_SB]: Connor we are going through current status
              (10:17:18 AM) cpmeister: ah, ok
              (10:17:39 AM) MotorViper: I've finished the first pass of the change in
              error reporting. Still more to do however.
              (10:17:59 AM) MotorViper: I've also started to write the lst editor.
              (10:18:42 AM) MotorViper: There's a small problem with getting the list
              of tokens automatically, which may be because I'm not fully up to speed
              with the code yet.
              (10:19:19 AM) MotorViper: For instance I see ConcretePreReqObject but
              not Feats!
              (10:19:48 AM) [Arch_SB]thpr: Let me pull together a description for you
              of how to get the token list
              (10:19:57 AM) James[Code_SB]: Shall we hit that one at the end?
              (10:20:12 AM) MotorViper: That's ok with me.
              (10:20:12 AM) [Arch_SB]thpr: yea, we can come back to taht
              (10:20:16 AM) James[Code_SB]: Cool
              (10:21:08 AM) James[Code_SB]: All done Mark?
              (10:21:27 AM) MotorViper: That's all for now.
              (10:21:55 AM) James[Code_SB]: Thanks! Connor, did you want to add a report?
              (10:22:20 AM) cpmeister: not particularly, I just wanted to drop by :)
              (10:22:26 AM) James[Code_SB]: :)
              (10:22:58 AM) James[Code_SB]: Cool - I assume you have been busy with
              studies?
              (10:23:32 AM) cpmeister: yeah, pretty much
              (10:24:01 AM) James[Code_SB]: ok, so it sounds like we are very close to
              being ready for a RC of 5.16.2.
              (10:24:18 AM) James[Code_SB]: In fact, once your SPELLEVEL fix is in TOm
              I'll start work on the release
              (10:25:11 AM) James[Code_SB]: Alright, moving on
              (10:25:12 AM) James[Code_SB]: 2. New UI demo - path getting something
              out before Christmas
              (10:26:33 AM) James[Code_SB]: We've been asked to provide something to
              the commuinity to comment on before we go too far, which I have to agree
              is a good idea
              (10:26:58 AM) James[Code_SB]: I think a few screen shots would be a good
              inital offering
              (10:27:36 AM) James[Code_SB]: and from what I have seen the CDOM-UI
              branch is probably up to that about now apart from how the character
              sheet would be displayed
              (10:27:45 AM) James[Code_SB]: Thoughts Connor?
              (10:28:44 AM) cpmeister: I think screen shots would be a good start,
              since trying to get a working demo would produce a lot of unnessesary code
              (10:28:59 AM) James[Code_SB]: Indeed
              (10:29:28 AM) James[Code_SB]: Would there be a simple way of grafting on
              the character sheet display in the way you intended?
              (10:29:55 AM) James[Code_SB]: I'd be equally happy to do some work in an
              image program to merge two screen shots for instance
              (10:31:18 AM) cpmeister: there should be, I'm not sure if the current
              demo just has a blank space where it is supposed to be, but iy would be
              fairly easy to set it up so you can easily image edit it
              (10:31:56 AM) cpmeister: I'd need to check
              (10:31:59 AM) James[Code_SB]: Should we have a quick chat offline about
              what you intended and I'll set up the demo?
              (10:32:14 AM) cpmeister: sure, if you want
              (10:33:22 AM) James[Code_SB]: So actions out of that:
              (10:33:31 AM) James[Code_SB]: Connro and James to chat about presentation
              (10:33:48 AM) James[Code_SB]: James to assemble some screenshots for
              community discussion
              (10:35:00 AM) James[Code_SB]: -
              (10:35:01 AM) James[Code_SB]: 3. Output sheets/output tokens
              (10:35:02 AM) James[Code_SB]: -
              (10:35:14 AM) James[Code_SB]: Tom, did you want to lead that one?
              (10:35:19 AM) [Arch_SB]thpr: sure
              (10:36:10 AM) [Arch_SB]thpr: So the goal is to look at how we
              restructure the output tokens
              (10:36:22 AM) [Arch_SB]thpr: this is a code change, not a literal
              formatting change for the tokens
              (10:36:39 AM) [Arch_SB]thpr: so if a token appeared in a file as
              "TEMPLATE.X.NAME" today, it would remain that way in the immediate future
              (10:36:48 AM) [Arch_SB]thpr: the intent here is to redo the code underneath
              (10:37:02 AM) [Arch_SB]thpr: this can accomplish a few things
              (10:37:21 AM) [Arch_SB]thpr: first, get the tokens out of the core, so
              that they are more plugins, akin to the LST token work done in 5.16
              (10:37:46 AM) [Arch_SB]thpr: second, get away from the long if
              statements we have in token lookups (which will help performance during
              output due to less string comparisons)
              (10:38:12 AM) [Arch_SB]thpr: third, provide more modularity to the
              tokens to allow easier and more isolated changes
              (10:38:26 AM) [Arch_SB]thpr: (this is similar to how we have separate
              LST tokens for subtokens of ADD, CHOOSE, etc.)
              (10:38:52 AM) [Arch_SB]thpr: fourth, to provide more code reuse (we have
              a bunch of copy/paste going on in the output system)
              (10:39:20 AM) [Arch_SB]thpr: and also, at least I'd like to get more of
              a handle on what the output tokens can do, so we can do conversions
              (10:39:30 AM) [Arch_SB]thpr: we have a few duplicate output tokens
              (10:39:42 AM) [Arch_SB]thpr: but it would be nice to be able to read in
              an unformatted OS and output a new unformatted OS with the "correct"
              token names
              (10:39:59 AM) [Arch_SB]thpr: just as we do automated conversion in the
              LST files today for token changes between versions (like we are doing
              with CHOOSE)
              (10:40:25 AM) [Arch_SB]thpr: so, with all of those expectations...
              (10:40:57 AM) [Arch_SB]thpr: the idea that I have is to turn the tokens
              into a form of pipeline
              (10:41:11 AM) [Arch_SB]thpr: so that each item does a set of processing
              and can pass to another item
              (10:41:25 AM) [Arch_SB]thpr: TEMPLATE.X.NAME for example, is 3 items,
              TEMPLATE, X, and NAME
              (10:41:40 AM) [Arch_SB]thpr: (the X presumably is from an IF statement
              that is iterating over a set of numbers)
              (10:42:06 AM) *[Admin]Drew is now known as Drew_afk*
              (10:42:45 AM) [Arch_SB]thpr: With that design, if we produced something
              that could take in a Domain and output its name (e.g. DOMAIN.X.NAME)
              (10:43:08 AM) [Arch_SB]thpr: that output item (specifically the NAME
              component) could be reused in other places where a Domain could be
              produced, e.g. DEITY.DOMAINS.X.NAME
              (10:43:20 AM) [Arch_SB]thpr: this is possible with the same code
              (10:43:31 AM) [Arch_SB]thpr: by making this separation for each item
              (10:43:59 AM) [Arch_SB]thpr: So (and I'm duplicating a bit what was in
              my prep note), this leads to 6 types of items:
              (10:44:15 AM) [Arch_SB]thpr: Starting List (e.g. TEMPLATE) ... MUST
              appear as the first item in a token, returns a list
              (10:44:21 AM) [Arch_SB]thpr: Starting Object (e.g. RACE) .... MUST
              appear as the first item in a token, returns an object
              (10:44:28 AM) [Arch_SB]thpr: Filter (e.g. SPELLCASTER) ... MUST not
              appear as the first item, MUST start with a list, and returns a list
              (10:44:35 AM) [Arch_SB]thpr: Expander (e.g. DOMAIN) ... MUST not appear
              as the first item, MUST start with a single object and returns a list
              (10:44:42 AM) [Arch_SB]thpr: Reducer (e.g. X) ... MUST not appear as the
              first item, MUST start with a list and returns an object
              (10:44:48 AM) [Arch_SB]thpr: Characteristic (e.g. NAME) ... MUST not
              appear as the first item, MUST start with a single object and returns a
              String.
              (10:45:44 AM) [Arch_SB]thpr: with a few exceptions, that should provide
              a feature-complete set of tokens
              (10:45:59 AM) [Arch_SB]thpr: The two main sets of exceptions are:
              (10:46:08 AM) [Arch_SB]thpr: 1) Stateful tokens controlling whitespace
              behavior
              (10:46:24 AM) [Arch_SB]thpr: 2) Some Game Mode information tokens, such
              as units (meters, feet)
              (10:46:52 AM) [Arch_SB]thpr: those are both single item type things that
              don't need the pipeline complexity
              (10:47:05 AM) [Arch_SB]thpr: any questions so far?
              (10:47:55 AM) MotorViper: Just a comment, making whitespace behaviour
              etc. different may be more efficient but it can fit into the schema and
              makes the code more consistent.
              (10:48:41 AM) [Arch_SB]thpr: I think they need to share some of the
              characteristics
              (10:48:50 AM) [Arch_SB]thpr: they shouldn't be in a big if statement
              still, for example
              (10:49:25 AM) [Arch_SB]thpr: but as far as sharing the same interfaces
              (which may return a String result), I have to think more about that.
              (10:49:31 AM) [Arch_SB]thpr: They don't process information, they
              control state, so they are different
              (10:50:18 AM) MotorViper: Not really they are just another type of
              output, the main difference is where they get their info from.
              (10:50:37 AM) James[Code_SB]: Except some of them do control state
              (10:50:54 AM) James[Code_SB]: The manual whitespace one for instance
              (10:51:10 AM) [Arch_SB]thpr: The Game Mode items are output, so they can
              probably share the Interface of the last set of tokens (that returns a
              String)
              (10:51:20 AM) [Arch_SB]thpr: But the whitespace controllers don't ever
              output anything, so I'm cautious to use that Interface
              (10:51:36 AM) [Arch_SB]thpr: because it leads can lead to false
              conclusions about behavior
              (10:52:13 AM) [Arch_SB]thpr: Long term, I'd like to get rid of them by
              having a different OS system (e.g. templating) that doesn't require them
              as a workaround
              (10:52:16 AM) MotorViper: Sorry got confused I assumed manual whitespace
              was inserting whitespace so I withdraw, at least partially, my comment.
              (10:52:36 AM) James[Code_SB]: True
              (10:52:47 AM) James[Code_SB]: I assume you have a plan in mind for
              characteristics which only apply to specific objects?
              (10:53:08 AM) [Arch_SB]thpr: Yes, pretty much identical to how the LST
              tokens work
              (10:53:25 AM) [Arch_SB]thpr: meaning it can be an OutputToken<Ability>
              and do things specifically for Ability objects
              (10:53:40 AM) [Arch_SB]thpr: or OutputToken<CDOMObject> and apply to any
              type of CDOMObject (this is what NAME would actually be)
              (10:54:14 AM) James[Code_SB]: Right
              (10:54:17 AM) [Arch_SB]thpr: this minimizes duplication of the basic
              CDOMObject info (NAME, SOURCE, etc.)
              (10:55:29 AM) [Arch_SB]thpr: so if I go back to the DEITY.DOMAINS.X.NAME
              example
              (10:55:33 AM) [Arch_SB]thpr: we can walk through that a bit
              (10:55:50 AM) [Arch_SB]thpr: DEITY is a Starting Object, since a PC can
              only have one Deity
              (10:56:01 AM) [Arch_SB]thpr: so it returns a Deity
              (10:56:23 AM) [Arch_SB]thpr: the next item (DOMAINS) is then evaluated
              in context to Deity
              (10:56:42 AM) [Arch_SB]thpr: meaning the system looks for a
              Characteristic or Filter that is for a DEITY
              (10:56:53 AM) [Arch_SB]thpr: If it was a Characteristic it would be an
              error (since it's followed by another item)
              (10:57:22 AM) [Arch_SB]thpr: DOMAINS would be an Expander<Deity> (making
              up the interfaces here)
              (10:57:32 AM) [Arch_SB]thpr: It would return a List<Domain>
              (10:58:15 AM) [Arch_SB]thpr: (I'm considering it returns the DOMAINS
              specified in the DOMAINS token in the LST file for the PC
              (10:58:17 AM) [Arch_SB]thpr: 's Deity)
              (10:58:36 AM) [Arch_SB]thpr: The next item is then tested in the context
              of List<Domain>
              (10:58:49 AM) [Arch_SB]thpr: X (representing a number) is a Reducer,
              which can work on a list
              (10:59:13 AM) [Arch_SB]thpr: (note that this could also be one or more
              filters followed by a reducer)
              (10:59:25 AM) [Arch_SB]thpr: the result of the reduction is a single Domain
              (10:59:43 AM) [Arch_SB]thpr: then NAME is tested in the context of
              Domain, and it's a Characteristic<CDOMObject>
              (11:00:04 AM) [Arch_SB]thpr: since Domain extends CDOMObject, it can be
              used, so the NAME of the Domain is output
              (11:00:39 AM) [Arch_SB]thpr: Similar as to how the LST tokens work, if a
              Characteristic<Domain> called "NAME" existed as well as a
              Characteristic<CDOMObject> called "NAME", the more specific one would "win"
              (11:01:02 AM) [Arch_SB]thpr: The system can also detect (and produce an
              error) if two Characteristics with the same target class and same name
              are loaded
              (11:01:08 AM) [Arch_SB]thpr: just as is done with LST tokens today
              (11:01:32 AM) James[Code_SB]: Sounds good
              (11:01:56 AM) [Arch_SB]thpr: that's pretty much it
              (11:02:10 AM) [Arch_SB]thpr: I have some specific examples of the
              interfaces in the note I shipped out
              (11:02:29 AM) [Arch_SB]thpr: and we'll need to polish that so there
              aren't code cycles
              (11:02:52 AM) MotorViper: Is it worth adding in something like
              DEITY.DOMAINS.NAMES where NAMES is an aggregator, i.e. it takes a list
              and produces a string
              (11:02:53 AM) [Arch_SB]thpr: (I haven't stopped long enough this week to
              work through that to ensure a solution I like)
              (11:03:46 AM) [Arch_SB]thpr: that sounds very interesting. Tir, are
              there places in the OS where we do that type of list generation that
              this would help eliminate a loop?
              (11:05:14 AM) [Arch_SB]thpr: I'll check on that; we can move on
              (11:05:21 AM) [Arch_SB]thpr: I think it's a good idea though
              (11:05:46 AM) [Arch_SB]thpr: and likely will help simplify OS, so we
              should consider that part of the plan unless we prove it really can't help
              (11:06:10 AM) TirGwaith: typically, we do a loop for getting at objects
              and data in them. But some of the tokens for Stat sheets just print a list
              (11:06:46 AM) TirGwaith: I'm not sure if they just loop through the
              objects and print names or not
              (11:07:02 AM) [Arch_SB]thpr: there are some cases, e.g. languages, where
              it seems that would be useful
              (11:07:13 AM) TirGwaith: proficiencies
              (11:07:14 AM) [Arch_SB]thpr: at least without looking at the OS :)
              (11:07:18 AM) [Arch_SB]thpr: another one, yes
              (11:08:13 AM) [Arch_SB]thpr: any other thoughts or ideas?
              (11:09:19 AM) [Arch_SB]thpr: back to you I think, James
              (11:10:24 AM) James[Code_SB]: That seemed like a pretty thorough study
              Tom - thanks
              (11:10:42 AM) James[Code_SB]: 4. Other business
              (11:11:03 AM) James[Code_SB]: I think the first thing to discuss was
              getting the list of tokens automatically for the editor
              (11:11:19 AM) [Arch_SB]thpr: eek
              (11:11:21 AM) [Arch_SB]thpr: not ready yet
              (11:11:25 AM) [Arch_SB]thpr: machine has been lagging with a build
              (11:11:34 AM) James[Code_SB]: ok, we can do that on the list easily enough
              (11:11:39 AM) James[Code_SB]: That work for you Mark?
              (11:11:51 AM) [Arch_SB]thpr: give me 2 min
              (11:11:54 AM) James[Code_SB]: ok
              (11:12:09 AM) James[Code_SB]: Anyone have anything else they wanted to
              discuss?
              (11:12:10 AM) MotorViper: Any time, as long as I'm still awake!
              (11:12:15 AM) James[Code_SB]: :)
              (11:15:59 AM) [Arch_SB]thpr: ok
              (11:16:13 AM) [Arch_SB]thpr: Sorry about the lag guys, having some
              issues here
              (11:16:15 AM) [Arch_SB]thpr: TokenFamilyIterator<T> it = new
              TokenFamilyIterator<T>(cl);
              (11:16:15 AM) [Arch_SB]thpr: while (it.hasNext())
              (11:16:15 AM) [Arch_SB]thpr: {
              (11:16:15 AM) [Arch_SB]thpr: CDOMPrimaryToken<? super T> token = it.next();
              (11:16:15 AM) [Arch_SB]thpr: }
              (11:16:37 AM) [Arch_SB]thpr: give the class you want to deal with (e.g.
              Race.class) to TokenFamilyIterator
              (11:16:46 AM) [Arch_SB]thpr: it will return to you the possible tokens
              you can use
              (11:17:11 AM) [Arch_SB]thpr: including any that are valid due to the
              parent of the class (e.g. CDOMPrimaryToken<CDOMObject> would also be
              returned for Race.class)
              (11:17:25 AM) [Arch_SB]thpr: You can see it actually used in public <T>
              Collection<String> unparse(LoadContext context, T cdo)
              (11:17:35 AM) [Arch_SB]thpr: within
              pcgen.rules.persistence.TokenSupport.java
              (11:17:43 AM) [Arch_SB]thpr: as part of supporting unparsing of data
              (11:17:56 AM) [Arch_SB]thpr: which has to do an exhaustive iteration
              over all the tokens
              (11:18:16 AM) [Arch_SB]thpr: is that what you're looking for Mark?
              (11:18:38 AM) MotorViper: I was actually trying to get the list of items
              at the level above, i.e. Race, Deity, Skill etc.
              (11:19:11 AM) [Arch_SB]thpr: ok, need to be specific here
              (11:19:22 AM) [Arch_SB]thpr: Race, has a token called Hands
              (11:19:28 AM) [Arch_SB]thpr: there is a global token called Spells
              (11:19:32 AM) [Arch_SB]thpr: when you ask for Race tokens
              (11:19:39 AM) [Arch_SB]thpr: do you want only Hands, or both Hands and
              Spells?
              (11:20:42 AM) [Arch_SB]thpr: or am I not following what you're asking for?
              (11:21:42 AM) MotorViper: I'm looking for the global tokens, i.e. I want
              something that will return the list that is partially hard-coded in the
              current list editor.
              (11:22:15 AM) [Arch_SB]thpr: so just pass in CDOMObject.class into
              TokenFamilyIterator
              (11:22:45 AM) [Arch_SB]thpr: or maybe I should ask where it's hardcoded
              (11:22:46 AM) MotorViper: I see, I'll give it a go now and see if it
              gives what I want. Can you wait a few minutes?
              (11:22:54 AM) [Arch_SB]thpr: absolutely
              (11:23:22 AM) [Arch_SB]thpr: sounds to me like were into detail beyond
              what we need to call the formal meeting though
              (11:23:43 AM) MotorViper: I agree this is probably outside the meeting.
              (11:23:48 AM) James[Code_SB]: One last thing I wanted to chat quickly about
              (11:24:10 AM) James[Code_SB]: I while ago I added Spring support into a
              sample of the facets
              (11:24:43 AM) James[Code_SB]: Just wondering if anyone had any views on
              it - for or against
              (11:25:36 AM) cpmeister: none from me
              (11:26:03 AM) [Arch_SB]thpr: I'm for, just hadn't done any of the others
              since my focus has been 5.16 bugs and CHOOSE changes
              (11:26:47 AM) James[Code_SB]: no worries - anyone can have stab at
              migrating some other too if they like. It's pretty straight forward
              (11:27:02 AM) James[Code_SB]: ok, anything else to discuss?
              (11:27:53 AM) TirGwaith: for some reason, I'm not seeing the raw data
              xml output on Elwood, so I can't really compare. I'm not sure where my
              system is putting it
              (11:29:05 AM) James[Code_SB]: I can give you a hand with that
              (11:29:35 AM) James[Code_SB]: coce/testsuite/output/Elwood.xml
              (11:30:01 AM) James[Code_SB]: and it is compared to
              code/testsuite/csheets/Elwood.xml
              (11:32:29 AM) TirGwaith: ok, different than I was expecting. Ok,
              something about Uncanny dodge, and some DESCs.
              (11:32:42 AM) James[Code_SB]: Happy to chat about those
              (11:32:43 AM) TirGwaith: I think it is a data change, but those would
              have to be from
              (11:32:49 AM) TirGwaith: Eddy's converter run
              (11:32:50 AM) James[Code_SB]: Sounds like that's all for now
              (11:32:57 AM) James[Code_SB]: Thanks for coming along everyone
            Your message has been successfully submitted and would be delivered to recipients shortly.