With the the changes to plbuf that need to be made to implement these features,
should the old code that was left in (the ifdef BUFFERED_FILE blocks) be
removed? The only time it is useful is on low memory machines that have the
ability to perform file I/O.
I'm not clear on the need to prefix the commands with the size. With the
version number there is sufficient information to use the appropriate parser.
I can make the changes described by Phil. Should I pull the current released
version from the repository?
> On Jan 12, 2015, at 10:10 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
>
> Okay then, so from all the various discussions I get the impression that the
> consensus is
> 1) The easiest way to get the buffer into/out of PLplot would be to add a
> command line option (e.g. -mfo filename and mfi filename) and have plplot
> core code pick this up and write to/from it. this requires no propagation to
> additional languages and ensures the
> 2) The file will consist of a header that will include a plplot identifier, a
> file format version number, a flag for endianness, the size of the type used
> for the coordinates (with the assumption that if this is ever increased to 32
> bit then it will become a real rather than an int) and the type of float used
> (e.g. 32 bit ieee). The file will then simply consist of a dump of the buffer.
> 3) In the future the buffer should be updated (probably internally and for
> the file) so that each command is prepended with the size of the command.
> This will allow new commands to be added or bugs to be fixed and still allow
> reading of the buffer by older software versions.
> 4) In the future the buffer could be written to a memory mapped file, perhaps
> by some known prefix to the file name or something. This will significantly
> increase speed for real time communication between processes reading/writing
> the buffer.
> 5) For now it seems sufficient to simply support reading/writing in native
> format, but in future we would introduce conversion from various file
> endianness and float formats into native format during reading.
>
> Does this sound sensible?
>
> I did some more work on the wxWidgets driver over the weekend and am
> basically at a point where until this mechanism is sorted I can't really do
> much more, unless I write a wxWidget driver specific version of this
> transport mechanism and then we generalise it to plplot core code later. The
> alternative is that we forget this as a general idea and I just implement
> something for wxWidgets myself.
>
> Phil
>
>> On 11 January 2015 at 19:41, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
>> On 2015-01-11 09:27-0000 Phil Rosenberg wrote:
>>
>>> Regarding the "special values" where small errors in floating points lead
>>> to jumps in integer representation - I think this is probably dealt with
>>> now by anti-aliasing in most modern drivers.
>>
>> No, it is worse than that. Generally, we have PLFLT input which is
>> transformed to internal physical coordinates which are then
>> transformed again (usually by simple scaling) by device drivers into
>> the actual physical coordinates (pixels or whatever) that driver
>> understands. So for certain magical combinations of input (which our
>> standard examples used to hit a lot), the internal physical coordinates
>> which are currently represented as 16-bit integers can flip to a
>> different integer causing a section of the whole plot to shift visibly
>> relative to the rest depending on platform. (Here we are defining
>> platform as the combination of computer language, optimization for
>> that language, OS, and hardware).
>>
>> In other words, the devices are following the orders they are given
>> (with or without antialiasing applied) by the internal physical
>> coordinates, but for magic input values those orders get changed by
>> +/- 1 integer out of the limited total range of 16-bit integers
>> depending on platform. We have historically adjusted our standard
>> examples to avoid these magic situations so that we get more
>> consistent test results comparing one platform with another. But that
>> is just a cover up, and I would far prefer our internal physical
>> coordinates simply had a lot more resolution so that in full
>> generality regardless of input values the PLplot results always look
>> the same (with small rounding errors consistent with 64-bit doubles
>> rather than much larger and visible rounding errors consistent with
>> 16-bit integers) from one platform to the next.
>>
>>
>> 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.
> vanity: www.gigenet.com
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
------------------------------------------------------------------------------
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
