I now am seeing red also, at version 10314.
Comparing SVG files for C and Ada on Example 1:
The file sizes are the same;
There are 535 differences;
Every difference (date excepted) is due to either
stroke="#FF"
or
fill="#FF"
in the Ada-generated file.
That's a lot
Alban said:
> As for your suggestion of using an overloaded repaint(), I'm afraid it's
not that easy, as any call to the plot function will cause the whole buffer
to be "replayed" anyway.
I did an experiment replacing the call to repaint() by a call to update().
The result was that example 17 wit
I have just committed the changes to the Ada bindings that implement
plspal0 and plspal1; the odd results that Alan and Andrew reported
were without those functions implemented. Prior to this commit, there
were no calls to either plspal0 or plspal1 in any of the Ada examples.
Now, Ada examp
Hi Arjen,
This helps - I no longer get a crash. There is still a further issue
somewhere. I'll see if I can track it down.
Andrew
On Fri, Aug 21, 2009 at 04:20:29PM +0200, Arjen Markus wrote:
> Hi Andrew,
>
> I looked at the source code for the bindings and I realised that
> currently we do n
Just for information, there was indeed an issue with superscripts/subscripts in
the Qt driver (floating point precision issue on a test), which was fixed in
the latest patch: so this was intentional and not just a side effect of
something else :)
Alban
PS : Alan, I've received an error message
On 2009-08-20 09:32-0700 Alan W. Irwin wrote:
> There is no difficulty with this latest version of the example either for
> -dev svg (when viewed by "display") or -dev xwin so I suspect there must
> still be some off-by-one logic error in superscript/subscript level in
> cairo.c that is causing th
Hi Andrew,
I looked at the source code for the bindings and I realised that
currently we do not use tcl_precision or something similar to _return_
values from PLplot routines. Instead we simply use %f to format the
returned number. Up to now that was satisfactory, but the time functions
return da
As a second report, I can confirm that I also see this. Using -cmap0 on the
command line to set the default palette cures the problem, so it looks like
it is somewhere in the initialisation. This just seems to be an Ada issue,
and happens for all the drivers I've tried. This is odd since with the
My working copy is 10303 and it is OK. The last change to plplot.h was
in 10302. Not sure what is happening here.
Jerry
On Aug 20, 2009, at 12:52 PM, Alan W. Irwin wrote:
> I presume this has something to do with the recent core cmap[01]
> changes.
> Hopefully, the fix can be found in a hurr
I've come a bit further with my Octave/Windows/PLplot problem.
For test purposes I replaced the fork in "matwrap" with a simple open.
(As far as I understand the fork is supposed to prevent problems with
quotes, which I don't have in my calls.) This worked fine, but I'm
running into new difficu
Hello Andrew,
I will modify qt_example to show the deep copy in the next patch, no problem.
As for your suggestion of using an overloaded repaint(), I'm afraid it's not
that easy, as any call to the plot function will cause the whole buffer to be
"replayed" anyway. I think about using a pointer
11 matches
Mail list logo
