LegacyKing: Created page with " =Board Meeting= Last meeting of 2014. ==Attendance== * Andrew * Tom * James * Doug * Stefan ==Summary== * 6.04.1 will be released on the 22nd of December - no further dela..."

2014-12-20T01:42:03Z

Created page with " =Board Meeting= Last meeting of 2014. ==Attendance== * Andrew * Tom * James * Doug * Stefan ==Summary== * 6.04.1 will be released on the 22nd of December - no further dela..."

New page

=Board Meeting=
Last meeting of 2014.

==Attendance==
* Andrew
* Tom
* James
* Doug
* Stefan

==Summary==
* 6.04.1 will be released on the 22nd of December - no further delays allowed. PCGen works... we'll release!
* 6.05.0 will be released on the 23rd of December.
* SVN will be frozen for migration to GITHUB. Timeline is anticipated to be 2-3 days for SVN to GITHUB after changes have been made. Skylar's model looked great, and James said it was exactly what he was looking to accomplish.
* ANT Support will be dropped effective immediately for 6.5.0+, all should use Gradle to build at this point.
* James will update the WIKI build instructions for using the Gradle wrapper in your build environment.
* Tom laid out the impact of the Formula Parser system, and what items have been discovered as part of the mock subset Andrew worked on. He mentioned a few areas where optimization would be implemented once he worked it out.
* Involving the community was mentioned
* Conversion was discussed, a smaller system was suggested to get the team used to the new syntax.
** FantasyCraft was pushed as the best fantasy d20 system to convert
** Killshot was also recommended, but discarded as the OS is not complete to have full testing.
** Deadlands was also recommended.
* Of those, Fantasy Craft has the smallest data footprint and would be the best.
* OS conversion was mentioned and Tom will come up with the proper method
* FACT/FACTSET is easier to plug in and was recommended to get in; Tom deferred that since another system needs to be built to allow two-way communication first.

=Meeting Log=
* [15:04] <@AndrewAAM[Chair]> Welcome everyone to the PCGen Board of Director's meeting.
* [15:04] <@AndrewAAM[Chair]> This is scheduled as a Deep Dive Meeting with a release component: (3pm PST, 6pm EST)
* [15:04] <@AndrewAAM[Chair]> Agenda: 1 hour meeting allotted.
* [15:04] <@AndrewAAM[Chair]> (1) Release Status of 6.4.1 & 6.5.0 (James - 5 minutes)
* [15:04] <@AndrewAAM[Chair]> (2) Migration plans (James - 5 to 10 minutes)
* [15:04] <@AndrewAAM[Chair]> (3) Assessment & Discussion of Formula Parser and public input (Tom - 45 minutes)
* [15:05] <Tom[Arch_SB]> Are we expecting James?
* [15:06] <@AndrewAAM[Chair]> Yes, I haven't heard from him otherwise
* [15:06] <Tom[Arch_SB]> k
* [15:06] <@AndrewAAM[Chair]> Since James is currently not present, we can skip his segments til he shows up. I'll send him a quick note.
* [15:06] *** James[Code_SB] has joined #pcgen
* [15:06] <@AndrewAAM[Chair]> Hi James!
* [15:06] <James[Code_SB]> Morning all
* [15:06] <Tom[Arch_SB]> Hi James
* [15:06] <@Zaister> That was some quick note!
* [15:07] <Tom[Arch_SB]> no kidding!
* [15:07] <@AndrewAAM[Chair]> Mental note... speed of thought!
* [15:07] <James[Code_SB]> Bit delayed this morning - so where are we up to?
* [15:07] <@AndrewAAM[Chair]> Welcome James, agenda items (1) is ready if you don't mind taking the floor.
* [15:07] <@AndrewAAM[Chair]> (1) Release Status of 6.4.1 & 6.5.0 (James - 5 minutes)
* [15:08] <James[Code_SB]> OK, we have had three release candidates, one really due to the rush to get things out quickly
* [15:09] <James[Code_SB]> We won;t do a forth unless the program doesn't start (it does) :)
* [15:09] <James[Code_SB]> So I'll release 6.4.1 on Monday (22 Dec)
* [15:09] <James[Code_SB]> Then I'll do 6.5.0 the following day
* [15:10] <James[Code_SB]> That will be the last release from svn
* [15:10] <James[Code_SB]> Any questions or concerns?
* [15:10] <Tom[Arch_SB]> ok, so the git conversion schedule also slips to freeze 22 and ready for input like 25?
* [15:10] <@AndrewAAM[Chair]> Sounds good to me. No questions here.
* [15:10] <James[Code_SB]> well, 25th has other significance
* [15:11] <@AndrewAAM[Chair]> That would be agenda item (2)
* [15:11] <@AndrewAAM[Chair]> :)
* [15:11] <@AndrewAAM[Chair]> (2) Migration plans (James - 5 to 10 minutes)
* [15:11] <@AndrewAAM[Chair]> Go ahead James...
* [15:11] <James[Code_SB]> Thanks Andrew
* [15:12] <James[Code_SB]> so with the slip of schedule, I don;t expect we will be moving to git until a few days after Christmas
* [15:12] <Tom[Arch_SB]> so freeze over the weekend after and ready for use 29?
* [15:13] <James[Code_SB]> Sounds reasonable, depending on Henk's time
* [15:13] <Tom[Arch_SB]> ok, or should we freeze from the 6.5.0 release
* [15:13] <@AndrewAAM[Chair]> I'd recommend a freeze on svn after 6.5.0 goes out.
* [15:13] <@Zaister> sounds reasonable to me
* [15:13] <James[Code_SB]> Well, I don;t think the freeze synced to 6.5.0 is so important, but it is a convenient marker
* [15:14] <Tom[Arch_SB]> my current work is in a series of sandboxes anyway, so no impact to me
* [15:14] <James[Code_SB]> It is a quiet time anyway
* [15:14] <@AndrewAAM[Chair]> There shouldn't be any work in the trunk after 6.5. Only thing left to manage would be utility updates - which I can push before 6.5
* [15:15] <James[Code_SB]> Agreed
* [15:15] <Tom[Arch_SB]> ok, then freeze 22nd as you approach 6.5.0 then restart 29 in git
* [15:16] <James[Code_SB]> Yep, noting that it is indicative pending availability during a time when many people are busy, away etc
* [15:16] <Tom[Arch_SB]> y
* [15:16] <@AndrewAAM[Chair]> Oh, we had a volunteer do a migration for us, not sure if you saw. Might save some work if the work looks good.
* [15:17] <James[Code_SB]> Yep, Skylar did a test migration which can be seen at https://github.com/pcgen-reorg/
* [15:17] <James[Code_SB]> It looks quite good
* [15:17] <James[Code_SB]> but removes the lib folder, which means the ant build will no longer work
* [15:17] <@Zaister> as long as gradle still work I guess I can live with that
* [15:17] <James[Code_SB]> With the gradle build now stable I think that is fine, but is everyone happy with that?
* [15:18] <Tom[Arch_SB]> well, we were moving to gradle anyway...
* [15:18] <@AndrewAAM[Chair]> I've been using gradle since you put it in.
* [15:18] <James[Code_SB]> Indeed, and that folder was 25% of the entire repo!
* [15:18] <@Zaister> in that context, is it safe to update gradle to 2.2.1 or might that break the build?
* [15:18] <Tom[Arch_SB]> and the lib being big enough and storing binaries not really in the spirit of git... it's probably better without lib
* [15:19] <@Zaister> indeed
* [15:19] <James[Code_SB]> I'd recommend using the wrapper as that means you don;t need to install gradle at all - it grabs it for you and ensures the version is correct
* [15:19] <@Zaister> oh ok
* [15:19] <@Zaister> where does it put it?
* [15:20] <@AndrewAAM[Chair]> @James - do we have those instructions?
* [15:20] <James[Code_SB]> Gradle wrapper is at gradle v2.2 currently
* [15:20] <@AndrewAAM[Chair]> If not, having them on our wiki would be great. :)
* [15:21] <James[Code_SB]> I don't know for sure but I expect it puts the gradle download in the .gradle folder
* [15:21] <James[Code_SB]> The docs in the wiki need to be updated - I'll get those done
* [15:21] <James[Code_SB]> but it is pretty simple now
* [15:21] <@AndrewAAM[Chair]> Excellent. Simple is good.
* [15:21] <James[Code_SB]> gradlew
* [15:21] <James[Code_SB]> from the pcgen checkout folder
* [15:21] <@Zaister> ah ok, so I don't actually need a gradle install from my distro
* [15:22] <James[Code_SB]> will give you a build
* [15:22] <James[Code_SB]> not with the wrapper, no
* [15:22] <@Zaister> OK
* [15:22] <James[Code_SB]> eclipse and intellij should also be able to use the wrapper, but I haven't played with them too much
* [15:23] <James[Code_SB]> Jenkins has already been switched to the wrapper and does not have gradle 2.2 installed at all
* [15:23] <@AndrewAAM[Chair]> Nice. Sounds like the migration will be easy then with the work Skylar did for us.
* [15:23] <James[Code_SB]> So I'll add a trunk task to remove the old ant build and the lib folder. That will be included in 6.5.0
* [15:24] <James[Code_SB]> Yeah I think so - his split looks good
* [15:24] <James[Code_SB]> We would of course retain our current NewSource repo but otherwise the repos would be as in his demo
* [15:25] <James[Code_SB]> The migration I understand takes around 2-3 days due to the traffic between sf's svn server and the machine where the git repo is being built
* [15:26] <@AndrewAAM[Chair]> Any further comments or questions before we move on to the deep dive discussion segment?
* [15:26] <James[Code_SB]> @cantsin that sound about right to you?
* [15:27] <@AndrewAAM[Chair]> Oh sorry, cantsin isn't skylar
* [15:27] <@AndrewAAM[Chair]> candavespin is skylar
* [15:27] <James[Code_SB]> Ah ok
* [15:28] <Tom[Arch_SB]> I'd actually like to know what the sandbox plan is, since I'm not sure I followed all the discussion
* [15:28] <James[Code_SB]> Well, the sandbox can just be a branch in git
* [15:28] <Tom[Arch_SB]> should they be in forks, or are we actively putting them into the master repository (with the assiciated size)
* [15:28] *** Distant_Scholar has joined #pcgen
* [15:29] <@Zaister> I think for a sandbox like you're using it makes sense to use a fork under your user path
* [15:29] <James[Code_SB]> Yes that is true - easy to be in personal forks then
* [15:30] <@AndrewAAM[Chair]> and those interested in helping or testing can pull your work into their own forks
* [15:30] <James[Code_SB]> However I would still use a branch in your fork to hold the sandbox
* [15:30] <@Zaister> yes
* [15:30] <James[Code_SB]> That way you can keep the fork/master up to date with pcgen master
* [15:30] <Tom[Arch_SB]> right
* [15:30] <James[Code_SB]> and sync the latest code with your branch easily
* [15:31] <@AndrewAAM[Chair]> That seems to be a natural lead in to our next agenda item.
* [15:31] <@AndrewAAM[Chair]> (3) Assessment & Discussion of Formula Parser and public input (Tom - 45 minutes)
* [15:32] <James[Code_SB]> One sec
* [15:32] <James[Code_SB]> Did everyone see the github advisory on a git client vulnerability?
* [15:32] <@AndrewAAM[Chair]> Zaister mentioned it premeeting
* [15:32] <James[Code_SB]> Make sure you update your git clients, particularly if you use windows
* [15:32] <James[Code_SB]> cool
* [15:33] <@AndrewAAM[Chair]> about the git exploit: http://arstechnica.com/security/2014/12/critical-git-bug-allows-malicious-code-execution-on-client-machines/
* [15:33] <@AndrewAAM[Chair]> Thanks James! :)
* [15:34] <@AndrewAAM[Chair]> Before I turn the floor to Tom, I want to mention we had a successful content meeting
* [15:34] <@AndrewAAM[Chair]> Our major discussion was the formula parser, FACT/FACTSET and the git migration. Everyone had a positive outlook and just a few technical issues.
* [15:35] <@Zaister> I can say that I have now understood FACT/FACTSET :)
* [15:35] <Tom[Arch_SB]> woot!
* [15:35] <Tom[Arch_SB]> so what do you think?
* [15:36] <@AndrewAAM[Chair]> Which is exactly the point of those meetings and discussions. :)
* [15:36] <@Zaister> Tom[Arch_SB]: looks like a good idea to me
* [15:36] <Tom[Arch_SB]> cool

==Deep Dive Discussion==
* [15:37] <@AndrewAAM[Chair]> Okay Tom, floor is yours. :)
* [15:37] <Tom[Arch_SB]> So about this formula parser... :)
* [15:37] <Tom[Arch_SB]> Andrew has been working through a small subset of data to get some experience at what it might look like
* [15:38] <Tom[Arch_SB]> I've also been testing things in the sandbox (some uncommitted code at the moment while I work things out)
* [15:38] <Tom[Arch_SB]> We've discovered a few things:
* [15:38] <Tom[Arch_SB]> (1) The Equipment Variable demo just has local vars in Equipment and "Parts" (Equipment Heads in the current code)...
* [15:39] <Tom[Arch_SB]> ...this will quickly need to include other things like Skills, Classes, Spells in order to convert all the BONUS objects
* [15:39] <Tom[Arch_SB]> This is not unexpected, and really with something like 100 ish lines to support a new scope (of those objects anyway - and not counting testing) it's not a huge burden
* [15:40] <Tom[Arch_SB]> (2) The current aggressive solver can be put into an infinite loop. One of the earlier ones would catch loops when modifiers were added, but the current one does not.
* [15:40] <Tom[Arch_SB]> This will need to be resolved... and there are a number of methods to do that, just need to decide which one is best
* [15:41] <Tom[Arch_SB]> It's possible that we prohibit loops altogether (even ones that would not be infinite)...
* [15:41] <Tom[Arch_SB]> I may go that path just to see if we prove that oversimplification fails in the real world, as it is easier to implement and will require less code at runtime
* [15:42] <Tom[Arch_SB]> (3) There is some confusion coming from VAR= being the default value for a variable (whereas something like an AREA (Face) needing to use AREA=Face
* [15:43] <Tom[Arch_SB]> This was a simplification to avoid the extra 4 characters constantly (under the assumption that folks are familiar with vars and thus would think that way unless prompted by something else)
* [15:43] <Tom[Arch_SB]> This should probably go back to the data team to see if they like the optimization or whether it would be easier to just be consistent and add a few characters on every use
* [15:44] <Tom[Arch_SB]> (It also keeps VAR from being special in the code, which wouldn't be bad)
* [15:44] <Tom[Arch_SB]> (4) There are a number of patterns that have already emerged from what Andrew has done. Some of these probably deserve optimization
* [15:44] <Tom[Arch_SB]> One thing we've seen is a lot of SOLVE|value()+...
* [15:45] <Tom[Arch_SB]> another is SOLVE|if(value() compare number,new,value())
* [15:45] <Tom[Arch_SB]> those are the two most frequent so far
* [15:46] <Tom[Arch_SB]> So we may redo how some things work in order to reduce those down
* [15:46] <Tom[Arch_SB]> I'll be looking into what code changes those would require and the impact it would have
* [15:47] *** aap_ has joined #pcgen
* [15:48] <Tom[Arch_SB]> ( 5 ) I think the magnitude of the change is sinking in :D
* [15:48] <Tom[Arch_SB]> Not sure what more to say about that since it's really an impact on the data team. Any comments Andrew?
* [15:48] <@AndrewAAM[Chair]> JEP is very pervasive.
* [15:49] <@AndrewAAM[Chair]> My stance on this project, it's a huge undertaking
* [15:49] <@Zaister> It certainly is
* [15:50] <@AndrewAAM[Chair]> I'd rather we dive in and do it in one fell swoop, then attempt to piecemeal it over time. I say this for the fact that JEP is pervasive and is in every aspect of the program
* [15:50] <@Zaister> Once we've done that, we have replaced both the blade and the handle of grandfather's axe.
* [15:50] <@AndrewAAM[Chair]> The issue is really of so much inter-dependency.
* [15:51] <@AndrewAAM[Chair]> You can't touch one part without affecting another part.
* [15:51] <@Zaister> I'm not sure if piecemeal is even possible
* [15:51] <Tom[Arch_SB]> So this is the balancing act I've been struggling with for a long while
* [15:51] *** aap_ has quit IRC: Ping timeout: 246 seconds
* [15:51] <@AndrewAAM[Chair]> I believe we should involve our community in this decision
* [15:52] <Tom[Arch_SB]> if you do it one token at a time, you end up with a risk of the two systems being permanently present
* [15:52] <Tom[Arch_SB]> if you do it all at once, you end up with a risk of a long time between releases
* [15:52] <Tom[Arch_SB]> there are other risks too, but those are two clear examples at the bookends, so to speak
* [15:53] <Tom[Arch_SB]> @Andrew: Absolutely, this can't be the decision of the folks on IRC right now
* [15:53] <Tom[Arch_SB]> or even the BoD
* [15:53] <@AndrewAAM[Chair]> Yes, I think from a data approach, we should go system by system (Pathfinder, 35e, Killshot, etc.) if we do choose to implement it.
* [15:54] <Tom[Arch_SB]> Any thoughts James?
* [15:55] <James[Code_SB]> Well, I would start with a smaller system than pathfinder first :)
* [15:55] <@Zaister> maybe we should do a new survey about which game mode are actually being used, and by how many
* [15:55] <Tom[Arch_SB]> That's part of why I encouraged Andrew to start with only a handful of classes on Pathfinder as he discovered what it would be like :)
* [15:55] <James[Code_SB]> Maybe take killshot or gaslight?
* [15:56] <@AndrewAAM[Chair]> PF, 35e, 3e, Modern and Darwin's World 2 have been discussed recently by users, so I know those have gotten used.
* [15:56] <@Zaister> Pathfinder is probably the most complex system by now
* [15:56] <@AndrewAAM[Chair]> @Zaister - YES!
* [15:56] <@AndrewAAM[Chair]> If we can conquer Pathfinder, then all the other systems will fall before our blades, erm, bananas!!
* [15:57] <@AndrewAAM[Chair]> Killshot would be the easiest to convert
* [15:57] <@AndrewAAM[Chair]> Also the hardest to test...
* [15:57] <@AndrewAAM[Chair]> since we lack a working OS sheet for it.
* [15:57] <@Zaister> Ah I remember
* [15:57] <@Zaister> I must admit I know nothing about that game
* [15:58] <@AndrewAAM[Chair]> It's various dice pools. I can send you a free pdf.
* [15:58] <Tom[Arch_SB]> I think starting with a smaller game mode is preferable
* [15:58] <@AndrewAAM[Chair]> Agreed, but we have to choose carefully, many are subsystems of a major system
* [15:59] <@AndrewAAM[Chair]> Darwin's World is Modern
* [15:59] <@Zaister> maybe implement a new one as test bed
* [15:59] <@AndrewAAM[Chair]> Gaslight is also based on Modern, but I've isolated it to be self-contained
* [15:59] <@Zaister> D&D 5E is still small :)
* [16:00] <@AndrewAAM[Chair]> Yeah, but no license, but if you want to ask BD to convert his set, I don't think he'd object
* [16:00] <@Zaister> yes the licence thing would be a problem for publication
* [16:02] <@AndrewAAM[Chair]> Deadlands might be a safe test bed
* [16:02] <Tom[Arch_SB]> I think we should do something with an OS
* [16:02] <@Zaister> yes
* [16:02] <@AndrewAAM[Chair]> What would you recommend Tom?
* [16:03] <Tom[Arch_SB]> I'm not sure I know all of what we ship Andrew
* [16:03] <Tom[Arch_SB]> so just nudging and letting you guys choose
* [16:03] <@AndrewAAM[Chair]> (Spycraft is also a safe test) and our demo of fantasy craft is likely the smallest set that would strain our capabilities and be safe as well.
* [16:04] <[OGL]Nylanfs> Shadowrun could be used as a testbed, and released via their forums. :)
* [16:04] <[OGL]Nylanfs> FantasyCraft would probably test the best with the smallest footprint for the data
* [16:04] <[OGL]Nylanfs> Erm what Andrew said.
* [16:04] <@Zaister> It might make sense to use a d20 system as test bed
* [16:05] <@AndrewAAM[Chair]> Fantasycraft is d20-flavored, and smallest footprint we have
* [16:07] <@AndrewAAM[Chair]> Any further thoughts?
* [16:07] <Tom[Arch_SB]> not from me
* [16:08] <James[Code_SB]> none here
* [16:08] <[OGL]Nylanfs> None from me
* [16:08] <@Zaister> no
* [16:08] <Distant_Scholar> When we get to changing Pathfinder, would we have to put a freeze on all other data changes, or is there a way to do them in parallel? I'm concerned about user wait times for bug fixes.
* [16:08] <@AndrewAAM[Chair]> Branches are a wonderful thing. No impact on release materials or hotfixes :)
* [16:09] <Tom[Arch_SB]> Not to mention if PF is done last, there will be a lot of experience in how things convert... and who knows, someone may have built tools to help by then too
* [16:09] <@AndrewAAM[Chair]> We'll be able to work on any system without impacting the official data till a conversion is completed.
* [16:09] <@Zaister> Yes but if you do fixes in the trunk, you have to port them to the dev branch
* [16:10] <@AndrewAAM[Chair]> Yes, that is true... I'll stick around after the meeting to discuss logistics. Thanks for coming everyone! *Bangs gavel*
* [16:10] <James[Code_SB]> Yes I'd expect impacts but presumably the payoff is such that we will get faster updates afterwards
* [16:10] <@Zaister> yes

== After meeting logistics discussion ==
* [16:11] <@AndrewAAM[Chair]> Logistics: Porting data is going to be interesting
* [16:12] <James[Code_SB]> As Tom pointed out we'll have to have a UI that can pick info from both backends too
* [16:13] <James[Code_SB]> Output would also be affected
* [16:13] <@AndrewAAM[Chair]> Looking for ideas and suggestions - Core set has to be converted first to set the ground work and what variables we're using .
* [16:14] <@AndrewAAM[Chair]> James - Would making a new OS folder for the converter sets be easier?
* [16:15] <@AndrewAAM[Chair]> I know the base.xml.ftl can be placed in each gamemode to keep changes for affecting other sets, so we can leverage that, and a different folder to prevent breaking things
* [16:15] <@AndrewAAM[Chair]> by different folder I mean the path we set in the miscinfo.lst file - so it points to the files that are updated.
* [16:16] <James[Code_SB]> Minor detail really
* [16:16] <@AndrewAAM[Chair]> For OS updates, we need to know how to access the new vartypes
* [16:17] <James[Code_SB]> I expect something like that will be necessary as Tom has proposed a new output model to pick up the character info and make it fit better into FreeMarker's object model
* [16:17] <@AndrewAAM[Chair]> I know the FACT/FACTSET has a system built in, but I haven't seen any proposals for OS regarding the Formula Parser yet.
* [16:18] <Tom[Arch_SB]> There are at least two ways to do it
* [16:19] <Tom[Arch_SB]> Global vars will probably just be something like ${var.xyz}
* [16:19] <Tom[Arch_SB]> local may end up with a VISIBLE in the variable file like FACT and FACTSET
* [16:20] <Tom[Arch_SB]> or we could do something like ${ability.var.localvarsuchandsuch}
* [16:20] <Tom[Arch_SB]> (I may be mangling FreeMarker's syntax a bit here, but you get the idea)
* [16:21] <@AndrewAAM[Chair]> Okay, let's go with a big item - Skills
* [16:21] <Tom[Arch_SB]> Actually will require some thinking to ensure namespaces work out ok too
* [16:21] <Tom[Arch_SB]> p.s. 10 minute warning for my departure
* [16:21] <@AndrewAAM[Chair]> Okay
* [16:22] <@AndrewAAM[Chair]> So, we want to output skills, total, rank, stat and bonustotal.
* [16:22] <@AndrewAAM[Chair]> We need a method to loop through the skill objects and grab that value.
* [16:23] <Tom[Arch_SB]> The looping is in FreeMarker
* [16:23] <Tom[Arch_SB]> <#list ${skills} as skill>
* [16:23] <Tom[Arch_SB]> etc
* [16:23] <Tom[Arch_SB]> ends with </#list>
* [16:24] <Tom[Arch_SB]> inside of that, you do:
* [16:24] <Tom[Arch_SB]> ${skill.xyz}
* [16:24] <Tom[Arch_SB]> where xyz might just be the var (e..g. total)
* [16:24] <Tom[Arch_SB]> or it might be var.total
* [16:24] <Tom[Arch_SB]> or something else to be determined
* [16:24] <Tom[Arch_SB]> but it's not a hard problem, given what else we are facing :)
* [16:25] <James[Code_SB]> and we have sensible standard tools to leverage which makes it easier
* [16:25] <Tom[Arch_SB]> I'm just trying to figure out how to work with like 3 parallel branches :)
* [16:25] <James[Code_SB]> :)
* [16:25] <Tom[Arch_SB]> the output shims, FACT/FACTSET, and the formula system
* [16:26] <@AndrewAAM[Chair]> FACT/FACTSET seems like a fairly simple system to install
* [16:26] <Tom[Arch_SB]> requires the shims, actually
* [16:27] <Tom[Arch_SB]> otherwise you can put data in but cant' get it out :)
* [16:27] <Tom[Arch_SB]> so I should probably go focus on the shims first
* [16:27] <@AndrewAAM[Chair]> shims, new terms. :)
* [16:28] <Tom[Arch_SB]> you can ignore it really
* [16:28] <Tom[Arch_SB]> programming slang
* [16:28] <@AndrewAAM[Chair]> yeah, fair enough, already cramming a ton of new information.
* [16:28] <@Zaister> I've looked it up, I hadn't heard it before either
* [16:28] <Tom[Arch_SB]> I'd call it a facade, but facade is like bracket. Depending on who you are talking to, it has a different meaning
* [16:28] <Tom[Arch_SB]> it's slang from construction, the things used to make sure windows and doors are square :)
* [16:29] <@Zaister> It's basically a wrapper around an interface of some kind, right?
* [16:29] <Tom[Arch_SB]> tend to be small, thin pieces of wood
* [16:29] <@AndrewAAM[Chair]> Yup, worked construction.
* [16:29] <Tom[Arch_SB]> so it's a thin layer of code between two things that "speak differently"
* [16:29] <Tom[Arch_SB]> to do the translation
* [16:29] <@AndrewAAM[Chair]> isn't that normally called an interface?
* [16:29] <Tom[Arch_SB]> adapter can be another term but that has other meanings too
* [16:30] <Tom[Arch_SB]> interface is what an object exposes to the world, so it has a specific meaning in programming
* [16:30] <Tom[Arch_SB]> that isn't this
* [16:30] <@Zaister> Yes, adapter is what came to mind, besides that fact that that term is also used for a design pattern that's not quite the same, I think
* [16:30] <Tom[Arch_SB]> ok, I'm turning into a pumpkin
* [16:30] <Tom[Arch_SB]> catch folks later
* [16:30] <@AndrewAAM[Chair]> okay. Night Tom
* [16:30] <@Zaister> bye Tom
* [16:31] <@AndrewAAM[Chair]> Zaister, were you going to be able to set up an OS for killshot? I can send you a link to grab the free sourcebook
* [16:32] <@Zaister> yes that would be nice
* [16:32] <@Zaister> I'm off work until Jan 5th, so I have time available
* [16:34] <@Zaister> "turn into a pumpkin", never heard that before :)
* [16:34] <@AndrewAAM[Chair]> Cinderella term
* [16:34] <@Zaister> Ah
* [16:34] <@AndrewAAM[Chair]> after midnight the items turn back... the carriage turns into a pumpkin
* [16:35] <@Zaister> I remember, yes
* [16:36] <James[Code_SB]> time for me to go also - have a good evening guys
* [16:36] <@AndrewAAM[Chair]> Night James
* [16:36] <@Zaister> bye James
* [16:37] *** James[Code_SB] has left #pcgen
* [16:42] <Distant_Scholar> ... I got nothin' left to say. Talk to y'all later.
* [16:43] <@Zaister> I should get to bed too
* [16:43] <@Zaister> good night!
* [16:44] *** Distant_Scholar has left #pcgen

Meeting 2014 12 19 - Revision history

LegacyKing: Created page with " =Board Meeting= Last meeting of 2014. ==Attendance== * Andrew * Tom * James * Doug * Stefan ==Summary== * 6.04.1 will be released on the 22nd of December - no further dela..."