Kar posted an item on the main list about requirements, and I believe we had a
discussion on the old -devel list about this... so this may be a good time &
place to revisit this.

--- In pcgen@yahoogroups.com, "Martijn Verburg" <martijnverburg@...> wrote:
> * PCGen 5.10.0 (and above) needs to run under Java 1.5.x (or above).

At this point, Java 1.5 is going "end of support" in October.

So, what do we do?

Should we step to Java 1.6?  I don't think it makes a lot of difference to the
core, but I know 1.6 has some changes in the UI packages that might make a
difference.

Thoughts?

TP.

I'm going to jump for a moment from the mainly "background on using a Graph"
descriptions that I've been doing (and need to finish) to another discussion
about how to structure the PlayerCharacter.

The reason for this is that I think PlayerCharacter could use some trimming.  It
would also be nice to plan for flexibility in non-d20 (or slightly modified d20)
systems.

The other reason that this is significant is that the Graph structure primarily
serves as a data store (or a data structure if you prefer).  It is not designed
to actually DO the processing, so another set of elements is required to
actually do the Graph analysis.

As some background, we do into a language problem: specifically what to call the
classes that are doing the processing on the PC.  I had been using the term
"subcomponent" (see
http://tech.groups.yahoo.com/group/pcgen_developers/message/52 ), but it has
since been pointed out that's a bad term (because "Component" is an AWT element,
so the term is confusing).  Until we establish a better term, I'm going to use
"facet".  There are other possibilities (e.g. "cog"), so I'm open to suggestion
if anyone has good (or even bad!) ideas...  just try to make sure it isn't
already something we use elsewhere (e.g. aspect would be confusing since we have
a token of the same name)

As far as analysis of the Graph, some of the required analysis is generic (e.g.
"Does the PC have Feat Dodge?" is simply a presence test in the Graph for the
Dodge Feat), and others are more complicated analysis that use other Graph
algorithms.  Eventually, however, there is domain-specific analysis that is
required for PCGen.  It is this domain-specific analysis that we need to
address.

The example I intend to use is the processing of Hands on a PlayerCharacter. 
There are two reasons for this:

First, it's reasonably simple.  The method currently in PlayerCharacter is only
a dozen or so lines long.  Basically the algorithm in the code is: Test the race
for HANDS, then use templates to override that value.

Second, there are things (other than a simple UI output field) that depend on
it.  Specifically, weapon locations are dependent upon the number of hands in a
PlayerCharacter.  We therefore need to define how this information is extracted
by other facets in the system.

I'm going to assert one thing (and there is still some work to do on this detail
of the architecture, but there will be something similar): All of the types of
objects (Race, Deity, Templates, Feats, etc.) have some form of manager which
knows precisely which items are currently applied to the PC.  You can think of
this as either a delegated method back to the Graph (e.g.
getNodesOfType(PCTemplate.class)) or as a facet serving as a caching mechanism
that is monitoring the contents of the Graph to be aware of the active objects
of a given type.

Given that, let's also assume for a moment we have a specialized facet to
calculate the number of hands on a PC.  This facet has the getHands() method on
it.

Some questions for discussion:
1) Can a facet cache?  I think the answer to this is yes: We will want to have
some facets cache, because there are some items that are rather computationally
intensive.  Others (like getHands) may not need to cache.

2) Assuming the facet can cache
2A) Does it store the cache locally?  (Pros: simple caching - local to the
object, easier testing as it doesn't require a working cache, simpler methods
(less incoming arguments), no casting.  Cons: one facet per PlayerCharacter uses
more memory, global clear is hard (and highly prone to error!), components can't
be reused in a web environment).  Open to discussion here, but the Cons are
pretty strong.
2B) If it's a global cache, what is the cache identifier? (This can be the
class, to keep things simple and provide a way for objects to avoid
cross-pollution.  I'm concerned about using Strings because if we do that, there
is a risk of facets from different places using the same identifier, and thus
PCGen would have to do error-checking on all of the loaded facets to avoid that
problem.)  Note that this presumes that the cache only stores 1 object per facet
(and the facet can store any data structure it wants inside of that object). 
This assumption is open to challenge.

3) How does the HandsFacet get connected?  Presumably it needs to know about the
RaceFacet and TemplateFacet.  Presumably this is provided at construction or in
setters or ??.  Thoughts?  (one comment: During construction concerns me because
we may run into circular dependencies)

4) Assuming HandsFacet caches the answer, how does it know when to purge the
cache?
4A) If it's a global cache, it could be globally purged whenever a graph change
takes place (similar to today's setDirty(true) and serial #).  I think a global
reset will cause wasted CPU, so I have a bias against this, but can be convinced
4B) There is a mechanism for a "character updated" message to go out to the
facets (think Observer - like).  This would include a graph revision (similar to
today's serial #)
4C) Fine grained updates, where explicit change messages are transmitted through
a Listener-Event system (or something similar) between the facets.

5) Other.  Really, this isn't cooked.  This got started as a discussion with
James on Spring, and we started to use this as an example since we both have the
same context within PCGen.  It got into enough implementation detail that we
stopped the discussion to ensure everyone can participate.  As a significant
note, I'm not sure Spring actually provides significant benefit to PCGen.  That
is certainly not determined, and if we seriously evaluate that path, we need to
make sure we demonstrate concrete benefit from it since it does take size and
may control design of the code.  I'm open to other frameworks as well, but IMHO
they are held to the same standard of demonstrating concrete benefit.

I think there are two ways forward here: First, we can discuss on the list. 
Then I think we should get together on IRC.  I'd suggest Fri Aug 14 6 PM EDT for
that discussion (gives people time to plan and is a time that James and I both
theoretically are available [real time subject to James checking his calendar!])

TP.

I say we go for it, it certainly has some UI improvements that would assist
Connor in his UI overhaul efforts.

K

> Kar posted an item on the main list about requirements, and I believe we had a
discussion on the old -devel list about this... so this may be a good time &
place to revisit this.
>
> --- In pcgen@yahoogroups.com, "Martijn Verburg" <martijnverburg@> wrote:
> > * PCGen 5.10.0 (and above) needs to run under Java 1.5.x (or above).
>
> At this point, Java 1.5 is going "end of support" in October.
>
> So, what do we do?
>
> Should we step to Java 1.6?  I don't think it makes a lot of difference to the
core, but I know 1.6 has some changes in the UI packages that might make a
difference.
>
> Thoughts?
>
> TP.
>

I seem to recall the biggest pinch point being on the Mac side.  I'm unsure when
they stepped up to 1.6, but if it was too recently, it could leave lots of folks
"out in the cold"

TP.

--- In pcgen_developers@yahoogroups.com, "Martijn Verburg" <martijnverburg@...>
wrote:
>
> I say we go for it, it certainly has some UI improvements that would assist
Connor in his UI overhaul efforts.
>
> K

Hi Folks!

Mac OSX 10.5 added Java 1.6 while 10.4 is limited to 1.5.

Maredudd

Tom wrote:
>
> I seem to recall the biggest pinch point being on the Mac side.  I'm unsure
when they stepped up to 1.6, but if it was too recently, it could leave lots of
folks "out in the cold"
>
> TP.
>
> --- In pcgen_developers@yahoogroups.com, "Martijn Verburg" <martijnverburg@>
wrote:
> >
> > I say we go for it, it certainly has some UI improvements that would assist
Connor in his UI overhaul efforts.
> >
> > K
>

Hi all,

Finally getting to commenting on all of the various architecture threads again,
here's the first one (and the easiest!).

> It's not 100% done, but you can see the state here:
>
http://www.pcgen-test.org/wiki/index.php?title=Architecture_Changes_5.17#Elimina\
te_Cloning

Great to be able to track this, I've got it bookmarked :)

>> Are the performance benefits primarily going to be realised simply
>> because we're no longer doing expensive cloning or are there other
>> advantages we can eek out because we will no longer be cloning?
>
> The literal cloning CPU effort is probably a small fraction of the
> performance issue.  It's the side effects of cloning that are
> painful.  In a clone environment, comparisons can't be instance
> equality (==), but must be string comparison on key... but you may
> not have the key to start, so you have to request the key (or
> abbreviation for a stat).  So even in trivial comparisons we can
> reduce:
>
> stat1.getAbbreviation().equalsIgnoreCase(stat2.getAbbreviation());
> to
> stat1.equals(stat2);
>
> Note that .equals() in this case for PCStat may have been reduced
> from a deep equals (that has to test values in the PCStat) to
> simply an instance equality (because no cloning means they are
> effectively type safe, thus can test solely on ==).  Thus for that
> equality test we're probably seeing 2 or 3 orders of magnitude of
> speed increase.  It's small savings each time, but keep in mind we
> do these tests thousands of times with every change to a PC.
>
> A concrete example is to look at PCStat objects (PCStats are
> Ability scores, things like STR, INT, WIS).  The cloning was
> literally removed in SVN 9690, but then SVN 9884-6, 9888-90,
> 9893-5, 9897, 9899, 9900 were all additional changes that removed
> behavior  required when a clone was present but wasteful when no
> cloning takes place.
>
> The removal of list searches, String comparisons, etc. provides
> improvement.  This is why I've been making the point that so much
> of the performance issue is dependent on other issues (and why I
> wanted to break the String dependencies between the LST files and
> the core).  We had to break the cloning behavior in order to be
> able to get to this point.  IMHO anyway.

OK, I understand this more clearly now, thanks for the explanation.

> We will need some examples for the "thought cases"/"counter-cases"
> that drive us to the current design, so, yes, some will need to be
> done.

OK, I see you have this in your
http://www.pcgen-test.org/wiki/index.php?title=Tom%27s_Arch_%22TO_DO%22_List
(which covers the other points raised in this discussion as well)

>> Perhaps a link to a basic graph theory explanation/tutorial/paper
>>/whatever on the web (even something like a Wikipedia article if
>>it's not too complex).
>
> Wikipedia http://en.wikipedia.org/wiki/Graph_(mathematics) and
> http://en.wikipedia.org/wiki/Graph_theory are both pretty good, as
> is this:
> http://www.boost.org/doc/libs/1_39_0/libs/graph/doc/graph_theory_review.html
>
> Note that PCGen will at least be using a directed graph (since we
> have objects granting other objects).  Some other items from the
> Graph page also come into play (likely a weighted graph as well)
>
> At some level, I need to concede that a good computer science
> education cannot be undervalued.  Reading something like
> "Introduction to Algorithms" or "The Algorithm Design Manual" might
> be a substitute if the individual in question learns enough by
> reading.  Then again, we don't really need a large subset of graph
> theory (one can stop after graph searches), so a bit of delving on
> Wikipedia and reading some related articles (depth first search,
> breadth first search, Dijkstra's algorithm) is probably sufficient.

OK, I've posted this onto the wiki under
http://www.pcgen-test.org/wiki/index.php?title=Graph_Theory#Graph_Theory_and_PCG\
en and linked to it from Architecture and Code Team pages.

>> I haven't dived into the code around this area very much either,
>> but to have a commented sample of how to ties two nodes together
>> with a relationship on the wiki would be very useful.
>
> Your request is data structure dependent. We're not there yet :)

Fair enough!

K

I'll post a poll to see how many 10.4 users there are.

K

> Hi Folks!
>
> Mac OSX 10.5 added Java 1.6 while 10.4 is limited to 1.5.
>
> Maredudd
>
> Tom wrote:
> >
> > I seem to recall the biggest pinch point being on the Mac side.  I'm unsure
when they stepped up to 1.6, but if it was too recently, it could leave lots of
folks "out in the cold"
> >
> > TP.
> >
> > --- In pcgen_developers@yahoogroups.com, "Martijn Verburg" <martijnverburg@>
wrote:
> > >
> > > I say we go for it, it certainly has some UI improvements that would
assist Connor in his UI overhaul efforts.
> > >
> > > K
> >
>

Hi Tom,

<snip>

> There is a lot of work to do in the Rules Persistence System, and
> some of this would be great work for a new programmer to PCGen:
>
> (1) There are a series of line-based files that are capable of
> unparse, but the overall wrapper system in the converter is not
> capable of unparsing a Kit file.
> Specifically, if one looks at the converter, you can see code in
> pcgen.gui.converter.LstConverter.java:
> 	 loaders.add(new CopyLoader(ListKey.LICENSE_FILE));
> 	 loaders.add(new CopyLoader(ListKey.FILE_KIT));
> 	 loaders.add(new CopyLoader(ListKey.FILE_BIO_SET));
> 	 loaders.add(new CopyLoader(ListKey.FILE_PCC));
> All 5 of these files types are just copied without PCGen parsing
> the contents.  Longer term this limits our ability to convert this
> information.  While this isn't a problem for the license files
> (that should stay copy), the Kit and BioSet files are particular
> concerns for me in things we may want to convert in the next
> version or two.  This involves developing a coverter system that is
> smart enough to queue a group of lines together for these file
> types before writing them back out.
>
> (2) In the same pcgen.gui.converter.LstConverter.java file, there
> is also:
> 	 loaders.add(new CopyLoader(ListKey.FILE_ABILITY_CATEGORY));
> This has a conversion problem as well, but Ability Category is
> token based.  The problem is that the ability category tokens (in
> plugin.lsttokens.gamemode.abilitycategory) are "old style" tokens
> that only have a parse and getTokenName method.  This contrasts
> with "new style" tokens that have an unparse (and a few other)
> methods.  A good project here is to do two things: Convert
> pcgen.persistence.lst.AbilityCategoryLoader.java to handle "new
> style tokens" and then to convert the tokens that implement
> AbilityCategoryLstToken into tokens that implement
> CDOMPrimaryToken<AbilityCategory>.  For a Loader that bridges the
> old (map) and new (context.parse) methods, you can look at the 5.16
> version of PCStatLoader.java (
http://pcgen.svn.sourceforge.net/viewvc/pcgen/branches/5.16.x/pcgen/code/src/jav\
a/pcgen/persistence/lst/PCStatLoader.java?revision=9635&view=markup ) and
compare that
> to the 5.14 version (which will have only the old style) or the
> Trunk version (which has only the new style).  Using this bridge
> method, only one token has to be converted at a time, so it can be
> gradual and a lot less pressure on the developer.
>
> (3) Cross-token validity is not evaluated. In particular,
> structures like this:
> MyObject <tab> TOKEN:Foo <tab> TOKEN:.CLEAR
> ...are not currently detected by PCGen. This is a weakness of the
> existing Token/Loader system. A reasonably simple solution to this
> problem exists. Currently the Load system has the tokens feed a
> single Tracking strategy which commits to a final Tracking (Editor)
> or Consolidated (Runtime) strategy. The solution to this problem is
> to have a Token-Tracking Strategy commit to a Line-Tracking
> Strategy, which commits to a final Tracking (Editor) or
> Consolidated (Runtime) strategy. The only additional code required
> is a set of detection methods for the (Line-)Tracking strategy to
> identify when non-sensical situations (.CLEAR after addition)
> occur.
>
> (4) Currently, the StringKey clearing system is not handled well.
> It is possible (likely?) that the globalClearSet map should be
> expanded to hold ANY of the *Key objects used in CDOMObject,
> including IntegerKey, StringKey, etc. rather than just ListKey.
>
> (5) There are a bunch of tokens where some simple additional
> features would be helpful.  Some of these are easy to get started
> on, and there are quite a few of them.  One example is support for
> .CLEAR for the TARGETAREA token (FREQ 2413630).  This is an
> isolated change that requires changing only one class, and there
> are other tokens with the features to show you what needs to be
> changed - so another good startup experience here.

Do we have a FREQs for these 5 already (The last one partially yes)?  I had a
quick scan through but couldn't find them.  I'm happy to make them if required.

> If anyone is interested in any of those, I'm happy to help people
> get started.  The Rules Persistence System is some of the newer
> code, and (hopefully at least) somewhat cleaner code, so this is
> probably a good place for new folks to get started.
>
> Those are bigger projects I can easily identify.  There are also
> cleanup projects (reducing code warnings, refactoring support) that
> also exist.  I'm not highlighting those, as they are likely to be
> less interesting.  If some of the new devs are just getting started
> with Java, those may be better options for getting familiar with
> the language and with the project, so I'm happy to point projects
> like that out as well (as can James, the code lead).

So developers!!  Do we have any volunteers for some of these items?  As Tom
points out there are some really small ones that can help get you familiar with
Java itself and/or the PCGen code base.

We currently have 38 members on this list and while I know not all are Java
developers I'm sure we've got a few new ones out there, please don't hesitate to
get in touch!

We can definitely even meet you on IRC to help walk you through some code
changes.

K

That's correct Tom. The situation sucks but Apple has tied it's Java
implementation to the OS so that the latest OS is needed to run the
latest Java version. The current OS, 10.5 is required to run Java 6. The
last OS, 10.4 (Tiger) is stuck with Java 5 and 10.3 can only run Java 4.
To compound the situation 10.5 will not run on older Macs like G4s,
although to be honest running PCGen on an 8 year old G4 is sometimes
like riding a dead horse, if you beat it hard enough it might move
(exaggerated for humor).

In my personal opinion if the code team feels Java 6 offers worthy
improvements we should move ahead.

Tom Parker wrote:
> I seem to recall the biggest pinch point being on the Mac side.  I'm unsure
when they stepped up to 1.6, but if it was too recently, it could leave lots of
folks "out in the cold"
>
> TP.
>
> --- In pcgen_developers@yahoogroups.com, "Martijn Verburg"
<martijnverburg@...> wrote:
>
>> I say we go for it, it certainly has some UI improvements that would assist
Connor in his UI overhaul efforts.
>>
>> K
>>
--
~ Eddy Anthony (MoSaT)
~ PCGen Board of Directors
~ Content Silverback, Chair Second

Hi Folks!

Pardon me for saying so but the poll as worded is insufficient. I do not use
10.4 exclusively but I do have a machine, my primary machine in fact, that is
not capable of running 10.5.

Maredudd

-----Original Message-----
From: Martijn Verburg [mailto:martijnverburg@...]
Sent: Tuesday, July 21, 2009 10:35 AM
To: pcgen_developers@yahoogroups.com
Subject: [pcgen_developers] Re: [From PCGen List] Java Version for PCGen

I'll post a poll to see how many 10.4 users there are.K>

Hi Folks!

Eddy wrote:
>
> That's correct Tom. The situation sucks but Apple has tied it's Java
> implementation to the OS so that the latest OS is needed to run the
> latest Java version. The current OS, 10.5 is required to run Java 6. The
> last OS, 10.4 (Tiger) is stuck with Java 5 and 10.3 can only run Java 4.
> To compound the situation 10.5 will not run on older Macs like G4s,

Yep. Thats the situation I'm in. My primary machine is a Mac Mini
running a 1.43 GHz G4. Its a bit faster than riding a dead horse
though . . . quite a bit . . . :-)

> although to be honest running PCGen on an 8 year old G4 is sometimes
> like riding a dead horse, if you beat it hard enough it might move
> (exaggerated for humor).
>
> In my personal opinion if the code team feels Java 6 offers worthy
> improvements we should move ahead.
>

I do have two G5 boxes but one os set up as my multimedia machine
and the other has significant reliability problems and I'm not ready to
move to if for my day-to-day activities. And I'm not in a position to
buy a new Intel Mac . . . though later this year I do plan on hacking
my Acer Netbook and installing Mac OSX on it . . . :-)

Maredudd

Hi Tom,

> Kar asked a bit ago about using the Graph implementation, but I
> mentioned that was premature.  In this, err, chapter ;) I'm going
> to walk through some of the reasoning behind the graph structure we
> have and some background on the proposal we currently have.  This
> basically sets up requirements.  I'll walk through a series of
> thought cases as we go along, and later I'll address specific usage.

Who is this Kar person who keeps causing trouble like this, ban them from the
project I say! ;p

> In particular, this note refers to the Character Data Store.  This
> is how a PlayerCharacter is stored in the memory of PCGen during
> runtime.  It is effectively a database of sorts, with the primary
> purpose being data storage (vs. behavioral code).  At some point,
> it is a reasonable discussion to have whether we should be using a
> database for this function or whether it is better served by
> objects (not to say those are mutually exclusive, given Hibernate
> and similar object-relational mapping technologies).

I was just about to ask about that, it seems that small lightweight DBs are
being used in this fashion, but as you say a discussion for another (much later)
day.

> One other note on terminology: You will see me refer to
> "PObjects".  PObject is currently a parent class of things like
> Feats, Skills, and Templates.  This is therefore a "catch all" name
> for "things that can be given to a PlayerCharacter".  Much of the
> original structure of PObject has been removed and consolidated to
> PObject's new parent class, CDOMObject.  Eventually PObject will be
> removed, but for the moment, much of what we have written and the
> historical naming is "PObject", so I will continue to use that name
> for now.

OK, I long to see the day where PObject dies (a noble death after its long
service, but a death all the same).

> I've already observed that the associations between objects is not
> a pure tree, but rather a mathematical graph.  There can be
> multiple associations to a given PObject. For example, a Template
> and a piece of Equipment could grant a particular Skill.
>
> From the perspective of usage, There are common, but mathematically
> sparse associations between PObjects. (The ratio of associations
> between implemented PObjects to implemented PObjects to is well
> below 2:1). This is relevant to how associations are stored; while
> it is a valid way to store associations in a very dense group, for
> our purposes, it is not efficient to an array of BitSet to indicate
> the object association. . . ick!
>
> At a high level, graphs generally contain nodes and edges. The
> edges provide connections between the nodes. In the proposed
> structure, the PObjects will be nodes.  Each PObject will contain
> the static information (information that is universal across all
> usages of that object, such as the Dexterity Prerequisite for the
> Dodge Feat) that is associated with that particular PObject.
> Dynamic information (that which is particular to a PlayerCharacter,
> such as the value of an ability score) is stored within an edge.

OK, I get that.

> Each Node is completely ignorant about what it is connected to.
> Each edge will contain the source Node and sink Node to which it is
> connected. A master PCGenGraph object stores the list of Nodes and
> Edges in the Graph, and can be queried to
> getAdjacentEdgesToNode(Node n). This design is appropriate for a
> sparse graph, and produces a directed, acyclic graph of classes
> (which is a good design principle).  Since the base design only
> stores information in one place, there are no risks of putting the
> graph into an invalid state (from a structural perspective - from a
> role playing rules perspective, we still have to prove that
> principle).  There are some abilities to cache information (such as
> the Node to Edge relationships) with an implementation of the Graph
> for boosted performance, while maintaining any duplication within a
> single class (avoiding contracts on the programmer and ensuring
> that the graph avoids an invalid state).  Currently, the Graph
> classes are much like the basic Collections classes and are not
> designed to be used in a multi-threaded environment.

OK...

> As we develop the characteristics of the graph, we need to look at
> some of the reasons why we are moving our data structure.  Note
> that unlike the Rules Persistence System code (which was integrated
> into PCGen 5.16 and is in the Trunk), the graph code can only be
> found in an experimental branch.  If you check out branches/cdom
> from our code repository, the packages are pcgen.base.graph.*
>
> One of these is performance.  Currently, the recursive nature of
> addition (A adds B, B adds C, C adds D) can get very tricky to keep
> correct when the addition process for different object types is a #
> different method (recursive loops are painful).  This can be done
> with a "graft" ob objects from the rules data store into the
> character data store.  There is also a strong desire to have a
> single processing method for adding objects to a PlayerCharacter,
> vs. separate methods that depend on the type of PObject being
> processed.
>
> Second, some significant functions that need to be able to trace
> the source of an object.  Therefore, the graph must track how a
> particular PObject came to be associated with the PlayerCharacter.
> (e.g. Chose Combat Reflexes as a feat at third level and Weapon
> Focus (Dagger) as a first level fighter bonus feat.)

Makes sense, this is important for if a character loses something which gave
him/her the ability to do something else.

> Third, it would be nice to avoid clutter.  Certain Edges will
> provide the ability to have a `weight' so that an object which
> provides multiple levels of a Skill can avoid multiple edges
> connecting the same PObjects (in addition to cluttering the graph,
> multiple identical edges create identity/equality risk and make
> identification and removal of edges more difficult).

So a +skill edge could give +1, +3, +5 etc over its 'lifetime' as opposed to
having 3 separate +skill edges of +1, +3 and +5?

> As a note, while we have a graph, there are consequences to using
> the concept of hyperedges and having more than one source node in
> an edge.  One specific counter-case is: How do you manage skill
> rank?
> Foo1 grants Knowledge (Arcana) Rank 2
> and
> Foo2 grants Knowledge (Arcana) Rank 1
> ...So the PC has rank 3... With only one edge leading into the
> single reference to the Knowledge (Arcana) skill, how do you
> distinguish that one source has "weight" 2 and one "weight" 1?
> (This assumes that the weight, as PC specific information, must be
> in the edge.  Combining these two rank grants into one edge may
> result in another map in (or from) the edge to measure source
> weight or some other external method of storing rank that results
> in either contract issues (programmer has to do 2 things to
> maintain consistent state) or more complex data structures than
> simply a system that uses two separate edges.

OK ignore my previous bit as a question.

> So in summary, the Character Data Store needs to:
> (A) Store items granted to the PC (such as a Feat)
> (B) Store items available to the PC (such as a starting language
> list)
> (C) Quickly answer "does the character have X" queries
> (D) Not confuse availability with granting
> (E) Track the source of every grant and availability
> (F) Be able to cleanly handle MULT:NO v. MULT:YES
> (G) Track exact sources (there are some nasty cases I will draw out
> later)
> (H) Handle removal of one MULT:NO parent while another is present
> to maintain the state (such as a user selection of a CHOOSE)
> (I) Appropriately store a CHOOSE result so it can be reused by
> other tokens/objects (so it has to be stored in a predictable
> location)
> (J) Replicate behavior from the existing tokens in PCGen 5.16.
> (K) It should also avoid making the assumption that it's a d20
> system.  Assume it needs to handle Rolemaster & Serenity if you're
> looking for particular challenges.
> (L) Handle undo/redo.
>
> We can also set up some structural rules...
>
> (1) It must be a directed acyclic graph, with no cycles in the
> code.  (And the use of an interface solely to break a cycle is
> sometimes, but not always indicative of a structural problem)
> (2) When a developer makes a code modification, the developer
> should not be forced to make a matching modification in another
> location in the code in order to maintain a valid structure (no
> contracts, as I would call them)
> (3) When a change is made to the internal data structure, a
> significant amount of "reorganization" to ensure a valid data
> structure should not be necessary (if you're incrementing through
> everything, then that's not good)
> (4) It should be fully unit testable, without major dependencies on
> other objects. (some will be expected)
> (5) It should have as simple of an interface as reasonably possible
> (if you're beyond 20 methods, you probably have a problem)
> (6) It will not expose its internal state to external modification
> other than through direct method calls.
> (7) You must not consume any errors (no catch Throwable or anything
> like that)
> (8) It should not produce side effects - methods do one thing.  No
> surprises for the uninitiated.
> (9) It should be a class that does one thing.
> (10) You must assume CDOMObjects are not cloneable.
> (11) It should minimize special cases.
> (12) It should have no knowledge of the UI
> (13) It should minimize the number of mental models another
> programmer needs to learn (see 11)
> (14) It should be built with as few classes as reasonably possible
> (but not at the expense of clarity or requirement (9) above.)
> (15)  Pools (e.g. skill points) must be stored in something that
> can be recalculated from a known good source.  Simply a numerical
> map that developers are trusted to update correctly is not
> appropriate.  We have demonstrated the challenges of that model in
> 5.x.
> (16) Known patterns / data structures should be used when
> appropriate (see 13)
> Recommendation: Type Safety is good
>
> This is a setup of requirements for the system.  Feel free to add
> to the list if you think I've missed anything.  I probably have.
> I'm going to refer back to these as I go through further
> explanations.  There are specific requirements that are drawn from
> certain thought cases, and some details of the implementation that
> are driven by such situations.  There are still some unresolved
> issues as well (and some nuances that we could use some elegant
> solutions for to avoid brute force fixes)

That's a pretty darn comprehensive list!

Is this list on the wiki somewhere?  I couldn't find it if it is :).  If it's
not then I'm happy to drop it in where you prefer!

K

--- In pcgen_developers@yahoogroups.com, "Martijn Verburg" <martijnverburg@...>
wrote:
> Do we have a FREQs for these 5 already (The last one partially yes)?

The last one is really a handful (or more) of FREQs, all of which exist.  If
someone is interested, I'm happy to read through and find them all.

> I had a quick scan through but couldn't find them.  I'm happy to make them if
required.

I don't think the other 4 are existing FREQs.

TP.

--- In pcgen_developers@yahoogroups.com, "Martijn Verburg" <martijnverburg@...>
wrote:
> [description of and question on edge weights]

Actually, let's walk through it because it may not be completely clear.

If a Skill (let's call it Hide) is granted by Ability Foo and Ability Bar, Hide
will have 2 incoming edges.  This is true even if Foo grants two ranks.

The alternative (if edges couldn't have weight) would be for Hide to have 3
incoming edges, two from Foo and one from Bar.  I find this to be "cluttered",
especially if Foo granted 10 ranks... that leaves a lot of graph traversing for
items which could care less about "weight".  Using weight as an attribute on the
edge allows only those items that really care about weight to do the necessary
processing to extract the value from the edge.

> > So in summary, the Character Data Store needs to:
> > [snip]
>
> That's a pretty darn comprehensive list!
>
> Is this list on the wiki somewhere?  I couldn't find it if it is :).  If it's
not then I'm happy to drop it in where you prefer!

Don't think it is, no.

TP.

Hi,

Has anyone had any experience with Launch4j? http://launch4j.sourceforge.net

I ask as it was suggested as an option for getting a memory setting
into an easy to run format and avoid the bat file. It seems that some
users on Vista are having a tough time getting PCGen to run. See
https://sourceforge.net/tracker/?func=detail&atid=384720&aid=2823722&group_id=25\
576
for an example

--
Cheers,
James Dempsey
PCGen Code SB

New question posted and poll deleted. - K

Hi all,

Well with 5.16.1 about to be released and the work done between code and data to
reconcile dependent trackers we now can sit down and discuss the Roadmap for
PCGen.

It's been decided to have a 6.0.0 release (as opposed to 5.18.0) in order to
start with a clean slate (versioning wise).  We can then follow the rules of
major.minor.patch more appropriately from here on in.

So to kick this off I've listed a bunch of team sections at
http://www.pcgen-test.org/wiki/index.php?title=Release_6.0.x for the various
teams to put in broad areas of what they would like to tackle for a 6.0.0
release.  Some architecture and code items are already *provisionally* (e.g. 
Still up for discussion) in there.

So users, team members, everybody!  Please use the
http://tech.groups.yahoo.com/group/pcgen_experimental mailing list to discuss
additions, edits and deletions for the Roadmap, we'll update the wiki page
accordingly until we're done!

K

James Dempsey wrote:
>
>
>  Hi,
>
>  Has anyone had any experience with Launch4j?
>  http://launch4j.sourceforge.net <http://launch4j.sourceforge.net>
>
>  I ask as it was suggested as an option for getting a memory setting
>  into an easy to run format and avoid the bat file. It seems that some
>  users on Vista are having a tough time getting PCGen to run. See
>
https://sourceforge.net/tracker/?func=detail&atid=384720&aid=2823722&group_id=25\
576
>
<https://sourceforge.net/tracker/?func=detail&atid=384720&aid=2823722&group_id=2\
5576>
>  for an example

James, that looks very promising. I think we should definitely give it a
spin.
>
>  -- Cheers, James Dempsey PCGen Code SB
>
>   <!-- #ygrp-mkp{ border: 1px solid #d8d8d8; font-family:
>  Arial; margin: 14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border:
>  1px solid #d8d8d8; } #ygrp-mkp #hd{ color: #628c2a; font-size: 85%;
>  font-weight: bold; line-height: 122%; margin: 10px 0px; } #ygrp-mkp
>  #ads{ margin-bottom: 10px; } #ygrp-mkp .ad{ padding: 0 0; } #ygrp-mkp
>  .ad a{ color: #0000ff; text-decoration: none; } --> <!--
>  #ygrp-sponsor #ygrp-lc{ font-family: Arial; } #ygrp-sponsor #ygrp-lc
>  #hd{ margin: 10px 0px; font-weight: bold; font-size: 78%;
>  line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{ margin-bottom: 10px;
>  padding: 0 0; } --> <!-- #ygrp-mlmsg {font-size:13px; font-family:
>  arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
>  #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
>  input, textarea {font:99% arial,helvetica,clean,sans-serif;}
>  #ygrp-mlmsg pre, code {font:115% monospace;*font-size:100%;}
>  #ygrp-mlmsg * {line-height:1.22em;} #ygrp-text{ font-family: Georgia;
>  } #ygrp-text p{ margin: 0 0 1em 0; } dd.last p a { font-family:
>  Verdana; font-weight: bold; } #ygrp-vitnav{ padding-top: 10px;
>  font-family: Verdana; font-size: 77%; margin: 0; } #ygrp-vitnav a{
>  padding: 0 1px; } #ygrp-mlmsg #logo{ padding-bottom: 10px; }
>  #ygrp-reco { margin-bottom: 20px; padding: 0px; } #ygrp-reco
>  #reco-head { font-weight: bold; color: #ff7900; } #reco-category{
>  font-size: 77%; } #reco-desc{ font-size: 77%; } #ygrp-vital a{
>  text-decoration: none; } #ygrp-vital a:hover{ text-decoration:
>  underline; } #ygrp-sponsor #ov ul{ padding: 0 0 0 8px; margin: 0; }
>  #ygrp-sponsor #ov li{ list-style-type: square; padding: 6px 0;
>  font-size: 77%; } #ygrp-sponsor #ov li a{ text-decoration: none;
>  font-size: 130%; } #ygrp-sponsor #nc{ background-color: #eee;
>  margin-bottom: 20px; padding: 0 8px; } #ygrp-sponsor .ad{ padding:
>  8px 0; } #ygrp-sponsor .ad #hd1{ font-family: Arial; font-weight:
>  bold; color: #628c2a; font-size: 100%; line-height: 122%; }
>  #ygrp-sponsor .ad a{ text-decoration: none; } #ygrp-sponsor .ad
>  a:hover{ text-decoration: underline; } #ygrp-sponsor .ad p{ margin:
>  0; font-weight: normal; color: #000000; } o{font-size: 0; }
>  .MsoNormal{ margin: 0 0 0 0; } #ygrp-text tt{ font-size: 120%; }
>  blockquote{margin: 0 0 0 4px;} .replbq{margin:4} dd.last p span {
>  margin-right: 10px; font-family: Verdana; font-weight: bold; }
>  dd.last p span.yshortcuts { margin-right: 0; } div.photo-title a,
>  div.photo-title a:active, div.photo-title a:hover, div.photo-title
>  a:visited { text-decoration: none; } div.file-title a, div.file-title
>  a:active, div.file-title a:hover, div.file-title a:visited {
>  text-decoration: none; } #ygrp-msg p#attach-count { clear: both;
>  padding: 15px 0 3px 0; overflow: hidden; } #ygrp-msg p#attach-count
>  span { color: #1E66AE; font-weight: bold; } div#ygrp-mlmsg #ygrp-msg
>  p a span.yshortcuts { font-family: Verdana; font-size: 10px;
>  font-weight: normal; } #ygrp-msg p a { font-family: Verdana; }
>  #ygrp-mlmsg a { color: #1E66AE; } div.attach-table div div a {
>  text-decoration: none; } div.attach-table { width: 400px; } -->

--

Andrew Maitland (LegacyKing)
Admin Silverback, PCGen Board of Directors
Data Chimp, Docs Tamarin
Unique Title "Quick-Silverback Tracker Monkey"

Hi Tom,

I'm still catching up with all of these Arch posts, so apologies if the
commentary is coming in late!

> I'm going to jump around in the architecture discussion so as to
> give folks some places to go work on code if they so choose.  In
> this case, I'm working under the assertion that we aren't going to
> do a rip and repair with the graph model being discussed elsewhere
> - we need an interim model that has more of the features of the
> graph model, but starts to leverage common code.  Note that this
> doesn't mean the interim model will survive to the next major
> release, but it is a set of smaller steps in which to do the code
> transition.

OK, seems sensible - I think we need to have this declared in the Roadmap, so
that everyone is aware of this, thoughts?

> In this discussion, I am going to assume that we have a set of
> subcomponents within PlayerCharacter that manage specific types of
> objects.  There is a "language subcomponent", "skill subcomponent",
> etc.  For now, these are not actually separate classes, but they
> could be in the interim model.  That's probably valuable, as it
> will help to reduce the size of PlayerCharacter (which is over
> 18000 lines).
>
> What are the characteristics of these subcomponents?
> - They store the information about what a PC has and provide that
> list to other components
> - They allow addition and removal of those objects
>
> I will assume this means a small set of methods:
> getXList (returns a List of X objects - NOTE this is value-
> semantic, so that modification of this list does NOT modify the
> PlayerCharacter!!!  Must use addX or removeX to modify the PC)
> addX (adds a single X object)
> addXs (add a List of X objects)
> removeX (removes a single X object)
> getAssociationsForX (returns associations on a specific X object)
> ...where X is the type of object
>
> I'm going to look at Languages first.  There are a few reasons this
> is a good place to start.  First is that languages are reasonably
> simple, in that they cannot grant other objects (in the current
> version of PCGen).  Second, there are some good characteristics in
> the language system that can demonstrate how features need to
> transition to be stored in a graph.  Third, there are a number of
> methods for accessing the current language list that can be inlined
> in a new system.
>
> I'm going to number the subprojects, in case anyone wants to pick
> up this set of work...

I'd like to Tracker all of this, would you prefer it under Freqs or under
Release Steps?  I'd like to actually tackle this one myself although I wouldn't
be able to start until September, however if someone else wants to take it
please do yell out!

> <snip details>

> That gives a view of some fixes for Language objects, which starts
> to build a foundation for how CDOMObjects will be stored within the
> new core.  If someone is interested in working this, please chime
> in, and I'll be happy to guide through the steps if they are
> unclear.

That was a very useful guide Tom, are there any other developers that would like
to tackle this?  If not I can start working on it in September, it's been way
too long since I coded on this project, might as well start learning the CDOM
stuff this way.

K

Hi Tom,

> Starting from the perspective of a Graph holding the contents of a
> PlayerCharacter, we can take a look at a simple graph of a
> PlayerCharacter:
> http://www.pcgen-test.org/wiki/images/f/f9/Graph_starter.png

Yay!  Pictures for meeeeee!  Err, sorry about that.

> Note that this ignores some complexities for the moment, but note a
> few things:
> (1) The graph is directed (the edges have direction)
> (2) There is a root object for the PlayerCharacter
>
> When referring to objects in the graph, I will often refer to
> "parent" and "child" objects in the graph.  Given the depiction of
> the graph above, the parent of Feat_Dodge is CharacterRoot (and
> Feat_Dodge is one of three children of CharacterRoot).
>
> A reminder that structural rules & requirements can be found in
> this message: http://tech.groups.yahoo.com/group/pcgen_developers
> /message/51
>
> One other point of background: All Nodes in the graph will extend
> PrereqObject.  In this way, the graph knows that each item can be
> tested for prerequisites, yet all objects don't inherit the
> overhead of PObject or CDOMObject.

PrereqObject being a very light weight Abstract Base Class right?

> Now the simple model shown above has some cases that exist in
> (R)SRD rules systems that require some clarification, which I will
> start to work through here:
>
> Issue #1: There can be group references.
>
> This issue originates in situations where entire groups of objects
> can be granted to a PlayerCharacter all at once.  For example, one
> might have:
> ABILITY:FEAT|AUTOMATIC|TYPE=SpecialType
>
> This must be resolved by making each item which is part of a group
> be a child of that group.  So that subgraph would look like:
> http://www.pcgen-test.org/wiki/images/b/b7/Graph_group.png
>
> And when attached to a PlayerCharacter, it would look like:
> http://www.pcgen-test.org/wiki/images/a/a9/Graph_with_group.png

Cool

> Issue #2: Some items fit into "slots"
>
> When a character advances to a certain level, they receive specific
> Skills, Feats, or other items.
>
> One possibility would be to have hyperedges having a source and no
> sink.  I think this adds unnecessary complexity to the graph, and
> it is cleaner to always have edges that are one source and one
> sink.  Thus, the working model is for Slots to be stand-alone
> PrereqObjects that know what type of object they are allowed to
> "acquire" as a child.
>
> Our PlayerCharacter now looks like:
> http://www.pcgen-test.org/wiki/images/3/3c/Graph_with_slots.png

Makes sense...

> Issue #3: The same item may be referenced multiple times by the
> same parent
>
> It should be noted that there are specific situations that force
> the PCGenGraph to be an identitybased Graph (at least for the
> edges). Consider one example: If ADD:FEAT|2|ANY were to be
> used, then the PlayerCharacter could select the same Feat twice (if
> the Feat was MULT:YES).
>
> Management of edge weights in this situation would be tricky.
> There are other cases
> where the edge weights can be based on a formula, not an Integer,
> and it also requires delving into each of the edges and modifying
> those edges to have the correct weight.  This requires code to
> constantly process "if resultingweight == 0 then allow removal, but
> if resultingweight != 0 then set the weight".  This is extremely
> hard to get correct (there have been a few different bugs in the
> equipment code that thinks in edge weights like this).  I assert it
> is better to have separate edges (even though this proliferates
> edge count) in order to have simple code.  Thus, selecting the same
> feat twice from the ADD above is best accomplished with two equal,
> but identity-independent edges. (meaning a.equals(b), but a != b)
>
> If edges are not based on identity, then one must find data that
> will make the two semi-identical edges unique (but
> deterministically unique, so two graphs can still be compared with
> .equals). I believe this would include storing the Source line
> number, source column number, and edge request count for the given
> token in order to make it deterministic and unique.
>
> The reason so much information is required is that the source line
> number required to
> distinguish:
> CustomDomain1 <tab> FEAT:Bar
> CustomDomain1.MOD <tab> FEAT:Foo
> CustomDomain1.MOD <tab> FEAT:Foo
> ...while the Source column number required to distinguish:
> CustomDomain1 <tab> FEAT:Bar <tab> FEAT:Foo <tab> FEAT:Foo
> ... and the edge request count required to distinguish: CustomDomain1 <tab>
FEAT:Bar
> <tab> FEAT:Foo, Foo
> Thus it is far easier to simply avoid the issue by making equal
> edges allowed as long as those edges have a unique identity (a !=
> b).

OK, that makes sense, but does it not get heavy storing all of that?  Or would
you only store that info for this particular scenario?


> Issue #4: Items may be removed (revalidation of the graph model
> over lists)
>
> This is requirement H.
>
> We would also like a system where items can be removed (e.g. the
> REMOVE:FEAT|x token) and not require a massively complicated change
> to the graph.
>
> This is another reason to avoid the use of lists (and move to a
> graph).
> First, a model based on lists requires validation-based change.
> Given that this concept is only
> marginally understandable without an example, here is an example of
> validation-based change.
> Assume the following:
> • Ability A1 grants Ability AMultNo
> • Ability A2 grants Ability AMultNo
> • Ability AMultNo may only be granted once
> • Ability AMultNo grants 2 skill points to the PlayerCharacter
> • PlayerCharacter MyPC has both Ability A1 and Ability A2 (chosen
> in that order)
> One possibility would be to have A2 NOT contain AMultNo (since it
> already exists in A1)
> when placed into MyPC. This would require that the list model is
> constructed so that the PObjects
> themselves are not aware of the relationships (otherwise, the
> PObjects would require cloning as
> they are placed into a PlayerCharacter, and we are back to the
> PCGen 5.x core). This is possible,
> but there are still problems with this model. If A1 is subsequently
> removed (due to a PC change or
> due to a REMOVE: Token), then the validation of the PlayerCharacter
> must realize that the Ability
> A2 should then grant AMultNo. Thus, the validation that is
> performed on MyPC must alter the
> internal data model if A2 does not contain AMultNo in the given
> example.
> Another possibility would be to suppress the expression of AMultNo
> from Ability A2.
> This does little to simplify the situation if A1 is subsequently
> removed. The validation of
> the PlayerCharacter must still realize that the Ability A2 should
> grant AMultNo (and thus the
> validation must reactivate the Ability). While there may be a
> solution to that problem that does not
> require validation-based change, it is not an ideal solution.
>
> A graph makes this reasonably easy:
> http://www.pcgen-test.org/wiki/images/e/e1/Graph_Mult_no.png
>
> Note that removing A1 would maintain a link to AMultNo through A2,
> so no major reprocessing is required.

And this I like very much.

> Issue #5: Association based prerequisites
>
> This was covered a bit in a previous note, but I think this is
> valuable to see graphically:
> Example: TEMPLATE:Foo<tab>DOMAIN:Sun[PREDEITY:SunGod]
>
> Many objects only grant a character other objects under specific
> circumstances. These are
> generally represented by having PREREQs on the granted object. The
> example above means that
> the Template Foo will grant the character the Sun Domain, but only
> if they have the Deity SunGod.
> As this impacts the Template, but should not alter the Domain, this
> situation requires the restriction
> be kept separate of the "contained" PObject (since the child
> PObject is not being restricted in all
> cases, and must not be cloned [Structural Rule 10]). Since this
> Prerequisite is part of the association,
> placing it in the graph edge is a good mental model. Therefore,
> each PCGenGraphEdge will be able
> to contain Prerequisites in order to prevent `traversal' of the
> graph to PObjects that are prohibited
> by their (association) Prerequisites.
>
> In graph form, this would look like:
> http://www.pcgen-test.org/wiki/images/8/85/Edge_Based_Prerequisite.png

That all made a good deal of sense and is _so_ much easier to understand with
the graphical representations.  As a side note it'll certainly help people get a
feel for making decisions when they draw 'rules' on a graph and quickly see that
doing X as a node is a bad idea or doing Y as an Edge is a bad idea.

Thanks again Tom, great stuff.

K

Hi Tom/All,

Will snip out parts this time :)

--- In pcgen_developers@yahoogroups.com, "Tom Parker" <thpr@...> wrote:
>
> Issue #6: Equipment Heads
>
> <snip>
>
> Issue #7: Removal of PObjects at Runtime
> Example: Template's REMOVE:
> In some cases, it is necessary to evaluate existing associations in
> the PCGenGraph. This will require some form of active pruning of
> the PlayerCharacter PCGenGraph. The challenge is in how to STORE
> the need for that pruning (since the potential list of pruned
> objects is dynamic)
>
> Generally, this is difficult to do without introducing a lot of
> complexity. The solution must consider a number of cases. The
> following examples cover attribute locking (this was a discussion
> on experimental), but in general, the cases also apply to Template
> removal.
>
> Given: Template A grants Ability AA, Template B removes Ability AA,
> Template C grants Ability AA.  Assume AA is MULT:NO
>
> Here are the cases we need to consider:
> • Add A, Add B, Remove B (restores A)
> • Add A, Add B, Remove A, Remove B (must not restore AA - the
> removal can't restore if the original parent is removed)
> • Add A, Add C, Add B (B removes AA from A, but AA remains from C)
> • Add A, Add C, Add B, Remove A (must not restore AA - removal now
> impacts C)
> • Add B, Add C (PC has AA)
> • Add A, Add B, Add C (PC has AA)
> • Add A, Add B, Add C, Remove object that granted A (must not
> restore AA - the removal can't restore if the original parent is
> removed)
> • Add A, Add B, lose B due to Prerequisite change (restores A and
> AA)
> • Add A, Add B, select AA, lose B due to Prerequisite change
> (restores A and AA, but a rules violation as AA is selected after
> grant)

Youch, that's a complex list.  If anyone doubts what difficult stuff we have to
deal with, here's yet another example!

> The rules violation should not be automatically cleaned up
> (guessing which feat slot to empty) as there is an interaction with
> retroactivity that requires user intervention.
>
> The proposed solution here is a removal object slot. This removal
> object identifies the source and sink (the sink being the removed
> object), and keeps the connecting edge. This removal object will
> need to monitor the graph to ensure it remains active, as well as
> to ensure that the grantor of the removed object is not eliminated
> from the graph.
>
> Let's walk through some examples:
> Example #1: Add A, Add B, Remove B (restores A)
>
> Add A:
> http://www.pcgen-test.org/wiki/images/a/ae/Remove_start.png
> Add B implements the removal of AA:
> http://www.pcgen-test.org/wiki/images/8/8c/Removed_B.png
> Removal of B restores AA:
> http://www.pcgen-test.org/wiki/images/a/ae/Remove_start.png
>
> Example #2: Add A, Add B, Remove A, Remove B
>
> Add A:
> http://www.pcgen-test.org/wiki/images/a/ae/Remove_start.png
> Add B implements the removal of AA:
> http://www.pcgen-test.org/wiki/images/8/8c/Removed_B.png
> Removal of A removes the trigger:
> http://www.pcgen-test.org/wiki/images/f/f7/Removed_B_A_removed.png
> Removal of B would leave the PlayerCharacter empty.
>
> Example #3: Add A, Add B, select AA, remove B (restores A and AA, but a rules
violation as AA is selected after grant)
>
> Add A:
> http://www.pcgen-test.org/wiki/images/a/ae/Remove_start.png
> Add B implements the removal of AA:
> http://www.pcgen-test.org/wiki/images/8/8c/Removed_B.png
> Select AA:
> http://www.pcgen-test.org/wiki/images/9/97/Removed_B_selectAA.png
> Removal of B restores AA from A, but AA is MULT:NO, so it triggers
> a rules violation:
> http://www.pcgen-test.org/wiki/images
> /0/05/Removed_B_selectAA_rules.png
>
> The only real side effect of this is that the Graph requires a
> GraphChangeListener structure so the removal system can track
> changes to the Graph.

We're also potentially get a massively bloated graph right?  Lets assume we have
a user who _loves_ tinkering with his/her PC, adding and removing various
Templates and other such things, is there a danger it's going to grow too large?

> Issue #8: Modifiers
> <snip>
>
> Issue #9: Hit Dice
> <snip>
>
> Issue #10: Storing Associations
> <snip>

All Made Sense, that removal stuff could get interesting though :)

K

Hi Tom,

> <snip material>

So we're effectively evaluating the Choose outside of the PC Graph and apply the
result to the Graph?

> If you go looking in the tokens, you can see that CHOOSE:LANGAUTO
> actually inserts itself into the ADD system, using that same
> infrastructure to avoid unique code in the core (while using a
> workaround in the token to prevent ADD:.CLEAR from clearing a
> CHOOSE:LANGAUTO token)

I'll go take a look at that and post back here if I have any questions.

K

Hi All,

> <snip>
>
> The reason for this is that I think PlayerCharacter could use some
> trimming.  It would also be nice to plan for flexibility in non-d20
> (or slightly modified d20) systems.

A very long term PCGen goal :)

> The other reason that this is significant is that the Graph
> structure primarily serves as a data store (or a data structure if
> you prefer).  It is not designed to actually DO the processing, so
> another set of elements is required to actually do the Graph
> analysis.

I figured as much, good to have that stated though.

> As some background, we do into a language problem: specifically
> what to call the classes that are doing the processing on the PC.
> I had been using the term "subcomponent" (see
> http://tech.groups.yahoo.com/group/pcgen_developers/message/52 ),
> but it has since been pointed out that's a bad term (because
> "Component" is an AWT element, so the term is confusing).  Until we
> establish a better term, I'm going to use "facet".  There are other
> possibilities (e.g. "cog"), so I'm open to suggestion if anyone has
> good (or even bad!) ideas...  just try to make sure it isn't
> already something we use elsewhere (e.g. aspect would be confusing
> since we have a token of the same name)

Facet is good I think, it lends itself nicely to thinking about a 'person'
(facets of them) which is what we're doing when talking about a PC.

> <snip>
>
> The example I intend to use is the processing of Hands on a
> PlayerCharacter.  There are two reasons for this:
>
> First, it's reasonably simple.  The method currently in PlayerCharacter is
only a dozen or so lines long.  Basically the algorithm in the code is: Test the
race for HANDS, then use templates to override that value.
>
> Second, there are things (other than a simple UI output field) that
> depend on it.  Specifically, weapon locations are dependent upon
> the number of hands in a PlayerCharacter.  We therefore need to
> define how this information is extracted by other facets in the
> system.
>
> I'm going to assert one thing (and there is still some work to do
> on this detail of the architecture, but there will be something
> similar): All of the types of objects (Race, Deity, Templates,
> Feats, etc.) have some form of manager which knows precisely which
> items are currently applied to the PC.  You can think of this as
> either a delegated method back to the Graph (e.g.
> getNodesOfType(PCTemplate.class)) or as a facet serving as a
> caching mechanism that is monitoring the contents of the Graph to
> be aware of the active objects of a given type.

OK, so the PC Graph is just a 'data store' and the managers know what's applied
for their facet.

> Given that, let's also assume for a moment we have a specialized
> facet to calculate the number of hands on a PC.  This facet has the
> getHands() method on it.
>
> Some questions for discussion:
> 1) Can a facet cache?  I think the answer to this is yes: We will
> want to have some facets cache, because there are some items that
> are rather computationally intensive.  Others (like getHands) may
> not need to cache.

OK, so we'll have to be very careful about what we cache.  For example it's
probably pointless to cahce soemthing we know changes rapidly on a PC Graph
(hypothetical example would be current hit points during a combat constantly
changing)

> 2) Assuming the facet can cache
> 2A) Does it store the cache locally?  (Pros: simple caching - local
> to the object, easier testing as it doesn't require a working
> cache, simpler methods (less incoming arguments), no casting.
> Cons: one facet per PlayerCharacter uses more memory, global clear
> is hard (and highly prone to error!), components can't be reused in
> a web environment).  Open to discussion here, but the Cons are
> pretty strong.
>
> 2B) If it's a global cache, what is the cache identifier? (This can
> be the class, to keep things simple and provide a way for objects
> to avoid cross-pollution.  I'm concerned about using Strings
> because if we do that, there is a risk of facets from different
> places using the same identifier, and thus PCGen would have to do
> error-checking on all of the loaded facets to avoid that problem.)
> Note that this presumes that the cache only stores 1 object per
> facet (and the facet can store any data structure it wants inside
> of that object).  This assumption is open to challenge.

I prefer the Global cache, partially because of the cons you mention (for
example, another very long term goal for PCGen is for it to be web friendly). 
But instinctively I know that many role playing effects are of a global type
(e.g.  A template that removes all spell INT bonuses), it makes more sense to be
able to change things in one place.

> 3) How does the HandsFacet get connected?  Presumably it needs to
> know about the RaceFacet and TemplateFacet.  Presumably this is
> provided at construction or in setters or ??.  Thoughts?  (one
> comment: During construction concerns me because we may run into
> circular dependencies)

This gets complicated (and I haven't got an answer), we're going to have to try
and make assumptions about what can know about what.  Since so many rule systems
like to have strange an unusual rules we could start drifting back towards the
'everything' knows about 'everything' PObject model, which is less than ideal :|

> 4) Assuming HandsFacet caches the answer, how does it know when to
> purge the cache?
>
> 4A) If it's a global cache, it could be globally purged whenever a
> graph change takes place (similar to today's setDirty(true) and
> serial #).  I think a global reset will cause wasted CPU, so I have
> a bias against this, but can be convinced.
>
> 4B) There is a mechanism for a "character updated" message to go
> out to the facets (think Observer - like).  This would include a
> graph revision (similar to today's serial #)

This would be the 'push' way of doing it yes, I do tend to find that if it's a
manual bit of code we need to add then that can get missed (the isDirty() flag
being a good example of this).

> 4C) Fine grained updates, where explicit change messages are
> transmitted through a Listener-Event system (or something similar)
> between the facets.

So Facets listening to 'their' nodes on the Graph?  That's a valid option as
well in my book.

> 5) Other.  Really, this isn't cooked.  This got started as a
> discussion with James on Spring, and we started to use this as an
> example since we both have the same context within PCGen.  It got
> into enough implementation detail that we stopped the discussion to
> ensure everyone can participate.  As a significant note, I'm not
> sure Spring actually provides significant benefit to PCGen.  That
> is certainly not determined, and if we seriously evaluate that
> path, we need to make sure we demonstrate concrete benefit from it
> since it does take size and may control design of the code.  I'm
> open to other frameworks as well, but IMHO they are held to the
> same standard of demonstrating concrete benefit.

I use Spring a bit at work, and there are other DI and AOP frameworks out there,
but as you say I'd like to see concrete examples thought out using those before
we made a switch over.

> I think there are two ways forward here: First, we can discuss on
> the list.  Then I think we should get together on IRC.  I'd suggest
> Fri Aug 14 6 PM EDT for that discussion (gives people time to plan
> and is a time that James and I both theoretically are available
> [real time subject to James checking his calendar!])

I'll probably be available then, I guess we can send out a calendar notification
in Y!.  But yes, more people should comment here first, especially those with
more working knowledge of the code than me (which is most of you).

K

Hi All,

I was looking a tidying up the links etc around our autobuilds when I noticed
the last autobuild had run on the 23rd of Jul?  Is this being affected because
of our site move or..?

K

Hi,

On 30/07/2009 2:13 AM Martijn Verburg wrote
> Hi All,
>
> I was looking a tidying up the links etc around our autobuilds when I noticed
the last autobuild had run on the 23rd of Jul?  Is this being affected because
of our site move or..?
>
>
That was the last check-in. As it only fires up if changes have been
made, it is operating correctly.

Cheers,
James.

--- In pcgen_developers@yahoogroups.com, "Martijn Verburg" <martijnverburg@...>
wrote:
> OK, seems sensible - I think we need to have this declared in the Roadmap, so
that everyone is aware of this, thoughts?


I do not believe it is specifically mentioned in any roadmap.  It's more of a
philosophy we adopted of doing incremental refactoring rather than rip & repair.


> I'd like to Tracker all of this, would you prefer it under Freqs or under
Release Steps?  I'd like to actually tackle this one myself although I wouldn't
be able to start until September, however if someone else wants to take it
please do yell out!


I'd prefer it as a single FREQ.  It's a reasonable process for one person, even
if not at one sitting.  The Release Steps probably need to be purged and redone.

TP.

--- In pcgen_developers@yahoogroups.com, "Martijn Verburg" <martijnverburg@...>
wrote:
> PrereqObject being a very light weight Abstract Base Class right?

PrereqObject is an interface.  A ConcretePrereqObject is a light-weight abstract
class that implements PrereqObject.

> > [issue about storing the Source line
> > number, source column number, and edge request count for the given
> > token in order to make it deterministic and unique.]

> OK, that makes sense, but does it not get heavy storing all of that?  Or would
you only store that info for this particular scenario?

The point is that using identity (==) rather than .equals(), that such detailed
information doesn't have to be stored... so we're avoiding getting 'heavy' in
the process. (*Note that an editor [vs. runtime] probably will have to store at
least some of that info in order to unparse correctly, but it's unnecessary at
runtime.)

TP.