Dev Meeting Log 20091114 - Revision history

Tom Parker: Created page with "==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
2014-02-19T00:54:03Z

Created page with "==Transcript== (10:01:37 AM) James[Code_SB]: Alright, I have 10am in Canberra so time to start<br/> (10:01:49 AM) James[Code_SB]: Welcome everyone to the PCGen code meeting<b..."

New page
==Transcript==

(10:01:37 AM) James[Code_SB]: Alright, I have 10am in Canberra so time to start<br/>
(10:01:49 AM) James[Code_SB]: Welcome everyone to the PCGen code meeting<br/>
(10:02:18 AM) James[Code_SB]: The agenda for todays meeting is<br/>
(10:02:20 AM) James[Code_SB]: 1. Status update (including readiness for 5.16.2)<br/>
(10:02:20 AM) James[Code_SB]: 2. New UI demo - path getting something out before Christmas<br/>
(10:02:20 AM) James[Code_SB]: 3. Output sheets/output tokens<br/>
(10:02:20 AM) James[Code_SB]: 4. Other business<br/>
(10:02:52 AM) James[Code_SB]: Any objections or extra suggestions?<br/>
(10:03:08 AM) [Arch_SB]thpr: Not unless Nuance shows up<br/>
(10:03:19 AM) James[Code_SB]: ok<br/>
(10:03:37 AM) James[Code_SB]: 1. Status update (including readiness for 5.16.2)<br/>
(10:03:44 AM) James[Code_SB]: I'll start<br/>
(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<br/>
(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.<br/>
(10:05:52 AM) James[Code_SB]: Tom, did you want to go next?<br/>
(10:06:36 AM) [Arch_SB]thpr: Sure<br/>
(10:06:56 AM) [Arch_SB]thpr: My machine is currently running the unit tests for the SPELLLEVEL issue<br/>
(10:07:05 AM) [Arch_SB]thpr: so that should be fixed here in about 15 mins once it finishes<br/>
(10:07:34 AM) [Arch_SB]thpr: (for 5.16.2)<br/>
(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<br/>
(10:08:14 AM) [Arch_SB]thpr: oh, I hadn't noticed that<br/>
(10:08:18 AM) [Arch_SB]thpr: because my fix is in the 5.16 branch<br/>
(10:08:25 AM) [Arch_SB]thpr: which appears clean so far<br/>
(10:08:34 AM) TirGwaith: James, what data change (which unit test)?<br/>
(10:10:19 AM) [Arch_SB]thpr: umm, where are the autobuilds now? The pcgen.org shows a 23 Jul set of tests<br/>
(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<br/>
(10:10:30 AM) [Arch_SB]thpr: great timing James<br/>
(10:10:40 AM) [Admin]Drew: might be a change I made...<br/>
(10:10:48 AM) [Arch_SB]thpr: We should delete the old results from pcgen.org<br/>
(10:10:54 AM) James[Code_SB]: Yep I'll do that<br/>
(10:10:56 AM) [Arch_SB]thpr: so people don't continue to look at them<br/>
(10:11:16 AM) TirGwaith: Drew, I'm checking into it now.<br/>
(10:11:58 AM) [Arch_SB]thpr: ok, back to my report I guess<br/>
(10:12:06 AM) TirGwaith: sorry for the sidetrack<br/>
(10:12:20 AM) [Arch_SB]thpr: Tir: no worries.<br/>
(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)<br/>
(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<br/>
(10:13:24 AM) James[Code_SB]: Nice<br/>
(10:13:32 AM) [Arch_SB]thpr: I also found some data bugs while developing, and opened some work for the data team<br/>
(10:14:00 AM) [Arch_SB]thpr: I think Drew may have addressed some of them already<br/>
(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<br/>
(10:14:59 AM) [Arch_SB]thpr: not much more work on the facet side since last time, so nothing to report there<br/>
(10:15:06 AM) [Arch_SB]thpr: that's it from me<br/>
(10:15:37 AM) cpmeister [/n=cpmeiste@s100-254.resnet.ucla.edu/] entered the room.<br/>
(10:15:44 AM) James[Code_SB]: Hi Connor<br/>
(10:15:50 AM) cpmeister: hi all!<br/>
(10:15:52 AM) [Arch_SB]thpr: Hey Connor<br/>
(10:16:48 AM) James[Code_SB]: Mark did you want to go next<br/>
(10:16:54 AM) MotorViper: OK<br/>
(10:17:04 AM) James[Code_SB]: Connor we are going through current status<br/>
(10:17:18 AM) cpmeister: ah, ok<br/>
(10:17:39 AM) MotorViper: I've finished the first pass of the change in error reporting. Still more to do however.<br/>
(10:17:59 AM) MotorViper: I've also started to write the lst editor.<br/>
(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.<br/>
(10:19:19 AM) MotorViper: For instance I see ConcretePreReqObject but not Feats!<br/>
(10:19:48 AM) [Arch_SB]thpr: Let me pull together a description for you of how to get the token list<br/>
(10:19:57 AM) James[Code_SB]: Shall we hit that one at the end?<br/>
(10:20:12 AM) MotorViper: That's ok with me.<br/>
(10:20:12 AM) [Arch_SB]thpr: yea, we can come back to taht<br/>
(10:20:16 AM) James[Code_SB]: Cool<br/>
(10:21:08 AM) James[Code_SB]: All done Mark?<br/>
(10:21:27 AM) MotorViper: That's all for now.<br/>
(10:21:55 AM) James[Code_SB]: Thanks! Connor, did you want to add a report?<br/>
(10:22:20 AM) cpmeister: not particularly, I just wanted to drop by :)<br/>
(10:22:26 AM) James[Code_SB]: :)<br/>
(10:22:58 AM) James[Code_SB]: Cool - I assume you have been busy with studies?<br/>
(10:23:32 AM) cpmeister: yeah, pretty much<br/>
(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.<br/>
(10:24:18 AM) James[Code_SB]: In fact, once your SPELLEVEL fix is in TOm I'll start work on the release<br/>
(10:25:11 AM) James[Code_SB]: Alright, moving on<br/>
(10:25:12 AM) James[Code_SB]: 2. New UI demo - path getting something out before Christmas<br/>
(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<br/>
(10:26:58 AM) James[Code_SB]: I think a few screen shots would be a good inital offering<br/>
(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<br/>
(10:27:45 AM) James[Code_SB]: Thoughts Connor?<br/>
(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<br/>
(10:28:59 AM) James[Code_SB]: Indeed<br/>
(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?<br/>
(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<br/>
(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<br/>
(10:31:56 AM) cpmeister: I'd need to check<br/>
(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?<br/>
(10:32:14 AM) cpmeister: sure, if you want<br/>
(10:33:22 AM) James[Code_SB]: So actions out of that:<br/>
(10:33:31 AM) James[Code_SB]: Connro and James to chat about presentation<br/>
(10:33:48 AM) James[Code_SB]: James to assemble some screenshots for community discussion<br/>
(10:35:00 AM) James[Code_SB]: -<br/>
(10:35:01 AM) James[Code_SB]: 3. Output sheets/output tokens<br/>
(10:35:02 AM) James[Code_SB]: -<br/>
(10:35:14 AM) James[Code_SB]: Tom, did you want to lead that one?<br/>
(10:35:19 AM) [Arch_SB]thpr: sure<br/>
(10:36:10 AM) [Arch_SB]thpr: So the goal is to look at how we restructure the output tokens<br/>
(10:36:22 AM) [Arch_SB]thpr: this is a code change, not a literal formatting change for the tokens<br/>
(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<br/>
(10:36:48 AM) [Arch_SB]thpr: the intent here is to redo the code underneath<br/>
(10:37:02 AM) [Arch_SB]thpr: this can accomplish a few things<br/>
(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<br/>
(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)<br/>
(10:38:12 AM) [Arch_SB]thpr: third, provide more modularity to the tokens to allow easier and more isolated changes<br/>
(10:38:26 AM) [Arch_SB]thpr: (this is similar to how we have separate LST tokens for subtokens of ADD, CHOOSE, etc.)<br/>
(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)<br/>
(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<br/>
(10:39:30 AM) [Arch_SB]thpr: we have a few duplicate output tokens<br/>
(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<br/>
(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)<br/>
(10:40:25 AM) [Arch_SB]thpr: so, with all of those expectations...<br/>
(10:40:57 AM) [Arch_SB]thpr: the idea that I have is to turn the tokens into a form of pipeline<br/>
(10:41:11 AM) [Arch_SB]thpr: so that each item does a set of processing and can pass to another item<br/>
(10:41:25 AM) [Arch_SB]thpr: TEMPLATE.X.NAME for example, is 3 items, TEMPLATE, X, and NAME<br/>
(10:41:40 AM) [Arch_SB]thpr: (the X presumably is from an IF statement that is iterating over a set of numbers)<br/>
(10:42:06 AM) [Admin]Drew is now known as Drew_afk<br/>
(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)<br/>
(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<br/>
(10:43:20 AM) [Arch_SB]thpr: this is possible with the same code<br/>
(10:43:31 AM) [Arch_SB]thpr: by making this separation for each item<br/>
(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:<br/>
(10:44:15 AM) [Arch_SB]thpr: Starting List (e.g. TEMPLATE) ... MUST appear as the first item in a token, returns a list<br/>
(10:44:21 AM) [Arch_SB]thpr: Starting Object (e.g. RACE) .... MUST appear as the first item in a token, returns an object<br/>
(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<br/>
(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<br/>
(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<br/>
(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.<br/>
(10:45:44 AM) [Arch_SB]thpr: with a few exceptions, that should provide a feature-complete set of tokens<br/>
(10:45:59 AM) [Arch_SB]thpr: The two main sets of exceptions are:<br/>
(10:46:08 AM) [Arch_SB]thpr: 1) Stateful tokens controlling whitespace behavior<br/>
(10:46:24 AM) [Arch_SB]thpr: 2) Some Game Mode information tokens, such as units (meters, feet)<br/>
(10:46:52 AM) [Arch_SB]thpr: those are both single item type things that don't need the pipeline complexity<br/>
(10:47:05 AM) [Arch_SB]thpr: any questions so far?<br/>
(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.<br/>
(10:48:41 AM) [Arch_SB]thpr: I think they need to share some of the characteristics<br/>
(10:48:50 AM) [Arch_SB]thpr: they shouldn't be in a big if statement still, for example<br/>
(10:49:25 AM) [Arch_SB]thpr: but as far as sharing the same interfaces<br/>
(which may return a String result), I have to think more about that.<br/>
(10:49:31 AM) [Arch_SB]thpr: They don't process information, they control state, so they are different<br/>
(10:50:18 AM) MotorViper: Not really they are just another type of output, the main difference is where they get their info from.<br/>
(10:50:37 AM) James[Code_SB]: Except some of them do control state<br/>
(10:50:54 AM) James[Code_SB]: The manual whitespace one for instance<br/>
(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)<br/>
(10:51:20 AM) [Arch_SB]thpr: But the whitespace controllers don't ever output anything, so I'm cautious to use that Interface<br/>
(10:51:36 AM) [Arch_SB]thpr: because it leads can lead to false conclusions about behavior<br/>
(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<br/>
(10:52:16 AM) MotorViper: Sorry got confused I assumed manual whitespace was inserting whitespace so I withdraw, at least partially, my comment.<br/>
(10:52:36 AM) James[Code_SB]: True<br/>
(10:52:47 AM) James[Code_SB]: I assume you have a plan in mind for characteristics which only apply to specific objects?<br/>
(10:53:08 AM) [Arch_SB]thpr: Yes, pretty much identical to how the LST tokens work<br/>
(10:53:25 AM) [Arch_SB]thpr: meaning it can be an OutputToken<Ability> and do things specifically for Ability objects<br/>
(10:53:40 AM) [Arch_SB]thpr: or OutputToken<CDOMObject> and apply to any type of CDOMObject (this is what NAME would actually be)<br/>
(10:54:14 AM) James[Code_SB]: Right<br/>
(10:54:17 AM) [Arch_SB]thpr: this minimizes duplication of the basic CDOMObject info (NAME, SOURCE, etc.)<br/>
(10:55:29 AM) [Arch_SB]thpr: so if I go back to the DEITY.DOMAINS.X.NAME example<br/>
(10:55:33 AM) [Arch_SB]thpr: we can walk through that a bit<br/>
(10:55:50 AM) [Arch_SB]thpr: DEITY is a Starting Object, since a PC can only have one Deity<br/>
(10:56:01 AM) [Arch_SB]thpr: so it returns a Deity<br/>
(10:56:23 AM) [Arch_SB]thpr: the next item (DOMAINS) is then evaluated in context to Deity<br/>
(10:56:42 AM) [Arch_SB]thpr: meaning the system looks for a Characteristic or Filter that is for a DEITY<br/>
(10:56:53 AM) [Arch_SB]thpr: If it was a Characteristic it would be an error (since it's followed by another item)<br/>
(10:57:22 AM) [Arch_SB]thpr: DOMAINS would be an Expander<Deity> (making up the interfaces here)<br/>
(10:57:32 AM) [Arch_SB]thpr: It would return a List<Domain><br/>
(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<br/>
(10:58:17 AM) [Arch_SB]thpr: 's Deity)<br/>
(10:58:36 AM) [Arch_SB]thpr: The next item is then tested in the context of List<Domain><br/>
(10:58:49 AM) [Arch_SB]thpr: X (representing a number) is a Reducer, which can work on a list<br/>
(10:59:13 AM) [Arch_SB]thpr: (note that this could also be one or more filters followed by a reducer)<br/>
(10:59:25 AM) [Arch_SB]thpr: the result of the reduction is a single Domain<br/>
(10:59:43 AM) [Arch_SB]thpr: then NAME is tested in the context of Domain, and it's a Characteristic<CDOMObject><br/>
(11:00:04 AM) [Arch_SB]thpr: since Domain extends CDOMObject, it can be used, so the NAME of the Domain is output<br/>
(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"<br/>
(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<br/>
(11:01:08 AM) [Arch_SB]thpr: just as is done with LST tokens today<br/>
(11:01:32 AM) James[Code_SB]: Sounds good<br/>
(11:01:56 AM) [Arch_SB]thpr: that's pretty much it<br/>
(11:02:10 AM) [Arch_SB]thpr: I have some specific examples of the interfaces in the note I shipped out<br/>
(11:02:29 AM) [Arch_SB]thpr: and we'll need to polish that so there aren't code cycles<br/>
(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<br/>
(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)<br/>
(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?<br/>
(11:05:14 AM) [Arch_SB]thpr: I'll check on that; we can move on<br/>
(11:05:21 AM) [Arch_SB]thpr: I think it's a good idea though<br/>
(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<br/>
(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<br/>
(11:06:46 AM) TirGwaith: I'm not sure if they just loop through the objects and print names or not<br/>
(11:07:02 AM) [Arch_SB]thpr: there are some cases, e.g. languages, where it seems that would be useful<br/>
(11:07:13 AM) TirGwaith: proficiencies<br/>
(11:07:14 AM) [Arch_SB]thpr: at least without looking at the OS :)<br/>
(11:07:18 AM) [Arch_SB]thpr: another one, yes<br/>
(11:08:13 AM) [Arch_SB]thpr: any other thoughts or ideas?<br/>
(11:09:19 AM) [Arch_SB]thpr: back to you I think, James<br/>
(11:10:24 AM) James[Code_SB]: That seemed like a pretty thorough study Tom - thanks<br/>
(11:10:42 AM) James[Code_SB]: 4. Other business<br/>
(11:11:03 AM) James[Code_SB]: I think the first thing to discuss was getting the list of tokens automatically for the editor<br/>
(11:11:19 AM) [Arch_SB]thpr: eek<br/>
(11:11:21 AM) [Arch_SB]thpr: not ready yet<br/>
(11:11:25 AM) [Arch_SB]thpr: machine has been lagging with a build<br/>
(11:11:34 AM) James[Code_SB]: ok, we can do that on the list easily enough<br/>
(11:11:39 AM) James[Code_SB]: That work for you Mark?<br/>
(11:11:51 AM) [Arch_SB]thpr: give me 2 min<br/>
(11:11:54 AM) James[Code_SB]: ok<br/>
(11:12:09 AM) James[Code_SB]: Anyone have anything else they wanted to discuss?<br/>
(11:12:10 AM) MotorViper: Any time, as long as I'm still awake!<br/>
(11:12:15 AM) James[Code_SB]: :)<br/>
(11:15:59 AM) [Arch_SB]thpr: ok<br/>
(11:16:13 AM) [Arch_SB]thpr: Sorry about the lag guys, having some issues here<br/>
(11:16:15 AM) [Arch_SB]thpr: TokenFamilyIterator<T> it = new TokenFamilyIterator<T>(cl);<br/>
(11:16:15 AM) [Arch_SB]thpr: while (it.hasNext())<br/>
(11:16:15 AM) [Arch_SB]thpr: {<br/>
(11:16:15 AM) [Arch_SB]thpr: CDOMPrimaryToken<? super T> token = it.next();<br/>
(11:16:15 AM) [Arch_SB]thpr: }<br/>
(11:16:37 AM) [Arch_SB]thpr: give the class you want to deal with (e.g. Race.class) to TokenFamilyIterator<br/>
(11:16:46 AM) [Arch_SB]thpr: it will return to you the possible tokens you can use<br/>
(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)<br/>
(11:17:25 AM) [Arch_SB]thpr: You can see it actually used in public <T> Collection<String> unparse(LoadContext context, T cdo)<br/>
(11:17:35 AM) [Arch_SB]thpr: within pcgen.rules.persistence.TokenSupport.java<br/>
(11:17:43 AM) [Arch_SB]thpr: as part of supporting unparsing of data<br/>
(11:17:56 AM) [Arch_SB]thpr: which has to do an exhaustive iteration over all the tokens<br/>
(11:18:16 AM) [Arch_SB]thpr: is that what you're looking for Mark?<br/>
(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.<br/>
(11:19:11 AM) [Arch_SB]thpr: ok, need to be specific here<br/>
(11:19:22 AM) [Arch_SB]thpr: Race, has a token called Hands<br/>
(11:19:28 AM) [Arch_SB]thpr: there is a global token called Spells<br/>
(11:19:32 AM) [Arch_SB]thpr: when you ask for Race tokens<br/>
(11:19:39 AM) [Arch_SB]thpr: do you want only Hands, or both Hands and Spells?<br/>
(11:20:42 AM) [Arch_SB]thpr: or am I not following what you're asking for?<br/>
(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.<br/>
(11:22:15 AM) [Arch_SB]thpr: so just pass in CDOMObject.class into TokenFamilyIterator<br/>
(11:22:45 AM) [Arch_SB]thpr: or maybe I should ask where it's hardcoded<br/>
(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?<br/>
(11:22:54 AM) [Arch_SB]thpr: absolutely<br/>
(11:23:22 AM) [Arch_SB]thpr: sounds to me like were into detail beyond what we need to call the formal meeting though<br/>
(11:23:43 AM) MotorViper: I agree this is probably outside the meeting.<br/>
(11:23:48 AM) James[Code_SB]: One last thing I wanted to chat quickly about<br/>
(11:24:10 AM) James[Code_SB]: I while ago I added Spring support into a sample of the facets<br/>
(11:24:43 AM) James[Code_SB]: Just wondering if anyone had any views on it - for or against<br/>
(11:25:36 AM) cpmeister: none from me<br/>
(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<br/>
(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<br/>
(11:27:02 AM) James[Code_SB]: ok, anything else to discuss?<br/>
(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<br/>
(11:29:05 AM) James[Code_SB]: I can give you a hand with that<br/>
(11:29:35 AM) James[Code_SB]: coce/testsuite/output/Elwood.xml<br/>
(11:30:01 AM) James[Code_SB]: and it is compared to code/testsuite/csheets/Elwood.xml<br/>
(11:32:29 AM) TirGwaith: ok, different than I was expecting. Ok, something about Uncanny dodge, and some DESCs.<br/>
(11:32:42 AM) James[Code_SB]: Happy to chat about those<br/>
(11:32:43 AM) TirGwaith: I think it is a data change, but those would have to be from<br/>
(11:32:49 AM) TirGwaith: Eddy's converter run<br/>
(11:32:50 AM) James[Code_SB]: Sounds like that's all for now<br/>
(11:32:57 AM) James[Code_SB]: Thanks for coming along everyone <br/>