Dev Meeting Log 20091114

Transcript

(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@s100-254.resnet.ucla.edu/] 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