On 2015-01-24 22:34-0500 Jim Dishaw wrote: > In the src/pdfutils.c file (pdf = portable data files) there exists functions > that allocate, free, and find the min/max for 2d matrices. The functions do > not read or write any data files and these functions are used in > > src/plot3d.c > src/plvect.c > src/plimage.c > src/pllegend.c > src/plgradient.c > ./bindings/f95/scstubs.c > ./bindings/f95/sccont.c > ./bindings/f95/sc3d.c > ./bindings/c++/plstream.h > ./bindings/c++/plstream.cc > ./bindings/d/plplot.d > ./bindings/tcl/tclAPI.c > ./bindings/swig-support/plplotcapi.i > ./bindings/ocaml/plplot_h > ./bindings/ocaml/plplot_impl.c >
> The purpose of src/pdfutils.c is to provide file I/O functions (plmeta uses pdf_utils) not to provide memory allocation. I would like to move them to a new file, for example src/plmem.c. I think moving them is a good idea. > Also, I would like to rewrite plAlloc2dGrid to use only one alloc because the multiple alloc algorithm that is currently used is unnecessary, slower, and on some OSes results in a fragmented heap. Also, by using one alloc call, plFree2dGrid needs only one free. I think not. I am pretty sure from code comments I have read in the past, the point of the two-dimensional mallocs (and frees) is to make dealing with dynamical two-dimensional arrays exactly the same as static two-dimensional arrays. That is a big benefit of the current code I would not want to give up. > [From a separate post] Does anyone build plplot with BUFFERED_FILE turned on I have looked through the entire source tree with the following command for mentions of BUFFERED_FILE. software@raven> find -type f |grep -v .git |xargs grep -l BUFFERED_FILE ./src/plcore.c ./src/plbuf.c ./include/plstrm.h And if you drop the -l option so you see all the instances, it is clear the BUFFERED_FILE macro is only used and not actually set. Actually there is substantial danger of a name clash here so "BUFFERED_FILE" could be set in some system header somewhere. So at minimum you should change this to PL_BUFFERED_FILE. However, I agree with your conclusion that this is just code clutter since it is definitely not set in our current CMake-based build system (in place for almost a decade now) and likely not set in our previous build system either. So I think (unless someone steps forward now to say this is experimental code they meant to get back to working on some day) you should go ahead and completely remove the code (from all 3 files above) that would be compiled if BUFFERED_FILE was ever #defined or specified as a compiler option. 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. http://p.sf.net/sfu/gigenet _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
