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

Contents

Board Meeting

Attendance

Summary

Meeting Log

Deep Dive Discussion

After meeting logistics discussion

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Start

Teams

Community

Strategic Development

Misc

Tools