"Deep Dive Meeting" - TOPIC "Formula Parser Compatibility"

Participants:

Andrew Maitland - Chair/Content Team
James Dempsey - Code SB
Tom Parker - Arch SB
Connor Petty - Code Team
Paul Grosse - Content Team

Summary:

Release issue raised by James Dempsey related with ANT and MAVEN. James is implementing Gradle as the replacement Build System (All members happy with this change) Tom Parker led the discussion for the Formula Parser and the options and issues with implementing this. Further discussion and questions directed to the PCGEN_Development Yahoo Group - Topic Header "Discussion Placeholder: BoD Discussion / Formula / Compatibility" started by Tom Parker

Raw Log

[17:00] <@Andrew[Chair]> *Bangs Gavel* Welcome to our PCGen Board of Director's Meeting - This is a Deep Discussion Format.
[17:00] <@Andrew[Chair]> Agenda today:
[17:00] <@Andrew[Chair]> * Release Issues (Only High Priority items)
[17:01] <@Andrew[Chair]> * Discussion Topics - Today's First Topic is by Tom Parker - Formula Parser Compatibility
[17:01] <Tom[Arch_SB]> I can be quick on the first one: I have no release issues to mention
[17:01] <@Andrew[Chair]> Rules - Observation till we reach the Discussion Topic, then everyone may participate.
[17:02] <@Andrew[Chair]> Thanks Tom. I have nothing that gates an Alpha release as well.
[17:02] <James[Code_SB]> My main report is that the 6.3.0 release hit a few problems
[17:03] <James[Code_SB]> they were related to the old maven 1 build we use
[17:03] <James[Code_SB]> As a result I have moved to use gradle instead, but the release steps are trhe final part fo that work
[17:03] <James[Code_SB]> That might delay the 6.3.1 release depending on how it goes
[17:04] <Tom[Arch_SB]> better to learn now than in beta :)
[17:04] <James[Code_SB]> yep
[17:04] <@Andrew[Chair]> Agreed
[17:05] <@Andrew[Chair]> Nothing else then for the Release?
[17:05] <James[Code_SB]> Just that the pdf sheets still need work to update to the new FOP - I'm progressing through those but paying a horrible price for the copy paste approach
[17:06] <@Andrew[Chair]> Fun, once finals are finished I'll lend a hand
[17:06] <James[Code_SB]> that's all
[17:06] <@Andrew[Chair]> Okay, Agenda item #2, Discussion Topics. Tom, floor is yours. (Free Participation allowed at this point for those observing)
[17:07] <Tom[Arch_SB]> Thanks Andrew
[17:07] <Tom[Arch_SB]> So the main reason for the discussion is that the formula system we have today needs to be replaced, and doing that in an incremental fashion is ... challenging
[17:07] <Tom[Arch_SB]> For purposes of this discussion we should assume there is no way to do an incremental change, that it has to be abrupt (And thus will break data)
[17:08] *** cpmeister has joined #pcgen
[17:08] <Tom[Arch_SB]> If anyone wants to discuss details of why that is true, then that is really a technical discussion I'm happy to have on _dev
[17:08] <cpmeister> Hi all
[17:08] <Tom[Arch_SB]> but I'd like to keep this to the cross-term interaction and resulting project impact
[17:08] <James[Code_SB]> Hi Connor
[17:09] <Tom[Arch_SB]> So with that basis, we basically end up with the assertion that we have an incompatible change to deal with
[17:09] <Tom[Arch_SB]> The question is what is the best way to deal with that particular challenge
[17:10] <@Andrew[Chair]> In terms of data impact, can you lay it out for the folks following along at home?
[17:10] <@Andrew[Chair]> What would we need to "fix" to use the proposed new method?
[17:10] <Tom[Arch_SB]> Well, let me generalize, because there are different ways we can do this that will have different impacts
[17:10] <Tom[Arch_SB]> so I'll come back to the different ways in a moment
[17:11] <Tom[Arch_SB]> but on some potential changes. We have things like COUNT[FEAT] ... which we would want to have folks using a count(...) function
[17:11] <Tom[Arch_SB]> So all the bracket stuff "goes away"
[17:11] <Tom[Arch_SB]> So those would have to be replaced with functions
[17:11] <Tom[Arch_SB]> others are a single thing... SPELLFAILURE perhaps is an example there.
[17:11] <[OGL]Nylanfs> Evening all sorry im late.
[17:12] <Tom[Arch_SB]> We call those "terms", they are effectively built in constants
[17:12] <Tom[Arch_SB]> The new system (intentionally) does not support that concept
[17:12] <Tom[Arch_SB]> Everything is data-controlled
[17:12] <Tom[Arch_SB]> So the game mode would need some method of "setting up" those items
[17:12] <Tom[Arch_SB]> That's one example
[17:13] <Tom[Arch_SB]> there are certainly others, but that will involve getting into a bit more detail
[17:14] <Tom[Arch_SB]> In order to be precise about the changes, we need to actually make some decisions about the magnitude
[17:14] <Tom[Arch_SB]> In effect, the formula system has a set of "semantics" of what is legal or not (non-computer scientist folks can think of this as a strict definition of behavior)
[17:15] <Tom[Arch_SB]> The question is whether we try to maintain any material portion of the semantics or whether we don't bother
[17:15] <Tom[Arch_SB]> The challenge is that the more we maintain, the more risk there can be from subtle errors that the system thinks is correct, but are not actually the calculations the data team wants/intends
[17:15] <Tom[Arch_SB]> The challenge is also that the less we maintain, the more work the conversion is
[17:16] <@Andrew[Chair]> Question -
[17:16] <Tom[Arch_SB]> so there is a bit of a "balancing act" here
[17:16] <@Andrew[Chair]> This balancing act, eventually we move completely to the new system. So in the end, we have to do the same amount of work correct?
[17:17] <Tom[Arch_SB]> again, it depends
[17:17] <Tom[Arch_SB]> there is certainly a tradeoff between how much code automatically converts and how much work data has to do
[17:17] <Tom[Arch_SB]> so that is tradeoff between teams. The data itself still has to change, but the work shifts
[17:18] <Tom[Arch_SB]> There is also a question of how much of the existing behavior we try to replicate
[17:18] <Tom[Arch_SB]> The more we match existing behavior, the easier it is to convert, but we also end up bringing some of the quirks (bad behavior) along with us
[17:19] <Tom[Arch_SB]> (Trying not to taint the discussion TOO much one way or another right now)
[17:19] <Tom[Arch_SB]> Does that somewhat (but not really) answer your question?
[17:20] <@Andrew[Chair]> Yes and no.
[17:20] <@Andrew[Chair]> Goal #1 - Replace JEP with new system
[17:20] <Tom[Arch_SB]> Let me lay out a few options and then we can talk about what those mean
[17:20] <Tom[Arch_SB]> because there really is a wide range of possibilities here
[17:20] <@Andrew[Chair]> Goal #2 - Remove bad behavior
[17:21] <@Andrew[Chair]> Yes, some options would help.
[17:22] <Tom[Arch_SB]> There is a spectrum here, so let me lay out kind of the two "bookends" and then some option in the middle
[17:23] <Tom[Arch_SB]> One end of the spectrum is literally that the compatibility is so important that the two goals Andrew listed (and much of this discussion) are effectively irrelevant.
[17:24] <Tom[Arch_SB]> Another is that we take the system, rip out JEP, put in the new system, and figure out what breaks. Obviously this will drive a lot of testing, et al (but I think there will have to be a lot of testing if we make a change)
[17:25] <Tom[Arch_SB]> To editorialize a bit, in the former case, I believe it effectively locks PCGen into the d20 systems that it has today, and any work to broaden the spectrum effectively becomes another project
[17:25] <Tom[Arch_SB]> (because SO much is dependent on the formula system and being able to see what is/is not legal)
[17:26] <Tom[Arch_SB]> In the latter case, it's admittedly a painful process, and it actually makes changes at a scale we have not done in many years (meaning it breaks compatibility)
[17:26] <Tom[Arch_SB]> It may also drive a lot of effort in terms of needing features and having to get those into the system to make it fully functional again, so you're putting release schedules at high risk
[17:27] <Tom[Arch_SB]> It also rather stinks because the questions you are asking Andrew, are ones that are very hard to answer.
[17:27] <[OGL]Nylanfs> I am always if favor of ripping out system specific code.
[17:27] <Tom[Arch_SB]> It's hard to say everything that will break, because a lot of LST files have been built to "what works" which may or may not be taking advantage of something that is either a bug or a not-very-well-understood corner case
[17:28] <Tom[Arch_SB]> Don't get me wrong - my goal is to get PCGen to handle a lot more than d20 - The game I run and multiple other characters are non-d20 systems that really don't fit well in PCGen
[17:29] <Tom[Arch_SB]> The question is how we do that while not mangling what we do today, which is stable and functioning (with normal error rates anyway)
[17:30] <Tom[Arch_SB]> Somewhere in the middle is an option that actually says "This is not a good project for the Trunk"...
[17:30] <Tom[Arch_SB]> and means we are running two systems in parallel for some period of time
[17:31] <Tom[Arch_SB]> Another middle option takes us closer to the "don't touch PCGen" end of the bookshelf, and effectively keeps the existing Trunk as d20
[17:31] <Tom[Arch_SB]> ...and drives other development in a branch that is allowed to be "more flexible"
[17:31] <Tom[Arch_SB]> With the lack of dependent data, there can be rapid changes to what is supported
[17:31] <Tom[Arch_SB]> Then new systems can be generated there... keeping the existing d20 stuff stable on the existing platform
[17:32] <Tom[Arch_SB]> Once the new platform has the right features, and data understands the new syntax and feels a transition is justified, we swap over that data over some period of time
[17:32] <Tom[Arch_SB]> This actually takes on the burden of having two different releases (Call them PCGen and NewGen for lack of better distinguishing names)
[17:33] <Tom[Arch_SB]> So effectively we end up with a few questions:
[17:33] <Tom[Arch_SB]> - Are we even doing an incompatible change (is this important enough to progress)
[17:33] <Tom[Arch_SB]> - Are we attempting to do this in the Trunk
[17:33] <Tom[Arch_SB]> - Are we enabling other changes in parallel to get to a point where other non-d20 is better supported
[17:34] <Tom[Arch_SB]> I think those are the key questions that have come up for me as I've been thinking about it.
[17:34] <Tom[Arch_SB]> Comments from anyone so far?
[17:34] <cpmeister> I think an important question to answer is how much of the current formula system operates in a defined manner. How much of the current data relies on undefined behavior?
[17:34] <[OGL]Nylanfs> So basically development on trunk would stop except for true bugs and data would have to wait for the new system to support new books?
[17:34] <Tom[Arch_SB]> I think the problem is that we don't know Connor
[17:35] <Tom[Arch_SB]> Nylanfs: Not exactly
[17:35] <Tom[Arch_SB]> The trunk could continue to progress with d20 supported, and we could still do enhancement there
[17:35] <Tom[Arch_SB]> just would be limited to things that really are the core datasets (RSRD, Pathfinder)
[17:35] <Tom[Arch_SB]> and would not include deep changes like the Ability work I have been doing
[17:36] <Tom[Arch_SB]> The "NewGen" would be trying to do things with Cyberpunk, maybe Andrew would do eclipse there, Killshot perhaps, that type of stuff
[17:36] <Tom[Arch_SB]> so I think new d20 books would still go into PCGen and would not and should not be gated by the NewGen path
[17:36] <Tom[Arch_SB]> (because the system as it is today can still do just about everything those books would need)
[17:37] <[OGL]Nylanfs> Okay i can see that and make sure that the users are aware that truely new mechanics might not be able to supported till newgen
[17:37] <@Andrew[Chair]> If I may interject then...
[17:37] <Tom[Arch_SB]> Connor, the other point I would make is that if we go off into a NewGen branch, then we can take out a lot of the d20 assumptions right away because there is no dependent data to get into deprecation issues
[17:37] <Tom[Arch_SB]> so it can extend beyond just formulas
[17:38] <Tom[Arch_SB]> Paul (Nylanfs): correct
[17:38] <@Andrew[Chair]> Why not swap places then? Move the d20 supported stuff to it's own branch - Stable d20 Pcgen. Then the development trunch would be where we go hog wild for lack of a better term?
[17:38] <James[Code_SB]> You could but its not really a standard approach
[17:38] <Tom[Arch_SB]> Yea, risk.
[17:39] <Tom[Arch_SB]> If for some reason NewGen fails, then your trunk just died
[17:39] <James[Code_SB]> and we would end up treating the stable branch like trunk and doing alpha releases from it etc
[17:39] <James[Code_SB]> yep
[17:39] <James[Code_SB]> It is sounding a lot like the new UI
[17:39] <Tom[Arch_SB]> I think it is to a degree
[17:39] <Tom[Arch_SB]> So full opinion time here
[17:39] <Tom[Arch_SB]> I think there are two key issues for me
[17:40] <James[Code_SB]> Use the branch as a way to let it be developed logically and then once it covers sufficient function, merge it in
[17:40] <Tom[Arch_SB]> 1) The data team is clearly and rightfully worried about magnitude of change, but it is hard for us to articulate the total set of changes, so we really need a "proof of concept" of sorts
[17:41] <Tom[Arch_SB]> 2) This change really needs to happen all at once, because a gradual transition increases the cost of development work and really the performance would be such that we could never release it as production... so way too much risk to put it in Trunk
[17:41] <Tom[Arch_SB]> The nice benefit of taking the "new systems" out to the branch is that it forces something into that branch to test it, and those will do a good job of stressing the system
[17:42] <cpmeister> yep, sounds like the new UI all over again.
[17:42] <Tom[Arch_SB]> and it keeps the d20 stuff in the main trunk where we know it works
[17:42] <@Andrew[Chair]> Yup
[17:42] <Tom[Arch_SB]> I think it's different though
[17:42] <James[Code_SB]> I'd like to see a basic d20 set there too - maybe just the pathfinder core rules - to ensure they cover those requirements too
[17:42] <Tom[Arch_SB]> I'm happy to carry some burden on RSRD there.
[17:42] <Tom[Arch_SB]> That will allow me to put all my PCs in one place
[17:44] <Tom[Arch_SB]> Does anyone think the other pathways make any sense or is there another good option?
[17:44] <cpmeister> I'm all for a new branch
[17:44] <@Andrew[Chair]> Branches have always been the best test method
[17:44] <Tom[Arch_SB]> So the implied thing here is that data is committing to bring some of the new systems over to that branch
[17:44] <@Andrew[Chair]> they are also outside of cycles, and thus can be developed at whatever pace they need.
[17:44] <Tom[Arch_SB]> Doesn't have to be all, you can talk to the team and get some
[17:44] <[OGL]Nylanfs> I think going to a new branch is a good idea
[17:45] <@Andrew[Chair]> I'll commit to porting all the systems I can get my hands on. <evil grin>
[17:45] <Tom[Arch_SB]> ok, I think we'll want to be careful to not bring all the core sets along though
[17:45] <Tom[Arch_SB]> I will want to move fast enough that I don't think those will be able to keep up
[17:46] <@Andrew[Chair]> I do have access to a good homebrew community and my own personal stuff. We can definitely test whatever systems you'd like.
[17:46] <[OGL]Nylanfs> And Rob will be a definite help in getting the sets into Newgen
[17:46] <Tom[Arch_SB]> Because I'd like to have other changes (non-formula) take place in parallel as well
[17:46] <Tom[Arch_SB]> If we're going to do a break, we should do it once and then be stable again for as long as we can
[17:46] <James[Code_SB]> Is that trying to squeeze too much into one change set?
[17:47] <Tom[Arch_SB]> From a code perspective it may be easier
[17:47] <Tom[Arch_SB]> For example:
[17:47] <Tom[Arch_SB]> Right now we have probably 20, if not more, tokens that are doing some form of number calculations
[17:47] <Tom[Arch_SB]> With the new formula system, I can assert that I can simply delete those tokens altogether, in one swoop
[17:48] <Tom[Arch_SB]> so it transfers power to data and saves code effort, at the expense of changes in the data...
[17:48] <Tom[Arch_SB]> but because we didn't bring any dependent data along...
[17:48] <Tom[Arch_SB]> There is then a back-end cost once we want to convert the d20 stuff
[17:49] <Tom[Arch_SB]> I would hope that between the net benefit and that we will have general guidelines on what the changes are that it can be made less than a complete gut
[17:49] <Tom[Arch_SB]> but will still be challenging
[17:50] <Tom[Arch_SB]> ...and to be honest, I'm struggling with the slow pace of change and not being able to get systems I want into PCGen.
[17:50] <@Andrew[Chair]> So far I agree with you Tom. How many systems do you want to be tested in the new branch?
[17:51] <@Andrew[Chair]> RSRD (Eclipse if you want), Killshot, and anything else?
[17:51] <Tom[Arch_SB]> Well, assuming we bring along some part of RSRD, let's get a level-less system, and a class-less system
[17:51] <Tom[Arch_SB]> James is being quiet though
[17:52] <James[Code_SB]> yeah
[17:52] <@Andrew[Chair]> RSRD complete is best, 3.5 Eclipse version, then. Levelless system would be Killshot (Though even that uses the level mechanism, if you want a true non-level system we'd want one of the other systems).
[17:52] <James[Code_SB]> I still need to come to terms with the break in data compatibility
[17:53] <James[Code_SB]> and am a bit worried about tiome frames
[17:53] <Tom[Arch_SB]> I think we have to assume the Trunk stays on cycle and we all have work to do there
[17:53] <James[Code_SB]> What sort of lifetime do you expect for the branch?
[17:54] <Tom[Arch_SB]> new UI was what, a year?
[17:54] <Tom[Arch_SB]> I don't see this being less
[17:54] <James[Code_SB]> yeah around that
[17:54] <Tom[Arch_SB]> but there is certainly key work in Trunk that would still help NewGen
[17:55] <Tom[Arch_SB]> Interface from core to output for Freemarker
[17:55] <Tom[Arch_SB]> Interface to UI and getting Facades out of core
[17:55] <Tom[Arch_SB]> both worthy to keep working in Trunk
[17:55] <James[Code_SB]> So we are well past just a new formula system then
[17:56] <Tom[Arch_SB]> I guess I'm at the point where if we are going to break data, break the data, and give a really compelling reason to move
[17:56] <James[Code_SB]> right
[17:56] <Tom[Arch_SB]> if it's not compelling, keep the Trunk and don't break it
[17:56] <@Andrew[Chair]> might as well.
[17:57] <Tom[Arch_SB]> Given how long it took to clean up Abilities, I just don't see a gradual move happening in less than years, and I'm struggling with that investment
[17:57] <James[Code_SB]> understood
[17:58] <Tom[Arch_SB]> The other way to do this is like what was done with CDOM
[17:58] <Tom[Arch_SB]> where I went off into a branch for some period of time, no data, and explored
[17:58] <Tom[Arch_SB]> things were brought back into Trunk, but the branch itself never became active in any sense
[17:58] <James[Code_SB]> yep
[17:59] <Tom[Arch_SB]> And maybe that's the way to start, because I could go off in some period of time and go do a deep gut of PCGen, trying to get to a minimal feature set
[17:59] <Tom[Arch_SB]> and then folks can look at what is left and see how compelling such a transition migh tbe
[18:00] <Tom[Arch_SB]> and that may also give a better sense of just how much data might change
[18:01] <Tom[Arch_SB]> So we're running up on time... are folks good for a bit, or do we want to pick this up in 4 weeks
[18:01] <@Andrew[Chair]> I'm good.
[18:01] <cpmeister> I'm good
[18:01] <@Andrew[Chair]> I'm doing schoolwork at the same time.
[18:01] <Tom[Arch_SB]> lol
[18:02] <James[Code_SB]> It has certainly been useful to get an idea of the scope and options
[18:02] <James[Code_SB]> So thank-you for the discussion
[18:03] <@Andrew[Chair]> So, of the options offered, I'm really keen on a working branch that we can play in. I'm taking it that we don't expect this to merge for about a year, or Alpha cycle of 6.5?
[18:03] <@Andrew[Chair]> or 6.7
[18:03] <Tom[Arch_SB]> I don't even want to talk schedule
[18:03] <Tom[Arch_SB]> premature until we consider options and choose a path. We're in early discussion right now
[18:05] <@Andrew[Chair]> With everything discussed so far, which option are you leaning towards Tom?
[18:07] <Tom[Arch_SB]> Not sure Andrew
[18:07] <Tom[Arch_SB]> part of this is me thinking through it as well and getting myself comfortable with the risks
[18:07] <Tom[Arch_SB]> and benefits
[18:09] <Tom[Arch_SB]> I think maybe we pause there and let folks ponder. I'd direct questions or comments to _dev so we can keep them in one place
[18:09] <James[Code_SB]> Sounds good, thanks Tom
[18:09] <Tom[Arch_SB]> and we can pick up again at the next deep dive session
[18:10] <Tom[Arch_SB]> Other options are welcomed as well, this shouldn't be just me determining what happens
[18:10] <@Andrew[Chair]> Of course
[18:11] <@Andrew[Chair]> You going to open a new thread on dev for the discussion then Tom?
[18:12] <Tom[Arch_SB]> I can make a placeholder post if you think that is useful
[18:12] <@Andrew[Chair]> Yeah, might be best to give people a place to gravitate towards
[18:12] <Tom[Arch_SB]> k
[18:12] <@Andrew[Chair]> If that is all, then I'll close out our meeting.
[18:13] <Tom[Arch_SB]> That's it from me
[18:13] <@Andrew[Chair]> *Bangs Gavel* Thanks for coming everyone. Meeting is closed out.

Meeting 2014 06 06

"Deep Dive Meeting" - TOPIC "Formula Parser Compatibility"

Summary:

Raw Log

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Start

Teams

Community

Strategic Development

Misc

Tools