>> It wasn't clear from Phil's summary that he was going to use plbuf
code, but I hope he does.
yes that certainly was my intention
>> I'm not clear on the need to prefix the commands with the size
A couple of examples where this might be useful - lets say we find a bug
and it turns out that when we output the colour we only have been
outputting rgb and forgot the alpha. If we then fix this to include alpha
we have to update the file version. Now old versions of our software are
entirely unable to read our latest files because of a small bug fix. If the
size of that command is included then old versions of the code can either
ignore that command or try to deal with it, but at least they can continue
past that command and read the rest of the buffer.
Alternatively if we add an extra command - we could update the file version
number but then we have a backwards incompatible change. However if older
versions of the software know how long that instruction is then they can
simply skip it (outputting a warning if we want) and carry on. It just
makes the file more robust and flexible.
Of course there is a cost to pay in terms of file size, but I think it
probably doesn't matter too much on the scale of the terabyte hard drives
that most people have nowadays.
As ever though I'm happy to be persuaded in another direction and I think
it is a nice to have rather than essential feature so something to be done
when time permits.
Phil
On 12 January 2015 at 18:27, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
wrote:
> On 2015-01-12 11:19-0500 Jim Dishaw wrote:
>
> I can make the changes [to plbuf] described by Phil. Should I pull the
>> current released version from the repository?
>>
>
> Hi Jim:
>
> It wasn't clear from Phil's summary that he was going to use plbuf
> code, but I hope he does. If so, and you want to help with any
> necessary changes in that code, then I suggest you use "git clone" to
> retrieve the master branch (much more advanced than the latest
> released version) from our SF repository so the PLplot base you are
> working on will be completely consistent with the base that Phil is
> working on. Then collaborate further with Phil using "git
> format-patch" (to collect your results so your collaborative partner
> can apply them to his topic branch) and "git am" so that a partner's
> work can be applied to your topic branch. For further remarks about
> git and PLplot and our workflow and why this method of git
> collaboration is necessary, check the README.developers file in the
> current master branch.
>
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
www.gigenet.com
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
