Loading ...
Sorry, an error occurred while loading the content.

Re: [pcgen-xml] New .lst Format (was: It lives! And is reborn!)

Expand Messages
  • gamer_dude@comcast.net
    ... Debuging is nice and I agree that a data format which lets you debug will be helpful. I guessing that there is an idea that I m just not catching. In my
    Message 1 of 8 , Oct 4, 2005
    • 0 Attachment

      >keep in mind, this is text.  I just tested out one

      >of these files (the ziped up style I was recommending
      >in the next thread), and *with* an embedded image it
      >came out to a whopping 20k or so.  As it stands,
      >a) we have said that section 2 is optional, and b)
      >it's for debug

      Debuging is nice and I agree that a data format which lets you debug will be helpful.  I guessing that there is an idea that I'm just not catching.  In my mind, what was proposed for section 2 (S2) could handle the purposes of S1 and S2, without having S2. In other words, just put the totals in S1, forget duplicating of the bulk of the info.  If debugging is not implemented (or the feature not being used) then the program can just put the data away (so it will be saved out on an update) or ignore it and re-calculate it when the file is re-saved (or something in between, that's an implementation choice).

      I had a little character tracker a long time ago, written in GW Basic (pre-windows days) in which I did things like this.  I didnt' save as much info since the characters were simpler, but it was close.  Mainly I saved HP gained as well as the new total.  While this was just one peice of data, and the only one that was a 'randomly added' peice of inforation at each level, I didn't implement a two step process (S1, S2). 

      Yes drives are bigger today, we have great file compression tools, etc. but I come from the school of programming which hammered home: "keep your code neat, avoid duplication of data and code whenever possible, and document document document." (one of my first semester classes was "business programming logic" an entire semester of nothing but flow-charting logic, which tells you how long ago this was). So to me it doesn't matter if the file is text, a graphic, or random characters being tossed out to just fill drive space.  Duplication of information always makes me think three times about if that duplication is needed.


      >- but if you seriously think that being able to

      >debug people's broken characters is unimportant...
      Talk about "harsh", especially when I never criticized the idea of debugging and in light of the observation below. In my experiance, comments like that are used by people who have a 'death grip' on their viewpoint and are trying to paint the other person in a negative light (basically accuses the other person of not caring).

      >Did you see the new proposal? 
      No, I didn't see it until last night, when I got home after work.  It's on my 'read' list for this week.


      >I think this charge is a little harsh, considering

      >that the extended proposal is umm, pretty
      >fundamentally different then the current one.
      Please accept my appologies. Seriously, I didn't mean to be harsh or rude, just plain spoken.  The impression I stated ("seems to be" instead of "you have a") was just that, an impression.  I will try to be more aware of how I state my impression.

       

      Al B.


    • Devon Jones
      ... Fair point :) Devon
      Message 2 of 8 , Oct 4, 2005
      • 0 Attachment
        Brass Tilde wrote:

        >While I completely agree that the criticism is harsh (though I would say
        >more than a little, and unjustified to boot), I'm not sure I agree with
        >"fundamentally" different. Significant, yes. Fundamental, no.
        >
        >What about your new proposal of a multi-document, single package format
        >is different in kind, rather than degree, from the multi-section single
        >file format proposed earlier? Off the top of my head, I didn't see
        >anything in the new format that couldn't have been stored in the old one
        >(though I will freely admit that storing an image as a 7 bit encoded
        >CDATA element would be...unweildy. :-)
        >
        >It's certainly well within the realm of possibility that my failure to
        >see this difference is my own lack of understanding.
        >
        >Bear in mind that I think your new proposal is a *good* one, and
        >implemented properly, will help support an ever greater degree of
        >functionality in PCGen
        >
        >
        Fair point :)

        Devon
      • Devon Jones
        ... See, and I don t necessarily expect it to be quite that - I m expecting it to be more of a file that lets the program log, non-destructively, so that the
        Message 3 of 8 , Oct 5, 2005
        • 0 Attachment
          gamer_dude@... wrote:

          > Debuging is nice and I agree that a data format which lets you debug
          > will be helpful. I guessing that there is an idea that I'm just not
          > catching. In my mind, what was proposed for section 2 (S2) could
          > handle the purposes of S1 and S2, without having S2. In other words,
          > just put the totals in S1, forget duplicating of the bulk of the
          > info. If debugging is not implemented (or the feature not being used)
          > then the program can just put the data away (so it will be saved out
          > on an update) or ignore it and re-calculate it when the file is
          > re-saved (or something in between, that's an implementation choice).
          >
          > I had a little character tracker a long time ago, written in GW Basic
          > (pre-windows days) in which I did things like this. I didnt' save as
          > much info since the characters were simpler, but it was close. Mainly
          > I saved HP gained as well as the new total. While this was just one
          > peice of data, and the only one that was a 'randomly added' peice of
          > inforation at each level, I didn't implement a two step process (S1,
          > S2).
          >
          > Yes drives are bigger today, we have great file compression tools,
          > etc. but I come from the school of programming which hammered home:
          > "keep your code neat, avoid duplication of data and code whenever
          > possible, and document document document." (one of my first semester
          > classes was "business programming logic" an entire semester of nothing
          > but flow-charting logic, which tells you how long ago this was). So to
          > me it doesn't matter if the file is text, a graphic, or random
          > characters being tossed out to just fill drive space. Duplication of
          > information always makes me think three times about if that
          > duplication is needed.
          >
          See, and I don't necessarily expect it to be quite that - I'm expecting
          it to be more of a file that lets the program log, non-destructively, so
          that the programmer can see a history of what's been done to the file.
          Keith and I have a somewhat different outlook on some of these pieces.
          I se it as this:
          Section 1) Minimum of data needed to re-create character in pcgen
          Section 2) Log
          Section 3) Full character representation

          But the important pare to me is that I see section 2 literally as a log,
          not just a list of consequences and changes - but a record of what
          operations were run on the file, for each program that wrote to it.

          As it stands, this is all kind of different now (to some degree at
          least) in the other thread.

          And as I have said, I don't expect S2 to get implemented any time soon,
          if at all. S1 & 3 are the ones that we need. S2 is just a nice to have.

          > Talk about "harsh", especially when I never criticized the idea of
          > debugging and in light of the observation below. In my experiance,
          > comments like that are used by people who have a 'death grip' on their
          > viewpoint and are trying to paint the other person in a negative light
          > (basically accuses the other person of not caring).
          >
          Fair enough, I appologize.

          > Please accept my appologies. Seriously, I didn't mean to be harsh or
          > rude, just plain spoken. The impression I stated ("seems to be"
          > instead of "you have a") was just that, an impression. I will try to
          > be more aware of how I state my impression.
          >
          Appology accepted, sorry I was harsh in my reply. I really appreciate
          input, and I deeply don't want to discourage people from stating their
          ideas plainly as you have here - it really is appreciated.


          Devon
        Your message has been successfully submitted and would be delivered to recipients shortly.