[Plplot-devel] memcairo driver
Hi all: I just got all the dependencies working and installed plplot 5.9.0 with the cairo drivers. Looks good! I'm curious about the 'memcairo' driver--I compiled it, but it fails under perl/PDL (my native language). The comments said it was turned off by default because it does not work well. I'm the originator of the 'mem' driver, and it would be nice to have in-memory plotting with the cairo fonts. Does anyone know what the issues are with the memcairo driver? I could perhaps take a crack at getting it working, but I'd like some background first. Thanks much, Doug Hunt [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Patch] Using xcairo device with X Drawables
Hazon, Jonathan: I would second the idea of having a memory buffer be the target at some level. I would be interested in getting memcairo working--this allows for powerful direct manipulation of images via PDL, plplot and image libraries. I have used this to good effect on several occasions, but the current limitation are the ugly fonts used by the plain vanilla 'mem' driver. Regards, Doug Hunt [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Tue, 4 Mar 2008, Hazen Babcock wrote: > > On Mar 4, 2008, at 9:36 PM, Jonathan Woithe wrote: > >> Hi >> >> I am working on an application which requires plots to be displayed >> within >> the context of the program's windows. In practice this means that >> I needed >> plplot to have the ability to plot to a supplied X Drawable rather >> than to an X window which plplot creates and manages itself. > > How well do you think it would work to have PLplot/cairo draw into a > memory buffer which is then transfered by the library user to a X > Drawable? This seems to be more general, but perhaps plotting to X > Drawable already covers 90% of the common use cases? The structure > for this already exists to some extent in the form of the memcairo > driver, but unfortunately this driver is not yet functional. > > Also, in your patch, you need to consider the situation where the > user does not have X Windows and the related libraries installed on > their machine. > > best, > -Hazen > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Patch] Using xcairo device with X Drawables
Hazen: (Sorry about the typo on your name!) I hope to be able to look into this today, but it might take me a while to get up to speed. I'll let you know if I find anything that might be of help on your weekend coding expedition... --Doug [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Wed, 5 Mar 2008, Hazen Babcock wrote: > > On Mar 5, 2008, at 11:12 AM, Doug Hunt wrote: > >> Hazon, Jonathan: I would second the idea of having a memory buffer be the >> target at some level. I would be interested in getting memcairo >> working--this allows for powerful direct manipulation of images via PDL, >> plplot and image libraries. I have used this to good effect on several >> occasions, but the current limitation are the ugly fonts used by the plain >> vanilla 'mem' driver. > > What is your time frame? I might have time this weekend to try and figure out > what is going wrong, but if you are already working on this... > > -Hazen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] memcairo driver fixes
Hazen: Thanks! --Doug [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Sun, 9 Mar 2008, Hazen Babcock wrote: > > On Mar 6, 2008, at 6:52 PM, Doug Hunt wrote: > >> Hi Hazen, all: I think I was able to get the memcairo driver working. >> Attached is a patch to plplot-5.9.0:drivers/cairo.c. >> >> The immediate problem was that the X and Y dimensions of the plot were not >> correct in plD_eop_memcairo. The PLstream record values pls->phyxma and >> pls->phyyma were updated during plotting (made larger) so that when the >> cairo drawing surface memory was copied back out to the user-supplied >> memory area, a SEGFAULT occurred. >> >> I replaced pls->phyxma and pls->phyyma in the loop with pls->xlength and >> pls->ylength (these were set up for this purpose in plD_init_memcairo) and >> that seemed to do the trick. >> >> The other changes I made were more basic. It seems that the memcairo >> driver as it stands was designed to overwrite the user-input memory area, >> initializing it to all black. This behavior is not useful, as the purpose >> of the 'mem' drivers (as I understand it) is to be able to add decoration >> to a user-supplied image (see the attachment). >> >> In order to get this behavior, I had to initialize the cairo drawing >> surface with the user-input memory area, using >> >> 'cairo_image_surface_create_for_data' >> >> instead of >> >> 'cairo_image_surface_create'. >> >> I also added an empty subroutine plD_bop_memcairo which is used instead of >> plD_bop_cairo. This is done because plD_bop_cairo zeroes out the image, >> which is not what is desired. >> >> Please take a look at this patch and consider including it in plplot. It >> has no effect on any driver other than memcairo. > > Hi Doug, > > It looks good. I applied it and now the memcairo driver works as expected > (v8261). Thanks for your work to make this driver functional. > > best, > -Hazen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] memcairo driver fixes
Hi again, Hazen, all: I just noticed that the patch I sent contains a bug. I used malloc where I ought to have used calloc in one place. Would it be possible for me to get SVN access so I can just fix this myself? I'd also like to look into the possibility of adding optional alpha channel support for the memcairo driver in the future. Thanks much! --Doug Hunt [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Sun, 9 Mar 2008, Hazen Babcock wrote: > > On Mar 6, 2008, at 6:52 PM, Doug Hunt wrote: > >> Hi Hazen, all: I think I was able to get the memcairo driver working. >> Attached is a patch to plplot-5.9.0:drivers/cairo.c. >> >> The immediate problem was that the X and Y dimensions of the plot were not >> correct in plD_eop_memcairo. The PLstream record values pls->phyxma and >> pls->phyyma were updated during plotting (made larger) so that when the >> cairo drawing surface memory was copied back out to the user-supplied >> memory area, a SEGFAULT occurred. >> >> I replaced pls->phyxma and pls->phyyma in the loop with pls->xlength and >> pls->ylength (these were set up for this purpose in plD_init_memcairo) and >> that seemed to do the trick. >> >> The other changes I made were more basic. It seems that the memcairo >> driver as it stands was designed to overwrite the user-input memory area, >> initializing it to all black. This behavior is not useful, as the purpose >> of the 'mem' drivers (as I understand it) is to be able to add decoration >> to a user-supplied image (see the attachment). >> >> In order to get this behavior, I had to initialize the cairo drawing >> surface with the user-input memory area, using >> >> 'cairo_image_surface_create_for_data' >> >> instead of >> >> 'cairo_image_surface_create'. >> >> I also added an empty subroutine plD_bop_memcairo which is used instead of >> plD_bop_cairo. This is done because plD_bop_cairo zeroes out the image, >> which is not what is desired. >> >> Please take a look at this patch and consider including it in plplot. It >> has no effect on any driver other than memcairo. > > Hi Doug, > > It looks good. I applied it and now the memcairo driver works as expected > (v8261). Thanks for your work to make this driver functional. > > best, > -Hazen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] memcairo driver fixes
Hi Hazen: The original 'mem' driver plotted into an unsigned char array with size 3 x height x width (thus no alpha channel). The cairo drivers plot into 32 bit RGB arrays (with an alpha channel). For the memcairo driver (as a first cut), I just copied in the 24 bits of RGB info into the 32 bit RGB/alpha words, leaving the alpha channel 0. When cairo is done with its magic, the 32bit RGB/alpha words are copied back into a 24 bit RGB array. I'd like to figure out how to get my graphics package to work with an alpha channel and add an option to pass in 32 bit RGB/alpha words. Regards, Doug [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Wed, 12 Mar 2008, Hazen Babcock wrote: > > On Mar 12, 2008, at 11:34 AM, Doug Hunt wrote: > >> Hi again, Hazen, all: I just noticed that the patch I sent contains a bug. >> I used malloc where I ought to have used calloc in one place. >> >> Would it be possible for me to get SVN access so I can just fix this >> myself? I'd also like to look into the possibility of adding optional >> alpha channel support for the memcairo driver in the future. > > memcairo doesn't already have alpha channel support? All the other cairo > drivers do since they use shared drawing functions. > > I'll defer your question re SVN access to one of the project administrators, > though I suspect that it won't be a problem. > > -Hazen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PLplot RGB(A) image support and 3D image support
Hi Hezekiah: I'm not sure what 'truecolor' is, but the 'mem' and 'memcairo' drivers (which I'm fiddling with right now) are designed to allow one to make a plot on an image background. You pass in an RGB array as the background, and make normal PLplot function calls. The lines, points, labels, etc generated by PLplot overlay the image, which is passed back to the user as an RGB array. Then you need to write the RGB array to some image format using external software. Currently the decorations are opaque, but I'm looking into allowing semi-transparent overlays on the input image (using the cairo alpha channel support in memcairo) right now. Regards, Doug [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Wed, 12 Mar 2008, Hezekiah M. Carty wrote: > Are there currently plans to add either of truecolor image support > (photo as a plot background for example) or 3D oriented plimagefr > support? If not, and there is an interest in including such functions > in plplot, I would like to tackle those after getting the plimagefr > coordinate transformation support finalized. > > For the truecolor image support, my thought is to have a function > along the lines of: > void plimagergba( > PLFLT** r, PLFLT** g, PLFLT** b, PLFLT** a, > PLINT xdim, PLINT ydim, > PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax, > void (*pltr) (PLFLT, PLFLT, PLFLT *, PLFLT *, PLPointer), PLPointer > pltr_data) > with function arguments being used similarly to how plimage works. > With the r,g,b,a values separate, any image loading routines could be > handles on the user's end or at least abstracted on top of this. > > Is there a function like plfill (and/or plfill3) which can take a RGBA > color to plot? The plimage* functions use plfill internally. Or is > there a better, more plplot-like way to go about this? > > Thanks, > Hez > > -- > Hezekiah M. Carty > Graduate Research Assistant > University of Maryland > Department of Atmospheric and Oceanic Science > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PLplot RGB(A) image support and 3D image support
Hi Hezekiah: > By "truecolor," I meant a photograph or similar image (MODIS visible > wavelength images in my case) plotted in the same colors perceived by > a human eye. The currently available plimage* functions plot colors > based on the magnitude or intensity of values. OK > > The mem and memcairo drivers were my first thought for this. However, > I think it would be useful to have an RGBA image plotting function > included in PLplot for the following reasons: > - It would be simpler to, for example, use the same coordinate > transformations in each portion of a plot. This would include > consistent pixel -> plot coordinate mapping and 3D orientation of > images for 3D plots. > - Images could be used as layers other than the background, without > needing to do post-processing of the PLplot output > - The available PLplot output devices are available for "free." > - I may be wrong about this, but I think it would make the process > of using such images easier for users of PLplot in languages other > than C. These are good arguments for having image processing directly in plplot. The 'mem' drivers are just another option... > > Is there documentation available for the this use of the memcairo > driver? If I am unable to implement a function to do what I want then > this would still do a lot of what I need. > No new doc right now--I'm still working on getting memcairo to do alpha blending of the generated PLplot decoration with the user-supplied background. I guess the doc you would need would be a description of the image format to be passed in? This is documented under 'plsmem': http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.0/plsmem.html Regards, Doug > Thank you for the response! > > Hez > >> Regards, >> >>Doug >> On Wed, 12 Mar 2008, Hezekiah M. Carty wrote: >> >> > Are there currently plans to add either of truecolor image support >> > (photo as a plot background for example) or 3D oriented plimagefr >> > support? If not, and there is an interest in including such functions >> > in plplot, I would like to tackle those after getting the plimagefr >> > coordinate transformation support finalized. >> > >> > For the truecolor image support, my thought is to have a function >> > along the lines of: >> > void plimagergba( >> > PLFLT** r, PLFLT** g, PLFLT** b, PLFLT** a, >> > PLINT xdim, PLINT ydim, >> > PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax, >> > void (*pltr) (PLFLT, PLFLT, PLFLT *, PLFLT *, PLPointer), PLPointer >> > pltr_data) >> > with function arguments being used similarly to how plimage works. >> > With the r,g,b,a values separate, any image loading routines could be >> > handles on the user's end or at least abstracted on top of this. >> > >> > Is there a function like plfill (and/or plfill3) which can take a RGBA >> > color to plot? The plimage* functions use plfill internally. Or is >> > there a better, more plplot-like way to go about this? >> > >> > Thanks, >> > Hez > > -- > Hezekiah M. Carty > Graduate Research Assistant > University of Maryland > Department of Atmospheric and Oceanic Science > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Checked in bug fix to memcairo
Hi all: I've checked in a change to drivers/cairo.c that fixes a bug in my earlier fix to memcairo. Now the memcairo driver should work for both little- and big-endian machines. Grepping though the code, I could not see that there was any standard way of determining the byte order of the machine or any pre-processor symbols set, so I put a simple test in the cairo driver code to check the endian-ness of the machine. If there is a more standard way of handling this, please let me know. 'ctest' passes with this change in place. Regards, Doug Hunt [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Cairo-based driver for externally created cairo contexts (was Re: [Patch] Using xcairo device with X Drawable
Hi Hazen: For what I use the memcairo driver for, clearing the memory not not the behavior I want. I want to pass in some memory already containing an image and then plot a graph on top of it. To first generate the image and then have plplot clear it would be disappointing, to say the least! I'd vote for adding an option to clear to the background, but not to make it the default. Regards, Doug [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Mon, 7 Apr 2008, Hazen Babcock wrote: > On Apr 6, 2008, at 9:17 PM, Jonathan Woithe wrote: >> >> Having said that, things are as they are because this is the behaviour of >> the current cairo-based devices. Admittedly a pre-existing drawable is >> different from one created by plplot but even so, consistency can sometimes >> be a good thing. The other thing to bear in mind is that "clearing to the >> background colour" will be the usual operational mode I would imagine, so >> an >> argument could be raised that the "don't clear" behaviour should be an >> opt-in option - possibly set using a new escape function or perhaps via a >> new "flags" option to the PLXcairoDrawableInfo structure. If we went with >> the latter though, PLXcairoDrawableInfo really needs to be made available >> to applications. Currently there's only 2 members - the display and the >> drawable - and it's not too hard for users to hack up their own structure >> to pass in. However, once we go beyond this PLXcairoDrawableInfo really >> must be publically available so users can't get it wrong. > > I'd propose making "clearing to the background color" a driver option so that > we can use it with xcairo, memcairo and extcairo. > > I think that we should make our decision about the clearing default > consistent across these 3 driver options, but I don't have much preference > about whether or not clearing is the default. > > Doug, any thoughts about having clearing be the default? > > best, > -Hazen - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] PLPlot -- how to install?
Hi Craig: I've been using PLplot successfully for quite a while now. Originally, I switched to it because PGPLOT was such a bear to install. Unfortunately, the newest PLplot has added many dependencies, so its getting harder to install. On the plus side, its getting many new interesting features and it has an active development community that is working well together. I've never installed it on a Mac, attached is my install receipe on Linux. I'm also CCing some PLplot folks in case they have some easy solutions for Mac. Regards, Doug [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Thu, 17 Apr 2008, Craig DeForest wrote: Hey, all, I've been wanting for some time to use PLPlot rather than PGPLOT, but I'm currently 0 for 4 on attempts to install it properly. To get the latest version to compile on my Mac, I had to seriously tweak the make files. I got some basic functionality (e.g. throwing up an X window) but never managed to advance to being able to generate plots. Is anyone here actively using PLPlot to make plots with PDL? If so, what's your system and how hard was it to install? I'm looking for some tips here as I'd like to migrate, but have never been able to make it work. I know Doug Hunt is a big fan, and Derek Lamb used it for a paper we published together. Who else is using it? Cheers, Craig ___ Perldl mailing list [EMAIL PROTECTED] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl Craig: Here are all the packages I install to get plplot working. Many may already be installed or are not necessary. # cmake (new build system, they are no longer using GNU tools for configuration) tar -xzf cmake-2.4.8.tar.gz cd cmake-2.4.8 ./bootstrap make make install # pkg-config (may already be installed) tar -xzf pkg-config-0.23.tar.gz cd pkg-config-0.23 ./configure make make install # glib GNOME libraries. I think this is necessary for pango/cairo, I doubt it is necessary for plplot without cairo drivers. tar -xzf glib-2.14.5.tar.gz cd glib-2.14.5 export PKG_CONFIG_PATH="/usr/lib64/pkgconfig:/usr/lib/pkgconfig" # maybe not necessary? ./configure --prefix=/ops/tools make make install # cairo (optional, needed for cairo drivers (which have nicer fonts)) tar -xzf cairo-1.4.14.tar.gz cd cairo-1.4.14 export PKG_CONFIG_PATH="/usr/lib64/pkgconfig:/usr/lib/pkgconfig" # might not be necessary? ./configure make make install # pango (optional, needed for cairo drivers (which have nicer fonts)) tar -xzf pango-1.19.3.tar.gz cd pango-1.19.3 export PKG_CONFIG_PATH="/usr/lib64/pkgconfig:/usr/lib/pkgconfig" # might not be necessary? ./configure make make install # plplot tar -xzf plplot-5.9.0.tar.gz cd plplot-5.9.0 export PKG_CONFIG_PATH ="/usr/lib64/pkgconfig:/usr/lib/pkgconfig" # might not be necessary? cmake CMakeLists.txt make make install - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Current ctest compare results
Hi Alan: I would like to help with these test cases, but I'm currently swamped. I'll see what I can do over the next 2 months. Regards, Doug Hunt [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Fri, 5 Sep 2008, Alan W. Irwin wrote: > Hi Doug: > > I am addressing this mostly to you because you are our perl/pdl expert. > However, for the others here I also have a Tcl question below. > > Here are the "ctest -R compare" results I have obtained recently > (using -DBUILD_TEST=ON -DENABLE_pdl=ON) > c++ > Missing examples : > Differing examples : > f77 > Missing examples : > Differing examples : > f95 > Missing examples : > Differing examples : > octave > Missing examples : 19 > Differing examples : > python > Missing examples : 19 > Differing examples : > tcl > Missing examples : 19 > Differing examples : 11 13 15 16 20 > perl > Missing examples : 27 28 29 30 > Differing examples : 02 08 20 21 23 > ada > Missing examples : > Differing examples : > ocaml > Missing examples : > Differing examples : > > The clean Ada result (a first for me) is due to Jerry's recent example 19 fix. > > My understanding is there are plans to add example 19 for both octave and > python. That would give us seven language bindings in exact agreement with > the C results for all standard examples which would be an outstanding > result. > > Question for the Tcl experts here. Are those differing examples due to the > string ==> float rounding issues with Tcl or are there deeper concerns? > > This leaves the perl/pdl language binding. Doug, would you be willing > to programme the remainder of the standard examples and make sure > the pdl interface to PLplot is complete? > > ctest -R perl has an example 20 issue which need to be addressed. Here was > the error message (for the 1:2.4.3-6+b1 version of the pdl package from > Debian testing). > > *** PLPLOT WARNING *** > plParseOpts: function deprecated. Use plparseopts instead > perl: symbol lookup error: > /usr/lib/perl5/auto/PDL/Graphics/PLplot/PLplot.so: undefined symbol: plimage > > I tried a local change to the preferred plparseopts for one of the examples, > but I then got this message: > > Undefined subroutine &main::plparseopts called at > /home/software/plplot_cvs/HEAD/plplot_cmake/examples/perl/x01.pl line 93. > > Doug, assuming my version 1:2.4.3-6+b1 of perl/pdl contains your latest > PLplot interface work it appears both plparseopts and plimage are not > defined within pdl, and I expect if you check all the c_ definitions in > include/plplot.h you will find other components of the PLplot public API > which are currently missing from pdl and which will be needed to fill out > the remaining standard examples that have not been implemented yet. > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __ > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] My initial pre-release testing
Hi all: Sorry I've been unresponsive of late... I start to chip away at the addition of the perl/PDL examples that are missing. Regards, Doug Hunt [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Thu, 27 Nov 2008, Jerry wrote: > > On Nov 27, 2008, at 2:36 PM, Andrew Ross wrote: > >> >> Alan, >> >> I've also tried the latest svn version with -DHAVE_PTHREAD=ON >> -DBUILD_TEST=ON -DBUILD_DOC=ON on my Ubuntu Hardy system. Enabled >> drivers and bindings are the same as Alan, except that I don't have >> PDL/perl enabled. The -fvisibility=hidden option was added to the >> gcc / g++ command line. All code (including documentation) builds. >> There >> are some warnings for the Ada documentation. Ctest runs fine and >> results >> agree with Alan. > > It is normal and unavoidable to get a few warnings when compiling the > Ada bindings. I discussed this in the Ada documentation. I suppose we > could turn off the issuance of warnings to avoid alarming people but > that could backfire if other warnings arise later that should be heeded. > > Jerry > >> >> I also have a problem with tcl. I have tcl 8.5 installed but this >> doesn't come with itcl so the bindings won't build. Removing all >> references to 8.5 from cmake/modules/FindTCL.cmake and it >> does work (I also have tcl 8.4 + itcl installed). This is a bit of a >> pain, but I'm not sure there is a neat workaround except setting >> lots of >> cmake variables explicitly on the cmake command line. >> >> I've also built and tested all the examples in the install tree. The >> only issue I found is that the ocaml examples don't run. test_ocaml.sh >> assumes the examples are x??ocaml, as in the build tree, but the >> Makefile generates x?? executables. I'll try and fix this up tomorrow, >> unless anyone beats me to it. >> >> Otherwise looks good for a release so far. >> >> Andrew >> >> On Thu, Nov 27, 2008 at 10:49:50AM -0800, Alan Irwin wrote: >>> My initial pre-release testing (currently of revision 9023) has >>> been done >>> with cmake-2.6.2 (my first use of this version of cmake) with >>> default cmake >>> device-driver and bindings options except for -DBUILD_TEST=ON >>> -DHAVE_PTHREAD=ON -DENABLE_pdl=ON -DHAVE_ADA_2007=ON. My system is >>> Debian Lenny (testing) with all possible PLplot dependencies >>> installed. >>> >>> Here is the CMake summary that resulted: >>> >>> ENABLE_DYNDRIVERS: ON >>> DRIVERS_LIST: >>> cairo;gd;gcw;hpgl;mem;null;pbm;ps;psttf;svg;tk;tkwin;wxwidgets;xfig;x >>> win >>> DEVICES_LIST: >>> pdfcairo;pngcairo;pscairo;svgcairo;xcairo;gif;jpeg;png;gcw;hp7470;hp7 >>> 580;lj_hpgl;mem;null;pbm;ps;psttf;svg;tk;tkwin;wxwidgets;xfig;xwin >>> >>> Library options: >>> BUILD_SHARED_LIBS: ON PL_DOUBLE: ON >>> >>> Optional libraries: >>> HAVE_QHULL: ON WITH_CSA: ON >>> HAVE_FREETYPE: ON HAVE_PTHREAD: ON >>> HAVE_AGG: ON >>> >>> Language Bindings: >>> ENABLE_f77: ON ENABLE_f95: ON >>> ENABLE_cxx: ON ENABLE_java:ON >>> ENABLE_python: ON ENABLE_octave: ON >>> ENABLE_tcl: ON ENABLE_itcl:OFF >>> ENABLE_tk: ON ENABLE_itk: OFF >>> ENABLE_pdl: ON ENABLE_wxwidgets: ON >>> ENABLE_gnome2: ON ENABLE_pygcw: ON >>> ENABLE_ada: ON ENABLE_d: >>> ENABLE_ocaml: ON >>> >>> IOW, I test all aspects of the default devices and bindings >>> available on >>> Linux except for PLD_cgm (libcd not installed) and iTcl/iTk (not >>> available >>> on my Debian testing system). >>> >>> The build (done in parallel with -j3 for my Intel core duo >>> system), install, >>> and ctest were done without obvious errors. Here are the ctest >>> compare >>> results: >>> >>> c++ >>>Missing examples : >>>Differing examples : >>> f77 >>>Missing examples : >>>Differing examples : >>> f95 >>>Missing examples : >>>Differing examples : >>> java >>>Missing exa
Re: [Plplot-devel] My initial pre-release testing
Hi Alan, Jerry, PLplot list. I just started updating the perl/PDL examples for plplot and have run into a question. I updated x02.pl to clean it up and add the second plot that was missing (I have not checked anything into SVN yet). In order to make this work, I also had to update the PDL::Graphics::PLplot driver, which is part of the PDL distribution to add interfaces for some plplot routines not included before. A new PDL version is not likely to be forthcoming for a while, at least several months, perhaps a year. I also maintain a stand-alone version of PDL::Graphics::PLplot on CPAN, so I could put the required interface changes there. My question is this: Would it be better to have complete perl/PDL examples which depend upon an external PDL module from CPAN, or would it be better to have incomplete examples that are compatible with the latest PDL release? Regards, Doug Hunt [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Wed, 3 Dec 2008, Doug Hunt wrote: > Hi all: Sorry I've been unresponsive of late... I start to chip away at the > addition of the perl/PDL examples that are missing. > > Regards, > > Doug Hunt > > [EMAIL PROTECTED] > Software Engineer III > UCAR - COSMIC, Tel. (303) 497-2611 > > On Thu, 27 Nov 2008, Jerry wrote: > >> >> On Nov 27, 2008, at 2:36 PM, Andrew Ross wrote: >> >>> >>> Alan, >>> >>> I've also tried the latest svn version with -DHAVE_PTHREAD=ON >>> -DBUILD_TEST=ON -DBUILD_DOC=ON on my Ubuntu Hardy system. Enabled >>> drivers and bindings are the same as Alan, except that I don't have >>> PDL/perl enabled. The -fvisibility=hidden option was added to the >>> gcc / g++ command line. All code (including documentation) builds. >>> There >>> are some warnings for the Ada documentation. Ctest runs fine and >>> results >>> agree with Alan. >> >> It is normal and unavoidable to get a few warnings when compiling the >> Ada bindings. I discussed this in the Ada documentation. I suppose we >> could turn off the issuance of warnings to avoid alarming people but >> that could backfire if other warnings arise later that should be heeded. >> >> Jerry >> >>> >>> I also have a problem with tcl. I have tcl 8.5 installed but this >>> doesn't come with itcl so the bindings won't build. Removing all >>> references to 8.5 from cmake/modules/FindTCL.cmake and it >>> does work (I also have tcl 8.4 + itcl installed). This is a bit of a >>> pain, but I'm not sure there is a neat workaround except setting >>> lots of >>> cmake variables explicitly on the cmake command line. >>> >>> I've also built and tested all the examples in the install tree. The >>> only issue I found is that the ocaml examples don't run. test_ocaml.sh >>> assumes the examples are x??ocaml, as in the build tree, but the >>> Makefile generates x?? executables. I'll try and fix this up tomorrow, >>> unless anyone beats me to it. >>> >>> Otherwise looks good for a release so far. >>> >>> Andrew >>> >>> On Thu, Nov 27, 2008 at 10:49:50AM -0800, Alan Irwin wrote: >>>> My initial pre-release testing (currently of revision 9023) has >>>> been done >>>> with cmake-2.6.2 (my first use of this version of cmake) with >>>> default cmake >>>> device-driver and bindings options except for -DBUILD_TEST=ON >>>> -DHAVE_PTHREAD=ON -DENABLE_pdl=ON -DHAVE_ADA_2007=ON. My system is >>>> Debian Lenny (testing) with all possible PLplot dependencies >>>> installed. >>>> >>>> Here is the CMake summary that resulted: >>>> >>>> ENABLE_DYNDRIVERS: ON >>>> DRIVERS_LIST: >>>> cairo;gd;gcw;hpgl;mem;null;pbm;ps;psttf;svg;tk;tkwin;wxwidgets;xfig;x >>>> win >>>> DEVICES_LIST: >>>> pdfcairo;pngcairo;pscairo;svgcairo;xcairo;gif;jpeg;png;gcw;hp7470;hp7 >>>> 580;lj_hpgl;mem;null;pbm;ps;psttf;svg;tk;tkwin;wxwidgets;xfig;xwin >>>> >>>> Library options: >>>> BUILD_SHARED_LIBS: ON PL_DOUBLE: ON >>>> >>>> Optional libraries: >>>> HAVE_QHULL: ON WITH_CSA: ON >>>> HAVE_FREETYPE: ON HAVE_PTHREAD: ON >>>> HAVE_AGG: ON >>>> >>>> Language Bindings: >>>> ENABLE_f77: ON ENABLE_f95: ON >>>&
Re: [Plplot-devel] My initial pre-release testing
Alan: OK, lets do it like that! --Doug [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Wed, 3 Dec 2008, Alan W. Irwin wrote: > On 2008-12-03 17:09-0700 Doug Hunt wrote: > >> Hi Alan, Jerry, PLplot list. >> >> I just started updating the perl/PDL examples for plplot and have run into >> a question. >> >> I updated x02.pl to clean it up and add the second plot that was missing >> (I have not checked anything into SVN yet). In order to make this work, I >> also had to update the PDL::Graphics::PLplot driver, which is part of the >> PDL distribution to add interfaces for some plplot routines not included >> before. A new PDL version is not likely to be forthcoming for a while, >> at least several months, perhaps a year. >> >> I also maintain a stand-alone version of PDL::Graphics::PLplot on CPAN, so >> I could put the required interface changes there. >> >> My question is this: Would it be better to have complete perl/PDL >> examples which depend upon an external PDL module from CPAN, or would it >> be better to have incomplete examples that are compatible with the latest >> PDL release? > > I suggest the former, "complete perl/PDL examples which depend upon an > external PDL module from CPAN". Once that work is completed, I would be > willing to take responsibility for changing our build system to test for the > CPAN version of PDL and change the list of examples in test_perl.sh.in > appropriately depending on whether the current official PDL release or the > CPAN version is available. > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __ > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] My initial pre-release testing
Hi Alan: I've just checked an update to perl/x02.pl into SVN. It depends upon PDL-Graphics-PLplot-0.40 which I just uploaded to CPAN. I'll be working on updating/adding new examples over the next weeks--I expect it will take a while! I'll update PDL-Graphics-PLplot as necessary. Regards, Doug [EMAIL PROTECTED] Software Engineer IV UCAR - COSMIC, Tel. (303) 497-2611 On Thu, 4 Dec 2008, Doug Hunt wrote: > Alan: OK, lets do it like that! > > --Doug > > [EMAIL PROTECTED] > Software Engineer III > UCAR - COSMIC, Tel. (303) 497-2611 > > On Wed, 3 Dec 2008, Alan W. Irwin wrote: > >> On 2008-12-03 17:09-0700 Doug Hunt wrote: >> >>> Hi Alan, Jerry, PLplot list. >>> >>> I just started updating the perl/PDL examples for plplot and have run into >>> a question. >>> >>> I updated x02.pl to clean it up and add the second plot that was missing >>> (I have not checked anything into SVN yet). In order to make this work, I >>> also had to update the PDL::Graphics::PLplot driver, which is part of the >>> PDL distribution to add interfaces for some plplot routines not included >>> before. A new PDL version is not likely to be forthcoming for a while, >>> at least several months, perhaps a year. >>> >>> I also maintain a stand-alone version of PDL::Graphics::PLplot on CPAN, so >>> I could put the required interface changes there. >>> >>> My question is this: Would it be better to have complete perl/PDL >>> examples which depend upon an external PDL module from CPAN, or would it >>> be better to have incomplete examples that are compatible with the latest >>> PDL release? >> >> I suggest the former, "complete perl/PDL examples which depend upon an >> external PDL module from CPAN". Once that work is completed, I would be >> willing to take responsibility for changing our build system to test for the >> CPAN version of PDL and change the list of examples in test_perl.sh.in >> appropriately depending on whether the current official PDL release or the >> CPAN version is available. >> >> 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); PLplot scientific plotting software >> package (plplot.org); 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 >> __ >> > > ___ > Perldl mailing list > [EMAIL PROTECTED] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] My initial pre-release testing
Hi Alan: > I saw your commit of the revised example 2 for Perl/PDL. Since then I have > made some build-system changes (revision 9037) to change the list of what > Perl/PDL examples are executed depending on the CMake variable > HAVE_PDL_GRAPHICS_PLPLOT_40. Currently, example 02 and example 20 are > excluded from the list if that variable is not "ON". > > Could you follow up on my work by maintaining the two lists in > plplot_test/test_perl.sh.in as you continue to update the perl/pdl examples > and add new ones? Will do. > > Also, could you put some basic cookbook-style instructions in > examples/perl/README.perldemos so a perl newbie (like me) could download and > install PDL-Graphics-PLplot-0.40? I would like to test out your updated > examples. (My current installed version of PDL is 2.4.3-8 from Debian Lenny.) You should be able to download PDL-Graphics-PLplot-0.40.tar.gz from CPAN, then: tar -xvzf PDL-Graphics-PLplot-0.40.tar.gz cd PDL-Graphics-PLplot-0.40 perl Makefile.PL make make test make install It is also possible that a CPAN install from the perl 'cpan' tool would work. > > The current method of specifying HAVE_PDL_GRAPHICS_PLPLOT_40 is to set > either -DHAVE_PDL_GRAPHICS_PLPLOT_40=ON or -DHAVE_PDL_GRAPHICS_PLPLOT_40=OFF > (the default) as one of the cmake options. > I would like to replace that crude control method by one that automatically > tests the version of PDL-Graphics-PLplot that is available and sets > HAVE_PDL_GRAPHICS_PLPLOT_40 appropriately. To implement that, I need to > know a simple command you could execute from the command-line that could be > used to figure out whether version 0.40 (or later) of PDL-Graphics-PLplot is > installed or not. Do you have such a command to suggest to me? Ideally, > the command would succeed (return code 0) or fail (non-zero return code) > depending on whether 0.40 or later was installed, but other possibilities > (such as returning a version number and letting CMake decide whether that is >> = 0.40) would work as well. I just uploaded a new version to CPAN which should support this. Now: perl -MPDL::Graphics::PLplot -e 'print "$PDL::Graphics::PLplot::VERSION\n"' should work, printing '0.41'. A test of 0.41 or greater should suffice, as I know I'll be releasing 0.42 soon. > > I am very pleased to hear that you are actively working on the Perl/PDL > aspects of PLplot again. I hope to find enough time this time around! Regards, Doug > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __ > -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] My initial pre-release testing
Hi Alan: > > I would prefer to be able to switch back and forth between the official > Debian PDL interface to PLplot and this new version so I can compare results > for both versions. So what is the best way to set that up? I assume there > is a way to install to a separate install prefix so you don't overwrite the > system version. What is the syntax for that? Also, how do you hook up the > system versions of Perl and PDL with that separate install prefix for > PDL-Graphics-PLplot-0.40? I don't know how to do that easily. The best I can think of is to manipulate the perl5 library area directly: /ops/tools/lib/perl5/site_perl/5.10.0/i686-linux-thread-multi/PDL/Graphics/PLplot.pm /ops/tools/lib/perl5/site_perl/5.10.0/i686-linux-thread-multi/auto/PDL/Graphics/PLplot/* I know this is awfully ugly. Also, I've checked in updates to x20.pl which now is complete with support for plimagefr. This requires PDL-Graphics-PLplot-0.42, which is now on CPAN. Its odd to be releasing so many CPAN versions, but I'm trying to do this in complete chunks in case I get called away by other priorities... Thanks, Doug > >> I just uploaded a new version to CPAN which should support this [version > test]. >> Now: >> >> perl -MPDL::Graphics::PLplot -e 'print "$PDL::Graphics::PLplot::VERSION\n"' >> >> should work, printing '0.41'. A test of 0.41 or greater should suffice, as >> I know I'll be releasing 0.42 soon. > > Thanks for this. I just checked that the above command returns the null > string for the official Debian Lenny version (instead of erroring out) so it > should be straightforward to use this command inside a CMake execute_process > command to help set HAVE_PDL_GRAPHICS_PLPLOT_40. > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __ > -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] My initial pre-release testing
Hi Alan: I did correct some perl roundoff errors as part of fixing up x02.pl, but I've checked these changes in. Right now from my build of plplot, I don't see any difference in the postscript output: cd examples c/x02c -dev psc -o x02c.ps perl/x02.pl -dev psc -o x02perl.ps diff x02c.ps x02perl.ps 6c6 < %%CreationDate: Fri Dec 5 10:26:34 2008 --- > %%CreationDate: Fri Dec 5 10:26:50 2008 In particular, the line: 1. 0.0745 0.0745 C Z is present in both postscript files. I seem to have checked everything in to the plplot SVN, and I don't think there is any difference in our PDL-Graphics-PLplot-0.42 drivers. I don't know how you run your 'ctest' suite. Maybe there is some difference there? Is it possible you are running with an old x02.pl? Regards, Doug [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Fri, 5 Dec 2008, Alan W. Irwin wrote: > Hi Doug: > > I was able to get > http://search.cpan.org/CPAN/authors/id/D/DH/DHUNT/PDL-Graphics-PLplot-0.42.tar.gz > working. I have put my recipe for doing this into > examples/perl/README.perldemos (revision 9039), and I have also > completed my build system changes so that HAVE_PDL_GRAPHICS_PLPLOT_40 is > now (revision 9040) automatically determined. > > Here are the ctest results using your latest (version 0.42) tarball from > CPAN. > > perl > Missing examples : 27 28 29 30 > Differing examples : 02 08 21 23 > > I looked more closely at the example 2 difference since you worked on that > recently. I got context diff pairs similar to the following when comparing > the pdl and corresponding C example: > > -1. 0.0745 0.0745 C Z > +0.9961 0.0745 0.0745 C Z > > I don't understand PostScript that well, but these are RGB colour triplet > numbers. This diff (and many more) show your RGB triplets are not quite the > same as those set in the C example. I don't know whether your problem is > located in your PDL interface or example 2, but the issue needs further > investigation. That difference between 1.000 and 0.9961 seems quite > familiar to me. I think there used to be a similar problem (some cast from > integer to float not following the C example?) with Ada example 2, but I may > be remembering that wrong. > > The other example you recently worked on was 20, and the above results show > a perfect comparison for that which is an encouraging step forward. > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __ > -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] My initial pre-release testing
Hi Alan: I just checked in fixes to x21.pl and a new x27.pl. As to your question below, I'm working on a 32 bit system, so this could be a 32/64 bit bug. Regards, Doug [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC, Tel. (303) 497-2611 On Fri, 5 Dec 2008, Alan W. Irwin wrote: > On 2008-12-05 15:02-0700 Doug Hunt wrote: > >> Hi Alan: >> >>> Could you double check with a fresh checkout and clean build of PLplot and >>> a >>> fresh download and build of PDL-Graphics-PLplot-0.42.tar.gz? >> >> I did a fresh check-out and build of plplot and a fresh install of >> PDL-Graphics-PLplot-0.42 and I still get the same (correct) output from >> x02.pl, which is attached. Everything looks good on my end--the perl >> output matches the c output. > > It matches my C output here as well. > > So it appears we have some sort of platform or PDL Graphics PLplot module > difference which is, of course, a pain in the ass to figure out. > > Will someone else try testing Doug's updates, please, to see how widespread > the problem is? > >> >> I've also uploaded a new version of the PDL interface >> (PDL-Graphics-PLplot-0.43) to CPAN which allows one to specify the plplot >> library and include areas as environment variables instead of having to >> hack on the Makefile.PL, as per your question 1) from another email. >> >>> >>> In case our different results are due to some platform difference I am >>> running Debian lenny with perl 5.10.0-17 and pdl 1:2.4.3-8 and following >>> the >>> 0.42 update directions in examples/perl/README.perldemos. Could you >>> please >>> also review those update directions to be sure they are correct? >> >> I tried out the instructions you give in >> examples/perl/README.perldemos--the 'make install' step does not work on my >> machine, so I came up with another approach: specify the install directory >> on the 'perl Makefile.PL' step instead of the 'make install' step. I think >> this is more correct perl-wise. >> >> I've updated the README.perldemos file to include specifying plplot >> location in environment variables and specifying the install area on the >> 'perl Makefile.PL' step. I've not updated the SVN, but this file is >> attached. >> >> My guess is that you might not be running with the correct version of >> PDL-Graphics-PLplot. Could you try using the new instructions in >> README.perldemos and seeing if things make more sense after that? > > Sure, I will try. However, that build only produces a relatively small > number of files in the install tree so there is not too much that can go > wrong with symlinking the files from that special install area to the > correct place in the system PDL location. And it appears that method worked > fine to get example 20 in perfect shape. So I am looking for some other > reason (see below) to explain the different results we get for example 2, > but not for example 20 (which you fixed later). > > Are your present results for a 32-bit system or a 64-bit system? Mine is > 64-bit. If you have only tested on a 32-bit system, could you (and other > PDL testers here as well, I hope) test on a 64-bit system as well? The > agreement we get for the C examples shows there are no problems with example > 2 for the core C library. Thus, the disagreement for the PDL example 2 > could be explained either by a 64-bit bug in the second standard example > implemented in PDL or by a 64-bit bug in PDL::Graphics::PLplot that is > exposed by that example. > > I will also look at example 8 (probably tomorrow). > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __ > -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] My initial pre-release testing
Hi Alan: I've got perl/PDL versions of examples 28, 29 and 30 checked in. Their psc output is identical to the examples/c version. They require yet another version of PDL-Graphics-PLplot, version 0.45. Thanks for the pointer to 'ndiff', this will be useful for my regular work! As to the differing examples, for 02 there was some 32/64 bit trouble that you had--was your 'x02.pl -dev psc' output generally consistent with the correct 'x02c -dev psc' output and just off by a few decimal places, or was it wildly in error? Unfortunately, I don't have a good 64 bit machine handy to try it myself. I'm having trouble getting my hands around example 23--I can't get any of the 'c' examples to give correct comparison output except 'xwin'. I get some bogus or missing characters for all other driver types. Do you have any hints as to how to which 'c' example you use for comparison and how to get it to work correctly? My plplot installation may be missing something required to get all the character sets to work. Finally, example 27 (after your fix) seems to compare correctly with 'ndiff'. I took a look at it and did not see anything incorrect in the perl/PDL code. Regards, Doug > > perl > Missing examples : 28 29 30 > Differing examples : 02 23 27 > -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] My initial pre-release testing
Hi Alan: I've just checked in a version of x23.pl which adds the missing pages. My system is not configured correctly to display all the fonts, but the perl and c example .ps files generated on my system do end up identical. Please let me know how this looks on your (better configured) system. Not sure what to do about examples 2 and 27--Ex 2 works fine on my system and mostly fine on yours. Ex 27 is close as well. Regards, Doug dh...@ucar.edu Software Engineer IV UCAR - COSMIC, Tel. (303) 497-2611 On Wed, 10 Dec 2008, Alan W. Irwin wrote: > On 2008-12-10 15:32-0700 Doug Hunt wrote: > >> Hi Alan: >> >> I've got perl/PDL versions of examples 28, 29 and 30 checked in. >> Their psc output is identical to the examples/c version. >> >> They require yet another version of PDL-Graphics-PLplot, version 0.45. > > I have made the corresponding PLplot build-system changes (revision 9084). > > Here is the latest ctest result for PDL-Graphics-PLplot, version 0.45 > on my 64-bit machine. > > perl > Missing examples : > Differing examples : 02 23 27 > > I am really happy to see that empty "Missing examples" list. That represents > a substantial amount of work by you which is much appreciated. > >> >> Thanks for the pointer to 'ndiff', this will be useful for my regular work! >> >> As to the differing examples, for 02 there was some 32/64 bit trouble that >> you had--was your 'x02.pl -dev psc' output generally consistent with the >> correct 'x02c -dev psc' output and just off by a few decimal places, or was >> it wildly in error? Unfortunately, I don't have a good 64 bit machine >> handy to try it myself. > > Here is a typical diff stanza: > > 1162c1162 > < 1. 0.0745 0.0745 C Z > --- >> 0.9961 0.0745 0.0745 C Z > > There are 20 of these differences with the maximum R, G, or B colour changed > from 1. to 0.9961 for the pdl version. There are also some maximum R, > G, or B colours still left at 1. in the pdl version. The c version has > no 0.9961 colours. > >> >> I'm having trouble getting my hands around example 23--I can't get any of >> the 'c' examples to give correct comparison output except 'xwin'. I get >> some bogus or missing characters for all other driver types. Do you have >> any hints as to how to which 'c' example you use for comparison and how >> to get it to work correctly? My plplot installation may be missing >> something required to get all the character sets to work. > > fontconfig is essential for managing Linux fonts > in an intelligent way so make sure that package is installed. After that > run cmake with the -DBUILD_TEST=ON option and after the "make" command run > > ctest -R '_c$|perl|compare' > > The '_c$' ctest runs all the C examples with -dev psc, the 'perl' ctest runs > all the PDL examples with -dev psc, and the 'compare' ctest compares them. > > After the above ctest command, run > > less Testing/Temporary/LastTest.log > > to see details of the ctests including the summary output I gave in the > first paragraph of this post. > > Here are the sizes of the example 23 results > > -rw-r--r-- 1 software software 301933 2008-12-10 22:48 x23c.psc > -rw-r--r-- 1 software software 244809 2008-12-10 22:48 x23pdl.psc > > when I checked with diff, it turns out x23pdl.psc is missing pages 12 to 16, > but the first 11 pages are fine. > >> >> Finally, example 27 (after your fix) seems to compare correctly with >> 'ndiff'. I took a look at it and did not see anything incorrect in the >> perl/PDL code. > > Here is what I get with "ndiff -relerr 0.01" > > 6c6 > < %%CreationDate: Wed Dec 10 22:48:07 2008 > --- field 5 >> %%CreationDate: Wed Dec 10 22:48:19 2008 > ### Maximum relative error in matching lines = 4.29e-03 at line 11279 field 8 > > If I set the -relerr value to a smaller value such as 0.0001 then lots of > differences show up. > > As I remarked before, that maximum relative error of 4.29e-03 is rather high > (most other PDL examples match exactly with no differences at all) so I > assumed there was some precision loss for the bindings exercised by example > 27 or in example 27 itself. If your maximum ndiff rel error is 0., (in > which case diff would show no differences at all) then it appears we might > have another 32 bit/64-bit issue. But if the maximum relative error > delivered > by ndiff is non-zero for you as well, then I would look for precision loss. > > In sum, 02 might be a 32/64 bit i
Re: [Plplot-devel] [Perldl] My initial pre-release testing
Alan, Andrew: Thanks for finding/fixing these problems.
> You were correct it was a problem with the Perl math library. The main
> trouble I had in finding this was figuring out how to print out individual
> elements of a pdl array. For future reference, this worked:
>
> for (my $i = 0; $i < int($windings)*int($steps)+1; $i++) {
> printf("%f,%f,%f,%f\n", $phi->slice($i)->slice('(0)'),
> $phiw->slice($i)->slice('(0)'), $xcoord->slice($i)->slice('(0)'),
> $ycoord->slice($i)->slice('(0)'));
> }
You can also do this:
wcols $phi;
--That will print out all 20,000 elements of $phi in a single column. Or
this:
print $phi->mslice([0,99]);
That will print out the first 100 elements of $phi.
>
> The result showed the errors gradually increased with phi which lead me to
> the scale error in the PI value used in dphi.
>
> Here is the crux of that scale error.
> perldl> p 4*atan2(1,1)
> 3.14159265358979
> perldl> p acos(-1.)
> 3.14159274101257
>
> The first is the correct value of PI to the printed precision, the second
> is wrong in the 7th place. In contrast, the C math library (and every
> other language binding we have) calculates PI to full precision
> without problems for acos(-1.)
>
> Doug, will you please do the honors and make the appropriate bug report?
> This is ugly, and I am amazed such a perl math library error is still with
> us after all these years.
It turns out that 'acos' is not a *perl* function, but it is a *PDL*
function. So, I have more control over this--I'll look into it. Good
catch!
--Doug
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] My initial pre-release testing
Hi Alan: I just got the notification from PAUSE:
The uploaded file
PDL-Graphics-PLplot-0.46.tar.gz
has entered CPAN as
file: $CPAN/authors/id/D/DH/DHUNT/PDL-Graphics-PLplot-0.46.tar.gz
size: 36621 bytes
md5: 96ad2ef28fcff7869da9b5612f24ae26
No action is required on your part
Request entered by: DHUNT (Douglas Hunt)
Request entered on: Thu, 11 Dec 2008 20:22:33 GMT
Request completed: Thu, 11 Dec 2008 20:23:14 GMT
So I imagine it is just taking a bit of time to propagate.
Regards,
Doug
dh...@ucar.edu
Software Engineer IV
UCAR - COSMIC, Tel. (303) 497-2611
On Thu, 11 Dec 2008, Alan W. Irwin wrote:
> Hi Doug:
>
> http://search.cpan.org/dist/PDL-Graphics-PLplot/ still shows only version
> 0.45. Is it usual for it to take this long for your CPAN upload to
> propagate? I am anxious to finish off the PDL testing, but it appears
> "a watched pot never boils".
>
> More below
>
> On 2008-12-11 14:30-0700 Doug Hunt wrote:
>
>> Hi Alan:
>>
>> On my machine acos(-1) works better than on yours. That's why
>> x27 worked for me and not you:
>>
>> perldl> p acos(-1)
>> 3.14159265358979
>> perldl> p 4*atan2(1,1)
>> 3.14159265358979
>>
>> Could you send me a:
>>
>> perl -V
>
> Attached.
>
>>
>> and also run:
>>
>> perldl
>>
>> and send me the startup message? I'm curious
>> what versions of perl and PDL you are using.
>
> ***
> ir...@raven> perldl
> perlDL shell v1.33
> PDL comes with ABSOLUTELY NO WARRANTY. For details, see the file
> 'COPYING' in the PDL distribution. This is free software and you
> are welcome to redistribute it under certain conditions, see
> the same file for details.
> ReadLines, NiceSlice, MultiLines enabled
> Reading PDL/default.perldlrc...
> Found docs database /usr/lib/perl5/PDL/pdldoc.db
> Type 'help' for online help
> Type 'demo' for online demos
> Loaded PDL v2.4.3 (supports bad values)
>
> Note: AutoLoader not enabled ('use PDL::AutoLoader' recommended)
> ***
>
> Hope this information helps you to figure out what is wrong on my system
> with the PDL version of acos. These perl and PDL versions are default for
> Debian Lenny so once you figure out what is wrong, I will send a bug report
> to Debian.
>
> 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); PLplot scientific plotting software
> package (plplot.org); 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
> __
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] bad PDL acos
Hi Alan: Looking at the PDL code, 'acos' is defined for both 'float' PDLs
and 'double' PDLs based on the C library 'acos' function. It seems like
the single precision 'acos' is being called instead of the double
precision one. The value you get from 'p acos(-1.)' is the single
precision value:
perldl> p acos(float(-1))
3.14159274101257
perldl> p acos(double(-1))
3.14159265358979
Even odder: On my machine, I get this:
perldl> p acos(-1)
3.14159265358979
perldl> p acos(-1.)
3.14159274101257
(!)
It seems that if you put a decimal point in, the value is interpreted as a
'float', not a 'double'.
PDL folks: Any idea why -1 is interpreted as 'double' and '-1.' is
interpreted as 'float'??
Regards,
Doug
dh...@ucar.edu
Software Engineer IV
UCAR - COSMIC, Tel. (303) 497-2611
On Thu, 11 Dec 2008, Doug Hunt wrote:
> Alan, Andrew: Thanks for finding/fixing these problems.
>
>> You were correct it was a problem with the Perl math library. The main
>> trouble I had in finding this was figuring out how to print out individual
>> elements of a pdl array. For future reference, this worked:
>>
>> for (my $i = 0; $i < int($windings)*int($steps)+1; $i++) {
>> printf("%f,%f,%f,%f\n", $phi->slice($i)->slice('(0)'),
>> $phiw->slice($i)->slice('(0)'), $xcoord->slice($i)->slice('(0)'),
>> $ycoord->slice($i)->slice('(0)'));
>> }
>
> You can also do this:
>
> wcols $phi;
>
> --That will print out all 20,000 elements of $phi in a single column. Or
> this:
>
> print $phi->mslice([0,99]);
>
> That will print out the first 100 elements of $phi.
>
>>
>> The result showed the errors gradually increased with phi which lead me to
>> the scale error in the PI value used in dphi.
>>
>> Here is the crux of that scale error.
>> perldl> p 4*atan2(1,1)
>> 3.14159265358979
>> perldl> p acos(-1.)
>> 3.14159274101257
>>
>> The first is the correct value of PI to the printed precision, the second
>> is wrong in the 7th place. In contrast, the C math library (and every
>> other language binding we have) calculates PI to full precision
>> without problems for acos(-1.)
>>
>> Doug, will you please do the honors and make the appropriate bug report?
>> This is ugly, and I am amazed such a perl math library error is still with
>> us after all these years.
>
> It turns out that 'acos' is not a *perl* function, but it is a *PDL*
> function. So, I have more control over this--I'll look into it. Good
> catch!
>
> --Doug
>
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ___
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] My initial pre-release testing
Hi Alan:
On my machine acos(-1) works better than on yours. That's why
x27 worked for me and not you:
perldl> p acos(-1)
3.14159265358979
perldl> p 4*atan2(1,1)
3.14159265358979
Could you send me a:
perl -V
and also run:
perldl
and send me the startup message? I'm curious
what versions of perl and PDL you are using.
This test is also simple enough that I can try it on one of our 64 bit
'production' machines. On this machine (which uses an earlier
version of PDL) it also works fine for me.
Regards,
Doug
dh...@ucar.edu
Software Engineer IV
UCAR - COSMIC, Tel. (303) 497-2611
On Thu, 11 Dec 2008, Alan W. Irwin wrote:
> On 2008-12-11 14:48- Andrew Ross wrote:
>
>> This [example 02 issues] was merely a slight difference between examples.
>> In the perl
>> version the 0-1 numbers were multiplied by 255, as opposed to 255.001 in
>> the C version. Fix this and the results are identical. I've committed
>> this to svn.
>
> Thanks, Andrew, for spotting that.
>
>> This [example 27 issues] looks like small rounding errors to me.
>> Coordinates are never
>> out by more than 1.
>
> You were correct it was a problem with the Perl math library. The main
> trouble I had in finding this was figuring out how to print out individual
> elements of a pdl array. For future reference, this worked:
>
> for (my $i = 0; $i < int($windings)*int($steps)+1; $i++) {
> printf("%f,%f,%f,%f\n", $phi->slice($i)->slice('(0)'),
> $phiw->slice($i)->slice('(0)'), $xcoord->slice($i)->slice('(0)'),
> $ycoord->slice($i)->slice('(0)'));
> }
>
> The result showed the errors gradually increased with phi which lead me to
> the scale error in the PI value used in dphi.
>
> Here is the crux of that scale error.
> perldl> p 4*atan2(1,1)
> 3.14159265358979
> perldl> p acos(-1.)
> 3.14159274101257
>
> The first is the correct value of PI to the printed precision, the second
> is wrong in the 7th place. In contrast, the C math library (and every
> other language binding we have) calculates PI to full precision
> without problems for acos(-1.)
>
> Doug, will you please do the honors and make the appropriate bug report?
> This is ugly, and I am amazed such a perl math library error is still with
> us after all these years.
>
> I have just calculated PI using atan2 for the example (revision 9087) and
> the results are now
>
> perl
> Missing examples :
> Differing examples : 23
>
> So we are close to perfection.
>
> I notice Doug has already uploaded a fix for example 23 so we may be
> PDL-perfect shortly. However, it is taking a while to propagate version 0.46
> of Doug's PDL Graphics, PLplot package at CPAN so I will have to wait to
> make the final test.
>
> 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); PLplot scientific plotting software
> package (plplot.org); 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
> __
>
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] My initial pre-release testing
You're welcome! Sorry it took me so long to get to this! --Doug dh...@ucar.edu Software Engineer IV UCAR - COSMIC, Tel. (303) 497-2611 On Fri, 12 Dec 2008, Andrew Ross wrote: > On Thu, Dec 11, 2008 at 02:49:59PM -0800, Alan Irwin wrote: >> The ctest result for Perl/PDL is now perfect. >> >> perl >>Missing examples : >>Differing examples : >> >> Good work, Doug! >> >> I will finish off the build system tweaks, and also put in a paragraph >> in README.release about your accomplishment. > > Alan, > > I can confirm your test results on 32-bit intel Ubuntu Hardy. Excellent > effort Doug. Nice to see the perl bindings looking so good. > > Andrew > -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Troubling PDL behavior with constants
Hi all: When testing the new PDL interface to plplot, we came across this
odd PDL behavior:
use PDL;
print "acos(-1.) = ", acos(-1.), "\n";
print "acos(-1 ) = ", acos(-1 ), "\n";
The acos(-1.) version incorrectly gives a single precision result, whereas
the acos(1) version gives the expected double precision result. This is
due to the fact that there is no integer version of acos and PP routines
default to 'double' instead of float in this case.
This stems from the fact that:
perldl> p PDL::get_datatype(-1.)
5 # $PDL_F
Which seems odd--most PDL operations default to double precision.
After a bit of digging with gdb, it turns out this is caused by:
From: pdlcore.c.PL
/* Check minimum, at least float, datatype required to represent number */
int pdl_whichdatatype_double (double nv) {
TESTTYPE(PDL_F,PDL_Float)
TESTTYPE(PDL_D,PDL_Double)
if( !finite(nv) ) { return PDL_D; }
croak("Something's gone wrong: %lf cannot be converted by
whichdatatype_double",
nv);
}
So, I would like to propose one of two remedies (attached).
The first (pdlcore.c.PL.diff) would be to get rid of
pdl_whichdatatype_double and just assume that scalars convert to doubles,
not floats. This would be a change to a long-standing rule, but I think
it would be sensible. It breaks one test in conv.t that was specifically
designed to verify this behavior--that test would have to be changed.
Another approach would be to leave the 'PDL::get_datatype(-1.) == $PDL_F'
problem alone and just fix 'acos' and the rest of the math functions that
can return either float or double values. The other attached patch
(math.pd.diff) just changes
GenericTypes => ['F', 'D']
to
GenericTypes => ['D', 'F']
in several pp_def calls. This has less impact, but solves the irksome
'acos(-1.) != acos(-1)' problem without changing the fact that '1.'
defaults to 'float' instead of 'double'.
I've tested both of these out and (with the exception of the conv.t test)
they both pass the test suite and solve the problem.
Any ideas on which approach to take?
Regards,
Doug
dh...@ucar.edu
Software Engineer IV
UCAR - COSMIC, Tel. (303) 497-2611*** ./Basic/Core/pdlcore.c.PL.orig Wed Nov 12 21:13:53 2008
--- ./Basic/Core/pdlcore.c.PL Fri Dec 12 17:56:11 2008
***
*** 175,192
nv);
}
- /* Check minimum, at least float, datatype required to represent number */
-
- int pdl_whichdatatype_double (double nv) {
- TESTTYPE(PDL_F,PDL_Float)
- TESTTYPE(PDL_D,PDL_Double)
-
- if( !finite(nv) ) { return PDL_D; }
-
- croak("Something's gone wrong: %lf cannot be converted by
whichdatatype_double",
- nv);
- }
-
#ifdef _MSC_VER
#pragma optimize("", on)
#endif
--- 175,180
***
*** 258,293
/* Figure datatype to use */
if ( !SvIOK(sv) && SvNOK(sv) && SvNIOK(sv) ) {/* Perl Double (e.g.
2.0) */
data = SvNV(sv);
!
! !NO!SUBS!
!
! # XXX HACK this may not be sensible (DJB 08/31/00)
! # - only relevant if BADVAL_USENAN is true in config file
! #
!
! if ( $bvalflag and $usenan ) {
!print OUT <<'!NO!SUBS!';
!
! /*
!* default NaN/Infs to double
!* XXX sensible ?
!*/
! if ( finite(data) == 0 ) {
! datatype = PDL_D;
! } else {
! datatype = pdl_whichdatatype_double(data);
! }
!
! !NO!SUBS!
! } else {
!
!print OUT "\tdatatype = pdl_whichdatatype_double(data);\n";
!
! } # if: $bvalflag
!
! print OUT <<'!NO!SUBS!';
!
! }
else { /* Perl Int (e.g. 2) */
data = SvNV(sv);
datatype = pdl_whichdatatype(data);
--- 246,253
/* Figure datatype to use */
if ( !SvIOK(sv) && SvNOK(sv) && SvNIOK(sv) ) {/* Perl Double (e.g.
2.0) */
data = SvNV(sv);
! datatype = PDL_D;
!}
else { /* Perl Int (e.g. 2) */
data = SvNV(sv);
datatype = pdl_whichdatatype(data);
*** ./Basic/Math/math.pd.orig Wed Nov 12 21:13:54 2008
--- ./Basic/Math/math.pdFri Dec 12 17:49:11 2008
***
*** 167,173
pp_def($func,
HandleBad => 1,
NoBadifNaN => 1,
! GenericTypes => ['F','D'],
Pars => 'a(); [o]b();',
Inplace => 1,
Doc => inplace_doc( $func ),
--- 167,173
pp_def($func,
HandleBad => 1,
NoBadifNaN => 1,
! GenericTypes => ['D','F'],
Pars => 'a(); [o]b();',
Inplace => 1,
Doc => inplace_doc( $func ),
***
*** 205,211
pp_def($func,
HandleBad => 1,
NoBadifNaN => 1,
! GenericTypes => ['F','D'],
Pars => 'a(); [o]b();',
Inplace => 1,
Doc => inplace_doc( $func ),
--- 205,211
pp_def($func,
HandleBad => 1,
Re: [Plplot-devel] plplot 5.9.1 / PDL problems
Orion: Do you know what device was being tested (psc, pngcairo, etc)? Could you send me the full install directory for PDL-Graphics-PLplot 0.46 after you build it? That should have "PLplot.xs", line 25179 in it. Do you know what version of perl you are using "perl -V"? Regards, Doug Hunt dh...@ucar.edu Software Engineer IV UCAR - COSMIC, Tel. (303) 497-2611 On Thu, 18 Dec 2008, Orion Poplawski wrote: > I'm trying to build plplot 5.9.1 for Fedora rawhide and getting the > following error: > > x16.pl > > Assertion ((svtype)((_svi)->sv_flags & 0xff)) >= SVt_RV failed: file > "PLplot.xs", line 25179 at > /builddir/build/BUILD/plplot-5.9.1/examples/perl/x16.pl line 186. > -- Process completed > > ***Failed > > > This is with a patched version of PDL 2.4.4 using the > PDL-Graphics-PLplot 0.46 module from cpan. > > > Thoughts? > > x16.pl line 186: > > plshades ($z, -1., 1., -1., 1., $shedge, $fill_width, > $cont_color, $cont_width, 1, 0, 0, 0); > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA DivisionFAX: 303-415-9702 > 3380 Mitchell Lane or...@cora.nwra.com > Boulder, CO 80301 http://www.cora.nwra.com > > -- > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] x31.pl in progress
Hi Alan: Happy new year (almost) and Merry Christmas! I fixed plgfnam and added plcalc_world to the just-released PDL-Graphics-PLplot-0.47. I've got rid of your FIXMEs in x31.pl and checked it in. Both psc output and stdout now match the C version. I'm still mulling over what to do about the scrambled argument order in many calls, fixing that (and cleaning up the rest of the interface) will be a big task! Best Regards, Doug dh...@ucar.edu Software Engineer IV UCAR - COSMIC, Tel. (303) 497-2611 On Thu, 18 Dec 2008, Alan W. Irwin wrote: > On 2008-12-18 13:19-0800 Alan W. Irwin wrote: > >> Hi Doug: >> >> The subject line pretty much says it all, but I wanted to make sure you >> got that information so we didn't duplicate effort. >> >> Once I have completed x31.pl, perl/pdl will have a perfect ctest compare >> result again. > > Well, I completed an initial version of x31.pl (revision 9199), but it turns > out that PDL::Graphics::PLplot needs to define plcalc_world and also needs > to revise plgfnam so that it works. (See comments near the various FIXME's > in x31.pl.) Could you please make the appropriate changes to > PDL::Graphics::PLplot? I would also appreciate you looking over x31.pl and > letting me know (a) what to do about the SYNC comment, and (b) letting me > know if you prefer a different style. > > There is one style issue I should discuss further with you. I found out by > happy accident that I didn't need to use the PDL->new(0) construct to set up > variables that will be filled by passing back arguments of plg functions. > > So instead of > > my $compression2 = PDL->new(0); > plgcompression ($compression2); > > I used the simpler method > > my $compression2 = plgcompression (); > > At least the simpler method appears to work for all the many plg functions > that are exercised by example 31, and I assume it takes care of all memory > management issues transparently. It's not clear that memory management is > okay if you pass back values through arguments specified by the user as in > the more complex method above. For example, what happens if some of the > passed back arguments are floats and others integers on platforms where > those are different sizes? > > I also notice x23.pl uses the more complex method while x01.pl uses the > simpler method (for plgver) and x14.pl uses the simpler method (for plgdev). > I just checked that "perl/x14.pl -dev xwin" worked fine. > Do you think it is a good idea to change x23.pl to use the simpler method? > > I also noticed for plgver that it will not accept any arguments. I assume > that is a good thing since passing back strings through arguments is > notorious for buffer overflow problems. So probably something has to be done > to plgfnam in PDL::Graphics::PLplot to make it conform to the plgver (and > plgdev?) style of passing back the string. > > Once you have updated PDL::Graphics::PLplot, you may want to also update > x31.pl or alternatively I can do that. In any case I will be happy to do > the required build-system changes for the new version of > PDL::Graphics::PLplot. > > I am looking forward to having an absolutely clean ctest compare result > for perl/PDL again. > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __ > -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plotting to a subregion of memory
Hi David: I hope your change does not alter the memory layout for the mem driver. The point of this driver is that external programs can give plplot an image to 'decorate'. I've got routines that rely on a certain layout of memory for the mem driver--best to preserve that! Regards, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Fri, 19 Jun 2009, David Gillard wrote: > I've been working with the mem driver. I need to be able to plot some data to > a subregion of an image in memory. Suppose for instance that you've set the > image memory to have dimensions 500 x 500, and you want to plot to a 200 x > 200 subregion of that memory with top left coordinate (60, 100). > > I can't see how to do this properly without modifying the source code, > because the memory for the subregion is not continuous. Right now, I've added > a c_plssubmem function to plcore.c which takes the dimensions and top left > coordinate of the subregion (provided plsmem is called prior), and modified > plD_line_mem in mem.c . > > Is there a better way to do this? If not, is this capability one that would > be good to have as part of the plplot source? > > > -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Trouble compiling current head on F11
Hi all: After just building a set of custom RPMs for the new plplot and all its dependencies (including cmake), I would just as soon not see plplot's build system changed again soon. I also struggle with understanding cmake (I have not spent much time on it, but it seems confusing) but a change in something as basic as the build system imposes a fair amount of work on users. I find autoconf confusing as well, for what its worth. I would bet a python or perl-based system would also end up being tricky and full of odd platform-dependent quirks. So, here's one vote for stability! Thanks, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Fri, 19 Jun 2009, Hazen Babcock wrote: > Werner Smekal wrote: >> Hi Geoffrey, >>> But what about Python? If I was trying to build a system from >>> scratch with >>> the same goals as cmake (as far as I understand that from the >>> reading that I >>> have done about it), there is no way on earth I would've started off >>> by >>> defining a new language. Especially not a quirky, byzantine >>> language. Isn't >>> Python on every platform that cmake is on? Wouldn't it make a lot >>> more sense >>> to have used a "real language", with great data structures, and >>> libraries, >>> and a module system, and all that? >> >> Introducing scons: http://www.scons.org/ - more or less the same aims >> then cmake, but all in Python. But at the time when we changed the >> build system, it just wasn't up to the task. I tried it for one of my >> bigger projects and failed, since it didn't get the basic things right >> - e.g. project files for Visual C++. And in my opinion the whole >> structure to configure things was not well "developed". Although the >> project was quite "big", it didn't depend on many 3rd party libraries, >> but the configure files where quite big. And I had to configure things >> for every operating system I used - this is much better done by cmake. > > I'm also a Python fan, and I also struggle with CMake, but my impression > is that the last line of the comparison with CMake section at the link > below captures the current situation pretty well: > > "To sum up, my very subjective opinion is that scons is a better idea, > but CMake has a stronger implementation " > > http://www.scons.org/wiki/SconsVsOtherBuildTools#head-3d0faf3f1d4d3b73f31eaa0ba97d4df18a474369 > > -Hazen > > -- > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PDL::Graphics:PLplot test
Hi Orion: Sorry about not putting the license in. I'll add a COPYRIGHT file for the next release. It will be under a perl Artistic License: Copyright (c) 2004-2009 Douglas Hunt. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. Regards, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Thu, 10 Sep 2009, Orion Poplawski wrote: > On 09/10/2009 08:32 AM, Doug Hunt wrote: >> Hi Alan, Orion: I will try to fit in updates to PDL::Graphics::PLplot >> soon. I would recommend a separate RPM for PDL::Graphics::PLplot, even >> though it might seem like overkill. I'm working on an RPM-based >> distribution for software we use at work and I've followed this route. >> >> Since PLplot is changing quickly, and since the release cycle for PDL is >> slower, I've always found it useful to have a separate >> PDL::Graphics::PLplot package. > > Okay, I'll start packaging it separately. One issue though - the separate > release doesn't appear to be released under any kind of license - which I > believe puts it as "Public Domain" by default. > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA DivisionFAX: 303-415-9702 > 3380 Mitchell Lane or...@cora.nwra.com > Boulder, CO 80301 http://www.cora.nwra.com > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PDL::Graphics:PLplot test
Hi Alan, Orion: I will try to fit in updates to PDL::Graphics::PLplot soon. I would recommend a separate RPM for PDL::Graphics::PLplot, even though it might seem like overkill. I'm working on an RPM-based distribution for software we use at work and I've followed this route. Since PLplot is changing quickly, and since the release cycle for PDL is slower, I've always found it useful to have a separate PDL::Graphics::PLplot package. Regards, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Wed, 9 Sep 2009, Alan W. Irwin wrote: > On 2009-09-09 16:56-0600 Orion Poplawski wrote: > >> On 09/09/2009 04:48 PM, Alan W. Irwin wrote: >>> On 2009-09-09 14:25-0600 Orion Poplawski wrote: >>> Is there any way to force HAVE_PDL_GRAPHICS_PLPLOT_40 to be true? The way PDL is packaged in Fedora, PDL::Graphics::PLplot does not return a version, but it is using version 0.50 so it will work. >>> >>> Hi Orion: >>> >>> This is mostly directed to you, but I hope Doug will take an interest >>> in this thread as well. >>> >>> What do you get when you run the following command from the command line: >>> >>> perl -MPDL::Graphics::PLplot '-e print >>> "$PDL::Graphics::PLplot::VERSION\n"' >>> >>> ? >>> >>> I think Doug recommended this command previously to me to determine module >>> version, but if he has a better/more reliable suggestion now for >>> determining >>> the PDL::Graphics::PLplot version, that would be great. >>> >>> I just downloaded and installed version 0.51 of Doug's PLplot module from >>> CPAN, and the result I get from the above command is 0.51 (as expected). >>> Previously I had downloaded and installed version 0.47 of the same module >>> and version determination worked the same way for that version as well. So >>> I think the above command to determine version should normally be >>> working for version 0.50 on Fedora as well. >>> >>> Anyhow, let me know the results of the above command (which is also used >>> in >>> cmake/modules/pdl.cmake to figure out the module version), and we can take >>> it from there. >> >> I've been packaging the perl-PDL package for Fedora as well recently, so we >> have flexibility. >> >> Currently the way I'm packaging PDL is to copy in plplot.pd and plplot.t >> from the PDL-Graphics-PLplot tarball into the PDL 2.4.4_05 distribution. >> At this point, I have to strip the VERSION line from plplot.pd or make >> check for PDL fails with a object version mismatch error from >> DynaLoader.pm. >> >> I guess another possibility is to strip PDL::Graphics::PLplot completely >> from the PDL package and package it separately. But I don't want to do >> this if the main PDL package will eventually catch up. > > I "install" Doug's latest work by copying three files from my > PDL::Graphics::PLplot build results to > /usr/lib/perl5/PDL/Graphics/PLplot.pm, > /usr/lib/perl5/auto/PDL/Graphics/PLplot/PLplot.so, and > /usr/lib/perl5/auto/PDL/Graphics/PLplot/PLplot.bs. For a full install, I > guess I should copy a man page too. I do agree that packaging ~4 files as a > separate rpm sounds like overkill, but maybe that is what you need to do as > a temporary measure until PDL catches up with Doug's work. > > The latest results with reguard to version 0.51 of the module are > > perl > Missing examples: > Differing postscript output : 03 16 19 29 > Missing stdout : > Differing stdout: 14 > > IIRC, those agree with results from version 0.47 of the module. > > These last two questions are directed to Doug. > > Is it possibly you are waiting until you get the above issues all cleaned up > (which requires PDL::Graphics::PLplot API updates as well as fairly trivial > changes to the examples to use that new API) before you ask PDL to include > your latest version of PDL::Graphics::PLplot? > > If PDL will not include your latest version of PDL::Graphics::PLplot in the > near term for whatever reason, then do you have a suggestion for Orion about > the best way to integrate that latest version with PDL? > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __ > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Rep
Re: [Plplot-devel] [PATCH] Support arbitrary storage of 2D user data
Hi Alan, all: Would this change require re-writing the perl interface to the 2D functions? Would this be required right away, or would there be backwards compatible variants left around to ease the transition? It might be useful to know which demos are affected by this. Thanks, Doug Hunt dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Tue, 16 Feb 2010, Alan W. Irwin wrote: > On 2010-02-15 14:10-0500 Hazen Babcock wrote: > >> David MacMahon wrote: >>> Adds support for arbitrary storage of 2D user data. This is very >>> similar to the technique employed by some existing functions (e.g. >>> plfcont and plfshade) that use "evaluator" functions to access 2D user >>> data that is stored in an arbtrary format. The new approach extends >>> the concept of a user-supplied (or predefined) "evaluator" function to a >>> group of user-supplied (or predefined) "operator" functions. The >>> operator functions provide for various operations on the arbitrarily >>> stored 2D data including: get, set, +=, -=, *=, /=, isnan, and minmax. >>> >>> To facilitate the passing of an entire family of operator functions (via >>> function pointers), a plf2ops_t structure is defined to contain a >>> pointer to each type of operator function. Predefined operator >>> functions are defined for several common 2D data storage techniques. >>> Variables (of type plf2ops_t) containing function pointers for these >>> operator functions are also defined. >>> >>> New variants of functions that accept 2D data are created. The new >>> variants accept the 2D data as two parameters: a pointer to a plf2ops_t >>> structure containing (pointers to) suitable operator functions and a >>> PLPointer to the actual 2D data store. Existing functions that accept >>> 2D data are modified to simply pass their parameters to the >>> corresponding new variant of the function, along with a pointer to the >>> suitable predefined plf2ops_t stucture of operator function pointers. >>> >>> The list of functions for which new variants are created is: >>> c_plimagefr, c_plmesh, c_plmeshc, c_plot3d, c_plot3dc, c_plot3dcl, >>> c_plsurf3d, and c_plsurf3dl, and c_plgriddata. The new variants are >>> named the same as their corresponding existing function except that the >>> "c_" prefix is changed to "plf" (e.g. the new variant of c_plmesh is >>> called plfmesh). >>> >>> Adds plfvect declaration to plplot.h and changes the names (and only the >>> names) of some plfvect arguments to make them slightly clearer. In >>> order to maintain backwards API compatibility, this function and the >>> other existing functions that use "evaluator" functions are NOT changed >>> to use the new operator functions. >>> >>> Makes plplot.h and libplplot consistent vis-a-vis pltr0f and pltr2d. >>> Moves the definitions of pltr2f (already declared in plplot.h) from the >>> sccont.c files of the FORTRAN 77 and Fortran 95 bindings into plcont.c. >>> Removes pltr0f declaration from plplot.h. >>> --- >>> bindings/f77/sccont.c | 182 -- >>> bindings/f95/sccont.c | 182 -- >>> include/plplot.h | 196 +++-- >>> src/CMakeLists.txt|1 + >>> src/plcont.c | 207 +- >>> src/plf2ops.c | 397 >>> + >>> src/plgridd.c | 119 --- >>> src/plimage.c | 16 ++- >>> src/plot3d.c | 212 +-- >>> src/plshade.c |8 +- >>> src/plvect.c | 17 +-- >>> 11 files changed, 1004 insertions(+), 533 deletions(-) >>> create mode 100644 src/plf2ops.c >> >> Unless anyone objects I will test & commit this change in about a week. > > I think we need more time than that. How about two weeks, instead? It > concerns me there has been no discussion of this API since David sent in the > patch. If you like it please say so! Of course, if you don't like it, say > so as well! > > I want to emphasize there was consensus on list (lead by Maurice) that an > API to handle arbitrary 2D data storage was well worth having, and I am > certainly willing to go along with that major change. However, I think it is > important for everyone with good C skills here (that let's me out!) to take > a good look at the overview of this implementat
Re: [Plplot-devel] Disabling Perl/PDL examples in tests
Hi Alan: I will try to start adding in new perl/PDL tests to cover the API changes. Regards, Doug Hunt dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Tue, 12 Apr 2011, Alan W. Irwin wrote: > As of revision 11696 I have disabled Perl/PDL examples in tests by > default as a signal that Perl/PDL is a language that no longer > completely supports PLplot. > > The reason for this change is that the external PDL::Graphics::PLplot > project is missing too much of the new PLplot functionality. For > example, according to the Changes file at > http://search.cpan.org/~dhunt/PDL-Graphics-PLplot-0.52, the last > attempt to update the PDL::Graphics::PLplot to be consistent with new > PLplot API was for PDL-Graphics-PLplot-0.46 which was released more > than two years ago. > > I would be happy to reinstate the Perl/PDL tests by default and also > help a bit with the necessary Perl/PDL example propagation to obtain > consistency with our C examples results once PDL::Graphics::PLplot has > been updated to include the new PLplot API that has been developed > over the last couple of years. > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __ > > -- > Forrester Wave Report - Recovery time is now measured in hours and minutes > not days. Key insights are discussed in the 2010 Forrester Wave Report as > part of an in-depth evaluation of disaster recovery service providers. > Forrester found the best-in-class provider in terms of services and vision. > Read this report now! http://p.sf.net/sfu/ibm-webcastpromo > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel > -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of perl/pdl examples
Hi Alan: I've been working on the perl/PDL demos for the last couple of days. I noticed the problem with the deprecated plplot functions. When I'm done, I'll release a new version of PDL::Graphics::PLplot which detects the version of PLplot and does the right thing. At that time, the instructions should be easier. Regards, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Fri, 15 Apr 2011, Alan W. Irwin wrote: > Hi Doug: > > As you know I have recently disabled the Perl/PDL examples by default. > However, that does not preclude trying the examples using the PLplot > cmake option -DENABLE_pdl=ON. When I did that today, there were some > complications due to the recently removed deprecated functions, and > the soname version bump that occurred for the 5.9.7 release and which > will occur again for the 5.9.8 release (partially due to those removed > deprecated functions). > > I have appropriately updated the PDL::Graphics::PLplot-0.52 build and > install instructions at examples/perl/README.perldemos. Note, those > instructions include patching plplot.pd as per > examples/perl/plplot.pd.patch to consistently remove deprecated API > from PDL::Graphics::PLplot that has also been recently removed from > PLplot. > > Here are the current diff results for the Perl/PDL examples against > the corresponding C versions. > > perl > Missing examples: 33 > Differing postscript output : 03 04 16 18 19 25 26 27 29 30 > Missing stdout : > Differing stdout: > > The widespread nature of these differences was my original motivation > for disabling testing of the Perl/PDL examples by default, but all the > complications you have to go through as indicated in > examples/perl/README.perldemos to even perform this test is another > excellent reason for disabling the tests of the Perl/PDL examples by > default for now. > > Of course, once you have adjusted PDL::Graphics::PLplot to be > consistent with the latest updated PLplot API for the svn trunk > version (which will soon turn into the 5.9.8 release), then the > instructions in examples/perl/README.perldemos (which I hope you > update when the time comes) should be much simpler, and I presume that > will allow us to enable Perl/PDL by default again. > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __ > -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of perl/pdl examples
Hi Alan: I've just checked in a bunch of changes to the perl/PDL test suite for plplot. Now all perl/PDL examples match the C examples when you use PDL-Graphics-PLplot-0.55, which I just uploaded to CPAN. Regards, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Fri, 15 Apr 2011, Alan W. Irwin wrote: > On 2011-04-15 13:33-0600 Doug Hunt wrote: > >> Hi Alan: I've been working on the perl/PDL demos for the last couple of >> days. I noticed the problem with the deprecated plplot functions. When >> I'm done, I'll release a new version of PDL::Graphics::PLplot which detects >> the version of PLplot and does the right thing. > > Hi Doug: > > That sounds good. Note, we always wait to bump the soversion until > the release (of 5.9.8 in this case) to insure avoidance of multiple > soversion bumps during a release cycle. So the soversion for the core > plplot C library is currently 10 (see > cmake/modules/plplot_version.cmake). That is the soversion associated > with the 5.9.7 release, but note it will be 11 for the 5.9.8 release > (in part to mark the removal in 5.9.8 of the previously deprecated > functions that were in 5.9.7). > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __ > -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] CPAN Testers Daily Summary Report for PDL-Graphics-PLplot-0.55: What gives?
Hi: I got your email address from the 'Find A Tester' page referenced
below. I don't understand this CPAN test summary for my recently released
module PDL-Graphics-PLplot-0.55.
Looking closely at one error report:
http://www.cpantesters.org/cpan/report/b6a7ac18-73c8-11e0-9c74-cad5bcb8094c
it seems that a pre-requisite for PDL-Graphics-PLplot-0.55 (PDL) was
selected (version 2.4.9--the most recent) and a 'make test' of this is
shown. At the end, I see this:
---
MISSING PREREQUISITES:
It was observed that the test suite seem to fail without these modules:
PDL::Graphics::PLplot
As such, adding the prerequisite module(s) to 'PREREQ_PM' in your
Makefile.PL should solve this problem. For example:
WriteMakefile(
AUTHOR => 'DHUNT (cpanplus-i...@lists.sf.net)',
... # other information
PREREQ_PM => {
'PDL::Graphics::PLplot' => '0', # or a minimum working version
}
);
---
which is odd, since PDL::Graphics::PLplot is what we are trying to test.
I really don't understand what is going on here--it seems my module
(PDL-Graphics-PLplot-0.55.) is failing on most all architectures and perl
versions.
Any help or insight would be appreciated!
--Doug Hunt
dh...@ucar.edu
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611
On Mon, 2 May 2011, CPAN Tester Report Server wrote:
> Dear Douglas Hunt,
>
> Please find below the latest reports for your distributions, generated by
> CPAN Testers, from the last 24 hours.
>
> To set your preferences for what you wish to have reported in this Daily
> Summary, please visit the CPAN Testers Preferences system at
> https://prefs.cpantesters.org.
>
>
> PDL-Graphics-PLplot-0.55:
> - amd64-freebsd / 5.12.1:
> - FAIL
> http://www.cpantesters.org/cpan/report/3b88031e-73c0-11e0-9c74-cad5bcb8094c
>
> - amd64-freebsd / 5.12.2:
> - FAIL
> http://www.cpantesters.org/cpan/report/cc038928-7423-11e0-9c74-cad5bcb8094c
>
> - amd64-freebsd-thread-multi / 5.10.1:
> - FAIL
> http://www.cpantesters.org/cpan/report/fd674b60-738f-11e0-815d-832831e3b300
>
> - amd64-freebsd-thread-multi / 5.12.0:
> - FAIL
> http://www.cpantesters.org/cpan/report/618d570a-73be-11e0-815d-832831e3b300
>
> - amd64-freebsd-thread-multi / 5.12.1:
> - FAIL
> http://www.cpantesters.org/cpan/report/2932f77c-73ee-11e0-815d-832831e3b300
>
> - amd64-freebsd-thread-multi / 5.12.2:
> - FAIL
> http://www.cpantesters.org/cpan/report/534362e6-741f-11e0-815d-832831e3b300
>
> - darwin-thread-multi-64int-2level / 5.8.8:
> - FAIL
> http://www.cpantesters.org/cpan/report/4d50354a-73e7-11e0-9abf-e615ed0326e0
>
> - i386-netbsd-64int / 5.10.0:
> - FAIL
> http://www.cpantesters.org/cpan/report/ee964d26-73e3-11e0-815d-832831e3b300
>
> - i386-netbsd-64int / 5.10.1:
> - FAIL
> http://www.cpantesters.org/cpan/report/1b5c3f58-7418-11e0-815d-832831e3b300
>
> - i386-netbsd-64int / 5.8.9:
> - FAIL
> http://www.cpantesters.org/cpan/report/a1648cac-73b6-11e0-815d-832831e3b300
>
> - i386-netbsd-thread-multi / 5.12.3:
> - FAIL
> http://www.cpantesters.org/cpan/report/8b73d674-7383-11e0-815d-832831e3b300
>
> - x86_64-linux / 5.10.0:
> - FAIL
> http://www.cpantesters.org/cpan/report/d07c1f86-7385-11e0-9c74-cad5bcb8094c
>
> - x86_64-linux / 5.10.1:
> - FAIL
> http://www.cpantesters.org/cpan/report/37c8def0-7394-11e0-9c74-cad5bcb8094c
>
> - x86_64-linux / 5.12.0:
> - FAIL
> http://www.cpantesters.org/cpan/report/859aa4a0-73a4-11e0-9c74-cad5bcb8094c
>
> - x86_64-linux / 5.12.1:
> - FAIL
> http://www.cpantesters.org/cpan/report/055c4f2e-73b7-11e0-9c74-cad5bcb8094c
>
> - x86_64-linux / 5.12.2:
> - FAIL
> http://www.cpantesters.org/cpan/report/b6a7ac18-73c8-11e0-9c74-cad5bcb8094c
>
> - x86_64-linux / 5.12.3:
> - FAIL
> http://www.cpantesters.org/cpan/report/deb785c6-73d6-11e0-9c74-cad5bcb8094c
>
> - x86_64-linux / 5.13.0:
> - FAIL
> http://www.cpantesters.org/cpan/report/c95078fc-73e3-11e0-9c74-cad5bcb8094c
>
> - x86_64-linux / 5.13.1:
> - FAIL
> http://www.cpantesters.org/cpan/report/69f38466-73f3-11e0-9c74-cad5bcb8094c
>
> - x86_64-linux / 5.13.2:
> - FAIL
> http://www.cpantesters.org/cpan/report/033b4d16-7403-11e0-9c74-cad5bcb8094c
>
> - x86_64-linux / 5.13.3:
> - FAIL
> http://www.cpantesters.org/cpan/report/16fac13a-7415-11e0-9c74-cad5bcb8094c
>
> - x86_64-linux / 5.13.4:
> - FAIL
> http://www.cpantesters.org/cpan/report/89a83ba6-7422-11e0-9c74-cad5bcb8094c
>
> - x86_64-linux / 5.13.5:
> - FAIL
> http://www.cpantesters.org/cpan/report/18172fcc-742e-11e0-9c74-c
Re: [Plplot-devel] Status of perl/pdl examples
Hi Alan: I've looked at your updated instructions for running the perl/PDL tests. I don't see any easy way to improve upon them. I typically install plplot first (with no mention of perl/PDL) and then PDL (with no mention of plplot, so the older internal version of PDL::Graphics::PLplot is not installed) and finally install PDL::Graphics::PLplot. At this point, if I want to run the perl/PDL examples from plplot, I would just go to the plplot/examples/perl directory in the plplot build area and run the perl scripts there manually. Perhaps it would make sense to package these test files with PDL::Graphics::PLplot in addition to plplot/examples/perl? There are several down-sides to this (mostly dual maintenance) but it would allow one to incorporate all the plplot tests with the 'make test' part of the PDL::Graphics::PLplot install. One could even put md5sums of expected output files (maybe in xfig format or some other device that is most always available) in PDL::Graphics::PLplot so the test could be rated as definitively passing or failing. Just a thought. Thanks, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Sat, 30 Apr 2011, Douglas Hunt wrote: > Hi Alan: Thanks for incorporating my fixes so quickly! I'm at home now and > can't look quickly at the updated build instructions for > PDL::Graphics::PLplot. I'll take a look when I get to my office. > > Best Regards, > > Doug Hunt > > On Fri, 29 Apr 2011, Alan W. Irwin wrote: > >> On 2011-04-29 16:27-0600 Doug Hunt wrote: >> >>> Hi Alan: I've just checked in a bunch of changes to the perl/PDL test >>> suite for plplot. Now all perl/PDL examples match the C examples when >>> you >>> use PDL-Graphics-PLplot-0.55, which I just uploaded to CPAN. >> >> Hi Doug: >> >> I appropriately changed our build/test system (as of revision 11735) >> to be consistent with PDL-Graphics-PLplot-0.55 and your example >> updates. >> >> Here are the diff results that can now be obtained from the >> test_diff_psc target in the build tree: >> >> perl >> Missing examples: >> Differing postscript output : >> Missing stdout : >> Differing stdout: >> >> These perfect standard test results confirm the perfect results you have >> obtained using alternative means, and this means all our languages now >> have perfect diff results for the first time ever. (YES!!!) >> >> We now enable testing of the Perl/PDL examples by default, but we turn >> off that testing unless PDL-Graphics-PLplot-0.55 (or later) is >> installed since trying to do limited testing of any prior version of >> PDL-Graphics-PLplot just isn't worth it any more. >> >> Please take a look at examples/perl/README.perldemos which I have now >> modified to be consistent with PDL-Graphics-PLplot-0.55. Those >> updated instructions are slightly simpler than before (a patch for >> PDL-Graphics-PLplot is no longer required) but the >> PDL-Graphics-PLplot-0.55 build and install still remains rather >> complicated. Did you have to go through all those steps yourself, or >> is there a simpler way to build and install PDL-Graphics-PLplot-0.55 >> that I am unaware of? >> >> The above perfect Perl/PDL diff results have been made possible by >> your effort to bring PDL-Graphics-PLplot and the Perl/PDL examples >> into consistency with the latest PLplot. Thanks for that effort! >> >> 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); PLplot scientific plotting software >> package (plplot.org); 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 >> __ >> > -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] CPAN Testers Daily Summary Report for PDL-Graphics-PLplot-0.55: What gives?
Hi Alan: Thanks for the insights. I have tested PDL-Graphics-PLplot-0.55 with (at least) plplot 5.9.4, I know it works for that release. I've got extensive logic to detect which version of plplot is installed on the machine as I used to support several versions. So, I don't think that is the problem. Regards, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Mon, 2 May 2011, Alan W. Irwin wrote: > On 2011-05-02 14:38-0600 Doug Hunt wrote: > >> I really don't understand what is going on here--it seems my module >> (PDL-Graphics-PLplot-0.55.) is failing on most all architectures and perl >> versions. >> >> Any help or insight would be appreciated! > > Hi Doug: > > I doubt that PDL-Graphics-PLplot-0.55 will pass any tests for now > other than our own because it is only compatible with the svn trunk > version of PLplot, and it is unlikely automatic testing procedures are > using that version. See remarks in examples/perl/README.perldemos > about the necessity of installing the latest version of PLplot. > > For now you should say that PDL-Graphics-PLplot-0.55 is incompatible > with PLplot-5.9.7 or earlier and requires the svn trunk revision 11742 > (or later) version of PLplot. Once we release PLplot-5.9.8, it will > have an appropriate soversion bump for our principal C library to warn > users/testers of the backwards-incompatible API changes (e.g., in > pllegend) since the release of PLplot-5.9.7. And at that point, you > should spell out that PDL-Graphics-PLplot-0.55 requires PLplot-5.9.8. > > By the way, we are not yet in a position to decide when PLplot-5.9.8 > should be released. Hez and I are still trying to finalize the new > plcolorbar API, and Hazen is working on adding important string length > (in mm) functionality to the qt device driver so that our pllegend > results will look just as good for the qt devices as they currently do > for the cairo devices. Both the plcolorbar and qt projects are > somewhat open-ended, but I am hoping they will not take too much > longer so that we can release 5.9.8 fairly soon. > > 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); PLplot scientific plotting software > package (plplot.org); 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 > __ > -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PDL-Graphics-PLplot 0.56 and plplot 5.9.8
Hi Orion: Thats too bad. I'll look into releasing a new version of PDL-Graphics-PLplot that generates C output instead of storing it as part of the test suite. Regards, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Wed, 24 Aug 2011, Orion Poplawski wrote: > On 08/24/2011 04:21 PM, Orion Poplawski wrote: >> I'm wondering if this is a fatally flawed test setup in that the C example >> comparisons are pre-generated and shipped with PDL-Graphics-PLplot. I >> imagine >> some small differences between Doug's machine and mine would account for >> the >> discrepancy. Does this seem correct? >> > > To answer my own question, if I compile and run the x01c example on my system > I get the same as the perl output, but different then the shipped output. So > I think you need to have the test build the C output as well on the testing > machine. > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA DivisionFAX: 303-415-9702 > 3380 Mitchell Lane or...@cora.nwra.com > Boulder, CO 80301 http://www.cora.nwra.com > -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PDL-Graphics-PLplot 0.56 and plplot 5.9.8
Hi Orion, all: I've just uploaded a new version of PDL-Graphics-PLplot to CPAN (v 0.57) which incorporates some fixes recently merged in from the the PDL source tree and also includes an improved plplot_library_tests.t. This test now compiles and runs the C sources from the plplot examples directory and compares them to the perl equivalent output instead of using canned C output for comparison. This is currently only tested on Linux/Ubuntu! The compiling of these C sources may not work on Windows, for example. Best Regards, Doug Hunt dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Wed, 24 Aug 2011, Orion Poplawski wrote: > On 08/24/2011 04:21 PM, Orion Poplawski wrote: >> I'm wondering if this is a fatally flawed test setup in that the C example >> comparisons are pre-generated and shipped with PDL-Graphics-PLplot. I >> imagine >> some small differences between Doug's machine and mine would account for >> the >> discrepancy. Does this seem correct? >> > > To answer my own question, if I compile and run the x01c example on my system > I get the same as the perl output, but different then the shipped output. So > I think you need to have the test build the C output as well on the testing > machine. > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA DivisionFAX: 303-415-9702 > 3380 Mitchell Lane or...@cora.nwra.com > Boulder, CO 80301 http://www.cora.nwra.com > -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PDL-Graphics-PLplot 0.56 and plplot 5.9.8
OK, I'll add -lm by default--I don't think that will hurt anything. I also owe Sisyphus a window compile update. Regards, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Thu, 8 Sep 2011, Orion Poplawski wrote: > On 09/02/2011 04:59 PM, Doug Hunt wrote: >> Hi Orion, all: I've just uploaded a new version of PDL-Graphics-PLplot to >> CPAN >> (v 0.57) which incorporates some fixes recently merged in from the the PDL >> source tree and also includes an improved plplot_library_tests.t. >> >> This test now compiles and runs the C sources >> from the plplot examples directory and compares them to the perl equivalent >> output instead of using canned C output for comparison. > > On Fedora, you need to link the C examples against -lm because the example > code uses that library. Not sure the best way to add that to your scheme. > > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA DivisionFAX: 303-415-9702 > 3380 Mitchell Lane or...@cora.nwra.com > Boulder, CO 80301 http://www.cora.nwra.com > -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] PDL-Graphics-PLplot 0.56 and plplot 5.9.8
Hi Orion: I just uploaded PDL-Graphics-PLplot version 0.59 to CPAN. This includes adding -lm and Sysiphus's Windows compile patch. Regards, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Thu, 8 Sep 2011, Doug Hunt wrote: > OK, I'll add -lm by default--I don't think that will hurt anything. > > I also owe Sisyphus a window compile update. > > Regards, > > Doug > > dh...@ucar.edu > Software Engineer > UCAR - COSMIC, Tel. (303) 497-2611 > > On Thu, 8 Sep 2011, Orion Poplawski wrote: > >> On 09/02/2011 04:59 PM, Doug Hunt wrote: >>> Hi Orion, all: I've just uploaded a new version of PDL-Graphics-PLplot to >>> CPAN >>> (v 0.57) which incorporates some fixes recently merged in from the the PDL >>> source tree and also includes an improved plplot_library_tests.t. >>> >>> This test now compiles and runs the C sources >>> from the plplot examples directory and compares them to the perl >>> equivalent >>> output instead of using canned C output for comparison. >> >> On Fedora, you need to link the C examples against -lm because the example >> code uses that library. Not sure the best way to add that to your scheme. >> >> >> -- >> Orion Poplawski >> Technical Manager 303-415-9701 x222 >> NWRA/CoRA DivisionFAX: 303-415-9702 >> 3380 Mitchell Lane or...@cora.nwra.com >> Boulder, CO 80301 http://www.cora.nwra.com >> > > ___ > Perldl mailing list > per...@jach.hawaii.edu > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] PDL-Graphics-PLplot 0.56 and plplot 5.9.8
OK! PDL-Graphics-PLplot 0.60 now includes ./a.out
--Doug
dh...@ucar.edu
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611
On Thu, 8 Sep 2011, Orion Poplawski wrote:
> On 09/08/2011 01:25 PM, Doug Hunt wrote:
>> Hi Orion: I just uploaded PDL-Graphics-PLplot version 0.59 to CPAN. This
>> includes adding -lm and Sysiphus's Windows compile patch.
>
> Thanks, that gets farther. Next step is that you are assuming that "." in in
> the user's path, which is not always the case. The below patch fixes.
>
> --- PDL-Graphics-PLplot-0.59/t/plplot_library_tests.t.path 2011-09-08
> 13:04:57.0 -0600
> +++ PDL-Graphics-PLplot-0.59/t/plplot_library_tests.t 2011-09-08
> 14:51:05.584271634 -0600
> @@ -50,7 +50,7 @@
>
> # Run C version
> my $devnull = File::Spec->devnull();
> - system "a.out -dev svg -o x${num}c.svg -fam > $devnull 2>&1";
> + system "./a.out -dev svg -o x${num}c.svg -fam > $devnull 2>&1";
> ok ($? == 0, "C code $c_code ran successfully");
>
> # Run perl version
>
>
> With that change the tests pass for me.
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA/CoRA DivisionFAX: 303-415-9702
> 3380 Mitchell Lane or...@cora.nwra.com
> Boulder, CO 80301 http://www.cora.nwra.com
>
--
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] PDL-Graphics-PLplot 0.56 and plplot 5.9.8
Hi Rob: Now PDL-Graphics-PLplot 0.61 (now on CPAN) includes your logic
for getting rid of './' for Windows. I've tested it under Linux/Ubuntu.
Regards,
Doug
dh...@ucar.edu
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611
On Sat, 10 Sep 2011, Sisyphus wrote:
>
> - Original Message - From: "Doug Hunt"
> To: "Orion Poplawski"
> Cc: "Plplot-devel mailing list" ;
>
> Sent: Friday, September 09, 2011 7:11 AM
> Subject: Re: [Perldl] [Plplot-devel] PDL-Graphics-PLplot 0.56 and plplot
> 5.9.8
>
>
>> OK! PDL-Graphics-PLplot 0.60 now includes ./a.out
>
> Which breaks Windows again :-)
>
> In t/plplot_library_tests.t, instead of:
>
> ##
> # Run C version
> my $devnull = File::Spec->devnull();
> system "./a.out -dev svg -o x${num}c.svg -fam > $devnull 2>&1";
> ##
> can we have something like:
> ##
> # Run C version
> my $devnull = File::Spec->devnull();
> my $dot_slash = $^O =~ /MSWin32/i ? '' : './';
> system "${dot_slash}a.out -dev svg -o x${num}c.svg -fam > $devnull 2>&1";
> ##
>
> That's fine (and tested) on Windows - and looks like it should be fine (but
> untested by me) on those systems that want the preceding "./".
>
> (I don't see there's any need to upload a new release of
> PDL::Graphics::PLplot to CPAN, just to fix this problem. I think it can wait
> until there are additional changes to make.)
>
> Cheers,
> Rob
--
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Capturing output in memory
Hi Bill: Check out the 'mem' and 'memcairo' drivers for plplot. --Doug Hunt dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Fri, 20 Apr 2012, Schwab,Wilhelm K wrote: I have a "working" interface to PLplot, but it relies on temporary disk files, which is not at all attractive. Some time ago, I asked how to avoid this and there were solutions, but not ones that were within easy reach. IIRC, one option was to set up a quad RGB buffer and use (Cairo?) to draw on it. The problem was that I could not (or did not know how to) readily use the data to draw (quickly at least) in my preferred Smalltalk environment. Recently, there are rumblings of Cairo support in Pharo Smalltalk, and I am starting to wonder whether I might be able to connect the dots in the near future. Am I describing something that makes any sense? Another option might to to create my own device driver. The web site says how easy it is to do, but does not go into detail that I could find. For example, Pharo readily uses some variations on RGB that I might be able to exploit with a suitable driver?? Comments/advice are welcome. This is something that will happen when the pieces come together; for now, temp files are UGLY but work. Another topic: multiple plots at one time. IIRC, PLplot was not threadsafe when I last checked. It would be nice to have a way to open a few plots at one time and work on them "at leisure." Is that possible to do? The fact that I do not recall obtaining and passing "plot IDs" suggests to me that there are global data structures and associated limitations?? Bill -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] segfaults in cairo devices under plplot5.9.9 with older pango/cairo
Hi all: I'm just now upgrading to plplot 5.9.9 in my CentOS 5.8 environment. This OS features old pango/cairo versions: pango-1.14.9-8.el5.centos.3 pango-devel-1.14.9-8.el5.centos.3 cairo-1.2.4-5.el5 cairo-devel-1.2.4-5.el5 When I run example 1 with any of the cairo devices, I get a segfault: [rpmbuild@fox c]$ ./x01c -dev pngcairo -o foo.png PLplot library version: 5.9.9 Segmentation fault Other device drivers work fine. Has anyone seen this? If not, I'll start debugging and/or trying to upgrade to a more recent pango/cairo. Regards, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] segfaults in cairo devices under plplot5.9.9 with older pango/cairo
Hi again: I've become frustrated with trying to install a recent
pango/cairo under CentOS 5.8--too many dependencies.
So, in trying to debug the segfault, I've found that:
./x01c -dev pngcairo -o foo.png
finally dies beyond tracing (in the plplot code, anyway) at:
line 289 of plcore:
289 ( *plsc->dispatch_table->pl_esc )( (struct PLStream_struct *) plsc, op, ptr
);
(see attached stack trace).
The function pointer called was in cairo code (I think):
(gdb) p *plsc->dispatch_table->pl_esc
$20 = {void (struct PLStream_struct *, PLINT, void *)} 0x2bd71087
The program was just in the process of drawing an axis label (the number
'1') deep within plbox.
Any ideas what I can do here short of upgrading my entire OS?
Thanks,
Doug
dh...@ucar.edu
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611
On Thu, 17 May 2012, Doug Hunt wrote:
Hi all: I'm just now upgrading to plplot 5.9.9 in my CentOS 5.8
environment. This OS features old pango/cairo versions:
pango-1.14.9-8.el5.centos.3
pango-devel-1.14.9-8.el5.centos.3
cairo-1.2.4-5.el5
cairo-devel-1.2.4-5.el5
When I run example 1 with any of the cairo devices, I get a segfault:
[rpmbuild@fox c]$ ./x01c -dev pngcairo -o foo.png
PLplot library version: 5.9.9
Segmentation fault
Other device drivers work fine.
Has anyone seen this? If not, I'll start debugging and/or trying to
upgrade to a more recent pango/cairo.
Regards,
Doug
dh...@ucar.edu
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
(gdb) where
#0 plP_esc (op=31, ptr=0x7fffd520) at
/home/rpmbuild/rpm/SOURCES/plplot-5.9.9/src/plcore.c:289
#1 0x2acec029 in plP_text (base=0, just=0, xform=0x7fffd6d0,
x=3244, y=22548, refx=3244, refy=22548, string=0x2af42620 "1")
at /home/rpmbuild/rpm/SOURCES/plplot-5.9.9/src/plcore.c:1106
#2 0x2ad1b40b in c_plmtex (side=0x2ad3801c "t", disp=0, pos=0,
just=0, text=0x2af42620 "1")
at /home/rpmbuild/rpm/SOURCES/plplot-5.9.9/src/plsym.c:691
#3 0x2ad1ca24 in plstrl (string=0x2af42620 "1") at
/home/rpmbuild/rpm/SOURCES/plplot-5.9.9/src/plsym.c:968
#4 0x2ad1b294 in c_plmtex (side=0x2ad31150 "b", disp=1.5,
pos=0.15254932189491802, just=0.5, text=0x2af42620 "1")
at /home/rpmbuild/rpm/SOURCES/plplot-5.9.9/src/plsym.c:677
#5 0x2ace02c5 in label_box (xopt=0x2ad38424 "bcnst", xtick1=1,
yopt=0x2ad3841d "bcnstv", ytick1=10)
at /home/rpmbuild/rpm/SOURCES/plplot-5.9.9/src/plbox.c:1475
#6 0x2acda8ff in c_plaxes (x0=0, y0=0, xopt=0x2ad38424 "bcnst",
xtick=0, nxsub=0, yopt=0x2ad3841d "bcnstv", ytick=0, nysub=0)
at /home/rpmbuild/rpm/SOURCES/plplot-5.9.9/src/plbox.c:570
#7 0x2acd83c8 in c_plbox (xopt=0x2ad38424 "bcnst", xtick=0,
nxsub=0, yopt=0x2ad3841d "bcnstv", ytick=0, nysub=0)
at /home/rpmbuild/rpm/SOURCES/plplot-5.9.9/src/plbox.c:82
#8 0x2ad21f1a in c_plenvi (xmin=0.10001, xmax=6,
ymin=0.010002, ymax=36, just=0, axis=0, old=1)
at /home/rpmbuild/rpm/SOURCES/plplot-5.9.9/src/plvpor.c:201
#9 0x2ad21636 in c_plenv (xmin=0.10001, xmax=6,
ymin=0.010002, ymax=36, just=0, axis=0)
at /home/rpmbuild/rpm/SOURCES/plplot-5.9.9/src/plvpor.c:94
#10 0x0040150b in plot1 (do_test=0) at x01c.c:254
#11 0x00401183 in main (argc=1, argv=0x7fffe248) at x01c.c:152
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] segfaults in cairo devices under plplot5.9.9 with older pango/cairo
Hi a third time:
It seems that this problem with the cairo drivers (for old
pango/cairo) cropped up some time between plplot5.9.7 and 5.9.8, since
the problem is not there for 5.9.7, but is there for 5.9.8.
Regards,
Doug
dh...@ucar.edu
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611
On Thu, 17 May 2012, Doug Hunt wrote:
> Hi again: I've become frustrated with trying to install a recent pango/cairo
> under CentOS 5.8--too many dependencies.
>
> So, in trying to debug the segfault, I've found that:
>
> ./x01c -dev pngcairo -o foo.png
>
> finally dies beyond tracing (in the plplot code, anyway) at:
>
> line 289 of plcore:
>
> 289 ( *plsc->dispatch_table->pl_esc )( (struct PLStream_struct *) plsc, op,
> ptr );
>
> (see attached stack trace).
>
> The function pointer called was in cairo code (I think):
>
> (gdb) p *plsc->dispatch_table->pl_esc
> $20 = {void (struct PLStream_struct *, PLINT, void *)} 0x2bd71087
>
>
> The program was just in the process of drawing an axis label (the number '1')
> deep within plbox.
>
> Any ideas what I can do here short of upgrading my entire OS?
>
> Thanks,
>
> Doug
>
> dh...@ucar.edu
> Software Engineer
> UCAR - COSMIC, Tel. (303) 497-2611
>
> On Thu, 17 May 2012, Doug Hunt wrote:
>
>> Hi all: I'm just now upgrading to plplot 5.9.9 in my CentOS 5.8
>> environment. This OS features old pango/cairo versions:
>>
>> pango-1.14.9-8.el5.centos.3
>> pango-devel-1.14.9-8.el5.centos.3
>> cairo-1.2.4-5.el5
>> cairo-devel-1.2.4-5.el5
>>
>> When I run example 1 with any of the cairo devices, I get a segfault:
>>
>> [rpmbuild@fox c]$ ./x01c -dev pngcairo -o foo.png
>> PLplot library version: 5.9.9
>> Segmentation fault
>>
>> Other device drivers work fine.
>>
>> Has anyone seen this? If not, I'll start debugging and/or trying to
>> upgrade to a more recent pango/cairo.
>>
>> Regards,
>>
>> Doug
>>
>> dh...@ucar.edu
>> Software Engineer
>> UCAR - COSMIC, Tel. (303) 497-2611
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> Plplot-devel mailing list
>> Plplot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] plplot image plotting performance with perl/PDL
Hi plplot folks: There has been a conversation on the PDL list recently about which plotting package to use by default for PDL. I've been advocating for use of PLplot, but have limited time to spend on interface development. One of the major perceived limitations of PLplot is image plotting speed. Apparently PLplot uses an expensive algorithm to contour data. A nice performance plot showing the problem is attached. Does any of you know about this? Is there a way to speed up image plotting? Thanks much, Doug Hunt dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 -- Forwarded message -- Date: Tue, 5 Mar 2013 10:43:10 -0700 From: Craig DeForest To: dh...@ucar.edu Cc: Craig DeForest , Karl Glazebrook , perldl list Subject: Re: [Perldl] A common, working plotting package? Funny you should mention that -- there's a Mac Port of PLplot now, and it installed flawlessly when I tried it last night -- which is a huge change from my earlier experience. It is indeed a very nice plotting package - the high level plots, in particular, are very nice looking. Derek has had difficulty using it for image plotting, largely because it uses a very expensive algorithm that is best adapted to low resolution data (and does a fabulous job in that case) but does not scale well to high resolution images. The difficulty is best summed up in the performance plot (apropos to the performance discussion last night). I don't know if there's a better way than the existing high-level contour plot method. As far as point-plotting speed, it's about the same as gnuplot. The plot times are on a 2011 MacBook Pro with stock Ports install. On Mar 5, 2013, at 10:03 AM, Doug Hunt wrote: Hi Karl: I still maintain that PLplot is a good, modern plotting package that runs on all required platforms. It is well maintained and has a nice build system. It also has interactive capabilities which I don't know much about. I have not supported Windows and Mac with PDL::Graphics::PLplot because I don't have the time and access to required machines. I think others who have time/machines could do this without much effort. I think PLplot could be brought up to speed with minor enhancements to PDL::Graphics::PLplot, which I don't necessarily have time to do. Regards, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Tue, 5 Mar 2013, Karl Glazebrook wrote: If GNUplot can plot a million points or a 4096^2 image with a delay < 1s and no memory disaster then that would be fast enough for me. I wish there was a better solution Karl On 04/03/2013, at 2:04 AM, Henning Glawe wrote: On Sun, Mar 03, 2013 at 10:04:45PM +1100, Karl Glazebrook wrote: I don't know how 'modern' PLplot is. The documentation still talks about Tektronix terminals! I did some googling, DISLIN seemed the closest but is only semi-frree. In astronomy people really only use pgplot at the c/f77 level. (At a higher level they use language specific graphics, e.g. IDL, IRAF, Python, sm (!), gnuplot, MMA). What about other scientific fields? What do people you know use? In my field (computational quantum physics/chemistry), computation and visualization are usually treated separately. Typically, the actual numerical simulations are very heavy (taking CPU-days or even CPU-weeks on current HPC-Clusters). The visualization is performed in a separate step, where different "classes" of tools are employed: * Special purpuse tools for molecule/crystal visualization, which show: - crystal structures - densities either on cutting planes or as equipotential surfaces Tools belonging to this class are: - xcrysden http://www.xcrysden.org/ - v-simhttp://www-drfmc.cea.fr/L_Sim/V_Sim/index.en.html * General-purpose plotting tools with a focus on 2D-visualization: - gnuplot http://gnuplot.sourceforge.net/ - gracehttp://plasma-gate.weizmann.ac.il/Grace/ * General-purpose plotting tools with more focus on 3D-visualization: - OpenDX http://en.wikipedia.org/wiki/IBM_OpenDX (Official website seems to be down) Learning curve is quite steep, interface is a bit awkward to use (for modern standards) - paraview http://www.paraview.org/ Easier to use than OpenDX; very powerful visualization tool, integrated python scripting support for - sources (data generation) - filters (data processing) - general-purpose macros Looks dismal. Perhaps the moral is people who put significant effort in to visuals tend to go commercial? I don't think so. You can get quite good results out of free visualization tools, altough sometimes you may have to tweak the settings a bit. One very good example for this is gnuplot; the default settings have not changed much in the past 20 years (think backwards compatibility), but with some modifications in your gnuplot scripts, plots may look a lot
Re: [Plplot-devel] Results of comprehensive PLplot builds and tests for cmake-2.8.11-rc3
Hi Alan: I noticed that you did not run the perl/PDL tests. Are they broken? Thanks, Doug dh...@ucar.edu Software Engineer UCAR - COSMIC, Tel. (303) 497-2611 On Wed, 24 Apr 2013, Alan W. Irwin wrote: > Today I decided to comprehensively test PLplot because it has been a > long time since I did that, and there is a new CMake version > cmake-2.8.11-rc3 that is about to get released as cmake-2.8.11 unless > cmake users (such as us) can find any issues. > > After cmake-2.8.11-rc3 was downloaded, built (using the bootstrap > method), and installed, I did the comprehensive test as follows: > > time (nice -19 scripts/comprehensive_test.sh --do_test_interactive no) > > (I turned off the interactive testing since otherwise I would have > had to babysit the test clicking on many GUI's to get the interactive > tests completed.) > > That comprehensive test required a number of minor PLplot fixups to be > made (see my recent commits) which reaffirms that these comprehensive > tests are worth doing. > > After those changes, the above run of comprehensive_test.sh took > 51 minutes to complete (and from > prior notes) on my entry-level PC and requires about 4GB of disk space > as a high-water mark to store the results of each of the many > components of the tests that are done before the resulting files are > cleaned. There were about 290M of files left at the end of the > comprehensive test. > > To look for meaningful error messages in those tests, I ran > > find ../comprehensive_test_disposeable/ -name "*.out*" | \ > xargs grep -i error |grep -v test.error > > That shows there are linking errors for the case of the static library > build + traditional (Make + pkg-config) build of the installed > examples. This used to work fine, but I guess the Debian wheezy > toolchain just doesn't handle this case properly any more (or takes > more care with linking of code generated from a variety of languages). > Note, I got the same bad results for this case when using > cmake-2.8.10.2 so this is not a cmake regression. > > Andrew, would you be willing to take a look? > > In contrast to the traditional build of the installed examples, the > CMake build system for these installed examples works fine for the > static library build. So it appears we could fix up these > linking issues for the traditional build by following what > is done for the cmake-based build of the installed examples. > > I also looked for warnings in the comprehensive test results and > got the following results: > > software@raven> find ../comprehensive_test_disposeable/ -name "*.out*" | \ > xargs grep -i warn |grep -v imultilib |grep -v "PLPLOT WARNING" | \ > grep -v perl |grep -v AGG > ../comprehensive_test_disposeable/shared/output_tree/installed_make_noninteractive.out:WARNING: > Some PostScript or stdout results were different > ../comprehensive_test_disposeable/shared/output_tree/make_noninteractive.out:WARNING: > Some PostScript or stdout results were different > ../comprehensive_test_disposeable/shared/output_tree/ctest.out:25: WARNING: > Some PostScript or stdout results were different > ../comprehensive_test_disposeable/shared/output_tree/make.out:sip: > Deprecation warning: > /home/software/plplot_svn/HEAD/plplot_allura/bindings/qt_gui/pyqt4/plplot_pyqt4.sip:25: > %Module version number should be specified using the 'version' argument > ../comprehensive_test_disposeable/shared/output_tree/make.out:/home/software/plplot_svn/HEAD/comprehensive_test_disposeable/shared/build_tree/config.h:55:0: > warning: "HAVE_FREETYPE" redefined [enabled by default] > ../comprehensive_test_disposeable/shared/output_tree/make.out:/home/software/plplot_svn/HEAD/plplot_allura/bindings/tk/plserver.c:134:9: > warning: passing argument 2 of ?Tcl_SetResult? discards ?const? qualifier > from pointer target type [enabled by default] > ../comprehensive_test_disposeable/shared/output_tree/traditional_make_noninteractive.out:WARNING: > Some PostScript or stdout results were different > ../comprehensive_test_disposeable/nondynamic/output_tree/installed_make_noninteractive.out:WARNING: > Some PostScript or stdout results were different > ../comprehensive_test_disposeable/nondynamic/output_tree/make_noninteractive.out:WARNING: > Some PostScript or stdout results were different > ../comprehensive_test_disposeable/nondynamic/output_tree/cmake.out:-- > WARNING: ENABLE_DYNDRIVERS is OFF so force PLD_extqt to be OFF > ../comprehensive_test_disposeable/nondynamic/output_tree/cmake.out:-- > WARNING: PLD_extqt is OFF so setting ENABLE_qt to OFF. > ../comprehensive_test_disposeable/nondynamic/output_tree/cmake.out:-- > WARNING: ENABLE_qt is OFF so setting ENABLE_pyqt4 to OFF. > ../comprehensive_test_disposeable/nondynamic/output_tree/ctest.out:25: > WARNING: Some PostScript or stdout results were different > ../comprehensive_test_disposeable/nondynamic/output_tree/make.out:/home/software/plplot_svn/HEAD/comprehensive_test_disposeable/nondynamic/build_tree/config
Re: [Plplot-devel] PDL-Graphics-PLplot and plplot 5.11.0
Hi Orion: Thanks for the patch. I'll look into this next week and try
to put out
an updated PDL-Graphics-PLplot.
Regards,
Doug Hunt
On 04/24/15 16:34, Orion Poplawski wrote:
> I'm trying to build PDL-Graphics-PLplot 0.67 with plplot 5.11.0. First I need
> the attached patch to handle the name change.
>
> Next issue I'm running into is the plplot.t test segfaulting:
>
> $ LD_LIBRARY_PATH=../blib/arch/auto/PDL/Graphics/PLplot/ gdb perl
> GNU gdb (GDB) Fedora 7.9-11.fc23
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from perl...Reading symbols from
> /home/orion/fedora/perl-PDL-Graphics-PLplot/PDL-Graphics-PLplot-0.67/t/perl...(no
> debugging symbols found)...done.
> (no debugging symbols found)...done.
> Missing separate debuginfos, use: dnf debuginfo-install
> perl-5.20.2-328.fc23.x86_64
> (gdb) run -I../blib/lib ./plplot.t
> Starting program: /usr/bin/perl -I../blib/lib ./plplot.t
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Detaching after fork from child process 26859.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x72fd66fa in plP_state (op=op@entry=7)
> at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
> 260 ( *plsc->dispatch_table->pl_state )( (struct PLStream_struct
> *) plsc, op );
> (gdb) bt
> #0 0x72fd66fa in plP_state (op=op@entry=7)
> at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
> #1 0x72ff4e84 in c_plschr (def=, scale= out>)
> at /usr/src/debug/plplot-5.11.0/src/plsdef.c:209
> #2 0x732e1ab2 in pdl_plschr_readdata (__tr=0x15924e0) at
> PLplot.xs:11154
> #3 0x755a6194 in pdl.ensure_trans ()
> from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
> #4 0x755a5150 in pdl_make_trans_mutual ()
> from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
> #5 0x732ababf in XS_PDL_plschr (my_perl=,
> cv=)
> at PLplot.xs:50441
> #6 0x77aea6ab in Perl_pp_entersub () from /lib64/libperl.so.5.20
> #7 0x77ae2f36 in Perl_runops_standard () from /lib64/libperl.so.5.20
> #8 0x77a729c0 in perl_run () from /lib64/libperl.so.5.20
> #9 0x00400d79 in main ()
> (gdb) list
> 255 plbuf_state( plsc, op );
> 256
> 257 save_locale = plsave_set_locale();
> 258 if ( !plsc->stream_closed )
> 259 {
> 260 ( *plsc->dispatch_table->pl_state )( (struct PLStream_struct
> *) plsc, op );
> 261 }
> 262 plrestore_locale( save_locale );
> 263 }
> 264
> (gdb) print plsc
> $1 = (PLStream *) 0x7321eaa0
> (gdb) print op
> $2 = 7
> (gdb) print plsc->dispatch_table
> $3 = (PLDispatchTable *) 0x0
> (gdb) print *plsc
> $2 = {ipls = 0, level = 0, verbose = 0, debug = 0, initialized = 0,
> dev_initialized = 0,
>program = 0x0, coordinate_transform = 0x0, coordinate_transform_data = 0x0,
> icol0 = 0,
>ncol0 = 16, icol1 = 0, ncol1 = 0, ncp1 = 0, curcmap = 0, cmap1_min = 0,
> cmap1_max = 0,
>curcolor = {r = 0 '\000', g = 0 '\000', b = 0 '\000', a = 0, name = 0x0},
> tmpcolor = {
> r = 0 '\000', g = 0 '\000', b = 0 '\000', a = 0, name = 0x0}, cmap0 =
> 0x155e310,
>cmap1 = 0x0, cmap1cp = {{h = 0, l = 0, s = 0, p = 0, a = 0,
>alt_hue_path = 0} }, width = 0, widthset = 0,
> widthlock = 0,
>arrow_x = 0x0, arrow_y = 0x0, arrow_npts = 0, arrow_fill = 0,
> dispatch_table
> = 0x0,
>plbuf_read = 0, plbuf_write = 0, device = 0, dev_minor = 0, termin = 0,
> graphx = 0,
>nopause = 0, color = 0, colorset = 0, family = 0, member = 0, finc = 0,
> fflen = 0,
>bytemax = 0, famadv = 0, dev_fill0 = 0, dev_fill1 = 0, dev_dash = 0,
> dev_di = 0,
>dev_flush = 0, dev_swin = 0, dev_text = 0, dev_xor = 0, dev_clear = 0,
> dev_fastimg = 0,
>dev_arc = 0, DevNa
Re: [Plplot-devel] PDL-Graphics-PLplot and plplot 5.11.0
Hi Orion: I put a new version of PDL-Graphics-PLplot (v 0.71) on CPAN
that does something
similar. I think my update is a bit cleaner.
Regards,
Doug
On 05/18/15 13:56, Orion Poplawski wrote:
> You can check here:
>
> http://pkgs.fedoraproject.org/cgit/perl-PDL-Graphics-PLplot.git/log/
>
> for what the Fedora packager did for 5.11.0 support.
>
> On 04/24/2015 05:41 PM, Doug Hunt wrote:
>> Hi Orion: Thanks for the patch. I'll look into this next week and try to
>> put
>> out
>> an updated PDL-Graphics-PLplot.
>>
>> Regards,
>>
>>Doug Hunt
>>
>> On 04/24/15 16:34, Orion Poplawski wrote:
>>> I'm trying to build PDL-Graphics-PLplot 0.67 with plplot 5.11.0. First I
>>> need
>>> the attached patch to handle the name change.
>>>
>>> Next issue I'm running into is the plplot.t test segfaulting:
>>>
>>> $ LD_LIBRARY_PATH=../blib/arch/auto/PDL/Graphics/PLplot/ gdb perl
>>> GNU gdb (GDB) Fedora 7.9-11.fc23
>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later
>>> <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-redhat-linux-gnu".
>>> Type "show configuration" for configuration details.
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>.
>>> Find the GDB manual and other documentation resources online at:
>>> <http://www.gnu.org/software/gdb/documentation/>.
>>> For help, type "help".
>>> Type "apropos word" to search for commands related to "word"...
>>> Reading symbols from perl...Reading symbols from
>>> /home/orion/fedora/perl-PDL-Graphics-PLplot/PDL-Graphics-PLplot-0.67/t/perl...(no
>>>
>>> debugging symbols found)...done.
>>> (no debugging symbols found)...done.
>>> Missing separate debuginfos, use: dnf debuginfo-install
>>> perl-5.20.2-328.fc23.x86_64
>>> (gdb) run -I../blib/lib ./plplot.t
>>> Starting program: /usr/bin/perl -I../blib/lib ./plplot.t
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>> Detaching after fork from child process 26859.
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x72fd66fa in plP_state (op=op@entry=7)
>>> at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
>>> 260 ( *plsc->dispatch_table->pl_state )( (struct PLStream_struct
>>> *) plsc, op );
>>> (gdb) bt
>>> #0 0x72fd66fa in plP_state (op=op@entry=7)
>>> at /usr/src/debug/plplot-5.11.0/src/plcore.c:260
>>> #1 0x72ff4e84 in c_plschr (def=, scale=>> out>)
>>> at /usr/src/debug/plplot-5.11.0/src/plsdef.c:209
>>> #2 0x732e1ab2 in pdl_plschr_readdata (__tr=0x15924e0) at
>>> PLplot.xs:11154
>>> #3 0x755a6194 in pdl.ensure_trans ()
>>> from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
>>> #4 0x755a5150 in pdl_make_trans_mutual ()
>>> from /usr/lib64/perl5/vendor_perl/auto/PDL/Core/Core.so
>>> #5 0x732ababf in XS_PDL_plschr (my_perl=,
>>> cv=)
>>> at PLplot.xs:50441
>>> #6 0x77aea6ab in Perl_pp_entersub () from /lib64/libperl.so.5.20
>>> #7 0x77ae2f36 in Perl_runops_standard () from
>>> /lib64/libperl.so.5.20
>>> #8 0x77a729c0 in perl_run () from /lib64/libperl.so.5.20
>>> #9 0x00400d79 in main ()
>>> (gdb) list
>>> 255 plbuf_state( plsc, op );
>>> 256
>>> 257 save_locale = plsave_set_locale();
>>> 258 if ( !plsc->stream_closed )
>>> 259 {
>>> 260 ( *plsc->dispatch_table->pl_state )( (struct PLStream_struct
>>> *) plsc, op );
>>> 261 }
>>> 262 plrestore_locale( save_locale );
>>> 263 }
>>> 264
>>> (gdb) print plsc
>>> $1 = (PLStream *) 0x7321eaa0
>>> (gdb) print op
>>> $2 = 7
>>> (gdb) print plsc->dispatch_table
>>> $3 = (PLDispatchTable *) 0x0
>>> (gdb) print *plsc
>>> $2 = {ipls = 0, level = 0, verb
