Re: [Plplot-devel] [PATCH] qt driver: use QMutexLocker
On 2009-06-23 15:48+0100 Andrew Ross wrote: On Fri, Jun 19, 2009 at 10:00:41AM -0700, Alan Irwin wrote: Hi Andrew: I have addressed this post to you as well because the previous commit message that put in a mutex for this device implied you had a thread safety test for the qt device at that time: r9765 | airwin | 2009-03-21 08:39:08 -0700 (Sat, 21 Mar 2009) | 8 lines AWI for Alban Rochel. - Introduce a mutex to make driver thread safe. Andrew noticed that when 2 qtwidgets were running on 2 streams, closing them didn't close the driver properly. This issue should be fixed by this change. Could you apply the same test for this new way of handling the qt mutex? Also, if you could share the details of your test (i.e., what example to run interactively and how to identify when the driver is not closed properly), I should be able to incorporate it into our interactive test suite so that anybody could run the test on any platform. Alan, The original test just involved running the multiple stream example 14 with two devices, one interactive and one file based. Originally there were global variables set which depended on the type of the first initialised device. I think problems occured if you initialised the file based driver first then tried to use an interactive driver for the second stream. I would have to check though. Do you happen to remember what those run-time problems were and how you triggered them? Testing of GUI's is tricky because results often depend on exactly which GUI buttons you pushed in what order. In any case, please give example 14 a thrashing to see if you see anything questionable now. There is now more urgency to extensive testing of the thread safety for the qt driver as well as the associated plplotqt library. In the latter case, qt_example shows some memory management issues concerning the mutex. (There were some build issues for that installed C++ example, but those have now [revision 10067] been completely fixed for the new CMake-based build system for the installed examples.) The run-time issue for qt_example is you cannot exit the associated GUI anymore using the usual methods (e.g., alt+F4). Instead, you have to hit control-c. I investigated some more with valgrind and exposed some severe memory management issues with the mutex when all I did in the resulting GUI was hit alt+F4 to exit. (I get a similar result if Dmitri's patch is reverted so the issue is probably Alban's mutex to make qt thread safe is not completely correct and that error propagated to Dmitri's implementation of that mutex logic.) The initial memory management error for qt_example is ==27514== Conditional jump or move depends on uninitialised value(s) ==27514==at 0x7E6BBE6: QtExtWidget::paintEvent(QPaintEvent*) (qt.cpp:1922) That line of code is if(!cursorParameters.isTracking || cursorParameters.cursor_x0) return; and presumably the issue is caused by one of those two variables not being properly initialized. I don't know whether this issue has anything to do with the later much more severe memory management issues found by valgrind for the mutex, but it is always a good rule of thumb to deal with the first obvious valgrind issue encountered so can somebody with more knowledge of the qt.cpp than me fix those uninitialized variables? For the record, that later issue starts with the following valgrind message ==27514== Invalid read of size 8 ==27514==at 0x7A41901: pthread_cond_destroy@@GLIBC_2.3.2 (in /lib/libpthread-2.7.so) ==27514==by 0x6F797A0: QMutexPrivate::~QMutexPrivate() (qmutex_unix.cpp:70) Hopefully, that will go away once the uninitialized variable is fixed. I also tried -dev qtwidget on example 10, and the first (and only) valgrind error for the qt.cpp codepath used by that device was ==27638== Conditional jump or move depends on uninitialised value(s) ==27638==at 0x6B859FB: plD_eop_qtwidget(PLStream*) (qt.cpp:1807) That line of code is while(currentPage==widget-pageNumber handler.isMasterDevice(widget) ! pls-nopause) and again we need a fix for one or more of those variables not being properly initialized. Finally, I also tried -dev epsqt on example 10, and no valgrind memory management issues were encountered for that device so it would be wrong to conclude qt.cpp was riddled with uninitialized variables. :-) But there are definitely some there for certain code paths as can be seen above. 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
Re: [Plplot-devel] [PATCH] qt driver: use QMutexLocker
On 2009-06-23 12:17-0700 Alan W. Irwin wrote: Finally, I also tried -dev epsqt on example 10, and no valgrind memory management issues were encountered for that device so it would be wrong to conclude qt.cpp was riddled with uninitialized variables. :-) But there are definitely some there for certain code paths as can be seen above. These uninitialized variables (also seen in a valgrind run on python ./pyqt4_test.py) have now been removed by a patch kindly supplied by Alban (revision 10068). This change makes -dev qtwidget completely valgrind clean (just like -dev epsqt), makes qt_example valgrind clean until an attempt is made to exit the GUI with alt-F4, and removes any reference to PLplot code from the valgrind output for python ./pyqt4_test.py Thanks for this fix, Alban! This fix will make it a lot easier to fix the remaining known qt issues which are as follows: * The QMutex destructor called twice issue that Dmitri discovered. This shows up as lots of valgrind output involving PLplot code and a hang (which you can get out of with ctrl-C) when you attempt to exit the qt_example GUI. * The blank GUI issue for python ./pyqt4_test.py. In this case, there is still extensive valgrind output but none of it involves PLplot code. Furthermore, I am pretty sure it is just python/valgrind noise because almost the same large amount of noise is produced if you attempt to use valgrind to analyze an interactive python session where all you do is immediately exit from the python session. So I now suspect the blank GUI issue is simply some programming issue rather than a more exotic memory management issue or uninitialized variable issue. 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] [PATCH] qt driver: use QMutexLocker
On 2009-06-24 23:13+0300 Dmitri Gribenko wrote: On Wed, Jun 24, 2009 at 6:50 PM, Alan W. Irwinir...@beluga.phys.uvic.ca wrote: * The QMutex destructor called twice issue that Dmitri discovered. This shows up as lots of valgrind output involving PLplot code and a hang (which you can get out of with ctrl-C) when you attempt to exit the qt_example GUI. After thinking and debugging a bit, I found out: * if you compile with ENABLE_DYNDRIVERS=OFF, the problem doesn't show up * with ENABLE_DYNDRIVERS=ON qt_example doesn't compile, the linker cannot find methods from QtExtWidget as well as plsetqtdev()/plfreeqtdev(). After I add -lplplotqtd to the line 88 of examples/c++/Makefile.examples.in, qt_example compiles fine. Am I doing anything wrong? I should have been clearer. I have been working with the new CMake-based build system for the installed examples to get it to properly build qt_example for the ENABLE_DYNDRIVERS=ON case. So you should stick to that case also (assuming you have downloaded and installed cmake-2.6.4 which is a necessity for the new build system for the installed examples). You use this new build system (after make install for the core build system) by simply running cmake $prefix/share/plplot5.9.4/examples cd c++ make qt_example from an initially empty build tree. N.B. the new CMake-based build system for the installed examples is configured by the core build system and finalized by make install for that core build system so there are no cmake options required in the above cmake command. Once we have sorted everything out for the new CMake-based build system for the installed examples and the ENABLE_DYNDRIVERS=ON case, then I will fix up the ENABLE_DYNDRIVERS=OFF case (by not building libplplotqtd.so at all and by linking qt_example to libplplotd instead) and also tweak the old Makefile+pkg-config approach for building the installed examples for both the ENABLE_DYNDRIVERS=ON and ENABLE_DYNDRIVERS=OFF cases. Therefore, I don't think there will be any necessity of splitting qt.cpp, and the patch you sent (in a later post) is probably fine as is. I will look at that 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 __ -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] qt split code status
I have changed the subject line since the old one was barely relevant any more. On 2009-06-24 22:58-0700 Alan W. Irwin wrote: Let's proceed in steps. 1. Get everything to work with qt.cpp unsplit both for DYNDRIVERS ON and OFF and for the new and old build system for the installed examples. I would also like to see the pyqt4 extension module (which also depends on libplplotqtd) working for the first time as well. Unless you prefer something different, tomorrow (Thursday) I will work on this including checking in your current patch to the unsplit version of qt.cpp (assuming it works for me as well as it did above for you). 2. Split qt.cpp and confirm things still work for the four cases (DYNDRIVERS ON and OFF and for the new and old build system) and also for the pyqt4 extension module. I actually think splitting qt.cpp into device driver code and a library is generally a good idea. However, there are some build system issues to be aware of for the DYNDRIVERS OFF case, but it should be fairly straightforward to solve them once we have 1. working in all cases. 3. Document. Once, I actually looked at the patch Dmitri sent to the list I had to agree with him that those macros made the source code difficult to understand and essentially emulated splitting the source code. Therefore, I skipped 1. above and proceeded directly to 2 with the aid of a patch that Dmitri sent me off list to split drivers/qt.cpp into drivers/qt.cpp and bindings/qt_gui/plqt.cpp. I added some cmake infrastructure to support the split source code, and the result (revision 10073) gives clean valgrind results for all four kinds of qt devices as well as qt_example. Thanks, Dmitri for your split patch, and thank Alban for your earlier patch to fix uninitialized variables. Those two patches have made these completely clean valgrind results possible. The build-tree and install tree versions of qt.so, libplplotqtd, and plplot_pyqt4.so pass the ldd -r test for undefined symbols. Nevertheless, the split does not solve the black/blank gui problem for pyqt4_test.py. Hopefully, though, the split code is now much more readable and easier to debug for that issue. N.B. The above tests were done just for the default CMake configuration (ENABLE_DYNDRIVERS ON, ENABLE_qt ON) and with the new build system for the installed examples. Additional testing for other configurations is in progress, and in particular there are still a few obvious changes I have to make and test for the traditional build system for the installed examples to complete this work. 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
[Plplot-devel] PLplot style guide for C/C++ now available as plplot-c-style.el
Thanks, Geoffrey, for your initial thoughts on a PLplot C/C++ coding style. I wanted to return to and emphasize my previous point which is a lot of us use emacs so that specifying an emacs settings file should be beneficial since it should help to focus the discussion and make it easy for us to bring the PLplot C/C++ code into conformance with our style guide as expressed by that emacs settings file. Dmitri previously mentioned the google C/C++ style guide so I looked that up (http://code.google.com/p/google-styleguide/), and there is actually an associated emacs settings file at http://google-styleguide.googlecode.com/svn/trunk/google-c-style.el. I figured the google types probably haven't made any huge blunders with their C/C++ style so I suggest we use that as a first approximation. Therefore, I downloaded and committed (revision 10075) that file (with essentially all instances of google changed to plplot) as plplot-c-style.el. I suggest we view this file as just a first approximation to where we want to go with a uniform C/C++ coding style for PLplot. So, for example, if a consensus develops that the indentation enforced by that file is not to our collective liking, then we can always change it and reprocess all our source files (ideally with a script) to bring them into conformance with the adopted change in style. I am currently trying plplot-c-style.el as follows: softw...@raven tail -6 ~/.emacs ; ; Support PLplot C/C++ style ; (load /home/software/plplot_cvs/HEAD/plplot_cmake_qt/plplot-c-style.el) (add-hook 'c-mode-common-hook 'plplot-make-newline-indent) (add-hook 'c-mode-common-hook 'plplot-set-c-style) Of course your own load command will be different depending on the location of the head of the PLplot source-code tree on your computer. I am an emacs newbie so the only method I know to enforce the PLplot style as given by plplot-c-style.el is to select all the text of the file and then hit ctrl-alt-backslash to change the indentation according to plplot-c-style.el. Resetting the indentation that way does work (i.e., plplot-c-style.el gives different indentation results than the emacs default c style, and both plplot-c-style.el and default C emacs indentation are different than revision 10073 of qt.cpp). I have committed the reindented (according to plplot-c-style.el) result as revision 10074 after confirming with svn diff -x -w qt.cpp that the changes are just whitespace ones. However, style is obviously more than just indentation. So I assume there are other emacs commands that I should be using to force qt.cpp to conform to the PLplot style as given by plplot-c-style.el. Can somebody advise what additional emacs commands I should use besides ctrl-alt-backslash to enforce that style? 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] configure(cmake)/build problems on F11
get: xiphi:t5/plplot/tmp | master make ... [ 12%] Building CXX object src/CMakeFiles/plplotd.dir/__/drivers/qt.cpp.o [ 12%] Building CXX object src/CMakeFiles/plplotd.dir/__/bindings/qt_gui/plqt.cpp.o /home/furnish/plplot/t5/plplot/bindings/qt_gui/plqt.cpp:34:16: error: qt.h: No such file or directory /home/furnish/plplot/t5/plplot/bindings/qt_gui/plqt.cpp:38: error: ?MasterHandler? does not name a type /home/furnish/plplot/t5/plplot/bindings/qt_gui/plqt.cpp:41: error: ?QMutex? does not name a type /home/furnish/plplot/t5/plplot/bindings/qt_gui/plqt.cpp:43: error: ?QtPLDriver? has not been declared /home/furnish/plplot/t5/plplot/bindings/qt_gui/plqt.cpp:43: error: expected constructor, destructor, or type conversion before ?(? token [dozens more lines, then] /home/furnish/plplot/t5/plplot/bindings/qt_gui/plqt.cpp:131: error: ?p? was not declared in this scope /home/furnish/plplot/t5/plplot/bindings/qt_gui/plqt.cpp:131: error: expected primary-expression before ?const? make[2]: *** [src/CMakeFiles/plplotd.dir/__/bindings/qt_gui/plqt.cpp.o] Error 1 make[1]: *** [src/CMakeFiles/plplotd.dir/all] Error 2 make: *** [all] Error 2 I have been recently working on this area, and some parts of it have not yet been tested by me so all the help you can give me with testing some of the logic combinations is much appreciated. When you do report problems could you _always_ give make VERBOSE=1 results? Otherwise, I have to guess what is going on. I could not replicate your bug with default settings (shared libraries, dynamic devices, and ENABLE_qt ON which has been working well for me), but then I guessed a lot more, and finally came up with a similar error when ENABLE_qt was forced OFF. (You could have also gotten that error by default if ENABLE_qt was OFF for some other reason.) I have now fixed that case (revision 10088). Note, that the overall qt build system logic is controlled by various PLD_*qt variables. If all of those are turned off for some reason (say if you are missing some Qt build essential), then nothing related to qt will work so ENABLE_qt (which controls only whether libplplotqt(d) is built) is turned OFF automatically in this case. Furthermore, if the user forces ENABLE_qt OFF or it is turned OFF automatically, then ENABLE_pyqt4 (which controls whether the plplot_pyqt4 python extension module is built) will be turned OFF automatically. The ENABLE_pyqt4 logic was screwed up, but is now fixed in the latest revision. Could you please try again to see if all your recent qt problems are now fixed? 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] configure(cmake)/build problems on F11
There are two followups to what I wrote last night: On 2009-06-28 02:19-0700 Alan W. Irwin wrote: [...]Thus, I would like to leave this task (make compiler problems not a fatal error) to someone else who is less experienced with our build system but would like to learn more about it by taking on an easy task. If someone wants to volunteer for this, please indicate that here so there won't be duplication of effort. 1. I think it is important to deal with small issues quickly and informally rather than worrying about triage for them. So I have changed my mind, and I plan to implement the solution myself later this afternoon. (If somebody who wanted to learn about cmake had his curiosity aroused by this problem, then I suggest that my commit will be an opportunity for them to learn.) [...] Note, that the overall qt build system logic is controlled by various PLD_*qt variables. 2. However, it is an imperfect world and there are occasions (such as screwups in the build system) where users like Geoffry want to turn off all qt devices conveniently with one variable rather than having to turn off each of the 10 (!) individual PLD_*qt (and PLD_qt*) variables associated with the qt device. Accordingly, I have just (revision 10092) implemented a DEFAULT_NO_QT_DEVICES option which will conveniently turn off all qt-related devices by default. At the same time I have implemented a DEFAULT_NO_CAIRO_DEVICES option which will conveniently turn off all 7 cairo-related devices by default. The remainder of our device drivers typically have few or only one device per driver so implementation of such DEFAULT_NO_*_DEVICES options for our other device drivers make little sense. 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] configure(cmake)/build problems on F11
On 2009-06-28 16:17-0700 Alan W. Irwin wrote: On 2009-06-28 02:19-0700 Alan W. Irwin wrote: [...]Thus, I would like to leave this task (make compiler problems not a fatal error) to someone else who is less experienced with our build system but would like to learn more about it by taking on an easy task. If someone wants to volunteer for this, please indicate that here so there won't be duplication of effort. [...]I have changed my mind, and I plan to implement the solution myself later this afternoon. DONE. revision 10094. Light testing (just a default build except for the -DENABLE_d=ON option) shows these changes (to allow continuation of the build if it turns out the compiler is broken/nonexistent) appear not to introduce regressions. My method of recovery in case of a bad compiler (disabling the appropriate bindings/examples) normally should work. However, my light testing was done for a platform with working Ada, C, C++, D, Fortran, and Java compilers so my method of recovery has not actually been tested. Geoffrey, as a first test of recovery will you test that these changes allow you to build PLplot without specifying -DENABLE_ada=OFF for your F11 system which appears to have a broken Ada compiler? 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] configure(cmake)/build problems on F11
On 2009-06-28 19:08-0700 Alan W. Irwin wrote:
[...]My method of recovery in case of a bad compiler
(disabling the appropriate bindings/examples) normally should work. However,
my light testing was done for a platform with working Ada, C, C++, D,
Fortran, and Java compilers so my method of recovery has not actually been
tested.
Geoffrey, as a first test of recovery will you test that these changes allow
you to build PLplot without specifying -DENABLE_ada=OFF for your F11 system
which appears to have a broken Ada compiler?
Geoffrey responded off list with the bad news that this OPTIONAL idea did
not work for Ada. I then got a lot smarter and figured out how to emulate a
bad compiler by e.g., FC='gfortran whatever' cmake ... where the
non-existing whatever file kills off the try_compile command which tests
the given compiler and which therefore exercises the recovery method for
PLplot.
Using such tests on the new build system for the installed examples (where
as of revision 10095 I also installed OPTIONAL language support), I
confirmed Geoffrey's result not only for Ada, but for every other compiler
we use (sigh). I then tried a really simple CMakeLists.txt file
cmake_minimum_required(VERSION 2.6.4)
project(test NONE)
enable_language(Fortran OPTIONAL)
message(STATUS CMAKE_FORTRAN_COMPILER_WORKS = ${CMAKE_Fortran_COMPILER_WORKS})
and got the same bad result (cmake quits with an error message for bad
compilers rather than returning control properly to the CMakeLists.txt where
the CMAKE_language_COMPILER_WORKS variable can be used to deal with the
issue). This issue got at least a small amount of attention from a CMake
developer on the CMake mailing list so following his instructions I have
reported this as a CMake bug at
http://public.kitware.com/Bug/view.php?id=9220.
It will obviously take a while for CMake developers to deal with this issue
so for the immediate future neither our core build system nor our new build
system for the installed examples will recover smoothly (by eliminating the
appropriate component of PLplot with a warning message and continuing) if
there exists a bad compiler that fails to pass the try_compile test.
For the case of a missing compiler (which should also be taken care of by
OPTIONAL once the CMake developers fix the bug), I have uniformly
implemented a workaround of searching for the compiler _before_ enabling the
language. (That workaround was used for at least some languages previously
to my last commit that eliminated it because I erroneously didn't think we
would need it anymore). Revision 10096 (which also contains the equivalent
fix for the new build system for installed examples) implements this
workaround for all our compiled languages.
It turns out another aspect of the above CMake bug is cmake errors out if
you specify a non-existing compiler with the CC, etc., environment
variables. So I tested revision 10096 by a different method which consisted
of systematically moving gcc, g++, gdc, gfortran, gnatgcc to a temporary
name. Under these conditions the new build system seems to work well (gives
a smooth recovery) for the installed examples in all but the Ada case (which
appears to be ideosyncratic since it shifts to trying gcc if gnatgcc is
unavailable).
So revision 10096 should deal with the missing compiler case in a smooth way
(except for Ada), but we are absolutely stuck with abrupt erroring out for
the bad compiler case until the CMake developers can come up with a fix to
bug 9220.
Geoffrey has told me off list that he is now reasonably satisfied. The other
build issues (qt, etc.,) that he was encountering have now been solved by my
other recent commits so he can continue his PLplot development work by
simply disabling Ada on Fedora 11.
Geoffrey has been a hard taskmaster for the build system, and I am sure that
will continue. However, I strongly encourage that. After all, it is only
fair because my testing activities reveal PLplot run-time bugs (segfaults,
memory management issues, etc.,) that make me a hard taskmaster for the C
and C++ experts here. Also, of course, having hard taskmasters on the
development team is fundamentally useful because it means we discover and
fix problems that were probably discouraging some of our users who didn't
have the confidence/expertise to report the issues to us.
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
Re: [Plplot-devel] plplot_pyqt4 status
On 2009-06-28 20:49-0400 Hazen Babcock wrote:
Hazen Babcock wrote:
Poking around a little more...
In the function plD_line_qt we are not getting past this statement:
#if defined(PLD_qtwidget) || defined(PLD_extqt)
if(widget==NULL) widget=dynamic_castQtPLWidget*((QWidget *) pls-dev);
#endif
if(widget==NULL) return;
So the dynamic cast is not working for some reason?
printf( %ld %ld\n, (long)pls-dev, (long)widget);
Suggests that pls-dev is valid, or at least not zero, but that widget
is still zero after the cast.
Hopefully someone can offer a few suggestions here...
So far I have:
(1) The C++ QtExtWidget constructor is called when the corresponding
python object is created.
(2) The C++ QtExtWidget destructor is called when the program the ends.
(3) The address of the C++ QtExtWidget is not being moved on the Python
side.
(4) Introspection on the C++ side of the python object says that yes it
is a QtExtWidget object. eg. calling this function which I added to
plqt.cpp:
void plprintaddress(QtExtWidget* widget)
{
printf(PA %x\n, (long)widget);
std::cout typeid(widget).name() std::endl;
}
Gives:
PA 1e0d3f0
P11QtExtWidget
(5) Forcing the cast (rather than using dynamic_cast) seems to make
things work (i.e.: widget = (QtPLWidget *)pls-dev;).
(6) Introspection in plD_line_qt like this:
std::cout typeid(pls-dev).name() std::endl;
Gives Pv as the type for both the Python originated QtExtWidget object
and the C++ originated object (by running the c++/qt_example program).
So, any thoughts as to what might be causing the problem with dynamic_cast?
Hi Hazen:
I am just a rank newbie on non-C aspects of C++ like dynamic_cast, but I did
(just) look up dynamic_cast, and it appears the casting conditions have to
follow certain conditions from the object-oriented point of view before
dynamic_cast works. You probably know all this stuff, but just in case, the
discussion I found was at
http://www.cplusplus.com/doc/tutorial/typecasting/. Its possible the code
is violating one of those conditions, but I don't have the object-oriented
expertise to figure out what that condition might be.
There was mention also there of dynamic_cast not working if the wrong
compiler flags having to do with RTTI are being used. But for g++, the
default (-frtti) is correct. I also double-checked that -fno-rtti was not
being used by mistake by inspecting make VERBOSE=1 results for a complete
build from scratch. There was no mention of rtti anywhere in those results
so the (correct) default is being used unless the documentation is all
wrong. Also, I double-checked that g++ (rather than gcc) was being used to
compile and link qt.so (which contains all the dynamic casts in the now
split qt code). So it appears the compilation and linking conditions are
perfect.
Another approach for debugging this issue is to look carefully at the
qt_example.cpp code and also how it is compiled and linked since qt_example
works perfectly right now. So you may want to investigate what is different
about that code or how it is compiled and linked compared to the
sip-generated code, sipAPIplplot_pyqt4.h, sipplplot_pyqt4QtExtWidget.cpp,
sipplplot_pyqt4QtPLDriver.cpp, sipplplot_pyqt4QtPLWidget.cpp, and
sipplplot_pyqt4cmodule.cpp in bindings/qt_gui/pyqt4 which is compiled and
linked into the Python extension module, plplot_pyqt4.so?
Another good possibility for figuring this out is you have stated your
example used to work when you were ignoring the PLplot build system and
simply using python to build plplot_pyqt4.so. If that really is the case,
then by use of the svn checkout --revision argument you should be able to go
back to exactly what we had before in an independent source code tree. If
you confirm that old approach works, but the current approach based on the
build system does not work, then that is an important clue to finding out
what is wrong with the current approach and detailed comparisons of the old
and new source trees and results should find the source of the problem. For
example, did the old python-based approach to configuring and running sip
produce the same sip-generated source code as the new CMake-based approach
to configuring and running sip?
I hope one or more of the above ideas will help you arrive at the needed
breakthrough. I think your pyqt4 work is important so don't hesitate to get
in touch with me off list if you need a (C++ naive, but CMake-smart and
svn-smart) sounding board. Anyhow, I wish you the best in figuring out this
issue.
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
Re: [Plplot-devel] python branch now merged
Hi Geoffrey: Thanks for your continuing efforts to resurrect access to plframe from python. On 2009-06-30 15:20-0500 Geoffrey Furnish wrote: Hi all, I've injected the work formerly done on the python branch, onto svn trunk tip. I've done a little messing around with cmake, so I would appreciate it if people could look over bindings/python/CMakeLists.txt in particular. One concern I have is that someone might disable Tcl/Tk, but enable python. In that case, it seems to me the python widget module should be built without linking to the Tcl/Tk stuff, and without using the TCL_INCLUDE dir. But I'm not able to author that in cmake-ese yet, so if someone could tweak that, I'd be really appreciative. DONE. revision(10105). I have also implemented an install of pytkdemo and its associated x??.py examples. If you build in a way that allows Tcl/Tk and Python to all be found and activated, you'll now have some new options in the Python code. One way to see this would be something along the lines of: cd wherever/plplot/examples/python env PYTHONPATH=$CMAKE_BUILD_PREFIX/lib64/python2.6/site-pakages \ python pytkdemo I tried that in the installed examples tree and I could click on several of the examples and get plotted results. I had never seen pytkdemo work before since I got involved with PLplot in 2000 so that result was nice to see. However, the GUI hung on an attempt to exit by hitting the dismiss button. Furthermore, there is cross-talk between the examples so that after running example 2 (I think), all subsequent examples were displayed at about 1/10th size. So it is working, but it is pretty rough. The other thing worth discussing is just to draw attention to the fact that in the past I had trouble with how the python modules are being linked. I haven't gotten as far as reinvestigating that, so I'll post more on it later. But in the past I found that explicitly linking to PYTHON_LIBRARIES caused problems for some applications. So, that's an open issue that I'll be reporting more on later, after I look into it again. I have a very simple rule that normally assures that linking AND dynamic loading (as occurs when Python loads an extension module) will work cross-platform for PLplot. That rule is ldd -r must not show any undefined symbols on Linux. Now, that is probably not a Linux necessity for the python case where python itself is dynamically loading the extension modules and making its own symbols available that way, but dynamic loading does not necessarily work that way on all platforms so the only safe thing to do with dynamically loaded modules is to link explicitly to resolve all symbols. To illustrate the point try to remove PYTHON_LIBRARIES, and the ldd -r result (which I just demonstrated to myself) is many undefined symbols (which makes sense since the plplot_widgets source code calls functions in the python library). I suspect the problems you had with explicit linking before was multiple versions of python interfering with each other so the python libraries found by cmake were not consistent with your python executable. I am tempted to remove your FIXME comments right now because I am virtually positive that explanation is correct, but I will wait until you are completely satisifed with the results of your further investigations with consistent python libraries and python executable. One additional obvious issue is the old x??.py python examples used by pytkdemo are showing their age, are buggy, and are seriously incomplete. Is there a straightforward way to use the new heavily debugged python examples xw??.py instead without interfering with the widgetless way of using those examples? If so, then please tell me how to do it, or else please make that change yourself. Assuming that works, it would allow us to get rid of those old examples and also rename all the current new xw??.py examples as the corresponding x??.py. Historically, the w in xw??.py stands for widgetless which was not one of my better naming convention moments! Anyhow, I would like to take this opportunity to claim back the x??.py namespace with the modern debugged examples if you can figure out a way to use those examples from pytkdemo so we can ditch the old ones. Other cleanups: * Can we now delete the directory bindings/python/1.4b3 ? * Can I now edit README.pythonbuild to get rid of the explanation of the old method you used to access plframe from python? That old method required a rebuild of a patched version of Python. That gives a bad impression of your work since I suspect most modern users would run away screaming with horror from the idea of rebuilding Python. :-) 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
Re: [Plplot-devel] python branch now merged
On 2009-06-30 23:29-0500 Geoffrey Furnish wrote: Alan W. Irwin writes: [...]I would like to take this opportunity to claim back the x??.py namespace with the modern debugged examples if you can figure out a way to use those examples from pytkdemo so we can ditch the old ones. Yes, I share this goal. I'll be working on that in the coming days, along with some other PLplot+Python improvement plans I have. Great! Other cleanups: * Can we now delete the directory bindings/python/1.4b3 ? Yes. DONE (revision 10106). * Can I now edit README.pythonbuild to get rid of the explanation of the old method you used to access plframe from python? That old method required a rebuild of a patched version of Python. That gives a bad impression of your work since I suspect most modern users would run away screaming with horror from the idea of rebuilding Python. :-) The short answer is: yes. DONE (revision 10107). The long anser is: I'll have to probably revisit the whole topic and explain things again. In my rewrite of README.pythonbuild, I now refer specifically to your recent work. That may already be enough since short explanations that just stick to the overview may be preferable. However, feel free to supplement that further if you like. 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] python extension linking, was RE: python branch now merged
On 2009-07-01 00:09-0500 Geoffrey Furnish wrote: [...]Now, what I find is that if I configure Python (today I tested 2.6.2, but I believe from prior experience that 2.5.x is the same in these regards) by just saying: cd Python-2.6.2 configure --prefix=$PREFIX make make install Then what happens is that libpython2.6.a is installed in $PREFIX/lib, but libpython2.6.so is NOT installed. To get that installed, you have to do: cd Python-2.6.2 make distclean # Critical to avoid configure hysteresis configure --prefix=$PREFIX --enable-shared make make install If you do that, then libpython2.6.so shows up in $PREFIX/lib. HOWEVER: PLplot's Python binding needs numpy. And here comes the rub. It turns out that Numpy's installation will *not work* if the python was built --enable-shared. If you don't build --enable-shared, then you can go into the numpy distribution and run $PREFIX/bin/python setup.py install, and it goes right where you want it, under $PREFIX. But if your installed $PREFIX/bin/python was configured with --enable-shared, then KABOOM, when you run numpy's installer, it tries to write into /usr/lib64/*, and ignores the PREFIX to which your python was configured. One possibility is that the automake based build you seem to be using for python may be outdated. Surely, you can now build a new version of python using an old version of python and the setup.py approach? It's possible if you do that, then numpy will work fine. Another possibility is that in the _numpy_ setup.py, there was a simple oversight where they hardcoded the system path rather than taking into account the possibility that you are building and installing all python-related items with your own PREFIX. It's been years since I have debugged a setup.py file, but IIRC they are usually pretty short so it may not be that difficult for you to debug this issue. But if you cannot do that, then a numpy bug report is certainly indicated. [...]The only solution to this unholy mess that I have been able to find, is to leave PYTHON_LIBRARIES off the link line for the PLplot python extension modules. On Linux at least, I know that this omission is inconsequential. When you actually load the extension modules at run time, the symbols are filled in from the dynloading executor process (which in my case will turn out to be an embellished python with some application-specific python extension stuff compiled in). And all is well. This seems like a reasonable temporary workaround for the bug in numpy installation, but the problem is we have already historically gone through platform testing of excluding PYTHON_LIBRARIES, and it caused problems. Thus, removing PYTHON_LIBRARIES now will always introduce a question mark about the reliability of our python extension module builds. (That concern would be reduced by redoing the platform testing again, but even if it worked now for the platforms we are able to test, it still leaves a question mark for the platforms we are not able to test at this time.) To avoid that question mark, I suggest the following compromise. Put in a cmake option (EXCLUDE_PYTHON_LIBRARIES) which you can set for your needs, and which everyone else can ignore. We can then remove that workaround once the fundamental issue with numpy is fixed. Once I have the okay from you for this approach, I can implement it in about 5 minutes inside cmake/modules/python.cmake by setting PYTHON_LIBRARIES to nothing if EXCLUDE_PYTHON_LIBRARIES is true. 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] plplot_pyqt4 status
10102) +++ examples/python/pyqt4_test.py (working copy) @@ -33,7 +33,7 @@ print init QtGui.QMainWindow.__init__(self, None) -self.plot = plplot_pyqt4.QtExtWidget(800, 800, self) +self.plot = plplot_pyqt4.QtExtWidget(self, 800, 800) self.setCentralWidget(self.plot) plplot_pyqt4.plsetqtdev(self.plot) Index: examples/c++/qt_PlotWindow.cpp === --- examples/c++/qt_PlotWindow.cpp (revision 10102) +++ examples/c++/qt_PlotWindow.cpp (working copy) @@ -35,7 +35,7 @@ plotMenu-addAction(Histogram, this, SLOT(plotHistogram())); plotMenu-addAction(Interactive Selection, this, SLOT(interactive())); - plot=new QtExtWidget(QT_DEFAULT_X, QT_DEFAULT_Y, this); + plot=new QtExtWidget(this, QT_DEFAULT_X, QT_DEFAULT_Y); setCentralWidget(plot); The result builds and installs without issues, and the installed qt_example builds and runs without (valgrind or any other) issues. However, pyqt4_test.py still provides just a black GUI with no plot drawn (sigh). So the above patch works as well as the present situation, but no better. Thus, it only appears to be useful as an indication of where QtPLWidget and QtExtWidget are resident in the source code, and as an example that shows the /TransferThis/ sip directive is (at least) not the complete answer. Hazen, if you want to try out further sip directives having to do with object ownership, the above patch might be a good start for you. 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] python extension linking, was RE: python branch now merged
On 2009-07-01 17:38-0500 Geoffrey Furnish wrote: Alan W. Irwin writes: To avoid that question mark, I suggest the following compromise. Put in a cmake option (EXCLUDE_PYTHON_LIBRARIES) which you can set for your needs, and which everyone else can ignore. We can then remove that workaround once the fundamental issue with numpy is fixed. Once I have the okay from you for this approach, I can implement it in about 5 minutes inside cmake/modules/python.cmake by setting PYTHON_LIBRARIES to nothing if EXCLUDE_PYTHON_LIBRARIES is true. Okay, I didn't perceive the extent of prior work in this area. I'm good with your suggestion. And thanks much for offering to whip that up in cmake. I'm sure you can do it a lot faster than me at this point in time. DONE. (revision 10108). Please test that this option solves your issues. I have only tested it in the default OFF state (i.e., PYTHON_LIBRARIES is is non-empty by default). 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] plplot_pyqt4 status
On 2009-07-02 13:14-0400 Hazen Babcock wrote: Alban Rochel wrote: Hello all, Actually, this is one of the few days I am in contact, so: - I must have misunderstood something about dynamic casts because I believed that QtPLDriver* widget=(QtPLDriver*)(pls-dev) would have created a pure QtPLDriver* object, and thus the member functions called after this would have been e.g. QtPLDriver::drawLine rather than e.g. QtRasterDevice::drawLine (no call of the virtual functions). This was the meaning of my cryptic comment. - There is a simple and straightforward way to fix that without worrying about RTTI or whatever (well, at least for that): just define plD_whatever functions for every kind of driver, using simple C-casts. I went ahead and implemented this fix for the extqt driver only as that is the driver that the PyQt4 bindings are using. If I ever figure out what the underlying issue is will try and clean up the ugliness I've added via this copy-paste approach. Thanks, Hazen, for dealing with this subtle issue. The result passes my much-beloved ldd -r tests for qt.so, libplplotqt.so, qt_example, and plplot_pyqt4.so. Also, qt_example continues to work well and continues to give a clean valgrind result As of revision 10114, I got rid of the old version of the pyqt4 example since the new one supersedes it, and I fixed the issue with the new example that occurred for a non-standard PLplot installation prefix. The new pyqt4 example works fine for me which I was very happy to see! Now that you have gotten pyqt4 to work correctly with PLplot, I am looking forward to you extending the present example and/or adding additional pyqt4 examples to demonstrate the pyqt4 PLplot possibilities that have now opened up. What do you think of removing the pyqt3 example (prova.py and qplplot.py) in examples/python now that we have a working pyqt4 example? Maintenance releases of pyqt3 continue as can be seen at http://freshmeat.net/projects/pyqt/releases/301031. So we cannot justify removing our pyqt3 example based on pyqt3 no longer being viable, but on the other hand, nobody has worked on our pyqt3 bindings or our one pyqt3 example since they were donated years ago, and we now seem to have a pyqt4 alternative that is being actively developed and used by you. 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] [Plplot-cvs] SF.net SVN: plplot:[10113] trunk/examples/python/pyqt4_example.py
On 2009-07-02 17:26-0400 Hazen Babcock wrote: air...@users.sourceforge.net wrote: import sys from PyQt4 import QtCore, QtGui +from plplot_python_start import * import plplot import plplot_pyqt4 I took that out since I could not run the example with it in the build tree. What is it supposed to do? plplot_python_start.py is a file that we configure separately for the build tree and install tree. The build-tree version points to the location of the python extension modules and ordinary python modules scattered in the build tree. I forgot to configure in the bindings/qt_gui/pyqt4 location, but I just fixed that with revision 10115. (The install-tree version of plplot_python_start.py that is configured, simply points to the single install tree location where the extension modules are installed.) So that is why my install-tree tests worked before, but why a change was needed to get the build-tree version to work. After copying pyqt4_example.py from the source tree to the build tree where the configured build-tree version of plplot_python_start.py is located, (or running a -DBUILD_TEST=ON build which does the same thing), I can run PLPLOT_LIB=/home/software/plplot_cvs/HEAD/plplot_cmake_qt/data ./pyqt4_example.py without issues from that build-tree location. I assume you can run ./pyqt4_example.py from the source tree location as well if you copy the configured plplot_python_start.py back to there from its build tree location. But that violates the principal of keeping your source tree absolutely clean. 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
[Plplot-devel] style
I have changed to the style subject line for this since it touches on three separate recent threads with varying subject lines involving style. On 2009-06-30 15:20-0500 Geoffrey Furnish wrote: Oh, one more really last thing. I haven't gotten around to trying out Alan's proposal for plplot-mode. It seems to me consensus on style has largely been reached, but I remain deeply concerned that all the thought and time that has gone into this discussion will be completely wasted unless somebody can come up with at least one method to make it easy to conform to our agreed-upon style consensus. Changing plplot-mode.el to reflect our style consensus is just one possibility for that, but my newbie emacs questions on how to use emacs to control more than just indentation (for example, to place whitespace around parentheses, break or attach brackets, etc.) have gone unanswered. It appears to me from describe-mode that parentheses and braces are specially defined so the answer may be that with the appropriate modifications to plplot-mode.el, that all new code will automatically conform to our parentheses and bracket style. I just checked with a bit of new C code, and it appears those modifications still need to be made. But I hope this much at least is possible with emacs. However, because of the strong possibility that emacs may not be suitable for changing the style of our old code, I started looking for other coding-style tool alternatives, and the first one I found (called astyle) looks interesting. Please take a look at http://astyle.sourceforge.net/astyle.html for all the possibilities for dealing with whitespace, parentheses, and brackets in programme source for C, C++, and Java. It's a command-line tool with the possibility of using a style file to control transforming our code base to our style consensus. Thus, at first look it seems ideal for our needs, and I would appreciate others here to look at it in more detail to make sure that really is the case. But I did pull down and install cmake-mode.el. Hoping to keep our style as similar as possible, despite several different languages being in play in the PLplot project, I changed cmake-mode.el to use 4 (rather than 2) for the tab stop setting. It seemed from our former discussion about C style, that people were all good with 4 char indentation levels, so I plan to use that also in my cmake-mode.el (and today's commits reflect that). I personally prefer two-space indentation for all languages and generally much less sprinkling around of white space than others here. However, it does appear to me that a consensus has formed around 4-space indentation so I am willing to go along with that in all our languages including CMake. Does anyone know why describe-mode doesn't seem to have much to say about cmake-mode? Skimming the file, you'd think there would be a number of functions bound to keys, but apparently not. Seems strange. Am I missing something that anyone else has found? cmake-mode.el is a work in progress by the CMake team of developers. The (almost) latest version can be found at cmake-2.6.4/Docs/cmake-mode.el. I just checked, and that is very different from the equivalent file for cmake-2.6.0. So if you are trying out an earlier version you should probably switch to the 2.6.4 version. That said, I just switched from the 2.6.0 version to 2.6.4, and the describe-mode results appear to be unchanged. I say almost above, because my understanding from the CMake mailing list is there has been a recent burst of activity extending cmake-mode.el in the form of a patch from an outside person adding some substantial functionality. The CMake developers apparently like the patch and have promised to put it into their cvs version and eventually their next release. Anyhow, Geoff, if you wanted to grab the 2.6.4 (or cvs) version of cmake-mode.el and commit it with an adaptation for our indentation needs, please do so. 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] cmap0.pal and cmap1.pal support
On 2009-07-07 11:06-0400 Hazen Babcock wrote: Alan W. Irwin wrote: plLibOpenPdfstrm currently tries a large number of standard locations (including the current directory) to find the file specified. Any pointers for using this function? When I try: fp = (FILE *)plLibOpenPdfstrm(filename); instead of: fp = fopen(filename, r); I get a segmentation fault at my first attempt to read from the file: fscanf(fp, %d\n, number_colors); My guess was that this was due to the fact that it opens the file in rb mode instead of r mode, but when I modified it to use r mode I still got the same segfault. Both plsym.c and plmap.c use routines in pdfutils.c to actually read the file they open with plLibOpenPdfstrm. So you might want to do the same (using pdf_rd_header?) or else adapt the file access methods in the pdfutils.c code for the colour palette reading needs. An additional format issue I just thought of for these ascii colour palette files is line endings. Presumably some of our Windows users will want to edit these files directly (since they have no access to -dev tk or the associated colour palette GUI) so the resulting ascii files will have the Windows line endings (\cr followed by \nl as opposed to the Unix \nl). Also, assuming that we use the svn native line ending property for these files, our Windows users will checkout a version of our official palette files that have the windows line endings. I presume the Windows line endings means the null-terminated string returned by pdf_rd_header will have a \cr prepended to that null termination which will require a bit of care when parsing that string (or a special provision in pdf_rd_header to remove the \cr if it exists and the platform is windows). 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Experimental OCaml support for the extcairo driver and plots in Gtk+ OCaml applications
Hi Hez: On 2009-07-09 12:01-0400 Hezekiah M. Carty wrote: Commit 10127 adds an experimental PLplot add-on library under bindings/ocaml/plcairo/ which allows one to use the extcairo driver under OCaml. The Plcairo library allows you to provide a Cairo context created with the Cairo OCaml bindings to PLplot for use with the extcairo driver. This supports modifications to the plot surface with Cairo directly as well as embedding extcairo plot surfaces in Gtk+ applications with the OCaml Gtk+ bindings (the lablgtk library). Three examples are included in the bindings/ocaml/plcairo/tests/ directory. These demonstrate some simple Cairo use, using multiple plot pages with the Plcairo library and embedding a PLplot-generated plot in a Gtk+ application window. I can see why you want to keep everything together at this experimental stage but ultimately you will want to move bindings/ocaml/plcairo/tests to examples/ocaml/plcairo (or possibly examples/ocaml) since the final location of all examples should be in the examples tree. aside for Andrew as octave maintainer Years ago Joao Cardoso donated octave binding and examples to PLplot with everything integrated into one bindings/octave tree. Through inertia the octave examples still reside there today. Do you agree with me that for consistency's sake we should move the octave examples to examples/octave in the source tree? If you like this idea, I can do all the build system changes (if you don't beat me to it), but I would probably need help from you with the pure octave side of things e.g., setting up octave to find the newly located examples in the build tree. /aside I have been using a similar version of this code for a while now, and it seems to function properly. That said, the API is very likely to change as I figure out the best way to integrate it properly in to the core OCaml bindings. Plcairo is built separately from the rest of PLplot at this point and does not yet make use of the PLplot CMake build system. Hez, if you are willing, this appears to be an excellent opportunity for you to become more familiar with CMake. :-) I think making use of the PLplot build system should be straightforward for you (just by following what is done for the ordinary OCaml bindings and examples), but if you run into any difficulties, I would be happy to answer your questions (or step in and find solutions if you become really stuck). 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] cmap0.pal and cmap1.pal support
On 2009-07-09 10:18+0100 Andrew Ross wrote: [...]I suggest we go with floating point in the range 0-1 for the pos parameter. For consistency we should also ensure we do the same for the r, g, b values. While we are on (since this requires a new file format) perhaps we should also add support for the rev parameter and for HLS as well as RGB color spaces. I've committed a straw man implementation for comment. This supports the old format .pal files, but any file which starts with v2 is assumed to be in the new floating point format. I've also included a sample palette in the data directory (cmap1_blue_yellow.pal). This is one I've used in the past for various plots and I quite like. I made some important changes today (up to and including revision 10135). * Fixed a bug for the old format where the rgb colours were not properly normalized (they ranged from 0 to 255 rather than 0. to 1.). This was the reason the bindings/tk/cmap1*.pal files gave such bad looking results before. (However, I agree that for the new format, the rgb colours in the file should be normalized to the range from 0. to 1.) * Fixed bug in current directory pldebug information output for plLibOpenPdfstr. * Dropped fopen logic that was screwing up the -cmap0 and -cmap1 options. (It is possible I am missing something there, but I don't believe there was any way for the old logic to work properly.) * Dealt properly with two (!) old tk formats (one with and one without rev information). bindings/tk/cmap1*.pal has the oldest format (without rev), but current output from -dev tk GUI cmap1 palette editor outputs rev information. My implementation demands the file stick to one or the other of these old formats if it is not the v2 format. * Implemented range checking for most of the plspal0 and plspal1 values that are set. Most of this range checking is routine, but now demand at least 16 colours when setting cmap0. I have done this because I now call plscmap0n from within plspal0. * Added cmap0_black_on_white.pal (black lines on white background) and cmap1_gray.pal (gray scale). cmap0_black_on_white.pal works well (at least to my eyes) with cmap1_blue_yellow.pal for the standard examples. (It is obviously a matter of personal taste, but I find the default cmap0 colours or the cmap0 colours in cmap0_white_bg.pal clash a bit with cmap1_blue_yellow.pal. Furthermore, for light backgrounds I far prefer the visibility of black lines to the coloured lines you get for the standard examples with the default cmap0 colours or the cmap0 colours in cmap0_white_bg.pal.) cmap1_gray.pal gives reasonable looking gray scale results for example 16, and should be useful (along with cmap0_black_on_white.pal) for those scientific journals who are still reluctant to publish colour figures. After these changes I am satisfied with the current status of our C library palette support, and the v2 format for cmap1 files seems fine to me. I believe the next step is to change the -dev tk colour palette editing GUI so the transparency can be edited, displayed and output for both pal0 and pal1 (with the latter in v2 format). After a week or so delay to make sure we have finalized the API, we should also propagate plspal0 and plspal1 to all the other languages 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] cmap0.pal and cmap1.pal support
On 2009-07-10 08:53+0100 Andrew Ross wrote: One further addition would be to explicitly set a palette using these commands in one of the examples. I don't have a strong preference which. Perhaps example 16? Yes. That is the best example for displaying cmap1 palettes that I have found, and like most other examples it is good for displaying cmap0 palettes as well. One further point - if the user explicitly adds -cmap[0]1 to the command line should this override any explicit calls to plspal[01]? As I recall this whole command-line options business is a bit of a can of worms so you might look into the suggestion below and find there is an even more urgent options issue that must be solved first. But for what it is worth, I believe the above question should be generalized to how we treat most command-line options. IIRC, they are currently always superseded by the explicit calls, but I think for many of them there would be some usefulness to allowing the command-line option to override explicit calls. Thus, I would suggest implementing this with one more command-line option (let's call it optfreeze for now) to turn off all explicit settings for certain of the command-line options after the parsing of command-line options is done. (IOW, you get the same result regardless of where optfreeze is set on the command line.) You could start by making plscmap0 and plscmap1 optfreeze aware and expand the list of functions with optfreeze awareness as time permitted. I am tempted to say make all such functions optfreeze aware, but there are bound to be a few (such as optfreeze itself) where we probably want explicit overrides to always work. 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] style
On 2009-07-12 10:19-0700 Alan W. Irwin wrote: What is needed now is a volunteer with a keen eye for C/C++ style issues to evaluate uncrustify-0.53 (and the latest versions of the others on the list if uncrustify is unsuitable) to find the combination of options which enforces the consensus on style that we have reached (i.e., the style details mentioned on list by Geoff which all core developers appeared to be willing to go along with). I am tempted to volunteer for this myself because I think it is really important to come up with a method of converting PLplot source code to a consistent style after all the effort that has gone into thinking about the ideal PLplot code style. However, I don't have a keen eye for C/C++ style issues since I am not as experienced in those languages as other PLplot developers. Thus, if I do this I might come up with a set of uncrustify options that enforce every style issue that Geoff brought up but still leave some obvious style issue in the result that will require additional work to fix. Thus, it would probably be best if someone else volunteered for this task. Well, we still need that style-conscious volunteer, but to get the ball rolling I just committed uncrustify.cfg in the top-level source tree which I think already does a pretty good job of enforcing the consensus style we have been discussing. uncrustify-0.53 has a number of example style files including the default style, defaults.cfg (which defines some 350 options). One of those style files is ben2.cfg which is the favorite style of the author of uncrustify. It only mentions ~60 options so I assume those are the most important options, and the code uses defaults.cfg for the rest. I edited ben2.cfg to create uncrustify.cfg. You can run it like this: ~software/uncrustify/install/bin/uncrustify -c uncrustify.cfg -f \ drivers/qt.cpp |less where the application pathname must point to the (latest) 0.53 version of uncrustify. I adjusted uncrustify.cfg following the documentation in defaults.cfg until the results looked consistent with what was mentioned on list. In addition to using less to view stdout, I have also used the programme to create a local styled form of qt.cpp which builds without issues. However, when looking at the styled source code I noticed that line breaking on one ugly long line starting with static DrvOpt qt_options gives an even uglier (but still correct) result. I presume it is the combination of alignment options (which I didn't change from Ben's version) which need tweaking here. Anyhow, uncrustify.cfg needs some more work following the documentation in defaults.cfg (from uncrustify-0.53), and patches or commits to that effect would be most welcome. 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] 5.9.5 release roadmap
On 2009-07-12 19:34-0400 Hazen Babcock wrote: Hello, We are rapidly approaching the tentative early August release date for PLplot 5.9.5. I believe we still have the following features pending for this release: (1) The addition of the plarc() function to the API. (2) Custom axis labeling. (3) Automated coding style cleanup. Anything else that we want to get in? Anything that we want to drop for this release? After this we'll be (or at least should be :) ) focusing our attention more on stability and less on features until after 5.10 comes out. Thanks for that reminder. It's amazing how quickly this summer is going by. Here are some additional features I would like to see in this release. (4) Improved interactive testing (much progress, but still only partially done). (5) Finish work on qsastime (leap seconds, ephemeris time, TT, etc.) and extending python example 29 to demonstrate these new time capabilities once they are available. (6) Propagate python example 29 (once it is finished) to the other languages with API adjustments as needed for our various languages. Feature 4 should not take me too much longer. I am sorry feature 5 has already been delayed much too long, but I promise to get back to it and finish it off. Once it is done, feature 6 is completely straightforward. In light of the above 6 features (and probably more since I assume Werner will want to finish his D examples), a release date of only two weekends from now (which was my idea in the first place) is obviously optimistic. So let's put it off until the earliest weekend in September that is convenient for Hazen, but make that a hard deadline (since timely releases are important). 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] style
) later after a satisfactory C++ style result has been produced. Once you are reasonably happy (via browsing through the results without actually changing any files) with the style produced by uncrustify.cfg for our C++ source files, then the next two tasks are to (1) test that uncrustify styling produces no changes in object files for all our C++ source, and (2) (assuming it passes that test) actually do the style changes and commit the results for our C++ source. The uncrustify -F option (which allows you to conveniently specify a list of files to be processed) should help for both tasks. I would be happy to implement automated scripts for (1) and (2) since I presume this process will need to be repeated from time to time. 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Aspect ratio fix for rotated plots
On 2009-07-14 15:01+0200 Mark de Wever wrote: Hi, The calculation of the aspect ratio doesn't take the rotation angle of the plot into account. This patch solves the aspect ratio for 90 and 270 degrees. Using other rotation angles still give odd results, should I file a bug report for this issue? Could you be more specific by running one of our standard examples and giving the exact command-line options where you are seeing the problem? It is possible you are seeing a rotation bug for a specific device rather than a core issue. I have just run our first standard example using -dev xwin with -ori 0, -ori 1, -ori 2, and -ori 3, and the default 4:3 aspect ratio is preserved in the results. Historically, I have also run this test on other devices with good results as well. However, I may have missed one. I do agree for all devices there are obvious problems (rectangles turn into parallograms) for non-integral -ori options such as -ori 1.2, but that is a well-known long-standing problem which nobody has been motivated to figure out, 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Aspect ratio fix for rotated plots
Hi Mark: (I also have an important note for Hazen at the end.) On 2009-07-15 10:48+0200 Mark de Wever wrote: Alan W. Irwin wrote: On 2009-07-14 15:01+0200 Mark de Wever wrote: Hi, The calculation of the aspect ratio doesn't take the rotation angle of the plot into account. This patch solves the aspect ratio for 90 and 270 degrees. Using other rotation angles still give odd results, should I file a bug report for this issue? Could you be more specific by running one of our standard examples and giving the exact command-line options where you are seeing the problem? It is possible you are seeing a rotation bug for a specific device rather than a core issue. I have just run our first standard example using -dev xwin with -ori 0, -ori 1, -ori 2, and -ori 3, and the default 4:3 aspect ratio is preserved in the results. Historically, I have also run this test on other devices with good results as well. However, I may have missed one. I just tested with the xwin device, with the following command: ./x01 -dev xwin -ori 3 -geometry 500x800 This is what my patch is supposed to fix. That does look odd, but all it is doing is rotating (and shrinking to fit into the window) the odd aspect ratio you have specified for ./x01 -dev xwin -geometry 500x800 In other words, the -ori option preserves the aspect ratio you get with -ori 0 (or no -ori option at all). So this is designed behaviour and not a bug. I suspect you want the aspect ratio of the rotated plot adjusted to fit into the window. In that case, use the -freeaspect option. You mentioned the default aspect ratio so I started to play a little bit with the aspect ratio and with the following command the plot also looks fine: ./x01 -dev xwin -ori 3 -geometry 500x800 -a 2 If you specify the aspect ratio, I just double-checked that is what is plotted at all -ori values (rather than the default aspect ratio you get with -ori 0). I hope this explanation clears everything up for you. I [...] also tested with the xcairo driver and it seems that when plotting rotated the text is no longer drawn. Good spotting! That is definitely a bug. The rest of this is a note for Hazen who is our cairo expert: Hazen, this cairo bug has to do with clipping of the subpage limits at the positions of the _original_ subpages rather than the rotated ones. To convince yourself of that try the series ./x01 -dev xcairo -ori 0.0 ./x01 -dev xcairo -ori 0.05 ./x01 -dev xcairo -ori 0.1 ./x01 -dev xcairo -ori 0.15 ./x01 -dev xcairo -ori 0.2 ... ./x01 -dev xcairo -ori 0.5 (which also nicely demonstrates the long-standing parallelogram bug in the PLplot core library, but that is beside the point here). You will see that in all series cases, the only text output is that which is still in the original subpage position. Of course, by the time you extend the series to -ori 1, -ori 2, and -ori 3, none of the rotated text is in its original (unrotated) sub_page window so all of the text is completely clipped. To further confirm the issue is a text clipping one, the problem disappears if you turn off text clipping completely with -drvopt text_clipping=0 which is a temporary workaround for the problem if you don't mind unclipped text. To fully deal with this cairo issue, the proper thing to do is to implement rotated sub-page boundary clipping limits for text. I hope that would be fairly trivial for you? 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] windows/mingw32 build questions
On 2009-07-15 17:53-0400 Hazen Babcock wrote: Alan W. Irwin wrote: [...]Furthermore, if you are still getting a warning (now) about a missing C++ compiler, I frankly don't understand why 5.9.4 works for you at all without erroring out at cmake time. The C++ language was an absolute requirement for 5.9.4. The method used to find C++ had a different top-level (the project command without any languages specified is the same as demanding C and C++), but the underlying method (CMakeDetermineCXXCompiler) for finding the C++ compiler should be identical. Are you using the exact same generator and environment variables for both PLplot 5.9.4 and PLplot svn trunk? The generator and CXX environment variable will make a difference to whether you find a C++ compiler or not. I believe everything is the same. I am using the CMake GUI configuration utility and not the command line cmake (due to the apparent gdi32 issue). The problem is that cmake-gui-plplot-5.9.4 considers my C++ compiler to be findable/acceptable whereas cmake-gui-plplot-svn does not. Note that cmake-gui-plplot-svn does find a Gnu CXX compiler but then errors out anyway. Any ideas about what might have changed to lead to this difference would be appreciated. I'd like to get Qt and PyQt working on the windows computer that I have access to so I'll need to get past this C++ hang up (and/or figure out the gdi32 thing so that I can use the command line version of cmake). Try disabling the wingcc device to avoid anything to do with gdi32. Does that solve all your Windows build issues? If under those conditions cmake works, but the cmake GUI does not for the svn trunk version, then that probably means my recent changes in how C++ is found have exposed a bug in cmake-gui. Frankly, I far prefer the cmake application since it makes it much easier to replicate issues. With a GUI it is never clear exactly what buttons got pushed in what order to generate the bug, certain sequences of commands can generate stale cache issues, and output is often difficult to capture. Furthermore, the cmake application is a mature product while I believe cmake-gui was only introduced at the start of the cmake-2.6.x series so there are likely to be more bugs in it than the cmake application. That said, I will try to replicate the issue with the cmake-gui application on Linux. By default cmake-gui is not built on Linux, but I just discovered that it does get built and installed if you use the CMake bootstrap --qt-gui option and qmake (from your qt development environment) is on your path. More later. 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] windows/mingw32 build questions
On 2009-07-15 16:19-0700 Alan W. Irwin wrote:
If under those conditions cmake works, but the cmake GUI does not for the
svn trunk version, then that probably means my recent changes in how C++ is
found have exposed a bug in cmake-gui.
I confirm this cmake-gui issue on Linux with the PLplot build and also for the
following really simple test case.
#stanza 1
project(test NONE)
cmake_minimum_required(VERSION 2.6.4)
#stanza 2
include(CMakeDetermineCXXCompiler)
message(STATUS CMAKE_CXX_COMPILER = ${CMAKE_CXX_COMPILER})
#stanza 3
enable_language(CXX OPTIONAL)
message(STATUS CMAKE_CXX_COMPILER_WORKS = ${CMAKE_CXX_COMPILER_WORKS})
The above combination is essential for the soft-landing logic, but it turns
out that combination exposes a cmake-gui bug
(CMAKE_language_COMPILER_WORKS is undefined for that combination) which I
have reported to the CMake list. For those following that list, I thought
of a particular workaround for the cmake-gui bug, but it turns out that
solution does not work for PLplot because cmake-gui leaves additional
essential language variables undefined for combinations like the above.
So we have the ugly choice of hard landings if any (!) of Ada, C++, D,
Fortran, or Java developments are missing (the model used in PLplot release
5.9.4 and rightly objected to by Geoffrey since it gives a bad first
impression) or use the present soft-landing system which precludes using
cmake-gui since that application currently gets confused (essential language
variables become undefined for some reason) by combinations like the above
stanza 2 and 3 for any language. To summarize the choice we can have
no soft landings or no cmake-gui.
Which is the preferred choice that we use until this can of worms is cleaned
up by the CMake developers?
I would be happy to implement whatever we decide and write up the resulting
limitation in our build system (no soft landings or no cmake-gui) in
README.release.
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
__
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] windows/mingw32 build questions
On 2009-07-15 22:46-0700 Alan W. Irwin wrote: [...]To summarize the choice we can have no soft landings or no cmake-gui. Which is the preferred choice that we use until this can of worms is cleaned up by the CMake developers? I would be happy to implement whatever we decide and write up the resulting limitation in our build system (no soft landings or no cmake-gui) in README.release. Ugh. I just had pointed out to me by a CMake user on the CMake list (and I also confirmed) that ccmake also has the same problem as cmake-gui. So if the CMake developers can't come up with a workaround for this ccmake AND cmake-gui issue I will probably go back to the 5.9.4 hard landing model. 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] windows/mingw32 build questions
On 2009-07-15 22:46-0700 Alan W. Irwin wrote: [...]To summarize the choice we can have no soft landings or no cmake-gui. I have just committed (revision 10153) the hard-landing solution because there is no way I wanted to have both ccmake and cmake-gui provide broken language results such as found by Hazen and confirmed in detail by me. However, immediately after I did that commit, the CMake gurus on the CMake list came up with a temporary workaround for bug http://public.kitware.com/Bug/view.php?id=9220. The workaround should provide a soft landing for both the missing and broken compiler cases which I think will work quite well. However, the implementation of this idea (to run a simple cmake configuration from within cmake to check on each compiler in question) is non-trivial so it will take me a while to finish with this issue. So more later. 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] windows/mingw32 build questions
On 2009-07-16 14:04-0700 Alan W. Irwin wrote: On 2009-07-15 22:46-0700 Alan W. Irwin wrote: [...]To summarize the choice we can have no soft landings or no cmake-gui. I have just committed (revision 10153) the hard-landing solution because there is no way I wanted to have both ccmake and cmake-gui provide broken language results such as found by Hazen and confirmed in detail by me. However, immediately after I did that commit, the CMake gurus on the CMake list came up with a temporary workaround for bug http://public.kitware.com/Bug/view.php?id=9220. The workaround should provide a soft landing for both the missing and broken compiler cases which I think will work quite well. However, the implementation of this idea (to run a simple cmake configuration from within cmake to check on each compiler in question) is non-trivial so it will take me a while to finish with this issue. So more later. I believe I have now (revision 10157) finished this saga. The new soft-landing method (issue a warning message, disable that component of PLplot, and continue) when compilers are missing/broken seems to work well. For example, it appears to work both for cmake and cmake-gui. Please try it out. I have also enabled the D compiler by default since its examples are fairly complete and the bindings and examples build without issues. Previously, we were rather reluctant to enable a new language by default, but now that a missing/broken compiler only causes a warning, I believe the criteria for enabling a language by default do not have to be quite so severe as before. 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Aspect ratio fix for rotated plots
On 2009-07-18 19:36-0400 Hazen Babcock wrote: Alan W. Irwin wrote: Hazen, this cairo bug has to do with clipping of the subpage limits at the positions of the _original_ subpages rather than the rotated ones. To convince yourself of that try the series ./x01 -dev xcairo -ori 0.0 ./x01 -dev xcairo -ori 0.05 ./x01 -dev xcairo -ori 0.1 ./x01 -dev xcairo -ori 0.15 ./x01 -dev xcairo -ori 0.2 ... ./x01 -dev xcairo -ori 0.5 The text clipping should be sort of fixed as of v10159. By sort of I mean that if you look at -ori 0.5 you can see that the xcairo driver is drawing text in areas where the graphs have been clipped (ie. on the left and right sides). So it seems that there is some additional text clipping information that the driver should be heeding. Any ideas what that might be? I have no idea why the PLplot core drawing clipping is acting in that peculiar way (visible offsets to clipping at the left and right borders of the overall X window) for -ori 0.5. Even if you try ./x01 -dev xwin -ori 0.5 -a 1 -geometry 800x800 there is a small (but incorrect, IMO) visible clipping offset at the right and left borders. And I wouldn't be surprised if there is also a similar incorrect clipping offset at the top and bottom as well which goes the other way so you don't see it because it is completely outside the X window. So I think your current cairo text clipping is correct, and the core drawing clipping wrong for non-integer -ori values. I guess we can ascribe this to yet another strange core effect for non-integer -ori values. Anyhow, the core and xcairo now agree about clipping for integer ori values which is the important thing. So thanks very much for this commit! 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-cvs] SF.net SVN: plplot:[10161] trunk/drivers/cairo.c
On 2009-07-19 01:59- hbabc...@users.sourceforge.net wrote: Revision: 10161 http://plplot.svn.sourceforge.net/plplot/?rev=10161view=rev Author: hbabcock Date: 2009-07-19 01:59:08 + (Sun, 19 Jul 2009) Log Message: --- Units are PI/2 not 2/PI. Also change to using the PLplot constant PI instead of 3.14159 Modified Paths: -- trunk/drivers/cairo.c Hi Hazen: Obviously, the PI/2 unit is the correct one, but what bothers me is the text clipping seems the same (good) both before and after this commit. If you also cannot spot any visual difference between the two commits, is there something that we are missing? 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] RE : Removed dynamic casts from Qt driver
On 2009-07-20 16:46+0100 Rochel, Alban wrote: Hello Andrew, Here is a version of the same patch based on R10166. There were indeed conflicts with your changes. There should be about 5 versions for the callbacks: - rasterqt (for png, bmp...), sometimes specialised as pngqt, bmpqt... where needed - svgqt - epspdfqt (sometimes epsqt and pdfqt) - qtwidget - extqt This patch only makes the code 20 per cent larger, and I think that is a completely acceptable price to pay for peace of mind about issues with how dynamic casting is implemented on Linux. Furthermore, qt.so built without issues and make test_noninteractive in the installed examples tree generated epsqt, pdfqt, bmpqt, jpgqt, pngqt, ppmqt, tiffqt, and svgqt results without issues. Also, c++/qt_example (which exercises extqt) worked fine. Therefore, I have committed this as revision 10168. Thanks, Alban! 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 __ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] unexported symbols for libplplotqtd.so (and plplot_pyqt4.so)
On 2009-07-21 05:23-0700 Alan W. Irwin wrote: On 2009-07-21 10:53+0100 Andrew Ross wrote: This just leaves the issue of getting the right PLDLLIMPEXP macros into the sip generated code. I have added the infrastructure to define the PLDLLIMPEXP_PYQT4 macros. All that is required is to add this macro to the definition of initplplot_pyqt4 in sipplplot_pyqt4cmodule.cpp and everything works. I've done this by hand and checked that the pyqt4_example.py example works correctly. I know nothing about sip. Is it possible to do this automatically or do we need to massage the code after it has been generated? I only know a slight bit about sip, but the specification files (such as plplot_pyqt4.sip) are very similar to headers. You will see in that file #include qt.h which in turn generates #include qt.h in sipplplot_pyqt4cmodule.cpp. I presume you could #include other headers as well in the sip specification file and they would correspondingly be #included in sipplplot_pyqt4cmodule.cpp. Would it be possible to #define initplplot_pyqt4 in a special header or even in qt.h so the PLDLLIMPEXP_PYQT4 macro is effectively used? I was all set to try this idea, but I couldn't even get the above by hand method to work wherever I placed the PLDLLIMPEXP_PYQT4 on the two alternate lines which define initplplot_pyqt4. Did you forget to commit something? For example, I cannot find any mention of pyqt in pldll.h.in. 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] windows/mingw32 build questions
On 2009-07-22 22:51-0400 Hazen Babcock wrote: Alan W. Irwin wrote: I believe I have now (revision 10157) finished this saga. The new soft-landing method (issue a warning message, disable that component of PLplot, and continue) when compilers are missing/broken seems to work well. [...]I just tested this today with MinGW on Windows and the cmake GUI no longer crashes when run on plplot v10175. However... I have the standard MinGW C++ compiler which worked in the past for compiling PLplot but neither command line cmake nor gui-cmake will let me use it. Nobody can help you without details. Therefore, could you be a lot more specific? What environment variables did you set (if any) to help cmake choose the compiler? What were the cmake options that you used? What generator did you use? What was the complete cmake output that you got? etc., etc. 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] windows binaries and/or installer
On 2009-07-24 15:25-0400 Hazen Babcock wrote: Alan W. Irwin wrote: Also note that my new CMake-based build system for the installed examples _should_ work on Windows (unlike the traditional Makefile+pkg-config approach) so it should be quite useful for Windows users of your planned binary package. But as far as I know, it hasn't been tested yet by our developers with access to a Windows box so it may need some additional work for that platform. I'll give it a test. That's great. I am really keen to make sure this new build system for our installed examples works just as well on Windows as it currently does on my Linux platform so I will try to give you fast turnaround if you discover some inadvertent cross-platform issues. However, such issues should be fairly limited since most of the scripts used are identical to what is used for ctest of the build tree (which both Arjen and Werner say works for them.) However, just to be sure you get the same results they do, I suggest you try ctest first. Once you have confirmed that is working for you, then you should be in good shape to test the new install-tree build system (on any platform. I don't think it has been tested on Mac's, either.) I assume you are referring to the what you discussed in your May e-mails Status of the new CMake-based build system for the installed examples? Yes. Maybe we should add those instructions to the wiki and/or update README.testing? Yes. I plan to do this before the forthcoming release unless someone else beats me to it. 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] windows binaries and/or installer
, and the places to download binary versions of qt and cairo, if the user was interested in those devices I would also replace the part of your script that is used to generate a binary distribution of PLplot since that just duplicates CPack functionality. Of course, CPack wasn't working at the time you first put the script together years ago so I understand why you did this, but I far prefer that Hazen get the CPack binary distribution functionality working since that supports zip and also many other packaging formats which we might find useful for our future needs. 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] windows binaries and/or installer
of a no_external binary package for PLplot which installs no external libraries, but instead gives the users the above script to build what they need. That option does not require external source distribution since you are not distributing external dll's in that case. Probably most users would prefer the complete light-weight or heavy-weight packages (at least to start), but the no_external package costs little to produce compared to the others, and its popularity (as measured by SF download statistics) might surprise us. 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
[Plplot-devel] Default colour palette files and background colour errors for some devices
Hi Hazen: (with a question for Alban below). I have just committed (as of revision 10186) the default colour palette files cmap[01]_default.pal which correspond to what you get by default from PLplot if no colour palette files are specified and you are using the default dark background. (The latter condition needs to be stated because PLplot uses a different default cmap1 for light backgrounds because of the vertex logic in plctrl.c. If someone actually likes the default cmap1 for light backgrounds they are welcome to add another cmap1 colour palette file corresponding to it.) Furthermore, I have made it easier to select these default colour palette files; when the actual argument of plspal0 is an empty string, cmap0_default.pal is chosen, and similarly for plspal1 and cmap1_default.pal. Finally, I have changed example 16 to change the colour palettes for each succeeding page. The new example 16 has revealed some device driver problems for the way that background colours are (not) supported. For -dev xwin the 4th page of example 16 stubbornly retains the white background of the previous pages rather than changing to the specified black background of cmap0_default.pal. There are also background colour errors for -dev qtwidget. I first spotted this for x16, but it turns out to be an issue for all examples. You can easily demonstrate this, by, e.g., running ./x10c -dev qtwidget -bg ff which should produce a white background but the resulting background colour is black. I suspect only a black background colour is supported for all qt devices. Alban, can you confirm (and hopefully fix) this issue? All other devices I have tried (xcairo, psc, psttfc, epscairo, and svg) produced correct colour results for all pages of example 16. Hazen, do you agree it is time to propagate pl[sg]pal[01] and example 16 changes to our other languages? Ideally, we will want to take care of this before our forthcoming release which is scheduled for early September. 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] PDL version check
On 2009-07-28 12:09-0600 Orion Poplawski wrote: The PDL version check code does not handle development version numbers. Could this be fixed? Thanks! -- PDL_VERSION = 2.4.4_05 -- WARNING: PDL version 2.4.1. Disabling Perl/PDL examples in tests Hi Orion: Thanks for highlighting this issue. I believe I have just (revision 10187) fixed this by ignoring everything in the version string after and including any character that does not match [0-9.]. I have also taken the opportunity to make TRANSFORM_VERSION more robust in other ways. Please give the new version a try and let me know whether it solves the above issue. 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] Default colour palette files and background colour errors for some devices
On 2009-07-29 08:41+0100 Alban Rochel wrote: Alan W. Irwin wrote: There are also background colour errors for -dev qtwidget. I first spotted this for x16, but it turns out to be an issue for all examples. You can easily demonstrate this, by, e.g., running ./x10c -dev qtwidget -bg ff which should produce a white background but the resulting background colour is black. I suspect only a black background colour is supported for all qt devices. Alban, can you confirm (and hopefully fix) this issue? Hello all, Actually, I didn't even know of the possibility to change the background colour and didn't realise there could be something missing here as this is not something we use in QSAS. So of course I confirm the issue and I will hopefully fix it this week. Thanks in advance, Alban. I suggest you use as your model what goes on with either the cairo or svg drivers. I have just enabled alpha channel/transparency for background for those drivers (see next post). 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
[Plplot-devel] alpha channel/transparency for our background colour
I have just (revision 10188) enabled alpha channel/transparency for our background colour for the cairo and svg device drivers. These drivers thus join the gd device driver in handling this correctly, and I hope later this week, Alban will be able to enable the same functionality for the qt devices (along with his planned changes to enable rgb background colour for the qt devices.) For now you can see what semi-transparent backgrounds look like by locally changing the second line of cmap0_black_on_white.pal from #ff 1.0 to, e.g., #ff 0.3 which gives a red mostly transparent background for the gd, cairo, and svg devices (and an opaque red background for our devices which are not transparency aware). I would also like to specify the transparency of the background conveniently using the -bg command-line option. I was thinking along the lines of -bg ff_0.3 to specify the same semitransparent background that I gave as an example above. The implementation would simply check the length of the option string and if greater than 6, parse the first 6 as hex, check for the underscore, and parse the remainder as a floating point value. Please comment _soon_ if you forsee any trouble with that implementation idea. Of course, our current semitransparent background results look rather dull because linux applications still are not as transparency aware as they should be, and therefore, they currently tend to impose opaque backgrounds of their own upon which the PLplot background is superimposed. To sort out which background is which, you can sometimes specify a background colour for the application. For example, the ImageMagick display application has the -background option to specify an opaque colour for their background, and I was able to use that display option to prove that _our_ background transparency was working correctly for the gd, cairo, and svg devices. (Of course, it would be nice if the display background could be semi-transparent as well so I hope some ImageMagick developer is working on that.) In the future, as Linux and other OS's become completely transparency aware, I can forsee our semi-transparent background capability allowing for some really cool effects such as superimposing our plots on top of other images or just on top of the general desktop behind where one of our plots is displayed. Anyhow, that was the motivation for the latest commit and will also be the motivation for the planned change to the -bg command-line option. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); 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] alpha channel/transparency for our background colour
On 2009-07-29 21:20+0200 Werner Smekal wrote: Hi Alan, I would also like to specify the transparency of the background conveniently using the -bg command-line option. I was thinking along the lines of -bg ff_0.3 to specify the same semitransparent background that I gave as an example above. The implementation would simply check the length of the option string and if greater than 6, parse the first 6 as hex, check for the underscore, and parse the remainder as a floating point value. Please comment _soon_ if you forsee any trouble with that implementation idea. I don't see any trouble, but what about -bg ff for opaque and -bg ff3f for transparent background. This would be much easier to check (must be 6 or 8 chars) and transparency has most of the times 255 values anyway AFAIK (depending on the implementation, e.g. png). But you solution would be also ok. Thanks for your bringing up the possibility of an 8-bit representation for the command-line value of alpha. That would certainly work, but I prefer the command-line values be consistent with the cmap0 related PLplot commands which use 8-bit representations of rgb, and a floating representation of the alpha value. 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] alpha channel/transparency for our background colour
On 2009-07-29 13:24-0700 Alan W. Irwin wrote: Thanks for your bringing up the possibility of an 8-bit representation for the command-line value of alpha. That would certainly work, but I prefer the command-line values be consistent with the cmap0 related PLplot commands which use 8-bit representations of rgb, and a floating representation of the alpha value. Now implemented (revision 10189). So to check device drivers for proper handling of semitransparent background colours, you don't have to edit cmap0 palette files any more. Instead, just use the -bg option with alpha specified, e.g., -bg FF_0.1 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
[Plplot-devel] Help needed with cgm device
I have just discovered that the new C example 16 (yet to be propagated to non-C languages) exposes severe memory management issues with -dev cgm. The various symptoms are segfaults, double frees, and lots of messages from valgrind. All other examples I have checked with this device are absolutely valgrind clean so I suspect it is the new updating of the colour palettes that occurs for every page of example 16 that is exposing the cgm issue. Note the rather similar gd.c (also written originally by Andrew Roach) has no such issues with the new example 16 so the fix to cgm.c is probably straightforward, but I don't have time right now to deal with this so I am hoping someone else will deal with it. Because of this issue I have disabled this device by default (revision 10194) for now. Thus, to see the issue, you will have to specify -DPLD_cgm=ON. 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] Disabling C++ bindings disables Qt drivers
On 2009-08-01 22:37-0700 Alan W. Irwin wrote: Hi Hez: The prior situation was that the C++ compiler was _always_ searched for (regardless of option settings) and if not found an error resulted. Now it is optional depending on how ENABLE_cxx is set (with a soft landing if a C++ compiler is missing/broken). However, I implemented that complete dependence on ENABLE_cxx without much thought. Now you have brought it up, I have decided we could do something a lot better there. I will work on that tomorrow. DONE. See the commit messages for revisions 10200 and 10201 for explanations. Please try it out to make sure it conforms to what you want. 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] Disabling C++ bindings disables Qt drivers
On 2009-08-03 00:13-0400 Hezekiah M. Carty wrote: On Sun, Aug 2, 2009 at 10:29 PM, Alan W. Irwinir...@beluga.phys.uvic.ca wrote: On 2009-08-01 22:37-0700 Alan W. Irwin wrote: Hi Hez: The prior situation was that the C++ compiler was _always_ searched for (regardless of option settings) and if not found an error resulted. Â Now it is optional depending on how ENABLE_cxx is set (with a soft landing if a C++ compiler is missing/broken). However, I implemented that complete dependence on ENABLE_cxx without much thought. Â Now you have brought it up, I have decided we could do something a lot better there. Â I will work on that tomorrow. DONE. See the commit messages for revisions 10200 and 10201 for explanations. Please try it out to make sure it conforms to what you want. Alan, Thank you for working on this. From a clean build directory (revision 10201), using the following cmake command: build$ cmake -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX=/home/hcarty/Applications/plplot -DBUILD_TEST=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_ocaml=ON ../ cmake.out I get a compilation error about a missing moc_files.h. Some time tomorrow I hope that we will be able to build the qt device driver with -DENABLE_qt=OFF, but that doesn't work at the moment as you found out. The workaround for now is either -DENABLE_qt=ON or -DDEFAULT_NO_QT_DEVICES=ON. 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] Disabling C++ bindings disables Qt drivers
On 2009-08-02 21:44-0700 Alan W. Irwin wrote: Some time tomorrow I hope that we will be able to build the qt device driver with -DENABLE_qt=OFF, but that doesn't work at the moment[...] Should work now (revision 10203), but this is just a temporary implementation that I plan to generalize tomorrow (Monday). I just realized a similar fix (create moc_files.h which #includes the moc-generated source) is required for the static drivers case, but instead of going through this in a 3rd location in our build system, I am going to run moc and create moc_files.h in just the include subdirectory of our build system. I then will refer to that result via a target dependency in the 3 places (building libplplotqt, qt.so, or libplplot) where it might be needed depending on cmake 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] alpha channel/transparency for our background colour
On 2009-07-31 11:49+0100 Alban Rochel wrote: [...] - QtWidget and ExtQt plot faster (1), especially when plotting x/y rectangular filled shapes (2). Example x20c is now *much* faster. [...] (1) - The buffer stores pointers to Qt plot primitives rather than the data used to generate them at every plot (e.g QRect* rather than struct holding x, y, width and height). I feared that this would consume more memory, but this is barely noticeable if at all in the end. - Colours are now only stored at colour changes, not associated to every primitive any more (2) - We used to use pens to draw the rectangles outlines, which is wrong as it adds width, and makes drawing much slower - Disabling of antialiasing for these primitives, as this could result in thin gaps between tiles, producing Moire patterns I have recently been doing some interactive testing, and I have to comment on the outstanding speed obtained with the new version of qtwidget. Here are some timing comparisons for example 8, but other examples also show these type of qualitative results. softw...@raven time c/x08c -dev xwin real0m0.769s user0m0.152s sys 0m0.072s softw...@raven time c/x08c -dev qtwidget real0m0.974s user0m0.624s sys 0m0.016s softw...@raven time c/x08c -dev xcairo real0m3.031s user0m1.232s sys 0m0.084s I held down the enter key to autorepeat as rapidly as possible through the various pages of the example in each case so I believe the real times are reliable even though in each case they are substantially larger than the sum of user + sys time (presumably because of different waits for system resources required by the three different methods used here for generating the results). Focussing just on the real times, the qtwidget speed is outstanding considering all the extra font rendering and antialiasing work it does to make nice looking results compared to -dev xwin in roughly the same amount of time. -dev xcairo has similar nice looking results as qtwidget, but it takes roughly three times longer to render the result. That's interesting, but I don't think that is a major xcairo concern since I believe developers should not optimize unless there is an order of magnitude or so to be gained, and that is clearly not the case here. I was curious about the speed of qtwidget in the old days and here is one result I posted to this list in late April. softw...@raven time c/x08c -dev qtwidget real0m5.423s user0m3.432s sys 0m0.132s Obviously, there has been more than 5 times improvement in qtwidget speed since then. Thanks, Alban! 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] Custom axis labeling is now in PLplot trunk
On 2009-08-05 11:25-0400 Hezekiah M. Carty wrote: Commit 10215 fixes the problem [segfault for example 19] on my system, with a slight change to the custom label callback signature. It now takes a string length argument, and the callback is expected to set the label text directly. Example 19 has been updated to reflect this change. Please let me know if this fixes the issue. Example 19 is now valgrind-clean on my system (64bit Ubuntu 9.04). Hi Hez: Yep, all is well now on my platform; example 19 no longer has a segfault and it is valgrind clean as well. Thanks for your quick response to the problem I found. Once you have some more time for PLplot would you be willing to add some additional documentation of plslabelfunc? At minimum, the meaning of the callback function label_func arguments should be documented. You already document the char* argument, but what about the PLINT, PLFLT arguments before it, and the PLINT, void * arguments after it? Probably, the best way to do such callback documentation is to move your documentation of the char* argument to some full documentation of at least one particular example of the label_func callback similar to how the plshades documentation refers to the full pltr0, pltr1, and pltr2 documentation for details about its pltr callback function, see http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.4/plshades.html. plshades documentation also refers to a chapter of general documentation concerning use of plshade(s), but it is up to you whether such a chapter would be useful in the plslabelfunc case or not. If you decide to go ahead with such a chapter (which could be as small as a few paragraphs) but cannot figure out how to stick it into the right place in the overall documentation, let me have the xml for the chapter, and I can do the rest of it. My wife defended her PhD dissertation yesterday and we are moving in the next few days. I apologize for my relatively slow responses recently. Once we are moved and somewhat settled in (~1 week from now, hopefully) I should be able to keep up with PLplot more effectively! No problem. PLplot developers are volunteers who often drop out for periods of time as other things take higher priority. You cannot go wrong if you do as much as you can with PLplot in your spare time (when that is available) on PLplot projects which are fun for you or which satisfy some basic plotting need that you feel is important. Of course, when you do make a change it is good to have a little spare time in hand for quick response (like you did above) in case there turns out to be some problem with your 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
[Plplot-devel] Latest comparison results show there is some work to do
The latest comparisons between results for various languages and our C results are not as clean as they have been in the recent past. Here is the summary (as given by both ctest in the build tree and make test_noninteractive in the installed examples tree). c++ Missing examples: Differing postscript output : 03 19 Missing stdout : Differing stdout: f77 Missing examples: Differing postscript output : 03 19 Missing stdout : Differing stdout: f95 Missing examples: Differing postscript output : 03 19 Missing stdout : Differing stdout: java Missing examples: Differing postscript output : 03 16 19 Missing stdout : Differing stdout: octave Missing examples: 19 Differing postscript output : 03 16 Missing stdout : Differing stdout: python Missing examples: Differing postscript output : 03 16 19 29 Missing stdout : Differing stdout: tcl Missing examples: Differing postscript output : 03 16 19 21 Missing stdout : Differing stdout: 21 perl Missing examples: Differing postscript output : 03 16 19 Missing stdout : Differing stdout: 14 ada Missing examples: Differing postscript output : 03 16 17 19 Missing stdout : Differing stdout: adathick Missing examples: Differing postscript output : 03 16 17 19 Missing stdout : Differing stdout: ocaml Missing examples: Differing postscript output : 16 19 Missing stdout : Differing stdout: lua Missing examples: Differing postscript output : 03 16 19 Missing stdout : Differing stdout: d Missing examples: 14 14a 20 21 22 28 31 Differing postscript output : 02 03 12 13 16 17 19 Missing stdout : Differing stdout: 01 The principal issues are recent important changes to our API and C examples 3, 16, and 19 have not been propagated much (if at all) to our other languages yet. Please do what you can for languages of interest to you to help clean this up for our forthcoming release. Hazen has started on the example 16 issues, but help from others will be required for some languages (probably at least Ada and OCaml) for example 16, and there is a lot of work to be done on examples 3 and 19 for all languages and also many of the examples for D. 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
[Plplot-devel] Python rendering tests
test_circle.py has been around for a while, but today (revision 10234) I added two other python scripts to test rendering for our devices. See examples/README.rendering_tests for details. Note especially that it is fairly pointless to propagate these tests to other languages since fairly rapid changes and additions to these tests are expected. One of the recent additions is called test_superscript_subscript.py which tests nested superscripts and subscripts as well as simple superscripts and subscripts for both Greek and Roman letters. You run this script by changing directory to the build-tree or install-tree version of examples/python, then executing, e.g., ./test_superscript_subscript.py -dev xwin -cmap0 cmap0_black_on_white.pal -dev xwin and -dev svg (when the result is rendered with the the ImageMagick display application) passes this test with flying colours. Also, -dev wxwidgets (wxGC) gets the vertical positioning right (although as with many other examples, there are horizontal spacing issues with wxwidgets for this example). The pdf, qt, and cairo devices do not give correct results for this example. I will take responsibility for dealing with this issue for the pdf and qt devices, and I have asked Hazen off-list whether he would be willing to take responsibility for this issue with the cairo devices. Probably other devices will also have problems giving properly rendered results for this test script so please check your favorite devices and fix any vertical positioning issues or font-size issues that you find this way. 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] Latest comparison results show there is some work to do
On 2009-08-12 21:16+0200 Werner Smekal wrote: i'm going to do the lua [...]changes. Hi Werner: Just for your information, the plslabelfunc API that has recently been implemented in bindings/swig-support/plplotcapi.i for Python and Java was not working correctly for Lua, and there was a resulting build problem for the Lua bindings. (To make the Lua build work for this function, I assume you have to implement support for label callbacks in bindings/lua/plplotluac.i.) Until you deal with this Lua build issue for plslabelfunc, I have temporarily (as of revision 10246) disabled that function for Lua in bindings/swig-support/plplotcapi.i. Don't forget to revert my change when you are ready to deal with the new plslabelfunc function for Lua and the corresponding example 19 changes. 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] QT flags in all compile/links calls
On 2009-08-13 09:06+0200 Werner Smekal wrote: Hi, I'm just trying to make a D compiler run on Mac OS X with cmake and plplot and encountered some problems. One of them is, that in the call to build the D bindings library, there are several Qt flags and one of them doesn't work with the dmd compiler (the /F flag for frameworks). Using make VERBOSE=1 I found out, that actually all C/C++ files are compiled with these flags, which is definitely far from perfect (although it doesn't harm obviously). Builds of PLplot components that are not related to Qt should not be contaminated with Qt flags. Such extra flags slow down the build and actively interfere with some component builds on some platforms (as you have just found out). I confirm the Qt build flag contamination problem on Linux. (For example, on my build with downloaded QT4 SDK, the -I/home/software/qtsdk-2009.02/qt/include option is used even for C language compiles.) I currently don't understand what could possibly be causing this contamination of build flags, but I will look deeper into it and attempt to fix it. 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] QT flags in all compile/links calls
On 2009-08-13 13:39-0700 Alan W. Irwin wrote:
On 2009-08-13 09:06+0200 Werner Smekal wrote:
Hi,
I'm just trying to make a D compiler run on Mac OS X with cmake and
plplot and encountered some problems. One of them is, that in the call
to build the D bindings library, there are several Qt flags and one of
them doesn't work with the dmd compiler (the /F flag for frameworks).
Using make VERBOSE=1 I found out, that actually all C/C++ files are
compiled with these flags, which is definitely far from perfect
(although it doesn't harm obviously).
Builds of PLplot components that are not related to Qt should not be
contaminated with Qt flags. Such extra flags slow down the build and
actively interfere with some component builds on some platforms (as you have
just found out).
I confirm the Qt build flag contamination problem on Linux. (For example,
on my build with downloaded QT4 SDK, the
-I/home/software/qtsdk-2009.02/qt/include option is used even for C language
compiles.) I currently don't understand what could possibly be causing this
contamination of build flags, but I will look deeper into it and attempt to
fix it.
Hi Werner:
The problem is that the Qt4 version of QT_USE_FILE uses the CMake commands,
add_definitions and include_directories to set up the Qt4 build environment.
Those commands contaminate all PLplot component builds with qt flags if the
include(${QT_USE_FILE}) CMake command is executed implicitly for the
top-level directory (via cmake/modules/qt.cmake) since every subdirectory
inherits the results of the add_definitions and include_directories
commands. The solution is to remove the include(${QT_USE_FILE}) command
from cmake/modules/qt.cmake and only use it in those subdirectories where it
is needed (revision 10247). I have tested the result for ENABLE_qt OFF and
ON, and ENABLE_DYNDRIVERS OFF and ON, and it seems to work.
Please let me know if this fix solves the specific problem you found on
Mac OS X.
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
[Plplot-devel] #define PLD_* questions
To Maurice and Andrew: Since the earth was cooling we seemed to have been maintaining a list of configurable #define PLD_* macros in both include/plDevs.h.cmake and config.h.cmake, and I have a question about those configurable macros. Could one of you (or anybody else here) remind me why we maintain two duplicate lists? Ideally, I would like to get rid of all the #cmakedefine PLD_* configurables in config.h.cmake, and use #include plDevs.h where needed (e.g., in the small fraction of files in drivers/* that do not include plDevs.h now.) Comments on that possible change would be appreciated. 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
[Plplot-devel] Some improvements to and evaluation of the pdf device driver
Hi Werner:
I recently did a build of -DDEFAULT_ALL_DEVICES=ON and ran into some minor
build troubles with your pdf device driver (based on the haru library) which I
have now fixed (as of revision 10259). The worst of these was I was running
into header troubles and a showstopper build problem on Linux (using a newly
downloaded and built libharu-2.1.0). The culprit was the -DHPDF_SHARED
compile option for non windows builds. When that was removed, all was well.
You also may have to fiddle with -DHPDF_* options in cmake/modules/pdf.cmake
to get this device to build properly on Windows and Mac OS X with
libharu-2.1.0.
Once I had pdf.so built properly, I evaluated it in the build tree of the
installed examples using
SRC_EXAMPLES_DIR=${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_CURRENT_SOURCE_DIR}/plplot-test.sh --verbose --front-end=c --device=pdf
where
CMAKE_CURRENT_SOURCE_DIR=/home/software/plplot_cvs/installcmake/share/plplot5.9.4/examples
for my particular case.
Running all 31 C examples for the pdf device that way showed no obvious
problems other than a segfault for C example 24.
Here is the full message from a standalone example 24 run with the pdf device:
softw...@raven c/x24c -dev pdf -o test.pdf
ERROR: error_no=1050, detail_no=0
Segmentation fault
I don't have time/libharu expertise to look into this segfault any further,
but I assume libhpdf (from the libharu-2.1.0 package) is returning that
ERROR message, and the segfault occurs because that error is not handled
properly by the pdf device.
The pdf results from the above test looked fine using gv except for examples
10, 15, 17, 24, and 30. I think the issues with examples 10 (box and text
position), 15 (pattern fill spacing), and 17 (legend position) are all
related; my guess is these issues are due to the driver failing to properly
initialize all required PLplot coordinate system parameters. I have already
discussed the example 24 segfault above. Example 30 shows this driver does
not yet support transparent colours.
The special rendering test, examples/python/test_superscript_subscript.py
gives excellent looking results for the pdf device without any changes on my
part (the off-list report I got from a user about such problems for the pdf
device probably was referring to either the pdfqt or pdfcairo device.)
To summarize, it is probably still worthwhile to work on this driver since
the single libharu dependency is much simpler than the many different
pango/cairo or Qt4 libraries that our pdfcairo and pdfqt devices depend on.
I now have the pdf.so build problems straightened out on Linux (at least for
libharu-2.1.0) and most standard examples look good on that platform.
Finally, when you do have some spare time to continue work on this driver, I
hope these notes on the remaining small number of issues that I found will
be useful.
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
[Plplot-devel] Test results for most of our devices
I recently used a combination of -DDEFAULT_ALL_DEVICES=ON and running make test_noninteractive and make test_interactive in the installed examples tree to test all non-interactive devices and most interactive devices that are accessible on Linux. Now that some bad devices have been retired, the remaining devices are in good shape with just a few exceptions. I will take this opportunity to list all issues I noticed today here even though some of them have been posted to this list before. Interactive issues: * qtwidget treats interactive 17 in a non-interactive way (i.e., just gives a snapshot of the final result). After I looked at this in detail, I was convinced this issue is due to qtwidget not implementing PLESC_FLUSH (used extensively by the strip chart api used by example 17) like our other interactive devices do. Alban has agreed to implement PLESC_FLUSH for qtwidget. Once that is completed, I am virtually positive this issue will go away. * wxwidgets (wxGC) has a number of obvious text position issues, but otherwise it is a pretty nice driver with good-looking results. My understanding is wxGC is the wave of the future here so Werner might want to consider concentrating his wxwidgets development time on only the wxGC component to get it into good shape and simplifying his life considerably by dropping the remaining components (basic and AGG ) of wxwidgets completely. * gcw runs without memory management issues, at least, but it does have a number of rendering issues. Personally, I think this deprecated driver and the associated gnome2 and pygcw bindings are headed for retirement within a year or so since cairo and qt beat it hollow in all respects. Non-interactive issues: * I have mentioned before that cgm shows severe memory management issues for example 16 but is completely valgrind clean for all other examples. * I have mentioned in a previous post some pdf device driver issues that Werner will be taking a look at. * A previously unknown issue (at least to me) that showed up as a result of this recent testing was example 2 segfaulted for -dev wxpng. I actually don't know the development status of wxpng, but I suspect it is largely experimental now which would explain this result. 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
[Plplot-devel] cmake re-run issue
Hi Werner: I changed the subject line to something more appropriate since this thread may continue for a while. On 2009-08-14 08:55+0200 Werner Smekal wrote: Hi Alan, In addition after I configure PLplot with cmake and run make, cmake is run again due Re-run cmake: build system dependency is missing (see make.out). It might have something to do with a misconfigured bindings, since when I turn all bindings off, this doesn't happen. I think the re-run should also not happen. I try to find out, which bindings causes this. I found out what causes the rerun. I have to disable f77 and f95 bindings at the command line, then a make call doesn't lead to an rerun of cmake. I attached both outputs of cmake. The command line was cmake -DBUILD_TEST=ON ../plplot cmake.out cmake.out cmake -DBUILD_TEST=ON -DENABLE_f77=OFF -DENABLE_f95=OFF ../plplot cmake_wo_fortran.out The difference between these files is -- The Fortran compiler identification is unknown -- Configuring done -- Generating done -- Build files have been written to: /Users/smekal/Development/plbuild/language_tests/Fortran -- The Fortran compiler identification is unknown -- WARNING: no working Fortran compiler so disabling Fortran bindings and examples. -- CMAKE_GENERATOR = Unix Makefiles Is this behavior reproducible on Linux (where no working Fortran compiler is available)? Let me know if you need further information. Valery Pipin has also reported the cmake re-run issue (on AltLinux, I believe). I had a detailed look this morning with cmake-2.6.4, and I could not reproduce the issue at all by simply disabling gfortran. However, by attempting to get as close as possible to what you did, I finally found a case where cmake reran on the first make attempt (but not subsequent ones for some reason). At this point I have no idea which of my seemingly innocuous steps to reproduce (for example, using make rather than my usual make -j4 install, dropping the FC environment variable, and disabling gnatmake as well as gfortran) was the essential one that triggered the cmake re-run. I haven't tried it myself yet, but another thing that surprises me is your setting of ENABLE_f77 and ENABLE_f95 to OFF made a difference for you. After all, your cmake.out and mine confirm that the first cmake run does this automatically by itself when it cannot find a fortran compiler. So I suspect you got a different result because of some slight other difference in how you invoked your test. There are still a lot of questions here, and the most innocuous details seem to matter so I think the best thing to do is to try to find the simplest case where I can reliably generate a cmake rerun, then start debugging with liberal use of the message command. Normally, I understand why cmake would be re-run when a compiler was missing since it does everything in its power to find compilers assuming that the user will immediately install one when he encounters the first missing compiler message. But our build system ignores all that (except for C and C++ which are special cases) and bypasses the compiler search altogether for subsequent runs (e.g., by setting both ENABLE_f77 and ENABLE_f95 to OFF) if the first attempt to find a compiler fails. Anyhow, I will keep investigating since there is no way that a cmake re-run should be triggered by a missing compiler when we supress all subsequent searches for that compiler. Also, I encourage you to continue your own independent investigation (being careful about any slight variations in the way you do your tests) since you might well find a solution to the problem before I do. 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] cmake re-run issue
On 2009-08-16 10:33-0700 Alan W. Irwin wrote: Valery Pipin has also reported the cmake re-run issue (on AltLinux, I believe). I had a detailed look this morning with cmake-2.6.4, and I could not reproduce the issue at all by simply disabling gfortran. However, by attempting to get as close as possible to what you did, I finally found a case where cmake reran on the first make attempt (but not subsequent ones for some reason). At this point I have no idea which of my seemingly innocuous steps to reproduce (for example, using make rather than my usual make -j4 install, dropping the FC environment variable, and disabling gnatmake as well as gfortran) was the essential one that triggered the cmake re-run. It turns out I can reproduce the cmake re-run problem with gnatmake enabled and make -j4, but if I then go back to using export FC='gfortran' (where you should end up with exactly the same compiler and flags for that compiler) the cmake re-run problem disappears again. So exporting FC or not makes all the difference even for the case when the same compiler and compiler flags are specified. Currently, I am pursuing all differences between the two cmake runs using, e.g., diff -Naur old_build_dir new_build_dir. More later. 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] cmake re-run issue
On 2009-08-16 12:35-0700 Alan W. Irwin wrote: On 2009-08-16 10:33-0700 Alan W. Irwin wrote: Valery Pipin has also reported the cmake re-run issue (on AltLinux, I believe). I had a detailed look this morning with cmake-2.6.4, and I could not reproduce the issue at all by simply disabling gfortran. However, by attempting to get as close as possible to what you did, I finally found a case where cmake reran on the first make attempt (but not subsequent ones for some reason). At this point I have no idea which of my seemingly innocuous steps to reproduce (for example, using make rather than my usual make -j4 install, dropping the FC environment variable, and disabling gnatmake as well as gfortran) was the essential one that triggered the cmake re-run. It turns out I can reproduce the cmake re-run problem with gnatmake enabled and make -j4, but if I then go back to using export FC='gfortran' (where you should end up with exactly the same compiler and flags for that compiler) the cmake re-run problem disappears again. So exporting FC or not makes all the difference even for the case when the same compiler and compiler flags are specified. Currently, I am pursuing all differences between the two cmake runs using, e.g., diff -Naur old_build_dir new_build_dir. As of revision 10270, I have made a change (dropping the OPTIONAL signature for enable_language in the independent CMake session trying to figure out whether a language is viable or not) that eliminates the unnecessary CMake re-run on my platform for reasons which I frankly don't completely understand. The only explanation of what I have observed is that the independent session with the OPTIONAL signature returns a success return code for certain combinations of circumstances (e.g., FC not set) when the the language doesn't actually work. In any case, dropping the OPTIONAL signature appears to make the correspondence between success or failure return code and language working or not more reliable. Could you please give this change a try to see whether it eliminates the CMake re-run issues on your platforms? 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] 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 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] Python rendering tests
On 2009-08-17 23:31-0400 Hazen Babcock wrote: Alan W. Irwin wrote: ./test_superscript_subscript.py -dev xwin -cmap0 cmap0_black_on_white.pal -dev xwin and -dev svg (when the result is rendered with the the ImageMagick display application) passes this test with flying colours. Also, -dev wxwidgets (wxGC) gets the vertical positioning right (although as with many other examples, there are horizontal spacing issues with wxwidgets for this example). The pdf, qt, and cairo devices do not give correct results for this example. I will take responsibility for dealing with this issue for the pdf and qt devices, and I have asked Hazen off-list whether he would be willing to take responsibility for this issue with the cairo devices. This should be fixed for the cairo driver in v10273, though you might want to tune the offsets a little. The only issue that I can see is that the phi subscript looks unusually low in xcairo vs xwin? That's a lot better, but I agree there is an issue with the scale of the Greek letter offsets (both superscript and subscript). Can you confirm the driver is currently using the span rise tag before the font change associated with the Greek letter, but not after? If that is the case, would you be willing to implement repeating the current span rise tag after each font change within the string (but before any character is rendered with the new font)? I think that is necessary since a font change potentially changes the scale of the fonts and therefore the interpretation of the span rise tag. Obviously the driver should continue what it is doing with the current span rise tag since there is no guarantee of a font change right after a superscript or subscript. However, I believe that if a repeat span rise tag is also put in after all font changes within a string, that might well fix the Greek-letter superscript/subscript offset issue. 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] Python rendering tests
On 2009-08-19 10:33-0700 Alan W. Irwin wrote: On 2009-08-17 23:31-0400 Hazen Babcock wrote: Alan W. Irwin wrote: ./test_superscript_subscript.py -dev xwin -cmap0 cmap0_black_on_white.pal -dev xwin and -dev svg (when the result is rendered with the the ImageMagick display application) passes this test with flying colours. Also, -dev wxwidgets (wxGC) gets the vertical positioning right (although as with many other examples, there are horizontal spacing issues with wxwidgets for this example). The pdf, qt, and cairo devices do not give correct results for this example. I will take responsibility for dealing with this issue for the pdf and qt devices, and I have asked Hazen off-list whether he would be willing to take responsibility for this issue with the cairo devices. This should be fixed for the cairo driver in v10273, though you might want to tune the offsets a little. The only issue that I can see is that the phi subscript looks unusually low in xcairo vs xwin? That's a lot better, but I agree there is an issue with the scale of the Greek letter offsets (both superscript and subscript). Can you confirm the driver is currently using the span rise tag before the font change associated with the Greek letter, but not after? If that is the case, would you be willing to implement repeating the current span rise tag after each font change within the string (but before any character is rendered with the new font)? I think that is necessary since a font change potentially changes the scale of the fonts and therefore the interpretation of the span rise tag. Obviously the driver should continue what it is doing with the current span rise tag since there is no guarantee of a font change right after a superscript or subscript. However, I believe that if a repeat span rise tag is also put in after all font changes within a string, that might well fix the Greek-letter superscript/subscript offset issue. I did some more testing of superscript/subscript rendering of mixed Greek and Latin letters for -dev xcairo, and it appears my above hypothesis is not correct. If I use Greek letters first (at superscript/subscript level 0) there is still the same issue; the superscript/subscript Greek letter is still off by one in its offset. I then expanded the test for a combination of Greek and Latin letters at superscript/subscript level 1 (see revision 10312), and I found a peculiar result; as soon as there is a shift to Greek letters (or probably any change in font) at the superscript or subscript level, the level interpretation changes by 1 and is uniform from then on regardless of whether Latin or Greek letters are used. There is no difficulty with this latest version of the example either for -dev svg (when viewed by display) or -dev xwin so I suspect there must still be some off-by-one logic error in superscript/subscript level in cairo.c that is causing the issues you can see for this example for -dev xcairo. I suggest the best way to debug this is to look carefully at the complete generated pangoMarkupString just before it is sent to the pango/cairo libraries. If that seems fine (i.e., you can explain every command and there are no changes in rise just before Greek letters occur in the superscript/subscript), then this must be a bug in how rise is interpreted by the pango/cairo libraries. But I hope you do see something wrong with pangoMarkupString since that is much easier to fix than some more fundamental issue with pango/cairo. 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] Qt driver update
Hi Alban: The first part of this addressed to you, but there are some comments about the animated octave examples that are addressed to Andrew at the end. On 2009-08-20 11:50+0100 Rochel, Alban wrote: Hello all, Here is a patch for the Qt driver. It fixes a couple of minor bugs, and it also adds the possibility to pass PLplot command line arguments to the qtext driver (embedded widget in a Qt application) and handles flush and clear for the interactive devices. Thanks for this, and thanks to Andrew for committing it. However, there still are issues with these implementations: - Command line arguments for the qtext driver: [...]I believe the only way to fix this other than changing -bg into something else in PLplot is to make a deep copy of argv before passing it to the QApplication constructor and passing this copy to plsetqtdev. Thus, it's up to the application developer to handle such matters. You can see this issue with qt_example: qt_example -bg FF000 will display a Qt warning message and go on with the default bg colour qt_example -cmap0 _whatever_ will work properly It appears from what you have said that there is a way for application developers to get around this issue. If that deep copy method is straightforward, would you be willing to implement that for qt_example since that is probably the first place other developers will look for inspiration for their own qt/PLplot GUI's? - flushing: it works, but example x17c is *slow* (about 30 times slower than xwin on my system!). This is because the Qt driver will replot everything from the last clear() everytime the flush is done. This is linked to the way the driver was designed, and despite my efforts, I haven't found a quick and easy way to fix this. I still plan to fix this, but it will require some redesign. In the meantime, people who wish to use the Qt driver to animate stuff may be happy to use the new lines_antialiasing command-line option which allows to (dis/en)able lines antialiasing (enabled by default), which makes the driver about 5 times slower than xwin. For what it is worth, with the default line antialiasing (same as -drvopt lines_antialiasing=1) it is almost exactly 10 times slower here. With -drvopt lines_antialiasing=0 it is roughly two times slower here than -dev xwin. This general trend makes sense since there is a built-in time delay with example 17 which will make the cpu time consumed by the driver less and less important as the cpu power of the hardware increases. Nevertheless a factor of 10 or more is still most annoying for antialiased animation so I had a look at the Qt documentation of repaint at http://doc.trolltech.com/4.4/qwidget.html#repaint. (For the others here, this function is called to deal with plflushes for qtwidget). It appears there are overloaded forms of repaint that allow you to repaint rectangular subregions of the widget. So if plflush is modified to pass a rectangular subregion to the device driver (which all devices would ignore except for qtwidget) then you might get a major increase in speed for the normal case where you are just adding one more x,y value to be plotted for the animation. IOW a small change to the PLplot core here (and I think it would be possible to do that without changing the plflush API) might be better than a complete qt driver redesign. :-) The rest of this is addressed to Andrew as octave maintainer. There a quite a few animated examples associated with octave (i.e., many of the high-level p examples as opposed to the standard low-level x examples). Joao was still actively working on the p examples when he retired as a core PLplot developer, and as far as I know nobody has touched them since. Right now, our ctest tests ignore p1[0124789] and p20 (presumably because they don't yet work properly for -dev psc). It would be great if you would be willing to get all of those working properly both with -dev psc (to give a snapshot at the end of the animation like x17 does now) and also the interactive devices. As I recall in the old days some of those animated examples were quite spectacular with -dev xwin, and it would be great to see them working now with xcairo and eventually with qtwidget as well (once the animation speed issue for qt is fixed). 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
[Plplot-devel] Ada examples now all give just a red rectangle with no plot
I presume this has something to do with the recent core cmap[01] changes. Hopefully, the fix can be found in a hurry because I think otherwise this would be a showstopper for the release 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] Python rendering tests
On 2009-08-20 09:32-0700 Alan W. Irwin wrote: There is no difficulty with this latest version of the example either for -dev svg (when viewed by display) or -dev xwin so I suspect there must still be some off-by-one logic error in superscript/subscript level in cairo.c that is causing the issues you can see for this example for -dev xcairo. Hi Hazen: Here is some extra relevant information I discovered this morning. examples/python/test_superscript_subscript.py -dev qtwidget works perfectly! Although I don't recognize anything relevant in Alban's patch that Andrew committed, it appears that some change he did solved all the superscript/subscript issues that appeared before. The same example works OK for -dev psc and -dev psttfc and works (with regard to font size issues and vertical offsets, but not horizontal offsets which generally have issues for this device in any case) for -dev wxwidgets (wxGC). Thus, the only cases I am aware of where this example doesn't have correct font scaling or vertical offsets are pdf (font scaling) and cairo (vertical offsets). 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] Ada examples now all give just a red rectangle with no plot
On 2009-08-22 17:25-0700 Jerry wrote: On Aug 22, 2009, at 2:05 PM, Alan W. Irwin wrote: Once plscmap0n(0) gives default colours like before, I suspect all the Ada red issues will go away. Jerry has remarked before that our Ada bindings do their own colour initialization, and my guess is that boils down in the cmap0 case to a call to plscmap0n(0). I didn't absorb all of what Alan wrote on my first and second quick readings, but here is what happens in the Ada initialization. The Ada binding, when initializing package plplot.adb or plplot_traditional.adb, makes several calls to plgcol0 as part of the color map 0 snapshot function--an initial snapshot is taken so that the user can later restore the initial colors if desired. No other calls are made. These calls to plgcol0 take place before plinit (which is normally called from the user program, after Ada package initialization). Hi Jerry: Thanks for that explanation which confirms my guess above. If you look at the plgcol0 implementation in plctrl.c, it's first two statements are if (plsc-cmap0 == NULL) plscmap0n(0); Therefore, the Ada bindings assume (indirectly via plgcol0) that plscmap0n initializes defaults for colour values before plinit is called. Presumably, some existing user code makes the same assumption since plscmap0n has long had this capability. Recent changes to svn trunk inadvertently dropped that capability, but Hez's patch restores it which explains why I found that patch fixes the Ada colour initialization problems. I felt there were other issues with that patch, but as soon as Hez and I get together on that (hopefully today if Hez is in e-mail contact this weekend), all should be well again on svn trunk for Ada (and user) colour initialization that occurs prior to plinit. 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] 5.9.5 release schedule.
On 2009-08-23 20:47-0400 Hazen Babcock wrote: We have 2-3 weeks until our tentative early September release date. I believe that everything that we wanted in 5.9.5 is in? Is there anything outstanding besides the tweaks to the color palette handling? Here are some comments on the present development issues I am aware of: * The release showstopper color palette initialization issue has now been fixed (see my last post to the list). * You have just fixed the superscript/subscript issue for the cairo devices, and I don't think any other devices have such issues other than the font size issue for the pdf device. I believe the pdf device is still considered to be experimental so it would be nice to get that issue fixed before the release, but it is not essential. * Werner has stated he will be working on device drivers (presumably pdf and wxwidgets) but I don't know how much time he has for that at the moment or how far he has gotten. * Hez mentioned the off-screen rendering patch in response to your post but didn't give an estimate of how long that would take. If that turns out to be long, I don't think we should delay the release for it. * Alban plans to make animated rendering faster for -dev qtwidget and do a final fix of the command-line options for qt_example the next opportunity he has to work on qt. But that next opportunity is apparently several weeks from now which is clearly too late for this release. Thus, his planned qt work will presumably be in the release after this present release. * This week I do have some plans to extend my install tree testing to the build tree, but that is just a matter of convenience and I presume that will not introduce or find any release showstopper issues. * I also plan to document the new build system for the installed examples, but such work should not introduce any release showstopper issues. * I have decided to put off the libqsastime enhancements I have discussed before until after this present release since those enhancements are pretty tricky (both in understanding the various time transformations that are implied and actually doing the C coding that will be required to implement them). Thus, the effort may take several weeks, and I certainly don't want to do it in a rush to meet a release deadline since that is a perfect recipe for introducing bugs. We certainly have more than enough improvements in svn trunk to justify a development release now without waiting for further development to be completed. Tomorrow I plan to do comprehensive tests of all three build modes (shared libraries + dynamic devices, shared libraries + static devices, and static libraries and devices) for the Debian stable platform accessible to me, and I suggest others do that as well on all platforms that are accessible to them. If those tests show no showstopper issues, then I am tentatively thinking that we could do the release next weekend (i.e., either Saturday, September 1st or Sunday September 2nd). Hazen, in case a release next weekend will not disrupt anyone's development plans, would it be convenient for you to release on one of those days? Of course, if it is not convenient for you or somebody prefers two weekends from now, that would be okay with me as well. However, I prefer we not let the timing slide to three weekends from now since I like to stick as closely as possible to release deadlines once they have been stated, and September 15th/16th barely qualifies (if at all) as early September. 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] 5.9.5 release schedule.
On 2009-08-23 22:23-0700 Alan W. Irwin wrote: Tomorrow I plan to do comprehensive tests of all three build modes (shared libraries + dynamic devices, shared libraries + static devices, and static libraries and devices) for the Debian stable platform accessible to me, and I suggest others do that as well on all platforms that are accessible to them. If those tests show no showstopper issues, then I am tentatively thinking that we could do the release next weekend (i.e., either Saturday, September 1st or Sunday September 2nd). I have completed one of these build mode tests so far (shared libraries + dynamic devices), and I had to comment on the vastly improved postscript differences that test revealed. Here are the full results: c++ Missing examples: Differing postscript output : Missing stdout : Differing stdout: f77 Missing examples: Differing postscript output : Missing stdout : Differing stdout: f95 Missing examples: Differing postscript output : Missing stdout : Differing stdout: java Missing examples: Differing postscript output : Missing stdout : Differing stdout: octave Missing examples: 19 Differing postscript output : Missing stdout : Differing stdout: python Missing examples: Differing postscript output : Missing stdout : Differing stdout: tcl Missing examples: Differing postscript output : 16 19 21 29 Missing stdout : Differing stdout: 21 perl Missing examples: Differing postscript output : 03 16 19 29 Missing stdout : Differing stdout: 14 ada Missing examples: Differing postscript output : 17 19 29 Missing stdout : Differing stdout: adathick Missing examples: Differing postscript output : 17 19 29 Missing stdout : Differing stdout: ocaml Missing examples: Differing postscript output : Missing stdout : Differing stdout: lua Missing examples: Differing postscript output : Missing stdout : Differing stdout: d Missing examples: Differing postscript output : Missing stdout : Differing stdout: Many languages are perfect now, and I thank everyone who helped to make that happen. I don't think we should delay the release for the remaining issues shown above, but it would be nice if most of them got addressed before the release. * I understand the long-standing missing example 19 issue for octave is a difficult one to solve so realisticaly fixing that issue will probably have to be put off until post release. * Arjen and Andrew are still working on precision issue for tcl. Once those are corrected and bindings and examples upgraded to be consistent with the updated C API tested by the updated C examples, the remaining tcl issues should go away or at least greatly simplify. * The perl issues require Doug Hunt to update his external PDL/PLplot bindings, and also update the examples to be consistent with the C API and example updates. * The red issue that generated quite a bit of e-mail over the weekend is completely gone for Ada, but there is still some more work for Jerry to do on the Ada bindings and examples to achieve consistency with the recent additions to the C API and the tests of that API that occur in the updated C examples 17, 19, and 29. 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] 5.9.5 release schedule.
On 2009-08-24 21:02+0200 Werner Smekal wrote: I added this to the wiki (http://www.miscdebris.net/plplot_wiki/index.php?title=Apply_a_patch) if this is ok for you. Sure. 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
[Plplot-devel] Progress report for new test infrastructure
I am currently working on a new test infrastructure for the core build which will leave the current ctest infrastructure alone, but which instead adds equivalent targets that can be run with make (or nmake). The point of this new test infrastructure is to have proper dependencies (unlike ctest) and also to be able to run tests in parallel (again unlike ctest) which is an advantage on a single-cpu machine (since these tests necessarily involve lots of i/o, one task can grab the cpu while others are waiting for their i/o to complete) and a huge advantage on multiple-cpu machines. I have been making quick progress this week because most of the test elements were already in place for the common CMake code that is also used for the install-tree tests. All the changes I am making to that common code are to distinguish locations in the build-tree and installed examples tree (which are set depending on the CORE_BUILD variable), and to make the dependencies more complete (which also simultaneously improves the existing installed examples tests). Here is what I can do now. With _nothing_ built in the build-tree, and if cmake has been configured with BUILD_TEST=ON, I can run make test_language_psc where language is ada, c, cxx, d, f77, or f95. The above command generates just the minimum parts of the build (bindings and examples builds) required to do the test (which just runs plplot-test.sh for the language front-end and the psc device). I also have implemented a target test_compare_sh which simply runs test_diff.sh with no dependencies. So the command make -j4 test_c_psc test_f77_psc test_f95_psc test_compare_psc will generate our standard PostScript and stdout difference report just for f77 and f95 versus c, just like the commands make -j4 all ctest -R '(examples_c$|examples_f77|examples_f95|examples_compare)' do now. However, for the reasons noted before the new core-build test method is _much_ faster on my 2-cpu machine than the ctest method for doing testing. You probably noted that I have only referred to a subset of our languages above. That is because there are still some dependency issues to work out for java, lua, octave, etc. I won't commit the new test infrastructure until it is matured a bit more, but that is happening rapidly so there is a good chance I will be able to commit this by tomorrow or Thursday in time for you to have a good chance to play with it before the release (this weekend?) 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] 5.9.5 release schedule.
On 2009-08-25 11:57-0400 Hazen Babcock wrote: Alan W. Irwin wrote: Tomorrow I plan to do comprehensive tests of all three build modes (shared libraries + dynamic devices, shared libraries + static devices, and static libraries and devices) for the Debian stable platform accessible to me, and I suggest others do that as well on all platforms that are accessible to them. If those tests show no showstopper issues, then I am tentatively thinking that we could do the release next weekend (i.e., either Saturday, September 1st or Sunday September 2nd). Um, you lost me here. On my calendar the 1st is a Tuesday and the 2nd is a Wednesday. Did you mean 8/29-30? or 9/4-5? Either is fine with me. Oops, you are right. (I was looking at the August calendar by mistake rather than the September calendar.) Let's release September 4th-5th (which gives us an extra week I didn't think we had). 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] 5.9.5 release schedule.
On 2009-08-25 09:19-0700 Alan W. Irwin wrote: On 2009-08-25 11:57-0400 Hazen Babcock wrote: Um, you lost me here. On my calendar the 1st is a Tuesday and the 2nd is a Wednesday. Did you mean 8/29-30? or 9/4-5? Either is fine with me. Oops, you are right. (I was looking at the August calendar by mistake rather than the September calendar.) Let's release September 4th-5th (which gives us an extra week I didn't think we had). Um, we are all now misquoting the calendar. Those weekend dates are actually September 5th and 6th which is what I propose for our release date(s). 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] 5.9.5 release schedule.
On 2009-08-25 19:09+0100 Andrew Ross wrote: While we're on the subject of patches, the svn patch command generates headers like Index: examples/c/x29c.c === --- examples/c/x29c.c (revision 10316) +++ examples/c/x29c.c (working copy) for each file. This is not in the standard patch format (as described above by Alan). Does anyone have any neat way of applying these patches without having to hand edit the patch first? This would be useful when people send patches from their working copy that I would like to test on my working copy before applying to svn. I can't seem to find an easy way to do this with my version of patch, but I can't believe there isn't a solution. How about using -p0 when patching from the top-level source tree? I haven't bothered now to try the above form by hand, but I know I have patched with that svn form of patch (at least the one you get with svn diff) before with no problems. 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] [PATCH] Compiler warning fixes
On 2009-08-26 11:12+0200 Mark de Wever wrote: Hi, The attached patches fix some compiler warnings: plargs-patch Make sure the functions return a value. cairo-patch Properly place parentheses, avoiding code having no effect. Thanks, Mark. I committed your plargs-patch and Hazen committed your cairo-patch. Good spotting on that last one! I double-checked the many other strncat calls within cairo.c, and it appears you found all the bad ones. I also noticed with gcc -Wall there are a lot of unused variables in plplot, if wanted I could provide a patch which removes those variables. Yes, please. 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] Qt driver update
On 2009-08-26 10:01+0100 Rochel, Alban wrote: You will find attached a patch for the Qt driver. It applies and builds without errors and the speedup in -dev qtwidget for animations like example 17 is extraordinary. I also get a x17c -dev qtwidget time that is comparable with the -dev xwin one. If I try ./qt_example -bg ff I do get the specified white background to the GUI. However, I also get the error message QColor::setNamedColor: Unknown color name 'ff' Can that error message be suppressed or are we stuck with it? That's the last qt issue (and an extremely minor one at that) that I am aware of on Linux. Thanks very much for all your efforts to make the qt devices some of the best that we have on Linux, and I am sure that with some additional work (especially with lots of test reports from our developers to help you narrow down the issues) the same will be true on Mac OS X and Windows. I have committed your patch as revision 10346. I am really happy to see this go in before our release. 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] RE : Qt driver update
On 2009-08-26 17:11+0100 Rochel, Alban wrote: The error message (or rather warning) is due to the QApplication trying to process the -bg argument, which is among the accepted arguments for a QApplication (try qt_example -bg red for instance). There is obviously a conflict, but nothing that would stop the software to work, so it is a choice for the developer to filter out or not the -bg arguments or make them available to either QApplication or the widget. Maybe we should add a comment there? I have fixed this issue in revision 10347. I set argc (but not Argc) to 1 so that QApplication sees only an empty command line (other than the command, itself). I prefer the simplicity of this approach for our qt_example, and I assume most Qt/PLplot GUI application developers will stick with that model where the command-line options are completely ignored by Qt and only interpreted by PLplot. However, I put additional commentary in so that if application developers want to allow both Qt options and PLplot options (say by splitting the two kinds of options by a special -- option like startx does for its two kinds of options), and putting one kind into argc for QApplication and the other kind into Argc for PLplot, it should be straightforward for them to do so. We are now down to zero qt issues on Linux that I am aware of. :-) 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] plssubmem patch
On 2009-08-26 13:28-0230 David Gillard wrote: I've submitted a patch to the source code via the patches tracker, under the name 'plssubmem function'. The patch incorporates is for the addition of a plssubmem function similar to plsmem except that it takes parameters specifying a subregion of the memory region to plot to. Clipping is handled in the case where the subregion falls outside the allocated memory. The major modification is to the mem driver. Other pl functions are not impacted. Thanks, David, for your potential contribution to PLplot. Doug, I think you should ultimately be the one to review this patch (at http://sourceforge.net/tracker/?func=detailaid=2844452group_id=2915atid=302915) because of your interest in the mem driver. I am somewhat concerned about adding another function to the core API because of the costs of propagating that function to other languages, documenting it, and extending a standard example (in all our languages) to use it. Could this be implemented as a driver option instead that is set either on the command-line or with plsetopt? In any case, I think we should hold off committing anything related to this patch until after our forthcoming release which is imminent. 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] Segmentation fault with qt driver
On 2009-08-26 13:48-0500 Hezekiah M. Carty wrote: While testing the qtwidget and other PLplot qt output devices I ran in to two issues. This is on Ubuntu 9.04 64bit, with the system Qt version (4.5.0). The first issue is similar in feel to an long-lived, ongoing Cairo problem - calling plinit and selecting a qt device after a call to plend causes a segmentation fault. Simply calling plinit(); plend(); plinit(); (selecting a qt device each time) is enough to trigger the bug here. I don't know if this happens for every qt device, but it happens consistently for me with the qtwidget device. Similar to the Cairo bug, calling plend1 rather than plend avoids this bug. Unlike the Cairo bug, no text rendering is required to trigger the qt segmentation fault. The second issue relates to using plend1. For example: plsdev qtwidget; plinit (); plenv 0. 1. 0. 1. 1 0; plend1 (); plsdev qtwidget; plinit (); plenv 0. 1. 0. 1. 1 0; plend1 (); The first call to plend1 will not display a plot, just the plot window with (on my system) a grey hatched background. The second plend1 call will show the plot. I don't use the qt driver except for occasional testing, so I'm not sure if these are PLplot bugs or bugs in some other library (for example, Qt 4.5.0 vs a later release). When persistent memory management problems (segfaults, etc.) are identified like this, I think it is important to add a simple C test routine to demonstrate the problem so we have an exact test case to talk about since _the symptoms_ of fundamental memory management issues can come and go depending very much on minor programming detail variations as well as platform, phase of the moon, etc. IOW, relying on segfaults to tell us about memory management issues is a first step, but valgrind is the only way (at least on Linux) to get definitive results. I have made such a test case in revision 10348 (which demonstrates exactly how to add such a test for our build system). It will build automatically in the build tree for BUILD_TEST=ON and also automatically in the installed examples tree. For this particular test (plend1, then plend), all is well even for valgrind tests of -dev qtwidget and -dev xcairo, but if that first plend1 is replaced by plend there are huge memory management problems revealed by valgrind for both -dev xcairo and -dev qtwidget (but not -dev xwin or -dev psc). This is for Qt version 4.5.1 downloaded from trolltech. I have forgotten the exact differences between plend and plend1, but I know the former calls the latter than does a bit more to completely close the plplot library. I guess that bit more is causing the problems (or else the subsequent plinit after a complete close of plplot is exposing reinitialization bugs for both the cairo and qt devices.) Andrew, I intend to look at this (especially the differences between plend and plend1) a bit more, but you are our expert on memory management issues so I hope you take a look as well. 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] What is qt4_wrap_cpp?
On 2009-08-26 14:50-0600 Orion Poplawski wrote: Trying to build the current svn version, and getting: CMake Error at include/CMakeLists.txt:123 (qt4_wrap_cpp): Unknown CMake command qt4_wrap_cpp. What is supposed to provide the qt4_wrap_cpp macro? That is provided by cmake. I thought it was impossible to get to that part of the CMake code with ANY_QT_DEVICE true, but without the qt4_wrap_cpp macro defined. Obviously there is some corner case where that strange combination is possible. To help track down what corner case is causing this, I need complete details from you (off list). Would you please send me the output of printenv (to get the CMake-related environment variables) and also let me know the exact cmake options that you specified, the cmake version, and the complete cmake output? TIA. 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] What is qt4_wrap_cpp?
On 2009-08-26 14:50-0600 Orion Poplawski wrote: Trying to build the current svn version, and getting: CMake Error at include/CMakeLists.txt:123 (qt4_wrap_cpp): Unknown CMake command qt4_wrap_cpp. Thanks for the extra information you provided off list. It turned out there was a bug in our build system for the case where the Qt4 development environment was not found. I have now fixed that (revision 10349). Could you please try the exact same build again to make sure everything works now for the no Qt4 case? Once you confirm that works, you will probably want to build your Fedora rpms in an environment where Qt4.5.x has been installed so Fedora users get access to all the qt device goodies. 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] Segmentation fault with qt driver
Hi Hez: This is mostly for you but there are some reassuring remarks for Alban here as well. On 2009-08-26 15:13-0700 Alan W. Irwin wrote: When persistent memory management problems (segfaults, etc.) are identified like this, I think it is important to add a simple C test routine to demonstrate the problem so we have an exact test case to talk about since _the symptoms_ of fundamental memory management issues can come and go depending very much on minor programming detail variations as well as platform, phase of the moon, etc. IOW, relying on segfaults to tell us about memory management issues is a first step, but valgrind is the only way (at least on Linux) to get definitive results. I have made such a test case in revision 10348 (which demonstrates exactly how to add such a test for our build system). It will build automatically in the build tree for BUILD_TEST=ON and also automatically in the installed examples tree. For this particular test (plend1, then plend), all is well even for valgrind tests of -dev qtwidget and -dev xcairo, but if that first plend1 is replaced by plend there are huge memory management problems revealed by valgrind for both -dev xcairo and -dev qtwidget (but not -dev xwin or -dev psc). This is for Qt version 4.5.1 downloaded from trolltech. I have changed plend1 to plend in the test example as of revision 10350. So it now reads in its heart as follows: plinit(); plenv(0., 1., 0., 1., 1, 0); plend(); plinit(); plenv(0., 10., 0., 10., 1, 0); plend(); exit(0); After a cmake configuration with BUILD_TEST=ON, and make, examples/c/test_plend -dev xcairo now produces a segfault as I said above. However, that same application is valgrind clean for -dev qtwidget (and other qt devices I have tested such as svgqt and epsqt)! I scrolled up my xterm to where I did my qt tests before, and I definitely got a segfault before with -dev qtwidget, but this was an original test case which was built by hand, and the cmake build system build seems to have eliminated all memory management problems with qt (but not cairo). So this is an excellent illustration of my point above to use easily reproducible results when dealing with memory management issues. :-) Anyhow, Alban, we are back down to zero known errors for qt (with Qt4.5) on Linux. I suggest everybody (especially Hez who got -dev qtwidget segfaults with his own hand-built plend/qt tests like I did) try examples/c/test_plend for various qt devices for their Qt4 version and OS platform to make sure all is well with that test example for qt in a platform-independent way. I wonder how many minutes the zero known errors remark will last this time for qt. :-) I have forgotten the exact differences between plend and plend1, but I know the former calls the latter than does a bit more to completely close the plplot library. I guess that bit more is causing the problems (or else the subsequent plinit after a complete close of plplot is exposing reinitialization bugs for both the cairo and qt devices.) Hez, I suggest you look at plend for yourself to see the really innocuous things that are going on. It calls plend1 for all streams, then releases all memory associated with Hershey fonts, dynamic drivers, and static drivers. That's basically it. In fact, if you modify test_plend.c to comment out the second plinit, plenv, and plend then the result is valgrind clean for -dev xcairo. So the problem cannot have anything to do specifically with the combined memory management of xcairo and plend alone. plend does set lib_initialized = 0 which means pllib_init (called by plinit) actually does something (restores the memory freed by plend and sets lib_initialized = 1), but again this is pretty innocuous stuff. So I doubt very much the problem lies specifically with pllib_init, and that view is supported by every other device driver having no troubles with revision 10350 of test_plend.c. Thus, I would look carefully at what happens with the cairo devices when you initialize them for a second time after memory associated with dynamic drivers has been freed and reinitialized. Wild guess: do the cairo devices hang on to some memory when they shouldn't so at reinitialization time they are still pointing at the old dynamic driver (dispatch table) memory that no longer exists because it has been freed (and allocated again) in the plend case? That freeing and allocation is the most prominent difference between plend followed by plinit versus plend1 followed by plinit. Hez, I hope this overview of plend, plinit, and pllib_init and the knowledge that no other device driver has problems (at least for the test_plend case), helps you to quickly find the issue in the cairo case. 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
[Plplot-devel] Problematic floating-point comparisions
Valery Pipin reported the following warning to me: *** PLPLOT WARNING *** Unrecognized cmap1 format #ff 100 0 At first glance that is impossible. The line in question is the last line in cmap1_default.pal, and that is just as perfectly formatted as the other lines in that file. However, a closer look at the code in plctrl.c showed a problematic floating-point test for whether pos[i] (calculated from the above 100 value by converting to double and multiplying by 0.01) was in the range from 0. to 1. I have now fixed that test as of revision 10351 to account for small floating-point errors in the calculation of pos[i]. Valery hasn't yet gotten back to me, but when he does I presume he will tell me that fix worked. This whole issue shows how important it is to run PLplot on a large variety of hardware with different floating point errors so that we find problematic floating-point comparisons like what I just spotted and fixed in plctrl.c. Anyhow, if you have access to PowerPC's, sparcstations, Dec Alphas, IBM mainframes or other non-Intel hardware, now would be a good time to do some thorough checking of PLplot on that hardware. 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] [PATCH] Compiler warning fixes
On 2009-08-27 16:05+0200 Mark de Wever wrote: Alan W. Irwin wrote: On 2009-08-26 11:12+0200 Mark de Wever wrote: I also noticed with gcc -Wall there are a lot of unused variables in plplot, if wanted I could provide a patch which removes those variables. Yes, please. Attached a patch which removes all unused variables in my configuration. I commented them out in 'examples/c/x32c.c' since the part that used them is also commented out. Your patch (sent later) to removed unused variable looks reasonable, applies cleanly, and generates no build errors for a full build of PLplot libraries and examples. Therefore, I committed it as revision 10352. Thanks! 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] More qt issues
On 2009-08-27 11:16-0600 Orion Poplawski wrote: On 08/27/2009 11:14 AM, Orion Poplawski wrote: Looking closer there may be some confusion between include/qt.h and drivers/qt.h? drivers/qt.h is what is being included here and it does not include plDevs.h while include/qt.h does. Scratch that, this is an artifact of how I'm patching plplot to the latest svn version. Yes, we moved some qt files (such as qt.h) to different locations. 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] Qt driver update
On 2009-08-27 09:05+0200 Werner Smekal wrote: * example 16 has wrong colors. The following warning messages are print to the screen: *** PLPLOT WARNING *** Unrecognized cmap1 format 0.0 1.0 1.0 1.0 1.0 0 *** PLPLOT WARNING *** Unrecognized cmap1 format 0. 240. 0.5 1.0 1. 0 *** PLPLOT WARNING *** Unrecognized cmap1 format 0.0 0.0 0.0 0.0 1.0 0 These warnings are evidence of more floating-point comparison issues that ocurred in plspal1 which I should have spotted when I fixed a similar issue that Valery Pipin found for cmap1_default.cmap. I believe I have now solved all these plspal1 floating-point comparison issues completely using a macro for the needed and oft-used programme fragment to deal with such issues (revision 10353). Also, I have made a much better fallback (gray scale rather than segfault) when the requested cmap1 palette file is completely wrong. Could you try again, please, to see if the above warnings are gone? Out of curiosity, what hardware were you using when you ran into the above warnings? I suspect it wasn't Intel/AMD. (That hardware uses 80-bit rather than 64-bit registers to store intermediate floating-point results. That leads to higher than normal floating-point precision and fewer floating-point comparison issues. The downside is that if you test exclusively on Intel/AMD, you may not notice the effects of problematic code which is subject to floating-point comparison issues.) 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] Qt driver update
To Werner, Hazen, and Jerry: Without decent colour maps, PLplot is pretty useless so colour issues are release critical by definition. Therefore, I hope all three of you with access to OS X will give the current plspal1 issues on Mac OS X that were discovered by Werner your immediate attention. Hazen and Jerry, do you confirm the issues Werner is seeing on Mac OS X? As far as I know he has only tested for qt, but I assume this issue is device independent. Could you make sure your experiments (with revision 10358, see below) include the following experiments I asked Werner to try? On 2009-08-28 10:29-0700 Alan W. Irwin wrote: So to summarize the experiments I would like you to try, please see whether -dev psc also produces the example 16 warning messages and please see whether can you reproduce similar issues for example 10 using -cmap1. Once the new warning messages have identified exactly where in the code the problem is occurring, could you please try a gdb session (or printf's scattered around plspal1) to see exactly what is going wrong? There have been two changes recently which I assume will not affect the issue that Werner discovered, but I mention them for completeness and just in case that assumption is incorrect. * At Arjen's suggestion, I changed the fuzz factor for floating point comparisons from 1.d-12 to 1.d-4. However, for the default typedef double PLFLT case, I expect floating point errors in quantities read in from palette files will be of order 1.d-16. Thus, this change should make no difference in that case. For the typedef float PLFLT you get when you specify -DPL_DOUBLE=OFF to cmake, I expect the floating-point errors in quantities read in from palette files will be of order 1.d-6. So for -DPL_DOUBLE=OFF this change will make an important difference (which is why Arjen suggested it), but otherwise not. * This morning I found four palette files (cmap0_alternate.pal, cmap0_white_bg.pal, cmap1_blue_yellow.pal, and cmap1_radar.pal) which had no svn:eol-style property assigned at all and others had native line endings (meaning they would have different line endings depending on what platform those files were checked out on). I think it is best that these PLplot input files have the exact same form whether obtained from our release tarball or svn so I have changed the svn:eol-style property to LF (Unix line endings) for all of them as of revision 10358. Regardless of platform, I don't see how line endings will make any difference to either cmap0_palette_read or plspal1 since they both use fgets from the C library. On Linux, fgets reads everything up to and including the line feed corresponding to the line end. I think Mac OS X line endings are also Unix (so the above property change should make no difference in any case) and I assume fgets act there the same as on Linux. For Windows, I assume fgets also reads everything up to and including the line feed regardless of whether that line feed is proceeded by a CR or not. Therefore, as far as I know changing to the LF property should generate the same results for cmap0_pallette_read and plspal1 on all platforms. So my assumption is the above two changes should make absolutely no difference to Werner's bad OS X results, but I need confirmation of that assumption from Werner and also confirmation of Werner's bad results on OS X by our other developers for revision 10358. If you do get differences from Werner's results, then it is important to see what is different about his Mac OS X system (Darwin version, etc., compared to yours) so give plenty of details if you cannot confirm his (bad) result. I believe I have done everything possible from this end to make it straightforward to debug this plspal1 issue on OS X, but ultimately one of you guys with access to Mac OS X has to sit down and actually debug the issue until you come up with a fix. Hopefully that will be in a timely manner (i.e., in the next few days) so we don't have to hold the release for the fix. 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
Re: [Plplot-devel] Fwd: [Perldl] surfaces with PDL
On 2009-08-29 13:02-0400 Hazen Babcock wrote: This just came up on the PDL mailing list. Any thoughts on how the build might have failed like this? Yep. The build system did not anticipate this user's case (PDL installed but not PDL::Graphics::PLplot). I have now (revision 10359) implemented a soft landing (warning message and continue) for this case From: P Kishor punk.k...@gmail.com Date: August 29, 2009 12:03:52 AM EDT To: perldl per...@jach.hawaii.edu Subject: Re: [Perldl] surfaces with PDL Reply-To: punk...@eidesis.org sorry to be replying here to my own rantings... I went ahead and followed the instructions listed below to install plplot, but received the following error -- PDL_PLPLOT_VERSION = Can't locate PDL/Graphics/PLplot.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.8/darwin-2level /usr/local/lib/perl5/5.8.8 /usr/local/lib/perl5/site_perl/5.8.8/darwin-2level /usr/local/lib/perl5/site_perl/5.8.8 /usr/local/lib/perl5/site_perl .). BEGIN failed--compilation aborted. This message comes from cmake/modules/pdl.cmake within the PLplot build. What is going on is perl -MPDL::Graphics::PLplot '-e print $PDL::Graphics::PLplot::VERSION' fails on this guy's system (presumably because PDL::Graphics::PLplot is not available). I assumed before that PDL::Graphics::PLplot would be installed if PDL was installed, but I have now check specifically for PDL::Graphics::PLplot. N.B. the PLplot build only pays attention to Perl/PDL for the purposes of deciding whether to install and test the pdl examples or not. So there is no major circular dependency here. If perl, perl/pdl, or (now) perl PDL::GRAPHICS:PLplot are not installed, you just get a soft landing and the rest of the PLplot build and install continues. In sum, Plplot must be installed and built (with or without the perl/pdl examples) before PDL::GRAPHICS::PLplot can be (re)built. (That perl module only depends on the PLplot library and not the Perl/PDL examples that happen to be contained in the PLplot source tree.) After that perl module is (re)built you are free to ignore the perl/pdl examples within PLplot, or do another PLplot build and install to install them in the correct place and run tests on them. I am not on the PDL list, but feel free to quote this message there. 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] Qt driver update
On 2009-08-30 11:51-0400 Hazen Babcock wrote: Alan W. Irwin wrote: To Werner, Hazen, and Jerry: Without decent colour maps, PLplot is pretty useless so colour issues are release critical by definition. Therefore, I hope all three of you with access to OS X will give the current plspal1 issues on Mac OS X that were discovered by Werner your immediate attention. Hazen and Jerry, do you confirm the issues Werner is seeing on Mac OS X? As far as I know he has only tested for qt, but I assume this issue is device independent. Could you make sure your experiments (with revision 10358, see below) include the following experiments I asked Werner to try? On 2009-08-28 10:29-0700 Alan W. Irwin wrote: So to summarize the experiments I would like you to try, please see whether -dev psc also produces the example 16 warning messages and please see whether can you reproduce similar issues for example 10 using -cmap1. Once the new warning messages have identified exactly where in the code the problem is occurring, could you please try a gdb session (or printf's scattered around plspal1) to see exactly what is going wrong? I'm not exactly sure what tests you wanted, but I ran examples 10 and 16 using both the psc driver and the xwin driver and everything was as expected w/ no warning messages. If you review the e-mail on this, Werner got error messages and warning colours (red scale) meaning he could not read some of the cmap1 palette files for example 16 on his particular OS X and hardware platform. The devices he used for the tests were qtwidget and pdfqt. However, palette file reading is done by the PLplot core and should largely be independent of the device driver used (unless there is some nasty side effect between the two that I am unaware of). I would like that assumption (that he gets warning messages and colours for all devices) confirmed by Werner by the tests requested above, but he hasn't reported back on that request yet. It appears you _can_ read those cmap1 palette files with no problems on your particular OS X and hardware platform for -dev psc and -dev xwin, but I would appreciate you also trying qtwidget and pdfqt (and other devices as well) to show that on your platform at least there are no side effects between cmap1 palette file reading success and the device used. 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] Qt driver update
Hi Werner:
Most of this is directed to you but there is also a request for Hazen and
Jerry at the end.
On 2009-08-31 08:27+0200 Werner Smekal wrote:
Hi Alan,
weekend is family time, so no work from my side on this issue here.
Understood. We are all volunteers here with limited (and variable) spare
time so we should all expect that responses to questions on this list are
sometimes delayed.
I just
updated to the last plplot version and I get now little different warnings.
*** PLPLOT WARNING ***
Unrecognized cmap1 format (wrong number of items for version 2 of format) 0.0
1.0 1.0 1.0 1.0 0
*** PLPLOT WARNING ***
Unrecognized cmap1 format (wrong number of items for version 2 of format) 0.
240. 0.5 1.0 1. 0
*** PLPLOT WARNING ***
Unrecognized cmap1 format (wrong number of items for version 2 of format) 0.0
0.0 0.0 0.0 1.0 0
By the way, I am pretty sure (unless a device driver is really screwed up)
that cmap1 palette reading troubles should be device independent. Could you
confirm that by trying -dev psc for example 16?
Nope, this warnings only occur with the qt devices. All other drivers I tried
(wxwidgets, xwin, ps, pdf) worked as expected.
That is a really strange result.
The relevant code from plctrl.c (subject to line rewrap) is identified
exactly by the unique error message above.
fgets(color_info, 160, fp);
if (sscanf(color_info, %lf %lf %lf %lf %lf %d,
pos_d, r_d, g_d, b_d, a_d, rev_i) != 6) {
snprintf(msgbuf,1024,
Unrecognized cmap1 format (wrong number of items for version 2 of format)
%s\n,
color_info);
So the above warning message outputs exactly the color_info which sscanf
cannot interpret properly. But if we look at the data in that warning
message above it is perfect; five floating point variables in a row, then an
integer just like the above sscanf format directives and corresponding
pointers. In particular, we already know there is no hidden null characters
embedded in the middle of color_info because then that would affect the
output of color_info in an obvious way (truncated early). It is hard to
tell from e-mail, but I suppose there could be a line ending or other
non-printing characters embedded in the middle of color_info.
Just to be sure that is not the case, could you run example 16 again and
capture the warning message directly into a file (using and not cut and
paste to make this test as direct as possible), then analyze that file with
something like od to see whether there are any non-printing characters in
color_info? This is improbable (since color_info is read immediately before
in the code with fgets above), but it would be good to have rock-solid
confirmation that this improbability is not true.
If you confirm the color_info output is perfect yet sscanf cannot read it,
this is a second very strange result (after the very strange result that the
problem only occurs for qt devices).
The third very strange result is that the 3rd message above corresponds to
cmap1_gray.pal which is read without issues for the first page of the same
example 16!
One hypothesis that might explain (more or less) all three strange results
is that dynamic loading of qt devices is linking in a Qt4 library that
breaks sscanf (or fgets if color_info turns out to have some embedded
non-printing characters) on your system in some way. I know that hypothesis
is quite speculative/improbable so if somebody here can come up with some
more probable hypothesis to explain these strange results, please speak up.
Werner: here are the next steps I would appreciate you doing to help figure
this out.
* Check color_info by directly capturing the above error message into a file
and binary dump that file with something like the od application to make
sure there are no non-printing characters embedded in the middle of
color_info. (I have done that already with this e-mail, and the color_info
output above was clean of embedded characters, but some of the applications
used in the long e-mail chain between us could have filtered out those
non-printing characters, and the right way to do this is by immediate file
capture on the platform where the warning message is generated.)
* Experiment with different Qt4 versions to see if the problem goes away
for one of them.
Hazen and Jerry: would you do similar experimentation (running example 16
with a number of different Qt4 versions) to see if you can replicate the
issue that Werner found? To switch from one Qt4 version to another, simply
put the appropriate qmake on your path before a fresh build and cmake does
the rest.
If by such experiments from Werner, Hazen, and Jerry we establish that the
cmap1 palette file reading problems for example 16 occurs only for one Qt4
version on OS X but not others, then we only have to warn about that bad Qt4
version for OS X in the release notes, and we are (finally) done with this
issue.
Alan
__
Alan W. Irwin
Astronomical research affiliation
Re: [Plplot-devel] Qt driver update
On 2009-09-01 09:12+0200 Werner Smekal wrote: This is improbable (since color_info is read immediately before in the code with fgets above), but it would be good to have rock-solid confirmation that this improbability is not true. I only see text, spaces and linefeeds, so it should be ok (see attached png). I agree that is completely clean of special characters (except for linefeeds in the right place). Thanks for that confirmation. One hypothesis that might explain (more or less) all three strange results is that dynamic loading of qt devices is linking in a Qt4 library that breaks sscanf (or fgets if color_info turns out to have some embedded non-printing characters) on your system in some way. I know that hypothesis is quite speculative/improbable so if somebody here can come up with some more probable hypothesis to explain these strange results, please speak up. Just to make it more strange. Nokia actually provides two packages of Qt - cocoa and carbon, whil cocoa is the new API (use for Mac OS X 10.6). I actually have two Macs here (both latest 10.5.8 and xcode) and on one I installed the carbon binary package and on the other cocoa binary package (see http://qt.nokia.com/downloads/mac-os-cpp). While the Qt carbon leads to this strange cmap results, does Qt cocoa not print out this warnings - so the file qt devices work regarding the color. But qtwidget is messed up again, since the first plot appears (for multipage examples and after I click on the plot, before only grey window), but the following plots are not shown only the background color. I really have to say that Qt on Mac OS X is quite buggy as it seems. I have to agree. Thanks for all these tests. Hazen and Jerry: would you do similar experimentation (running example 16 with a number of different Qt4 versions) to see if you can replicate the issue that Werner found? To switch from one Qt4 version to another, simply put the appropriate qmake on your path before a fresh build and cmake does the rest. I used the binary packages, where a switch is not that easy. I just don't have the time to download the 450Mb source package and compile qt in different versions, which I assume will really take a long time, if this 450MB monster is uncompressed. I don't believe compilation will be necessary so using the SDK may be a lot more straightforward than you think. Just to give my own experience, on Linux I downloaded the Qt4 SDK (software development kit) from https://edit.qt.troll.no/downloads). I have forgotten where I got the subsequent instructions, but here are my notes of exactly what I did. chmod u+x qt-sdk-linux-x86_64-opensource-2009.02.bin ./qt-sdk-linux-x86_64-opensource-2009.02.bin i.e., I changed the permission to execute and then ran that downloaded installer binary application. That installer then gave you a GUI where you could choose the installation prefix. By default that was a non-system location (/home/software/qtsdk-2009.02 for me where software is the name of the user account where I did the install). After that, the installation was quite fast with lots of disk activity but no cpu activity consistent with just getting a binary installed from the downloaded SDK rather than actually compiling it. I suspect if you download the 442MB Qt4 SDK for Mac OS X (see https://edit.qt.troll.no/downloads) it will also result in a binary install to a non-system location. After that, if you put that binary installs version of qmake (/home/software/qtsdk-2009.02/qt/bin/qmake in my case) on your PATH, then a fresh build of PLplot will just use that version of Qt4 with no interference from your system version. To Werner, Hazen, and Jerry: There is no mention on the above trolltech site whether the downloaded SDK for Mac OS X is packaged with Carbon or Cocoa or neither, but since the Carbon and Cocoa system packages for Qt4 seem to be broken in various ways for Werner regardless of Qt4 version, you might want just avoid those and use the downloadable trolltech Qt4 SDK instead. I also have the same advice (use the trolltech Qt4 SDK) on both Linux and Windows platforms. On Linux, that SDK version was certainly the most reliable version of Qt4 for me. That makes a lot of sense since Trolltech is the world's expert on building Qt4, and, of course, the SDK is their recommended version of Qt4. 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
Re: [Plplot-devel] RE : RE : Qt driver update
On 2009-09-01 12:08+0200 Werner Smekal wrote: Hi Alban, yes this [setting locale in qt] works. Hi Werner: Thanks very much for thinking of locale as a possibility for messing up sscanf. That was a stroke of debugging genius, and it is wonderful news that we now have the reason for all the strange results you were getting when attempting to read palette files. However, I don't think the current solution (revision 10363) to this problem is correct. Instead of forcing the C locale whenever we use qt, the user should be allowed to use any locale they like for _user_ input to PLplot regardless of device driver. Of course, our palette files absolutely require setlocale(LC_NUMERIC, C); in order to be read properly as you have discovered. Thus, I think our best solution to this whole issue is to save the user locale, use setlocale(LC_NUMERIC, C); to read the file, then restore the user locale in both cmap0_palette_read and plspal1. This method absolutely guards against any locale issue (say for a different library than qt) ever again screwing up palette file reading so this is what I like. What do you think of this idea? If you agree, would you be willing to help with the implementation and testing? (I don't know how to get the current locale [there appears to be no function called getlocale, although localeconv might be a possibility on Linux], and we have to insure that setlocale [and whatever you recommend for getting the current locale information] works on all our platforms.) 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] Qt segmentation fault, Qt version and test_plend
Hi Alban: On 2009-09-02 11:36+0100 Alban Rochel wrote: I have to confess that I am a bit worried by this bug, as I can't find a way to reproduce it on a smaller scale program. It seems to occur only on 64 bit systems (Linux only?), with Qt 4.5.x (Qt 4.4 is OK), when the Qt driver is compiled and loaded dynamically. I've tried creating a small program loading dynamically a Qt Application, and unloading it after execution, but it behaves normally. According to the few forum entries I've found, nothing is wrong with creating a dynamically loaded Qt application. My guess for why you are unable to replicate the problem with a sample programme is just one particular Qt4 call in qt is causing the issue, and your sample programme doesn't have that call. However, it would be a lot of work to go through all the qt-related code and systematically try every Qt4 call in your sample code so you will probably want to try that only as a last resort to figure out this problem. So I would be glad if anyone had ideas that could help identify the issue (e.g. tools to use, as valgrind, strace and gdb don't bring me much help). Testing on different systems could be interesting too (various Unix flavours, Mac, 64-bit Windows). The other important point about this bug is my Linux (Debian stable), 64-bit (amd64) system does not have it for _any_ Qt4 version I try. To be specific valgrind reports the following results for qtwidget/qtwidget: valgrind examples/c/test_plend -dev qtwidget [...] Enter device number or keyword: qtwidget ==23168== ==23168== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 944 from 4) ==23168== malloc/free: in use at exit: 248,205 bytes in 6,285 blocks. ==23168== malloc/free: 54,218 allocs, 47,933 frees, 9,436,280 bytes allocated. ==23168== For counts of detected errors, rerun with: -v ==23168== searching for pointers to 6,285 not-freed blocks. ==23168== checked 378,984 bytes. ==23168== ==23168== LEAK SUMMARY: ==23168==definitely lost: 165,456 bytes in 5,432 blocks. ==23168== possibly lost: 2,016 bytes in 2 blocks. ==23168==still reachable: 80,733 bytes in 851 blocks. ==23168== suppressed: 0 bytes in 0 blocks. ==23168== Rerun with --leak-check=full to see details of leaked memory. Note, above I entered qtwidget for the second device. The important result here is 0 errors from 0 contexts which essentially means segfaults are impossible. Qt4 does have some unfreed memory problems (most for which no pointer can be found any more), but experience shows most external libraries have such unfreed memory errors, and normally it is a fairly benign error. N.B. The above result was for Qt4.5.1 (from the SDK I downloaded a few months ago), but I also tried Qt4.5.0 (from the downloadable SDK from January this year), _and also the Debian stable system version, Qt4.4.3_, and they gave essentially identical valgrind results to above. I wonder whether the problem is related to gcc compiler version for 64-bit systems on Linux. Debian stable has gcc (Debian 4.3.2-1.1) 4.3.2 (which presumably has bug-fix patches from later versions). I am virtually positive the downloadable SDK versions of Qt4 are binary versions (see my previous post), but trolltech might well have chosen a similar compiler version as Debian stable to build those binaries which is why they are working for me. To investigate that possibility further what are your valgrind results for the latest SDK downloadable binary version of Qt4? (I will download and try that version myself right after I send this, but I assume it will continue to produce valgrind clean results aside from unfreed memory errors.) Do you have the same gcc compiler version number as above that was used to compile your Qt4 system version that is generating valgrind errors? (Of course, even if that gcc version number is the same, the compilers are likely still different because the patches applied by your distro will be different from those applied by Debian.) What other important differences do you have with Debian stable for your 64-bit system where valgrind shows errors? 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
Re: [Plplot-devel] Missing documentation for plenv
On 2009-09-02 00:08-0700 Jerry wrote: x19c.c uses 70 as the last argument in plenv, axis, but the documentation does not mention such a value. This was detected by the Ada compiler at compile time. I have made the Ada code accept arguments up to 70 by creating a constant called Undocumented_Feature but I don't know if 70 is high enough or what is the meaning of arguments above 63. I suppose it is in the C code somewhere but I much prefer writing to the documentation rather than reading C which I seem genetically unable to do well. Genetics notwithstanding, the docs should probably be updated. Done, revision 10364. In response to your genetics comment (which I assume was it least partially tongue in cheek although I also have my troubles with C sometimes), have a look at src/plvpor.c where the meanings of the last argument to (c_)plenv (including the 70-73 values) are clearly documented. That's the source I used for the above revision to doc/docbook/src/api.xml. Our website documentation will be built from api.xml (and other files in that directory) as part of the release process. Until then, you will have to rely on api.xml or plvpor.c for documentation of plenv. 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] Missing documentation for plenv
On 2009-09-02 12:00-0500 Hezekiah M. Carty wrote: I'm still not entirely familiar with how Docbook markup works, but the PDF output looks good here and I think it gets the information across appropriately. Suggestions for improvement in the Docbook code as well as the actual documentation are welcome as always. Hi Hez: Thanks very much for your documentation update. The principal issue to be careful of is make validate finds no errors. (Your latest commit passes this test.) That is a fast and easy method (which requires the onsgmls application be installed but which does not require special configuration of the build) of checking that you haven't introduced some DocBook XML syntax error that will kill everybody's documentation build including the one that Hazen does for releases. It's that potential to kill the build that leads me to give make validate results the highest priority when evaluating patches to or commits of files in doc/docbook/src. The actual content of documentation upgrades is a second priority after that primary one. Basically, I believe we should be happy to take anything that we can get as the first try for documenting some aspect of PLplot; if necessary we can always refine the wording/organization/consistency of form later. Of course, as you have found, DocBook XML is not that hard to learn since you can do a lot simply by analogy with other aspects of the files in doc/docbook/src. Thus, I strongly encourage everybody on this list to send patches or make commits to those files to improve our DocBook documentation. And if some of you don't have onsgmls installed on your system, I am happy to try make validate here and correct any syntax errors it finds in your updates to the documentation. 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
