Hi Per,
no probably not, libart is quite picky what we expect it to graph
... I worked around this problem in releases up to 1.2.10 by giving
it only squares to draw ... lots of it ... this turned out to be
extreemly expensive ... in the 1.2.11 release I took a different
apporoach, where I try to
Ruud H.G. van Tol schreef:
A preliminary result that was easy to achieve and fun to do:
http://www.xs4all.nl/~rvtol/pics/rrd/bigtops.001.png
And from that, it was a little step to
http://www.xs4all.nl/~rvtol/pics/rrd/bigtops.002.png
(but that seems to have some problems with the x-labels)
Ruud H.G. van Tol:
Ruud:
A preliminary result that was easy to achieve and fun to do:
http://www.xs4all.nl/~rvtol/pics/rrd/bigtops.001.png
And from that, it was a little step to
http://www.xs4all.nl/~rvtol/pics/rrd/bigtops.002.png
(but that seems to have some problems with the x-labels)
Hi Ruud,
Just wanted to say that I really appreciate what you're trying to do here. I've
often found that I had to split things into two separate images for lack of a
secondary y-axis when it'd be more naturally to have them together.
My requirements are simpler than yours as I'd be happy with
Per Jessen wrote:
I guess a temporary work-around for me would be to write the PNG output to a
file
instead of stdout - that way I still end up with a valid PNG file, even if
libart spews
out some warnings.
This isn't stricly rrd-related, but in this context, well -
I call rrdtool graph
Per Jessen:
As the problem was that the PNG ended up being invalid
because of the stderr warnings from libart, I figured I would just
close stderr before I do the system() call.
Why not just redirect stderr to a different handle?
What programming language do you use?
--
Grtz, Ruud
--
Ruud H.G. van Tol wrote:
OK, but then I don't understand how the stderr-data could get mixed with
the PNG-data. Or did I understand that wrong?
Does libart maybe send error messages to stdout too?
when I use rrdtool graph -, everything that is sent to stdout and stderr ends
up on
stdout,
