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

Re: Code Team meeting, Friday Nov 13

Expand Messages
  • 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 1 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 2 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 3 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 4 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.