Dev Meeting Log 20090911

Summary

• LST editors will work in the LST format using the LST tokens for parsing and validation.
• The tokens driving the LST editors will be separate from the LST token classes so as to keep the UI code out of the main unit tests. This allows the unit tests to still be run on a system with no screen (aka headless).
• The current LST token validation will need to be enhanced to provide the position of any flagged error. This will be used by the LST editor
• We will go ahead with introducing Spring to manage dependency injection and use it for facets and LST editor tokens initially.
• We need to define a test plan for Jira to allow proper evaluation (on the webteam list)

Actions

• James - Add Spring DI to trunk
• Tom and Andrew - talk about function parsing offline
• James - provide Connor with an example of Summary tab config
• James - prepare Equipment Facades for CDOM UI

Transcript

(8:03:30 AM) James[Code_SB]: OK, so lets gets started
(8:03:38 AM) James[Code_SB]: Welcome everyone to the developers meeting
(8:03:46 AM) James[Code_SB]: The agenda items raised were:
(8:03:46 AM) *[Chair]Eddy
[/n=[Chair]E@c-68-53-197-8.hsd1.tn.comcast.net/] entered the room.*
(8:04:06 AM) James[Code_SB]: 1) The LST Editor reimplementation
(8:04:30 AM) James[Code_SB]: 2) The Dependency Injection framework proposal for PCGen
(8:05:14 AM) cpmeister: may I add a few?
(8:05:28 AM) James[Code_SB]: Tom has raised both of these items. Did Tom or Connor want to kick off the LST Editor discussion? Maybe some background on what is planned and the issues being faced would be a good start?
(8:05:33 AM) James[Code_SB]: Sure Connor
(8:06:03 AM) cpmeister: they are less important things so I can understand them not getting covered
(8:07:29 AM) cpmeister: 1) UI Filters reimplementation
(8:07:30 AM) cpmeister: 2) Generators reimplentation (entirely optional)
(8:07:59 AM) cpmeister: 3) UI discussion for Spells Tab
(8:08:34 AM) cpmeister: I could list more, but I think those are enough for now
(8:08:56 AM) cpmeister: unless we wanted to add the Summary tab UI discussion in as well :)
(8:09:07 AM) cpmeister: but I'm not sure how much time everyone actually has
(8:09:33 AM) James[Code_SB]: I think a status update on the UI demo might be worthwhile too
(8:09:46 AM) cpmeister: although, the Filters reimplementation is sorta a biggie for me
(8:10:00 AM) James[Code_SB]: Lets add that after the DI and then go on to the filters and see how much time we have
(8:10:07 AM) James[Code_SB]: Sound ok?
(8:10:16 AM) cpmeister: sounds fine :)
(8:10:31 AM) [Arch_SB]thpr: I might suggest that after DI we run around and have a "hit list" of what is holding people up
(8:10:46 AM) [Arch_SB]thpr: Connors is filters and I'm okay with further discussion on that
(8:10:55 AM) James[Code_SB]: ok, so the LST editor - Tom/Connor?
(8:11:00 AM) [Arch_SB]thpr: but it might be helpful for people to understand why i'm harping on Kar about OS tokens :)
(8:11:11 AM) James[Code_SB]: Yep
(8:11:17 AM) [Arch_SB]thpr: ok, LST Editor
(8:11:25 AM) [Arch_SB]thpr: let me take a shot at this first
(8:11:38 AM) [Arch_SB]thpr: Thread on _developers is here: http://tech.groups.yahoo.com/group/pcgen_developers/message/153
(8:11:54 AM) [Arch_SB]thpr: Basic idea is that we have tokens today that do LST parsing
(8:12:13 AM) [Arch_SB]thpr: we then want an independent set of tokens capable of editing values in those tokens
(8:13:11 AM) [Arch_SB]thpr: So one issue is lining up how the editor token knows the LST token it is associated with
(8:13:17 AM) James[Code_SB]: independant set of UI elements presumably?
(8:13:32 AM) [Arch_SB]thpr: the editor tokens would include the UI elements
(8:14:01 AM) [Arch_SB]thpr: one way of doing that association is to match the class (e.g. Equipment) and the token name (e.g. CONTAINS)
(8:14:26 AM) [Arch_SB]thpr: but we've realized this is inefficient since we have many tokens that share behavior (HANDS, LEGS, and many others are just simple integers)
(8:14:40 AM) [Arch_SB]thpr: So if we go down the DI path, we can find another way to associate them
(8:14:47 AM) [Arch_SB]thpr: (meaning define that in XML)
(8:14:53 AM) [Arch_SB]thpr: I'll hold off more detail on that
(8:15:08 AM) [Arch_SB]thpr: because it's another sticking point that I think we want to get to on the LST editor sid
(8:15:18 AM) cpmeister: should the DI discussion go first?
(8:15:21 AM) [Arch_SB]thpr: and that is where the LST editor token has a tight association
(8:15:47 AM) [Arch_SB]thpr: let's handle the tight association first
(8:15:56 AM) cpmeister: very well
(8:16:00 AM) [Arch_SB]thpr: Let's use hands as an example.
(8:16:12 AM) [Arch_SB]thpr: Can be 0 to, well, MAX_INTEGER I guess
(8:16:28 AM) [Arch_SB]thpr: but the question is how this is loaded into the "Rules Data Store"
(8:16:40 AM) [Arch_SB]thpr: which is our internal data format
(8:16:45 AM) [Arch_SB]thpr: that we can write out to LST files
(8:16:47 AM) [Arch_SB]thpr: or use to build a PC
(8:17:06 AM) [Arch_SB]thpr: One method is to have the editor tokens be aware of that data structure
(8:17:25 AM) [Arch_SB]thpr: e.g. it would directly load "2" by template.put(IntegerKey.HANDS, 2);
(8:17:36 AM) [Arch_SB]thpr: that would then be unparsed into HANDS:2 in an LST file
(8:17:47 AM) [Arch_SB]thpr: this creates a tight association between the editor token
(8:17:51 AM) [Arch_SB]thpr: and the internal format in memory
(8:18:07 AM) [Arch_SB]thpr: it leaves the association to the actual format in the LST file loose
(8:18:31 AM) [Arch_SB]thpr: (meaning we could store it in the LST as "HANDS:Two" and the Editor token wouldn't change
(8:18:42 AM) [Arch_SB]thpr: option #2
(8:18:59 AM) [Arch_SB]thpr: is to have the EditorToken closely associated with the LSTToken (HandsToken)
(8:19:11 AM) [Arch_SB]thpr: but loosely associated (only associated through HandsToken) with the internal data format
(8:19:24 AM) [Arch_SB]thpr: meaning the Editor Token would produce "HANDS:2" and tell the system to parse that token
(8:19:36 AM) [Arch_SB]thpr: HandsToken then knows to load 2 into IntegerKey.HANDS
(8:20:09 AM) [Arch_SB]thpr: meaning, we could store this in the rules data store into a Double (ObjectKey.HANDS)
(8:20:15 AM) [Arch_SB]thpr: and the EditorToken would not need to change
(8:20:26 AM) [Arch_SB]thpr: there are tradeoffs either way
(8:20:37 AM) [Arch_SB]thpr: Option #1 Tight Association with Memory Format
(8:20:54 AM) [Arch_SB]thpr: + that it is separated from LST and if we change LST then we don't have to change the EditorToken
(8:21:25 AM) [Arch_SB]thpr: - that it has to be aware of legal values in pretty specific detail. Meaning, it has to know it can't load -2 into IntegerKey.HANDS
(8:21:44 AM) [Arch_SB]thpr: (or alternately, the unparse method of HandsToken needs to detect and warn on this situation and not write that bad value to the file)
(8:21:59 AM) [Arch_SB]thpr: Option #2 Tight Association with LST format
(8:22:31 AM) [Arch_SB]thpr: + That all error checking can be done by the LSTToken (since they are very strict [give or take CHOOSE and BONUS])
(8:23:00 AM) [Arch_SB]thpr: - That the editor token is tightly bound to our persistent format, meaning we can't change from LST to another format without altering the EditorTokens as well.
(8:23:42 AM) [Arch_SB]thpr: Note that Option #2 doesn't relieve the EditorToken from having some form of error checking for complex tokens, since the true/false return from the LSTToken is unlikely to be sufficient to appropriately highlight the problem area to a user
(8:23:54 AM) [Arch_SB]thpr: We would want to have some good detail (for the complex tokens) to indicate what broke
(8:24:02 AM) [Arch_SB]thpr: (or what is invalid, I should say)
(8:24:13 AM) [Arch_SB]thpr: everyone clear on those options?
(8:24:17 AM) [code]nuance: yeah
(8:24:46 AM) cpmeister: I think this also expands to a reimplementation of the error reporting system
(8:24:57 AM) [Arch_SB]thpr: how so?
(8:26:04 AM) cpmeister: how would the token notify the the editor system about exactly what part of the unparsing is incorrect?
(8:26:32 AM) [Arch_SB]thpr: I'm not sure either option is all that good for that checking
(8:26:44 AM) [Arch_SB]thpr: for the complex tokens, I think the EditorToken is going to have to do some validation work
(8:27:32 AM) cpmeister: but that would imply that the editor token would have intricite knowledge about what is a valid value for a token
(8:28:08 AM) [Arch_SB]thpr: In some cases you definitely want it to
(8:28:17 AM) [Arch_SB]thpr: Hands for example, I would present as an Integer spinner
(8:28:25 AM) [Arch_SB]thpr: I dont' want to be able to set it to anything below 0
(8:28:40 AM) [Arch_SB]thpr: so we need to tell that system that negatives are invalid
(8:28:44 AM) James[Code_SB]: A starting point would be to have the errors generated by the LSTToken displayed to the user, along with the error marker driven by the true/false response from the parse
(8:28:52 AM) [Arch_SB]thpr: James: yes
(8:28:56 AM) [code]nuance: how is the validation currently done? is it against the original text rather than the final value?
(8:28:57 AM) [Arch_SB]thpr: this can either be done by hardcoding that knowledge in the editor token
(8:29:08 AM) [Arch_SB]thpr: or by having that knowledge injected by DI
(8:29:14 AM) James[Code_SB]: I think you can do this today without too much work as the LST errors are on a different stream
(8:29:37 AM) [Arch_SB]thpr: validation is currently done based on what is in the text file when reading LST files
(8:29:43 AM) [Arch_SB]thpr: in the Editor system today, I'm not sure much is error checked, to be honest
(8:29:43 AM) [code]nuance: that seems to favour option 2
(8:29:45 AM) cpmeister: true, but in the case for choose tokens, their format is highly variable, not only that, but their lst format is constantly changing (unless I've ill informed)
(8:29:48 AM) [Arch_SB]thpr: and what is seems hardcoded
(8:30:21 AM) James[Code_SB]: For a few reasons I am strongly in favour of option 2.
(8:30:35 AM) [Arch_SB]thpr: CHOOSE is also beneficial in that the new CHOOSE tokens, which is where we will be, have validation already
(8:30:47 AM) [Arch_SB]thpr: meaning you can do: choiceSet.getGroupingState.isValid()
(8:30:59 AM) [Arch_SB]thpr: give or take some parens missing on my getGroupingState call
(8:31:32 AM) [Arch_SB]thpr: I have to admit, I've been going down the path of #1
(8:31:36 AM) [Arch_SB]thpr: and writing checks into the unparse methods
(8:31:42 AM) [Arch_SB]thpr: which is easy for the easier tokens
(8:31:49 AM) [Arch_SB]thpr: but gets to be a REAL bear for the complex ones
(8:31:59 AM) [Arch_SB]thpr: so I am growing less and less fond of option #1
(8:32:33 AM) [Arch_SB]thpr: since it seems to be a lot of work with not much gain (since the Editor Token needs to do much of the same validation anyway)
(8:32:49 AM) James[Code_SB]: 1. I don't think we are close to changing LST format. Driving the decision on something that may or may not ever happen seems wasteful to me.
(8:32:56 AM) James[Code_SB]: 2. The LST editors are a bridge to manual LST editing. We'd like them to be able to be used by the LST monkeys for small tasks also.
(8:33:01 AM) [code]nuance: CAn we extract that and do one validation object
(8:33:09 AM) [code]nuance: that would be used by everything that needs it
(8:33:10 AM) James[Code_SB]: That means that the format shouldn;t be something new as that will cause even more confusion
(8:33:21 AM) [code]nuance: LST, editior, unparser, whatever
(8:33:57 AM) James[Code_SB]: 3. We have a good validation system already
(the LST tokens) we should be using that where possible, even if it isn't the first layer of validation
(8:35:22 AM) [Arch_SB]thpr: Andrew: I'd have to think about it
(8:35:24 AM) James[Code_SB]: @nuance - I think that still puts us on the option 2 path - as the validator is simplest when it is only handling one format
(8:35:46 AM) *Papa-DRB [/n=Papa-DRB@205.231.151.244/] entered the room.*
(8:35:57 AM) [Arch_SB]thpr: it may be as simple as having the LSTToken return the character at which the error occurred
(8:36:12 AM) [Arch_SB]thpr: presumably the Editortoken would know the text string it built (thinking option #2 method here)
(8:36:21 AM) [Arch_SB]thpr: and know the source of that character
(8:37:11 AM) James[Code_SB]: Yes that seems ideal
(8:37:16 AM) cpmeister: that would work
(8:39:04 AM) [code]nuance: The thing that bothers me about that is, it makes it easy to forget to update the editor when you change something
(8:39:31 AM) [code]nuance: Then we end up with a similar situation where we have constant complaints about broken editors :-(
(8:39:55 AM) James[Code_SB]: Is that in terms of new tags or changes to tags?
(8:39:55 AM) [Arch_SB]thpr: My thought there is to make the EditorToken the same class as the LSTToken
(8:40:01 AM) [Arch_SB]thpr: two separate interfaces, so they are independent
(8:40:17 AM) [Arch_SB]thpr: but one place so people think about changing both at the same time
(8:40:25 AM) [Arch_SB]thpr: I'm referring to changing tags
(8:40:33 AM) [code]nuance: yeah me too
(8:40:40 AM) James[Code_SB]: ok
(8:40:41 AM) [Arch_SB]thpr: new tags are handled by the "can detect a tag and just put up a boring text field for validation"
(8:40:57 AM) [Arch_SB]thpr: it's at least better than nothing
(8:41:04 AM) James[Code_SB]: Yes having that basic level of support is essential
(8:41:31 AM) James[Code_SB]: and the tag list should be able to be automatically generated given we have internal lists of tokens vs LST object types
(8:41:43 AM) cpmeister: so should the generic editors be stored in the pcgen packages, not the plugins?
(8:41:56 AM) James[Code_SB]: Yes that would make sense
(8:42:05 AM) James[Code_SB]: and specific ones are then plugins
(8:42:37 AM) [Arch_SB]thpr: yes
(8:43:10 AM) [Arch_SB]thpr: Anyone have thoughts on making the EditorToken and LSTToken the same class to force people thinking about changes
(8:43:35 AM) Karianna: Sorry all, have to drop out now, can someone post the log please?
(8:43:38 AM) [Arch_SB]thpr: or make the EditorToken a static class within the same Java file
(8:43:51 AM) [code]nuance: doesn't that mean simple tokens get horribly duplicated?
(8:43:55 AM) James[Code_SB]: Yep I'll do that Kar
(8:44:01 AM) cpmeister: I rather like that idea Tom
(8:44:42 AM) cpmeister: but I'm surprised you brought it up since I thought you vehemently opposed it :)
(8:44:53 AM) [code]nuance: or does the fact that they all need different validation mitigate taht , they are different
(8:45:17 AM) James[Code_SB]: The concern I have is that running tests of the LST tokens on a headless machine would be problematic as you would have swing classes included
(8:45:55 AM) [Arch_SB]thpr: ah, yea
(8:46:01 AM) *Karianna left the room (quit: "Colloquy for iPhone - http://colloquy.mobi"). <http://colloquy.mobi>*
(8:46:05 AM) [Arch_SB]thpr: you've mentioned that before James, I forgot
(8:46:14 AM) cpmeister: does running headless mean that javax.swing isn't loaded in the virtual machine upon startup?
(8:46:18 AM) [Arch_SB]thpr: the simple tokens will depend on DI
(8:46:36 AM) [Arch_SB]thpr: so we'll have to come back to that Andrew
(8:46:49 AM) [code]nuance: fair enough
(8:46:56 AM) James[Code_SB]: yes pretty much Connor - any attempt to instantiate a swing or ui class will result in a Headless exception
(8:47:09 AM) [code]nuance: I'm kinda reading that doc in the background
(8:47:30 AM) James[Code_SB]: I'm currently experimenting with building on our VPS and had to do some workarounds for that
(8:47:39 AM) cpmeister: so...isn't it simple enough to just have the tests not try to istantiate swing? :)
(8:48:11 AM) James[Code_SB]: Well they must instantiate the LSTtokens and if they include JTextField then you have an issue
(8:48:27 AM) cpmeister: as long as the editor tokens have lazy initialization for its UI components there shouldn't be a problem
(8:50:23 AM) [Arch_SB]thpr: I'm not sure that's how class loaders work
(8:50:42 AM) [Arch_SB]thpr: I think if you import the class it gets loaded
(8:50:45 AM) James[Code_SB]: It also relies on each developer to do the right thing
(8:50:50 AM) cpmeister: well, when I ran tests on the new plugin loader system, they seemed to work like that
(8:51:16 AM) cpmeister: an exception would only be thrown when the code encountered a class that didn't exist in the ClassLoader
(8:51:34 AM) [Arch_SB]thpr: Another way to address this is externally to the code
(8:51:43 AM) [Arch_SB]thpr: meaning we now have JIRA on the VPS
(8:52:01 AM) [Arch_SB]thpr: and with JIRA we can create a set of trackers that when they are closed trigger other behaviors
(8:52:12 AM) [Arch_SB]thpr: so we could automatically trigger Doc FREQs, etc.
(8:52:18 AM) [Arch_SB]thpr: so it can ask if the editor work has been done
(8:52:19 AM) James[Code_SB]: yes true
(8:52:23 AM) [Arch_SB]thpr: and if not open a tracker for it
(8:52:34 AM) [Arch_SB]thpr: we'd have to write that path, but it's possible to do
(8:53:02 AM) James[Code_SB]: I haven't done that level of automation ion Jira before - is that something you have seen work Tom?
(8:53:16 AM) [Arch_SB]thpr: I was playing with it when I originally evaluated JIRA
(8:53:34 AM) [Arch_SB]thpr: I did build my own pathways (build a voting method for token changes), so I know how to do it
(8:53:47 AM) James[Code_SB]: cool
(8:54:41 AM) James[Code_SB]: Closing in on the hour - I think we might need to bring the editor discussion to a conclusion
(8:55:25 AM) [Arch_SB]thpr: I think we all recognize the editor vs LST token needs some smoothing to make sure they stay in sync
(8:55:30 AM) [Arch_SB]thpr: I think we're on option #2
(8:55:47 AM) [Arch_SB]thpr: and enhance the error messages in parse to return a character # of where the error occurred
(8:56:14 AM) James[Code_SB]: Agreed
(8:56:14 AM) [code]nuance: seems like the path of least resistance
(8:56:15 AM) cpmeister: did we come to an agreement on wether editor tokens are in the same class as the tokens?
(8:56:21 AM) [Arch_SB]thpr: different class
(8:56:30 AM) cpmeister: ah, very well then
(8:56:34 AM) [Arch_SB]thpr: I think is the best option to avoid headless issues
(8:56:52 AM) [Arch_SB]thpr: also allows us to control size if we only build a viewer someday
(8:57:59 AM) cpmeister: so, moving on then?
(8:58:03 AM) James[Code_SB]: Yep
(8:58:19 AM) James[Code_SB]: #2 was the Dependency Injection framework
(8:58:49 AM) [Arch_SB]thpr: you or me leading this James?
(8:58:52 AM) James[Code_SB]: We covered this a bit last meeting and I posted a background article on it to the dev list
(8:59:00 AM) James[Code_SB]: You can lead Tom
(8:59:34 AM) [Arch_SB]thpr: ok, but if people have questions about DI, James is the expert :)
(8:59:47 AM) James[Code_SB]: :)
(9:01:05 AM) [Arch_SB]thpr: At a high level, a DI system manages classes to ensure associations (listeners, etc.) are set up when a class is taken from the DI container
(9:01:27 AM) [Arch_SB]thpr: There are two obvious cases where this gets useful in PCGen
(9:01:36 AM) [Arch_SB]thpr: The first is in the facet system
(9:02:00 AM) [Arch_SB]thpr: If you go do code/src/java/pcgen/cdom/facet/
(9:02:07 AM) [Arch_SB]thpr: there is a class FacetInitialization
(9:02:27 AM) [Arch_SB]thpr: effectively those adds would be externalized to XML
(9:02:58 AM) [Arch_SB]thpr: so that the associations are a bit easier to keep track of
(9:03:23 AM) [Arch_SB]thpr: it also has the advantage that it would set the valies that I'm currently storing as fixed references to FacetLibrary within each of the Facets
(9:03:36 AM) [Arch_SB]thpr: HandsFacet for example has
(9:03:37 AM) [Arch_SB]thpr: private TemplateFacet templateFacet = FacetLibrary
(9:03:38 AM) [Arch_SB]thpr: .getFacet(TemplateFacet.class);
(9:03:38 AM) [Arch_SB]thpr: private RaceFacet raceFacet = FacetLibrary.getFacet(RaceFacet.class);
(9:03:57 AM) [Arch_SB]thpr: sets for those two fields would both go into the XML
(9:04:15 AM) [Arch_SB]thpr: this has the advantage of allowing circular references to exist between the facets without being a critical problem
(9:04:21 AM) [Arch_SB]thpr: (would drive an initialization error today)
(9:04:42 AM) James[Code_SB]: Yep the handling of secondary dependencies is where DI gets compelling.
(9:04:58 AM) James[Code_SB]: I think you'll find that DI would reject a circular dependancy
(9:05:06 AM) [Arch_SB]thpr: really
(9:05:15 AM) James[Code_SB]: as it couldn't create a correct initialisation order for it.
(9:05:22 AM) [Arch_SB]thpr: ugh
(9:05:31 AM) [Arch_SB]thpr: that leaves us in a bit of a bind
(9:05:41 AM) James[Code_SB]: Well circular dependencies are bad
(9:05:53 AM) [Arch_SB]thpr: yes
(9:05:55 AM) [Arch_SB]thpr: but...
(9:05:57 AM) [code]nuance: where is the circularness?
(9:06:14 AM) James[Code_SB]: The solution might be to do some specialised late binding of those to close thr loop
(9:06:15 AM) [Arch_SB]thpr: TemplateFoo FEAT:FeatFoo
(9:06:21 AM) [Arch_SB]thpr: FeatFoo TEMPLATE:TemplateBar
(9:06:28 AM) [code]nuance: :-(
(9:07:00 AM) [Arch_SB]thpr: Somewhere in that construction the Template and Ability Facets will end up with some form of "I need to tell you to add something"
(9:07:24 AM) [Arch_SB]thpr: okay, let's put that aside for a moment
(9:07:34 AM) [Arch_SB]thpr: example #2 is in the LST Editor system
(9:07:49 AM) [Arch_SB]thpr: Again, HANDS, LEGS, etc. are Integer based tokens
(9:08:03 AM) [Arch_SB]thpr: instead of writing the EditorToken a bazillion times for the dozens of integer tokens we have
(9:08:44 AM) [Arch_SB]thpr: it would be best to have a single EditorToken class where different instances can be initialized with the token name (e.g. HANDS) and the limits (lower bound = 0, upper bound = Integer.MAX_VALUE)
(9:08:54 AM) [Arch_SB]thpr: that initialization can be done in the XML
(9:09:11 AM) [Arch_SB]thpr: would radically reduce the # of Editor Token classes we need
(9:10:31 AM) [Arch_SB]thpr: everyone follow that?
(9:10:38 AM) [code]nuance: yep
(9:10:44 AM) cpmeister: yea
(9:10:55 AM) James[Code_SB]: yep
(9:11:10 AM) [Arch_SB]thpr: anyone have strong opinions either way?
(9:11:34 AM) [code]nuance: no
(9:11:36 AM) TirGwaith: yes
(9:11:50 AM) cpmeister: where would the xml code be put?
(9:11:51 AM) TirGwaith: time lag. no to the last q
(9:12:25 AM) [Arch_SB]thpr: I would put it in the JAR with the LSTToken
(9:13:07 AM) cpmeister: what about the facet xml code?
(9:13:56 AM) [Arch_SB]thpr: no particular preference from me on location of that right now
(9:14:03 AM) [Arch_SB]thpr: since all the facets are in the core today
(9:14:44 AM) cpmeister: k then
(9:14:44 AM) James[Code_SB]: IN a 'normal' project you would have one or more xml files in the root of the JavaSource tree which define the rules for the dependency injection engine. We can provide more control over that if we want and in the case of plugins I think this would be pretty much essesntial
(9:15:28 AM) [Arch_SB]thpr: I've already demonstrated "partial" loading using many XML files (only about 15-20 lines of code), so it's not a big deal to have many XML files
(9:15:57 AM) *Maredudd
[/n=Maredudd@adsl-074-229-198-246.sip.mco.bellsouth.net/] entered the room.*
(9:16:17 AM) cpmeister: k, I was just curious
(9:18:06 AM) [Arch_SB]thpr: I would prefer to have a DI engine around, since I think it helps reduce duplication
(9:18:10 AM) [Arch_SB]thpr: and there are other areas we can use it
(9:18:26 AM) [Arch_SB]thpr: So I would recommend that path unless there are objections
(9:18:37 AM) [Arch_SB]thpr: I guess we should mention it would increase our distribution size a bit
(9:18:53 AM) cpmeister: would it run faster?
(9:19:18 AM) [Arch_SB]thpr: Other than reducing memory use by consolidating a code base into less classes, I don't think so
(9:19:52 AM) [code]nuance: how much is a bit?
(9:20:11 AM) [Arch_SB]thpr: James, do you know (I'm trying to find it on my system)
(9:20:14 AM) [code]nuance: 5-10% is probably neither here not there
(9:21:28 AM) cpmeister: if you are worried about distribution size, when the new UI is finished, it would reduce the size of the pcgen.jar by 25% or more
(9:21:51 AM) James[Code_SB]: Sorry I'll just grab it
(9:22:40 AM) James[Code_SB]: Spring is 2.8Mb- there might be a smaller jar we can use if we are focused on their DI only though
(9:25:19 AM) James[Code_SB]: I'm happy to investigate that and report back to the dev list
(9:26:13 AM) James[Code_SB]: ah ok. I think we would be looking at 2 jars totalling @500Kb
(9:26:33 AM) cpmeister: thats not much at all
(9:26:39 AM) James[Code_SB]: no
(9:27:09 AM) [code]nuance: even 2.8Mb is only about 10% of our current download
(9:27:25 AM) [Arch_SB]thpr: so no big deal then
(9:27:54 AM) James[Code_SB]: Nope
(9:28:04 AM) James[Code_SB]: So I'd say we should go for it
(9:28:37 AM) [Arch_SB]thpr: I agree (but I already said that :)
(9:28:39 AM) James[Code_SB]: BTW: Of the DI frameworks in the article I linked to, I preferred the Spring implementation. Any other views?
(9:28:42 AM) [code]nuance: it certainly seems like a good idea for the editors
(9:29:07 AM) [code]nuance: I don't know enough about any of the frameworks to have an opinion
(9:29:14 AM) cpmeister: same here
(9:29:30 AM) [code]nuance: if you're happy with spring, it works for me
(9:29:46 AM) [Arch_SB]thpr: I think we do Spring because you have experience with it James
(9:29:54 AM) [Arch_SB]thpr: makes more sense since none of the rest of us seem to have any
(9:30:49 AM) James[Code_SB]: I am biased as that is what I am familiar with, but it is also a very widely used library and thus new people will quiote possibly be familiar with it and having experience with it from PCGen could be useful to people's professional lives too
(9:31:14 AM) cpmeister: sounds good to me :)
(9:32:58 AM) James[Code_SB]: ok, I'll handle adding in the spring libraries to the code base then
(9:33:05 AM) James[Code_SB]: Should be able to do that today
(9:33:45 AM) [Arch_SB]thpr: ok
(9:33:59 AM) [Arch_SB]thpr: Do we want to do a quick run-around on what people are doing and what they are held up by?
(9:34:17 AM) James[Code_SB]: You beat me to it :)
(9:34:28 AM) James[Code_SB]: I'll start
(9:35:39 AM) James[Code_SB]: I'm currently pottering about on a few small things and helping out with the UI-CDOM interface. No holdups currently apart from getting time to work on PCGen
(9:36:02 AM) James[Code_SB]: next
(9:36:26 AM) [Arch_SB]thpr: I have a few projects in flight
(9:36:31 AM) [Arch_SB]thpr: I've been trying to eliminate cloning. PCClass and Abilities are the major remaining items
(9:36:55 AM) [Arch_SB]thpr: PCClass held up for two reasons, one is that PREVAR get modified internally based on the PCClass name
(9:37:18 AM) [Arch_SB]thpr: I can unwind that if I understand more about the Class prereq bypass preference, message on _exp as of today
(9:37:35 AM) [Arch_SB]thpr: Reason #2 is SubClasses and how they are processed (and keeping variable referencing correct)
(9:37:42 AM) [Arch_SB]thpr: that's tougher
(9:38:00 AM) [Arch_SB]thpr: Abilities have a number of issues, primarily related to the many different ways they are added to PlayerCharacter
(9:38:21 AM) [Arch_SB]thpr: working to unwind that, but actually gated by the fact that PRExxx for Abilities are treated as Requirements
(9:38:27 AM) [Arch_SB]thpr: meaning they are tested with every change to the PC
(9:38:36 AM) [Arch_SB]thpr: rather than only when the Ability is added to the PC
(9:38:53 AM) [Arch_SB]thpr: so I need to build a PRExxx monitoring system in order to unwind the active ability worker loop
(9:39:24 AM) [Arch_SB]thpr: Project #2 is the CHOOSE system, and Tir responded to the unparsing preferences, so hopefully we can drive that discussion to completion soon and get Eddy to converting the data
(9:39:35 AM) [Arch_SB]thpr: once the data is clean, I can continue with the CHOOSE rebuild
(9:40:17 AM) [Arch_SB]thpr: Project #3 is the facets. These are actually gated by the active ability worker method treating PRExxx as requirements as well
(9:40:33 AM) [Arch_SB]thpr: I have all non-Ability objects now in a Facet
(9:41:02 AM) James[Code_SB]: Tom will the choose rebuild break 5.16 era data or can that be brought up to speed by the LST converter?
(9:41:06 AM) [Arch_SB]thpr: so once I get Abilities, I can then start converting many of the behaviors (SR, other token reactions) to forward processing rather than pull and process on demand (w/o any cache)
(9:41:22 AM) [Arch_SB]thpr: I haven't made any changes that deprecate any existing CHOOSE tokens
(9:41:35 AM) [Arch_SB]thpr: I've been waiting for Eddy to finish the conversion first
(9:41:49 AM) [Arch_SB]thpr: once he finishes that, I will write the converter tokens for the existing CHOOSE tokens, and deprecate the old ones
(9:41:53 AM) [Arch_SB]thpr: So everything will cleanly convert
(9:41:56 AM) James[Code_SB]: ah ok
(9:41:59 AM) [Arch_SB]thpr: the only problem will be CHOOSE:SALIST
(9:42:06 AM) TirGwaith: Tom, even after the PRE/REQ thing, most abilities will still be attached to REQs, not PREs
(9:42:08 AM) [Arch_SB]thpr: because I can't find any examples that anyone claims works
(9:42:09 AM) ***James[Code_SB] afk for a short time
(9:42:46 AM) TirGwaith: so they will still be tested with every change to a PC
(9:42:50 AM) [Arch_SB]thpr: Tir: That's fine, it's just different than just about everything else in the way it's treated, so it's just different (and a bit trickier) logic
(9:42:59 AM) TirGwaith: ok
(9:43:20 AM) [Arch_SB]thpr: doesn't help that there are over 100 methods across AbilityUtilities and PlayerCharacter that are involved in Ability addition or query
(9:43:37 AM) [Arch_SB]thpr: there are so many permutations it's hard to make any changes without breaking one of them
(9:44:00 AM) TirGwaith: gotcha.
(9:44:23 AM) [Arch_SB]thpr: The other thing on Facets will be the "analysis" facets
(9:44:28 AM) [Arch_SB]thpr: which is where we start to get into the OS domain
(9:44:38 AM) [Arch_SB]thpr: since that analysis should be shared between OS and UI
(9:44:44 AM) [Arch_SB]thpr: so we dont' write the same code twice
(9:45:01 AM) [Arch_SB]thpr: So my question on that path is what the long-term structure of the OS tokens will be
(9:45:08 AM) [Arch_SB]thpr: Today we have things like DEITY.DOMAINS.0.NAME
(9:45:21 AM) [Arch_SB]thpr: which takes a single item, expands it to a list, selects from that list, and queries that object
(9:45:55 AM) [Arch_SB]thpr: the questions I have are (1) Will this "pipeline" structure still exist if we go to a templating engine, or do we need to have that discussion before work on analysis facets is done
(9:46:05 AM) [code]nuance: I'm thinking about how to recognise the end of a token in a formula and wondering if I'm going to have to reimplement the understanding of how output tokens fit togther into the formula parser. and hoping the answer is no.
(9:46:28 AM) [Arch_SB]thpr: (2) If the "pipeline" still exists, then what form of transformations take place
(9:46:51 AM) [Arch_SB]thpr: Andrew:
(9:46:53 AM) [Arch_SB]thpr: not sure
(9:46:58 AM) [code]nuance: if we're going to change the OS tokens we desperately need something that can parse the old and convert to the new
(9:47:06 AM) [Arch_SB]thpr: I think that heavily interacts with what a templating engine would do to OS
(9:47:15 AM) [Arch_SB]thpr: absolutely agree with you on that
(9:47:27 AM) [Arch_SB]thpr: that's why I didn't want Kar to remove the deprecated versions of the OS tokens
(9:47:30 AM) [code]nuance: today you can basically use any OS token in any formuila
(9:48:23 AM) [code]nuance: we hav an insane jumble of Jep, OS token and the "variables"
(9:48:26 AM) [Arch_SB]thpr: and there are 2 aspects to that use in a Formula: (1) We have to be able to convert it (as you said) and (2) We need to know what the future structure will look like if it's significantly different than today (for parsing reasons, as you also said)
(9:48:27 AM) TirGwaith: yeah, but I really wish you couldn't, since it sets up some really bad potential for infinite looping
(9:49:15 AM) [Arch_SB]thpr: I don't need OS to set up an infinite loop. We'll have to write a detector here at some point
(9:49:37 AM) [Arch_SB]thpr: shouldn't be hard once we have "forward looking" contents of CHOOSE, BONUS, and PRExxx
(9:49:44 AM) [Arch_SB]thpr: vs. the String formats we have today
(9:50:16 AM) [Arch_SB]thpr: So that's my projects
(9:50:19 AM) [Arch_SB]thpr: next
(9:50:27 AM) TirGwaith: ok. It would be nice for data to be just data, not OS token usage inside data
(9:50:33 AM) TirGwaith: anyway...
(9:50:54 AM) [code]nuance: detectiung the end of the variables is nasty, since they can end with a class anme or a skill, or an abiltiy "skill focus (Perform (dance))" anyone?
(9:51:31 AM) [Arch_SB]thpr: Why can't you just separate on the mathematical operators?
(9:51:58 AM) [code]nuance: or(foo + 2, 1, 0)
(9:52:13 AM) [Arch_SB]thpr: (,+ all magical
(9:53:02 AM) [code]nuance: or(foo, <deeply nested mess of OS and JEP>, 1)
(9:53:29 AM) [Arch_SB]thpr: ok, let's find time to walk through that offline
(9:53:31 AM) [code]nuance: the operators could be anye
(9:54:00 AM) [code]nuance: I'd like to strangle whoever added jep to the mix :-)
(9:54:04 AM) [Arch_SB]thpr: since I wrote the formula parser I think we can work through much of it, but would like to understand where it breaks
(9:54:23 AM) [code]nuance: ok
(9:54:59 AM) ***James[Code_SB] back
(9:55:36 AM) cpmeister: my turn?
(9:55:46 AM) [Arch_SB]thpr: if nuance is done
(9:55:49 AM) [code]nuance: yep
(9:56:05 AM) cpmeister: There are several things I?ve been working on:
(9:56:13 AM) cpmeister: First and foremost is the new UI code / UI demo.
(9:56:26 AM) cpmeister: I?m currently gated by several factors:
(9:56:27 AM) cpmeister: 1) my current Filter implementation needs to be remodeled and formalized
(9:57:46 AM) cpmeister: with filters, I need a way to formalize the initialization, persistance, and access of filters
(9:58:14 AM) cpmeister: my current UI demo is running filterless atm
(9:58:59 AM) James[Code_SB]: BTW: I don't think we need a full implementation before providing a demo to the community
(9:59:36 AM) cpmeister: but it has to be done sometime :/
(9:59:44 AM) James[Code_SB]: Oh yes
(10:00:08 AM) cpmeister: I've been trying to mull through to figure out wether Tom's chooser filters would be of some use, but so far I haven't had any conclusions
(10:00:50 AM) [Arch_SB]thpr: I would suspect you should be able to use those
(10:01:00 AM) [Arch_SB]thpr: but would need to delve a bit more into how the UI uses them
(10:01:29 AM) cpmeister: I could explain in further detail at a later time if you like? :)
(10:01:58 AM) [Arch_SB]thpr: Yea, let's catch up at some point
(10:02:31 AM) cpmeister: the other thing holding the UI back is lack of ideas for tab remodels
(10:02:48 AM) cpmeister: so far only the tabs for skills, classes, and feats have been implemented (feats might be reimplmented since I?m getting better ideas for it) all the remaining tabs have yet to be implmeneted. Some of them I need to just make the tabs for them, others need to go under discussion.
(10:03:07 AM) cpmeister: Equipment Tab ? I?ve been formalizing the idea of combining the equipment purchase tab and the character equipment tab, but I have yet to create a prototype tab. This could go for discussion for anybody interested.
(10:03:41 AM) cpmeister: but the equipment tab is also held back by a lack of Facades to build it upon
(10:04:08 AM) cpmeister: so the facades need to be created as well
(10:04:12 AM) James[Code_SB]: I can sort out some facades if you like
(10:04:47 AM) cpmeister: that would be very helpful, thanks James! :)
(10:05:00 AM) James[Code_SB]: BTW: The data model if you like for equipment runs like this
(10:05:33 AM) James[Code_SB]: Equipment Definition -> Owned Equipment -> Equipped Item -> EquipSet
(10:06:16 AM) James[Code_SB]: where Equipped item is a many to many between Owned equipment and equipset
(10:06:22 AM) *[Chair]Eddy left the room.*
(10:07:20 AM) cpmeister: I was planning on reducing that into Equipment Definition/Purchase -> Owned Equipment/Carried/Not Carried equipment, would that work?
(10:07:43 AM) [Arch_SB]thpr: No
(10:07:47 AM) [Arch_SB]thpr: I think we want different equipsets
(10:08:04 AM) James[Code_SB]: Dungeon v travelling v tower etc
(10:08:18 AM) *Papa-DRB left the room (quit: "~ Trillian Astra - www.trillian.im ~").*
(10:08:22 AM) cpmeister: oh, forgot to include those...hmm
(10:08:57 AM) James[Code_SB]: Its actually a bit like spellbooks in some ways
(10:09:12 AM) James[Code_SB]: (if that helps)
(10:09:55 AM) cpmeister: I know how the equipment set works, I've just trying to create a mental picture in my head of the UI setup
(10:10:08 AM) cpmeister: I'll get to that later
(10:10:10 AM) James[Code_SB]: np
(10:10:25 AM) cpmeister: moving on
(10:10:26 AM) cpmeister: Spells tab- This is a tab has not been implemented due to complete lack of ideas, I doubt that the current one is the best but unless I can get some ideas from other people, I don?t know what to change.
(10:11:15 AM) cpmeister: theres been a lot of discussion regarding the spell chooser, so I didn't really want to make a tab for spells until a resolution was reached
(10:11:17 AM) James[Code_SB]: A fair bit of thought went into the current implementation - I wouldn't reject it out of hand :)
(10:12:38 AM) James[Code_SB]: I am sure improvements could be made but I would start by considering what the shortcomings of the current implementation are and trying to correct those
(10:12:40 AM) cpmeister: but then again, isn't the spell tab linked with the equipment tab due to the fact that one can purchase spellbooks?
(10:13:22 AM) cpmeister: well, not linked, but related
(10:13:25 AM) James[Code_SB]: There is a link yes but only via the list of owned equipment
(10:13:47 AM) [Arch_SB]thpr: the core should tell you the owned spellbooks
(10:13:52 AM) James[Code_SB]: yep
(10:13:56 AM) [Arch_SB]thpr: the UI shouldn't make that interaction itself
(10:14:06 AM) James[Code_SB]: and that is what happens currently IIRC
(10:14:39 AM) cpmeister: I can work with that
(10:15:48 AM) cpmeister: I have noticed that some of the tabs are not necessary in many instances, Domain for instance
(10:16:10 AM) cpmeister: no point in having a Domain tab if the character hasn't taken a class that needs them
(10:16:28 AM) cpmeister: Anyone oppose the idea of downgrading it from a tab?
(10:17:21 AM) cpmeister: and instead opting for an option on a Misc tab?
(10:18:37 AM) [Arch_SB]thpr: why can't we have it only display if there are "points" in the Domain pool?
(10:18:46 AM) [Arch_SB]thpr: from BONUS whatever it is
(10:19:16 AM) James[Code_SB]: or if you move/downgrade it, it should still be associated with the deity tab
(10:19:43 AM) cpmeister: k
(10:20:46 AM) cpmeister: the last tab that I need some ideas on is the Summary Tab.
(10:21:06 AM) James[Code_SB]: Oh that one has always bee contentious :)
(10:21:22 AM) cpmeister: as I recall, there was suggestions to have different summary tabs for different game modes
(10:21:40 AM) James[Code_SB]: Yes that has always been a popular option
(10:22:28 AM) James[Code_SB]: It might be as simple as having a series of drop-in components which can be chosen/arranged in an xml file for each gamemode
(10:23:04 AM) cpmeister: could you perhaps provide an example of different summary tab configurations?
(10:23:31 AM) James[Code_SB]: I can do that offline if you like
(10:23:47 AM) cpmeister: yeah, sure
(10:23:48 AM) James[Code_SB]: but very quickly and simply, modern doesn't show the alignment drop-down
(10:23:57 AM) James[Code_SB]: other game modes do
(10:24:11 AM) cpmeister: ah
(10:25:02 AM) cpmeister: my concern with the Summary tabs was how it might display repetitive information when compared with the CharacterSheet that would be displayed directly above all the tabs
(10:25:25 AM) James[Code_SB]: Fair point
(10:25:34 AM) TirGwaith: aside: I wish I could choose a class without having to set alignment. Don't have to for race, but do for class. ugh.
(10:25:45 AM) James[Code_SB]: The current approach is focused on getting the key things able to be entered quickly
(10:26:07 AM) James[Code_SB]: but lets take this offline - we've been going to 2 and a half hours now :)
(10:26:26 AM) cpmeister: k
(10:27:50 AM) [Arch_SB]thpr: Are there any items Drew, Eric or Tir want to bring up to the code team?
(10:28:42 AM) [Admin]Drew: That was a lot to absorb... I'll have to compose my thoughts and email them to the dev list
(10:31:16 AM) [Arch_SB]thpr: I'd take that as a no from the others
(10:31:27 AM) [Arch_SB]thpr: James, do you remember the next date we had discussed?
(10:31:49 AM) James[Code_SB]: Hmm
(10:31:56 AM) James[Code_SB]: I think it was in about a month
(10:32:51 AM) James[Code_SB]: I'll dig it up and post to the dev list
(10:33:20 AM) [Arch_SB]thpr: k
(10:34:20 AM) Maredudd: I have nothing. Mostly cuz I'm so confused . . . :-)
(10:34:25 AM) James[Code_SB]: :)
(10:35:08 AM) James[Code_SB]: I'll post a log but I'll also try and post a summary including agreed actions. It might be later today though
(10:35:14 AM) [Admin]Drew: Oh, I have something
(10:35:21 AM) [Arch_SB]thpr: thanks James
(10:35:37 AM) James[Code_SB]: Anything further to raise or shall we call, this meeting to a close?
(10:36:02 AM) James[Code_SB]: OK drew, off you go
(10:36:28 AM) James[Code_SB]: I'll assume no one has anything else unless stated before Drew finishes :)
(10:37:27 AM) TirGwaith: Not really. I think any GUI changes need a good run-by from the users at large
(10:37:35 AM) James[Code_SB]: agreed Tir
(10:38:03 AM) [Admin]Drew: Can I have all you coders please comment on the JIRA installation we have please... Anyone with experience I'd love help setting up pathways and flows, etc...
(10:38:12 AM) [Admin]Drew: (Sorry for the delay, computer froze)
(10:38:51 AM) [Arch_SB]thpr: Given that it's now running, we really need to define a test plan for it
(10:39:00 AM) [Arch_SB]thpr: that's where comments come from
(10:39:01 AM) [Admin]Drew: Just need input on what everyone would like so we can get a prototype going...
(10:39:12 AM) James[Code_SB]: Did you want replies on the websiteteam list or the dev list Drew?
(10:39:26 AM) [Admin]Drew: I monitor both, so it doesn't matter
(10:39:44 AM) [Admin]Drew: But feedback and a test plan would be helpful
(10:40:22 AM) James[Code_SB]: For those who missed it jira is running at http://113.20.10.179:8081/
(10:40:38 AM) cpmeister: ah, thanks james
(10:40:41 AM) [Admin]Drew: I set up a project for new data sources for Eric to review, and would like to hammer out how many or few we need to cover the bases for all the teams and related trackers we have currently
(If we can compress things great)
(10:41:08 AM) [Arch_SB]thpr: Let's test it before we make any assumptions about a transition plan
(10:41:34 AM) [Admin]Drew: Tom - Yes, agreed. Currently we need to really define and set up a project
(10:41:52 AM) [Admin]Drew: Anyways, that's my quick comment... thanks.
(10:41:56 AM) James[Code_SB]: How about we start a thread on the website team list about a test plan for Jira?
(10:42:10 AM) [Admin]Drew: Sounds good
(10:42:16 AM) James[Code_SB]: and build it up in discussions there
(10:42:27 AM) TirGwaith: Why do we need another tracker site?
(10:42:36 AM) TirGwaith: We trying to move away from SF?
(10:42:58 AM) [Admin]Drew: Functionality not present in the current site and features that have been requested by teams.
(10:43:15 AM) [Arch_SB]thpr: There are certain things we can't do at SF and part of this is to evaluate if we can do all those things in JIRA
(10:43:40 AM) [Arch_SB]thpr: for example, with a token change, when the code team closes the FREQ, it could automatically open Doc, PrettyLst, Data trackers
(10:43:46 AM) [Arch_SB]thpr: can't do that at SF
(10:44:28 AM) [Arch_SB]thpr: We could also list dependent FREQs, so if B was dependent upon A, we can have the list of items that are really workable
(10:44:32 AM) [Arch_SB]thpr: which includes A and not B
(10:45:42 AM) TirGwaith: I reserve the right to ignore it and force TMs to do all my tracker work. :p
(10:45:58 AM) James[Code_SB]: :)
(10:46:01 AM) [Arch_SB]thpr: LOL
(10:46:11 AM) James[Code_SB]: Alright I think that about wraps it up
(10:46:26 AM) James[Code_SB]: Thanks for coming along everyone and the great discussion
(10:46:29 AM) TirGwaith: Seriously: Trackerizing everyhting, and changing HOW we use trackers every so often is an disinsentive to do work
(10:46:57 AM) James[Code_SB]: Have a great weekend everyone