[rrd-developers] Problem with perl (RRDs::graph) on XP, using Jun 10 snapshot

[Calvert, Kerry]

I am trying to use the RRDTool feature COMPUTE, so that I can run Cricket
with PERFMON, but I am having
some difficulty.  I am using Windows XP Pro with the .NET programming
environment.  I am able to compile
and build the binaries, and compile the Perl Shared binaries, but the test
doesn't complete. In some
investigation I find:
 	- The Perl bindings to the create, update, and last keywords work
just fine. Demo1.RRD and Demo2.RRD
are created and look correct, based on using RRDTool.EXE to examine the
databases created by the Perl script.
 	- RRDs::graph and RRDs::info both fail, and in fact cause Perl to
crash.
 	- RRDs::fetch works, but not correctly.  500 values went in to the
database, but 863 came out. The
first 363 values are undefined, then almost 500 records that seem valid,
then an occasional undefined record
near the end.

 	When I use RRDTool.EXE to create a graph using the database created
by the base.t script, and using the
graph parameters from BASE.T, I can see a graph if I make the following
changes:
 	- Fonts didn't work because the default font directory is incorrect
for my computer.  I added the
following line to config.h (in the confignt directory), rebuilt the system.
This value is only used in 
rrd_graph.c, but it seemed better to add it to config.h rather that change
the value in rrd_graph.c. 
 		#define RRD_DEFAULT_FONT "C:/windows/fonts/cour.ttf"
	- I deleted the STACK command.  The message said that the stack
command needed to follow another 
graphing element.
 
I noticed one other thing that seems suspicious, and that is when I compare
the current snapshot (Jun 10)
Perl Shared directory with the production version(1.0.38), every thing is
the same except that fetch is 
starting at "start" in 1.0.38, but is starting at   "start+step" in the new
version.  I wondered if this had 
anything to do with a comment in the changelog about "an off-by-one bug".

I am new to RRDTool, but I hope that someone could offer a suggestion as to
what I could do to fix the Perl 
subsystem. Otherwise, perhaps these comments will help in the development
effort.

 Thank you very much,
 Kerry Calvert
 Software Sustaining Engineer
 Intel Corp.
 Hillsboro, OR
 
 kerry.calvert at intel.com
 

--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi