On 2015-01-13 21:13- Andrew Ross wrote:
>
> Can I suggest a script which runs all the standard examples, saves as
> plmeta files, then re-renders using the psc driver. It would be
> illuminating to compare with the direct psc driver and should also
> highlight any missing API elements in the b
Can I suggest a script which runs all the standard examples, saves as
plmeta files, then re-renders using the psc driver. It would be
illuminating to compare with the direct psc driver and should also
highlight any missing API elements in the buffering.
I'll see if I can knock something togeth
Jim and others
A gotcha that I just found doing unrelated stuff (actual work!) is that
calls to plscmap0and plscmap0n are not saved to the buffer, but calls to
plcol0 are saved to the buffer using the index it is called by. I found the
bug because I was changing the colour map part way through plot
On Saturday, January 10, 2015 at 13:57:16 (-0600) Maurice LeBrun writes:
> Design issues include:
> - The physical device coordinate space was a limiting factor, say for later
> zooms.
> - Ditto for the physical device API. A metafile/renderer built at a higher
> level would've had more ver
In my experience, you will definitely need file versioning. Won't be used
that often but essential for backward compatibility.
The original plmeta/plrender also had a nifty way to seek to a given page in
the file, seek forward/backward N pages, etc. Unfortunately it meant backing
up and filling
>> 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 whe
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 w
On 2015-01-12 15:10- Phil Rosenberg wrote:
> Does this sound sensible?
Yes. Go for it.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with th
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
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
On 2015-01-11 09:27- 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
When the buffer needs to reallocate, it grows by a multiple of a fixed amount
(plbuf_buffer_grow). The multiple is computed such that the growth is large
enough to meet the demand.
plbuf_buffer_grow = 128KB (set in plbuf_bop)
growth_multiplier = (top_of_buffer + needed_space - size_of_buffer) /
Thanks Maurice and Alan
This is all really worth thinking about for planning this stuff. I would in
general think that a move towards floating point internal
representation would be worthwhile. Some comments on your above comments -
I am probably "teaching my granny to suck eggs" but thought I woul
On Saturday, January 10, 2015 at 15:54:23 (-0800) Alan W. Irwin writes:
> I assume for the purposes of the further discussion that you meant
> "internal" physical device coordinates but please confirm that (or
> take the rest of what I say with a grain of salt if that assumption is
> incorrect)
On 2015-01-10 13:57-0600 Maurice LeBrun wrote:
> Both the endianness and IEEE float issues are dealt with in a portable way by
> the functions in src/pdfutils.c. Neither integers or floating point are
> dependent on the native architecture, making the metafiles 100% portable.
>
> 1. Endianness is
On 2015-01-10 14:57- Phil Rosenberg wrote:
> Alan - a question about git procedure. We are going to end up in a
> situation here where my wxWidget branch that I've already begun is going to
> require access to changes made on other branches. I think the only way to
> do this is to merge the ma
Both the endianness and IEEE float issues are dealt with in a portable way by
the functions in src/pdfutils.c. Neither integers or floating point are
dependent on the native architecture, making the metafiles 100% portable.
1. Endianness is "little", by fiat, implemented by shifts & masks.
2. Flo
Hi Alan and Jim
One other implementation option I just thought of - would a command line
option be a relatively easy way to indicate that a metafile must
be written? Then the core library could do this transparently
whatever driver is being used and basically the only code needed would be
an if sta
compression I think, but that adds yet
another dependency.
Phil
-Original Message-
From: "Jim Dishaw"
Sent: 10/01/2015 02:14
To: "Phil Rosenberg"
Cc: "Hazen Babcock" ; ""
Subject: Re: [Plplot-devel] Fwd: metafiles
Another option to consider
. So there
are some advantages to our own format, the question is whether the effort is
worth the benefits
Phil
-Original Message-
From: "Hazen Babcock"
Sent: 09/01/2015 21:47
To: "plplot-devel@lists.sourceforge.net"
Subject: Re: [Plplot-devel] Fwd: metafiles
&
t;plplot-devel@lists.sourceforge.net"
Subject: Re: [Plplot-devel] Fwd: metafiles
On 2015-01-09 16:38- Andrew Ross wrote:
>
> Phil,
>
> The problem was that we updated the API and added new functionality that
> was never included in the metafiles since no-one was supporting
>>
>> Phil,
>>
>> The problem was that we updated the API and added new functionality that
>> was never included in the metafiles since no-one was supporting it. In
>> the end we took the decision to disable it by default rather than
>> distribute something that didn't work fully. The plrender code
On 2015-01-09 16:38- Andrew Ross wrote:
>
> Phil,
>
> The problem was that we updated the API and added new functionality that
> was never included in the metafiles since no-one was supporting it. In
> the end we took the decision to disable it by default rather than
> distribute something tha
On 2015-01-09 09:58- Phil Rosenberg wrote:
> Hi all
>
> Does anyone know if the metafile driver still exists and if so what CMAKE
> parameters are needed to enable it - I currently don't get it for my builds.
Hi Phil:
The list of device drivers in cmake/modules/drivers-init.cmake should
be a
Phil,
The problem was that we updated the API and added new functionality that
was never included in the metafiles since no-one was supporting it. In
the end we took the decision to disable it by default rather than
distribute something that didn't work fully. The plrender code is still
there
No problem. Let me know how I can help out. If you wanted to enable the
capability to select temporary files vs memory buffer at runtime, the #ifdef
could be changed to if blocks. However, that would require a flag variable to
denote which one to use. I would recommend against that because it
Hi Jim
Thanks for that info.
I have done a bit of googling and it seems that there also used to be a
tool called plrender which read in metafiles - however I found an email
from Alan in 2007 (
https://www.mail-archive.com/plplot-general@lists.sourceforge.net/msg00177.html)
saying that the metafile
I believe those BUFFERED_FILE blocks are from the patches I submitted years ago
that implemented the memory buffer.
Prior to that patch, Plplot used a temporary file to buffer plot commands
(using a plplot internal command set). Those temporary files would often get
left behind on abnormal ter
28 matches
Mail list logo
