[Plplot-devel] Java tests on Mac OS X fail
Hi,
I just ran the plplot tests (latest svn) on Mac OS X, turning
everything on I got and the Java tests fail in example 19:
3/ 17 Testing examples_java
Test command: /bin/bash -c EXAMPLES_DIR=/Users/smekal/Development/
plbuild/examples\ SRC_EXAMPLES_DIR=/Users/smekal/Development/plplot/
examples\ PLPLOT_JAVA_WRAP_DIR=/Users/smekal/Development/plbuild/
bindings/java/\ PLPLOT_CLASSPATH=/Users/smekal/Development/plbuild/
examples/java/plplot.jar\ ./plplot-test.sh\ --verbose\ --device=psc\ --
front-end=java
Test timeout computed to be: 1500
Testing front-end java
x01
x02
x03
x04
x05
x06
x07
x08
x09
x10
x11
x12
x13
x14
x15
x16
x17
x18
x19
./test_java.sh: line 47: 98261 Segmentation fault java -classpath
${PLPLOT_CLASSPATH} ${JAVA_TEST_OPTS} plplot.examples.x${index} -dev
$device -o ${OUTPUT_DIR}/x${index}${lang}%n.$dsuffix $options 2
test.error |${OUTPUT_DIR}/x${index}${lang}_${dsuffix}.txt
-- Process completed
***Failed
I believe Andrew had a similar problem on his computer.
Regards,
Werner
--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886
email: sme...@iap.tuwien.ac.at
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
+43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499
--
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
[Plplot-devel] [ plplot-Support Requests-2839637 ] PLplot + Octave + Windows: choose two. (plplot_octave.cc))
Support Requests item #2839637, was opened at 2009-08-18 16:29 Message generated for change (Tracker Item Submitted) made by antarse42 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=202915aid=2839637group_id=2915 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Daniel Sachse (antarse42) Assigned to: Nobody/Anonymous (nobody) Summary: PLplot + Octave + Windows: choose two. (plplot_octave.cc)) Initial Comment: Hi all, I cannot get Octave+PLplot running under Windows XP. I got a freshly installed system, I installed Octave (via OctaveForge, binary) Strawberry Perl and MinGW (realizing later that Strawberry in fact already includes MinGW binaries) and have all three in my PATH variable. I am following the instructions on your Wiki regarding the MinGW setup but I run into trouble: CMake runs fine, then I proceed to mingw32-make and get this: 1) Scanning dependencies of target test_nistcd [ 11%] Generating test_nistcd_dir/cdexp1.cgm mingw32-make[2]: *** [lib/nistcd/test_nistcd_dir/cdexp1.cgm] Error -1073741515 mingw32-make[1]: *** [lib/nistcd/CMakeFiles/test_nistcd.dir/all] Error 2 mingw32-make: *** [all] Error 2 This error can be remedied by copyinh libnistcd.dll from plplot\buildmingw\dll to plplot\buildmingw\lib\nistcd. Then i run mingw32-make again and get this: 2) [ 43%] Generating plplot_octave.cc, tmp_stub '-' is not recognized as an internal or external command, operable program or batch file. matwrap: C preprocessor exited with error status mingw32-make[2]: *** [bindings/octave/plplot_octave.cc] Error 2 mingw32-make[1]: *** [bindings/octave/CMakeFiles/plplot_octave.dir/all] Error 2 mingw32-make: *** [all] Error 2 I have traced the error to the perl script matwrap, line ~211 (plus/minus) where it seems that the program seems to try and fork - which, in Windows, leads to problems. What can I do? Greetings from Oslo, Daniel Huge fan of Open Source, but unfortunately bound to Windows. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=202915aid=2839637group_id=2915 -- 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
[Plplot-devel] Question on plstrip_gen
Hello everyone,
I have started updating the Qt drivers to handle PLESC_FLUSH, and trying
this on example x17c, I've noticed serious speed issues, which led me to
this observation: when the chart is regenerated, the plot is cleared
with a call to plfill:
plfill(4, x[0], y[0]);
where x={0.,1.,1.,0.} and y={0.,0.,1.,1.} (line 182, plstrip.c)
This is an issue for the Qt driver as this one buffers all the commands
in the page, and thus all the layers are drawn every time the chart is
regenerated (which is a lot!). I could trap such fills and map them to a
clearBuffer(), but I wonder if it wouldn't be more sensible to change
the fill to a call to plP_esc(PLESC_CLEAR, NULL) if the driver supports it?
Sorry if my question is naive, just wondering...
Alban
--
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
[Plplot-devel] PLplot + Windows + Octave
Hi all, I've sent this question as a Support Request on SFnet and was referred to this mailing list (not without some good initial help, thanks smekal). The case is this: I'm trying to get PLplot to work together with Octave on a (urks) Windows machine. PLplot compiles (and runs) fine for GCC but as soon as I enable the Octave binding, I get this: mingw32-make [..] [ 43%] Generating plplot_octave.cc, tmp_stub '-' is not recognized as an internal or external command, operable program or batch file. matwrap: C preprocessor exited with error status mingw32-make[2]: *** [bindings/octave/plplot_octave.cc] Error 2 mingw32-make[1]: *** [bindings/octave/CMakeFiles/plplot_octave.dir/all] Error 2 mingw32-make: *** [all] Error 2 The is not recognized expression is a Windows command line error message when it tries to open/run something that does not exist. I have traced the error to the perl script matwrap, line ~211 (plus/minus) where it seems that the program wants to try and fork - which, in Windows, leads to problems. What can I do? Greetings from Oslo, Daniel Huge fan of Open Source, but unfortunately bound to Windows. -- 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] D bindings (nearly finished) and tests on Mac OS X
On Tue, Aug 18, 2009 at 11:05:31AM +0200, Werner Smekal wrote: Ok, I submitted now the last D example and the D bindings are therefore finished. Actually not really finished, since example 20 delivers slightly different postscript results than the C example. Although if I compare the output (xwin, wxwidgets, psc) visually I can't spot any difference. I don't think this is a showstopper, but will have a look later on, I don't consider that as too serious. In addition I ran the plplot tests on Mac OS X with the following results: Test timeout computed to be: 1500 c++ Missing examples: Differing postscript output : 29 Missing stdout : Differing stdout: Werner, This one I find odd. C++ results should be completely identical to the C ones since there is no worrying about cross-language support or any of that. I get identical results for all examples with C and C++ using latest svn. java Missing examples: 20 21 22 23 24 25 26 27 28 29 30 31 Differing postscript output : 19 Missing stdout : Differing stdout: 19 python Missing examples: Differing postscript output : Missing stdout : Differing stdout: 23 tcl Missing examples: Differing postscript output : 03 16 19 21 24 26 29 Missing stdout : Differing stdout: 21 d Missing examples: Differing postscript output : 20 Missing stdout : Differing stdout: -- Process completed ***Failed 88% tests passed, 2 tests failed out of 17 The following tests FAILED: 3 - examples_java (Failed) 17 - examples_compare (Failed) Errors while running CTest The only bad error is the segmentation fault of the Java example 19. Otherwise everything configures and compiles fine on Mac OS X. Next I'll improve the Lua samples, then pdf, then wxWidgets device. I have now implemented all but the plslabelfunc call in f77 / f95 bindings and updated the examples accordingly. I've left the plslabelfunc call to last as it is a bit messy. Octave is also up to date (except for example 19 - not yet worked out how to do function callbacks for mapform / labelfunc.) tcl clearly still needs work, as do ada and ocaml. Otherwise, we're beginning to get all the languages and examples back into shape again ready for the release. Andrew -- 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] I have retired hpgl, impress, and ljii. Should we retire tek as well?
On 2009-08-15 12:51-0700 Alan W. Irwin wrote: Some recent testing I have done has shown a number of run-time issues (segfaults and such) with the deprecated hpgl, impress, and ljii devices. Since no user has complained about these run-time issues, I assume this means these historical devices have long been completely unused by our users. Therefore, I have (revision 10263) retired these devices by commenting out the appropriate part of a list in drivers-init.cmake. Part of that revision is an announcement in README.release about the retirement of these device drivers. I went ahead with this change because I think it is completely noncontroversial, but if somebody thinks otherwise I am open to the possibility of reverting some/all of these changes. As part of my testing I also noticed that the deprecated tek driver had some build issues (e.g., incorrectly named PLD_ options and inconsistent use of such names in tek.c and elsewhere). This driver contains the following list of devices: conex:Conex vt320/tek emulator:1:tek:24:conex\n mskermit:MS-Kermit emulator:1:tek:21:mskermit\n tek4107t:Tektronix Terminal (4105/4107):1:tek:20:tek4107t\n tek4107f:Tektronix File (4105/4107):0:tek:28:tek4107f\n tekt:Tektronix Terminal (4010):1:tek:19:tekt\n tekf:Tektronix File (4010):0:tek:27:tekf\n versaterm:Versaterm vt100/tek emulator:1:tek:22:versaterm\n vlt:VLT vt100/tek emulator:1:tek:23:vlt\n xterm:Xterm Window:1:tek:18:xterm\n In my opinion, the only one of those devices which still might be useful is xterm, but that is quite lame (e.g., ugly fallback to software fills) and requires X, and xwin is a much better alternative that also just depends on X. I would be glad to retire the deprecated tek device driver as well rather than waste time fixing up the build issues for something that is probably not used at all. However, I will wait to do that until it is clear there are no strong objections from the developers here to that retirement. Since nobody commented, I have assumed retiring the tek devices rather than fixing them is also noncontroversial so that is what I have done as of revision 10282. If somebody missed the above discussion and feels strongly that the tek drivers are still worth keeping as a deprecated option, I am certainly open to reverting this change. 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 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] Alternate cmap0 in plctrl.c
On Tue, Aug 18, 2009 at 4:45 PM, Hezekiah M.
Cartyhezekiahca...@users.sourceforge.net wrote:
Is it worth adding a PLplot cmake/compile-time option to change the
default color map 0 to this or some other alternate? This would allow
someone who wants white backgrounds to be the rule rather than the
exception to avoid having to set the palette for each plot.
I have attached an initial patch which adds cmake configuration
support for enabling the alternate cmap0 by default. One can pass
-DPL_ALT_CMAP0=ON to cmake to use to alternate color map 0 colors by
default. If PL_ALT_CMAP0 is set to OFF or is left unset (it defaults
to OFF), the current default (black background) color map 0 palette is
used.
If this compile-time palette support is added to PLplot, I would
appreciate a review of this patch, particularly the CMake pieces. I
think I am setting things up correctly, but I'm not sure if everything
is in the proper location.
Enjoy,
Hez
--
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science
diff --git a/include/plConfig.h.cmake b/include/plConfig.h.cmake
index 8bc0252..b90723d 100644
--- a/include/plConfig.h.cmake
+++ b/include/plConfig.h.cmake
@@ -75,4 +75,7 @@
* - broken Mac OSX systems */
#cmakedefine PL_BROKEN_ISNAN_CXX
+/* Define if you want to use the alternate cmap0 */
+#cmakedefine PL_ALT_CMAP0
+
#endif /* __PLCONFIG_H__ */
diff --git a/src/plctrl.c b/src/plctrl.c
index 4428ed8..ae51a59 100644
--- a/src/plctrl.c
+++ b/src/plctrl.c
@@ -898,6 +898,7 @@ plcmap0_def(int imin, int imax)
{
int i;
+#ifndef PL_ALT_CMAP0
color_def(0,0, 0, 0, 1.0, black );/* black */
color_def(1, 255, 0, 0, 1.0, red); /* red */
color_def(2, 255, 255, 0, 1.0, yellow ); /* yellow */
@@ -914,23 +915,24 @@ plcmap0_def(int imin, int imax)
color_def(13, 255, 0, 255, 1.0, magenta ); /* magenta */
color_def(14, 250, 128, 114, 1.0, salmon ); /* salmon */
color_def(15, 255, 255, 255, 1.0, white ); /* white */
-
-/* color_def(0, 255, 255, 255, white ); /\* white *\/ */
-/* color_def(1,0, 0, 0, black ); /\* black *\/ */
-/* color_def(2,0, 0, 255, blue ); /\* blue *\/ */
-/* color_def(3, 255, 0, 0, red); /\* red *\/ */
-/* color_def(4, 165, 42, 42, brown ); /\* brown *\/ */
-/* color_def(5, 250, 128, 114, salmon ); /\* salmon *\/ */
-/* color_def(6, 255, 192, 203, pink ); /\* pink *\/ */
-/* color_def(7, 127, 255, 212, aquamarine ); /\* aquamarine *\/ */
-/* color_def(8, 245, 222, 179, wheat ); /\* wheat *\/ */
-/* color_def(9, 64, 224, 208, turquoise ); /\* turquoise *\/ */
-/* color_def(10, 190, 190, 190, grey ); /\* grey *\/ */
-/* color_def(11, 0, 255, 255, cyan ); /\* cyan *\/ */
-/* color_def(12,0, 255, 0, green ); /\* green *\/ */
-/* color_def(13, 255, 255, 0, yellow ); /\* yellow *\/ */
-/* color_def(14, 255, 0, 255, magenta ); /\* magenta *\/ */
-/* color_def(15, 138, 43, 226, BlueViolet ); /\* Blue Violet *\/ */
+#else
+color_def(0, 255, 255, 255, 1.0, white ); /* white */
+color_def(1,0, 0, 0, 1.0, black ); /* black */
+color_def(2,0, 0, 255, 1.0, blue ); /* blue */
+color_def(3, 255, 0, 0, 1.0, red); /* red */
+color_def(4, 165, 42, 42, 1.0, brown ); /* brown */
+color_def(5, 250, 128, 114, 1.0, salmon ); /* salmon */
+color_def(6, 255, 192, 203, 1.0, pink ); /* pink */
+color_def(7, 127, 255, 212, 1.0, aquamarine ); /* aquamarine */
+color_def(8, 245, 222, 179, 1.0, wheat ); /* wheat */
+color_def(9, 64, 224, 208, 1.0, turquoise ); /* turquoise */
+color_def(10, 190, 190, 190, 1.0, grey ); /* grey */
+color_def(11, 0, 255, 255, 1.0, cyan ); /* cyan */
+color_def(12, 0, 255, 0, 1.0, green ); /* green */
+color_def(13, 255, 255, 0, 1.0, yellow ); /* yellow */
+color_def(14, 255, 0, 255, 1.0, magenta ); /* magenta */
+color_def(15, 138, 43, 226, 1.0, BlueViolet ); /* Blue Violet */
+#endif
/* Any others are just arbitrarily set */
--
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] Alternate cmap0 in plctrl.c
On 2009-08-18 16:45-0500 Hezekiah M. Carty wrote: PLplot has apparently had, for some time, a commented-out alternate color map 0 with a white background and multiple foreground colors. I think that this, or a similar cmap0, is worth including with PLplot. I agree that looks pretty good and is worth preserving as yet another palette file. I have attached the pngcairo output from the first page of example 2 as an illustration of this alternative palette versus the default palette. If there are no objections I will add this as cmap0_alternate.pal to the PLplot trunk. Any suggestions for a better file name? Palette file names that actually describe the colours in the palette are going to be virtually impossible to realize in general so I suggest we should normally use a memorable name for palette files following some naming convention we all agree on. For example, we could take names from the collection of Arabic names for stars (betelgeuse, etc.) or the collection of names donoting bird genera, or whatever takes our fancy (so long as there is lots of choice of names). (When we had a similar problem naming the computers in our astrogroup back in 1991 we decided on a marine animal naming theme which explains my e-mail address.) Is it worth adding a PLplot cmake/compile-time option to change the default color map 0 to this or some other alternate? This would allow someone who wants white backgrounds to be the rule rather than the exception to avoid having to set the palette for each plot. I think this is a good idea. The DEFAULT_CMAP0_FILE and DEFAULT_CMAP1_FILE options (to pick some reasonable names for those cmake options) should just be a PLplot builder-specified string corresponding to one of the existing cmap[01] palette files in the standard places where palette files appear (which includes the current directory for those who really want to play with colour schemes). If those options were not specified, then the fallback for the default would be the existing cmap[01]_default.pal files which give the default colour scheme that our traditional users expect. Such a change would also allow us to do the initial setup of cmap0 and cmap1 when libplplot is opened using the specified default palette files. I feel such use of palette files to initialize cmap[01] is an improvement over the current hard-coded specification of the default cmap0 and cmap1 when libplplot is opened. 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 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] Alternate cmap0 in plctrl.c
On 2009-08-18 18:21-0500 Hezekiah M. Carty wrote: On Tue, Aug 18, 2009 at 4:45 PM, Hezekiah M. Cartyhezekiahca...@users.sourceforge.net wrote: Is it worth adding a PLplot cmake/compile-time option to change the default color map 0 to this or some other alternate? This would allow someone who wants white backgrounds to be the rule rather than the exception to avoid having to set the palette for each plot. I have attached an initial patch which adds cmake configuration support for enabling the alternate cmap0 by default. One can pass -DPL_ALT_CMAP0=ON to cmake to use to alternate color map 0 colors by default. If PL_ALT_CMAP0 is set to OFF or is left unset (it defaults to OFF), the current default (black background) color map 0 palette is used. I prefer a palette file approach rather than hard-coded approach. See my previous post on this (which crossed with your latest post) where I give more details of how I hope this evolves. With regard to your cmake question, I think #define (rather than cmakedefine) in config.h.cmake is the way to go. See the first part of that file for how #defines are configured corresponding to various CMake variables. In these cmap[01] cases, the variables would be strings that are specified as CMake options with default values of cmap[01]_default.pal (i.e., used if the user does not specify those options). 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 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] D bindings (nearly finished) and tests on Mac OS X
I'm working on the Ada. Had a weird cmake problem until I installed Qt--seemed to me like even though I told it not to build for Qt it was trying anyway. Don't know if it was a cmake problem or a Jerry problem but I can once again get a build. (Not all of the Qt devices are working but I'll save that for another day.) Jerry On Aug 18, 2009, at 8:51 AM, Andrew Ross wrote: tcl clearly still needs work, as do ada and ocaml. Otherwise, we're beginning to get all the languages and examples back into shape again ready for the release. Andrew -- 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
