Re: [Plplot-devel] SVG driver
On 2006-11-27 22:23-0500 Hazen Babcock wrote: > > On Nov 27, 2006, at 4:04 PM, Werner Smekal wrote: > >> Hi Hazen, >> >> I tried to turn off the svg driver here in Windows with - >> DPLD_svg=ON. Cmake lists the drivers, it gets compiled, but doesn't >> show up in the driver list in the examples. >> >> Any ideas? > > That is a bit puzzling. I used ccmake to enable the svg driver rather > than the command line switch, but I don't think that that should make > any difference. It doesn't have any dependencies so you can't be > missing anything. Did you notice whether it got compiled at the make > stage? While investigating this I have found an error on Linux with svg.c which might not be related, but which should still be fixed first so I can investigate Werner's issue more closely. It struck me that Werner tests on windows where ENABLE_DYNDRIVERS must be set to OFF so I tried that on Debian stable cmake -DCMAKE_INSTALL_PREFIX=/home/software/plplot_cvs/installcmake -DCMAKE_VERBOSE_MAKEFILE=ON -DENABLE_java=OFF -DENABLE_DYNDRIVERS=OFF -DPLD_svg=ON ../plplot_cmake All seemed well. I then built with that configuration, and svg.o was built, but an error showed up when linking libplplotd.so.9.2.1 (which necessarily for this case [ENABLE_DYNDRIVERS=OFF] includes all the code for all the device drivers). (note the following is a poorly wrapped error message from a very long linking command for libplplotd.so.9.2.1, but you should get the idea) CMakeFiles/plplotd.dir/home/software/plplot_cvs/HEAD/plplot_cmake/drivers/svg.o( .text+0x7a3): In function proc_str': : multiple definition of proc_str' CMakeFiles/plplotd.dir/home/software/plplot_cvs/HEAD/plplot_cmake/drivers/gcw.o( .text+0x1940): first defined here /usr/bin/ld: Warning: size of symbol proc_str' changed from 2592 in CMakeFiles/ plplotd.dir/home/software/plplot_cvs/HEAD/plplot_cmake/drivers/gcw.o to 1552 in CMakeFiles/plplotd.dir/home/software/plplot_cvs/HEAD/plplot_cmake/drivers/svg.o So gcw.c and svg.c have a name clash that affects the case when gcw.o and svg.o are in the same library. Hazen, can you fix this name clash? I doubt this error will affect either you or Werner since I don't think either of your platforms are currently capable of building -dev gcw (tons of library dependencies), but once this issue is fixed on Linux, I can at least look further to see whether I get the same symptoms as Werner for the ENABLE_DYNDRIVERS=OFF case. Thanks in advance. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] How to use the installed PLplot libraries
> > I would like to ask you a few questions: > Does that mean re-installing PLplot using CMake? > If I will re-install using CMake, are all files overwrited > safely ? Yes, everything of importance will safely be overwritten. You will be left with a folder of examples in /usr/local/share called 5.7.0 from your previous installation efforts. To summarize what others have suggested (and assuming that you have root privileges on your mac), you will want to: (1) Download and install cmake from here: http://www.cmake.org/HTML/Download.html. You will want the latest version (i.e. 2.4.4). (2) Follow the OS-X install direction on our wiki here: http://www.miscdebris.net/plplot_wiki/index.php?title=Main_Page Note that (a) plplot-working-directory is one directory up from your build directory (b) cvs-plplot/directory is your local (uncompressed and untarred) copy of plplot-5.7.1. (c) the plplot-build directory that you create will initially be empty but executing the ccmake (or cmake) command in that directory will populate it with the files that will be needed to build plplot. The easiest way to configure the various plplot options is to use the command ccmake. It will give you a simple graphical menu that you can use to configure your plplot build. You might in particular want to set "BUILD-TEST" to ON. This will compile the examples in the build tree. You can the verify that your installation of PLplot is working by running one of the examples: ~/plplot-working-directory : ./examples/c/x01c Alternatively you can compile and test the examples in the install tree: cd /usr/local/share/plplot5.7.1/examples sudo make ./c/x01c HTH, -Hazen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] SVG driver
On Nov 27, 2006, at 4:04 PM, Werner Smekal wrote: > Hi Hazen, > > I tried to turn off the svg driver here in Windows with - > DPLD_svg=ON. Cmake lists the drivers, it gets compiled, but doesn't > show up in the driver list in the examples. > > Any ideas? That is a bit puzzling. I used ccmake to enable the svg driver rather than the command line switch, but I don't think that that should make any difference. It doesn't have any dependencies so you can't be missing anything. Did you notice whether it got compiled at the make stage? -Hazen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] How to use the installed PLplot libraries
On 2006-11-28 08:46+0900 Hiroyasu Yasuda wrote: > |*|This is all taken care of in the recommended pkg-config approach that is > |*|used with our new CMake build system. Again, look at what the installed > |*|examples/f95/Makefile file does (for our new CMake build system), and > |*|copy that. > > I would like to ask you a few questions: > Does that mean re-installing PLplot using CMake? > If I will re-install using CMake, are all files overwrited > safely ? There are three file trees of relevance here. Here is what I suggest to have pristine results for all of them. (1) Source tree. You should start by removing the plplot-5.7.1 directory (use rm -rf if you have the courage to use that dangerous command), then unpack the 5.7.1 tarball. That should create a pristine source tree. (2) Build tree. If you follow the cmake build system directions at http://www.miscdebris.net/plplot_wiki/ you will use a build tree that is separate from the source tree. Be sure to start with an absolutely empty build tree (rm -rf is again your dangerous friend), and that insures a pristine build tree. (3) Install tree. "make install" installs into whatever install prefix you specify with the cmake -DCMAKE_INSTALL_PREFIX option. Usually, I specify something accessible from an ordinary user account for this prefix rather than a root-owned area. Use something unique for that install prefix for your CBS builds and always remember to rm -rf that prefix directory before each build to insure a clean install tree. (If you don't set CMAKE_INSTALL_PREFIX, then the default will be to install to /usr/local which is owned by root and not unique so you cannot safely remove it with rm -rf). I am sure there are other methods to assure pristine source, build, and install trees, but these are what I use. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] From now on please avoid introducing ARGS subcommands into our cmake build system
Some cmake style comments. The ARGS subcommand is ignored in cmake everywhere but in the EXEC_PROGRAM command which itself is deprecated in favor of EXECUTE_PROCESS. Essentially ARGS was an old experiment that failed so modern cmake just ignores it (except for EXEC_PROGRAM) if it is detected. So if you find yourself wanting to write an ARGS subcommand or use EXEC_PROGRAM as you adjust our cmake build system, please don't. I got rid of the last of the useless ARGS (I hope) tonight outside the remaining EXEC_PROGRAM uses which I plan to get rid of by converting to EXECUTE_PROCESS instead (unless some enterprising soul 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] How to use the installed PLplot libraries
|*|On 2006-11-28 05:18+0900 hiroyasu yasuda wrote: |*| |*|>> You could try the following: |*|>> |*|>> - Copy, say, x01f.f90 to a separate directory |*|>> - Then compile it and link it like this: |*|>> |*|>> gfortran -o example x01f.f90 -I/directory/with/modules -L/ |*|>> directory/with/libraries -lplplotf95d -lplplotf95cd -lplplotd |*|> |*|> |*|> I gave above-command Include directory and Libraries directory on my |*|> system, I could succeed compiling. |*|> Since I can not find 'plplot.mod' in /usr/local/include/, I give |*|> unziped plplot directory as Include directory temporally. |*|> How to produce 'plplot.mod' ? Where should be modules file |*|> 'plplot.mod' ? |*| |*|This is all taken care of in the recommended pkg-config approach that is |*|used with our new CMake build system. Again, look at what the installed |*|examples/f95/Makefile file does (for our new CMake build system), and |*|copy that. I would like to ask you a few questions: Does that mean re-installing PLplot using CMake? If I will re-install using CMake, are all files overwrited safely ? Regards. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Issue with 5.7.1 and h2def.py on Fedora
On 2006-11-27 14:26-0700 Orion Poplawski wrote: > /usr/share/pygtk/2.0/codegen/h2def.py on Fedora is not executable. The > following patch fixes. If there is a variable for the python > executable, presumably you want to use that instead. Thanks, Orion. I have committed the fix (slightly modified) to CVS. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
On 2006-11-27 21:41+0100 Werner Smekal wrote: > I think, Arjen ment that we replace the sh-scripts with jim/tcl-scripts. So > for Linux, we don't need to compile jim, since tcl might be available most of > the times, and for Windows we use jim. So this might be a good solution. I hope he didn't mean that... :-) I want to keep the current scripting intact for the Unix side of everything since shell scripting is installed by default for Unix and most Unix developers understand it. OTOH, Tcl is not installed by default, and I am not sure that most Unix developers understand it. > >> >> It appears the only downside to the windows bash solution is our windows >> developers and users will need to independently install bash if they want >> to >> use ctest and/or the install-tree plplot-test.sh tests. I doubt >> installing >> a windows bash is going to be a difficult burden for Arjen or any other >> windows developer that wants to contribute to PLplot since Werner has >> already been successful at this, and almost by definition our developers >> are >> good at installing PLplot dependencies. That leaves only the question of >> our users. To make life easier for them, I think we should put together a >> test to look for bash. If that test fails we should give the appropriate >> warning message, force BUILD_TEST to OFF, and not configure or install >> plplot-test.sh and the test*.sh scripts. Also, Werner should expand our >> wiki a bit more giving a reference to windows bash and perhaps a sentence >> or >> two about how to install it if that is not obvious. > > I can do that (the wiki stuff), but have to mention, that the bash is really > not a good solution in the moment. e.g. cmake doesn't like sh.exe in the path > if I use MinGW/CLI combination, I have to rename it, run cmake, rename sh > again to run the tests. And then we would need still some tweaking - it works > far from perfect in the moment, and all tweaks are actually hacks, since you > always need to program around the fact, that bash isn't actually meant to be > there. Well, those general hacking requirements sound like a showstopper for the windows bash idea. Too bad! It looks like we are back to a separate (please!) tcl scripting solution and the maintenance (as I said mostly irritating rather than difficult) that would go into that. However, I would advise you to steer clear of building your own tcl interpreter within the windows version of PLplot because of the additional maintenance load you would bear. I really think it is up to windows users to install their own tcl solutions (if they really want to try ctest or the install tree tests). Of course, you can advise them on the wiki that jim works great for this purpose if they don't have access to a full-blown Tcl. >> [...]However, if the windows developers >> still >> prefer the jim/tcl alternative (and are willing to develop it and more >> importantly maintain it), I will go along since windows developers know >> a lot more about windows than I do. :-) > > We may should do some test first, if the jim solution is really the best one, > since we might run into the same trouble as with bash - don't know how good > tcl/jim is with the filenames. If jim fails there are always python and perl and windows-only alternatives. Even if python or perl were ultimately chosen I would like those to be a separate (please!) windows-only solution because scripting is installed by default and well understood on Unix and python (and sometimes perl) are not. So forget the Unix side (which should remain intact as is) and go for a separate windows-only solution that you are most comfortable with. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] How to use the installed PLplot libraries
On 2006-11-28 05:18+0900 hiroyasu yasuda wrote: >> You could try the following: >> >> - Copy, say, x01f.f90 to a separate directory >> - Then compile it and link it like this: >> >> gfortran -o example x01f.f90 -I/directory/with/modules -L/ >> directory/with/libraries -lplplotf95d -lplplotf95cd -lplplotd > > > I gave above-command Include directory and Libraries directory on my > system, I could succeed compiling. > Since I can not find 'plplot.mod' in /usr/local/include/, I give > unziped plplot directory as Include directory temporally. > How to produce 'plplot.mod' ? Where should be modules file > 'plplot.mod' ? This is all taken care of in the recommended pkg-config approach that is used with our new CMake build system. Again, look at what the installed examples/f95/Makefile file does (for our new CMake build system), and copy that. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Windows+python (was Re: Windows+java)
Hi Alan, thanks for the help. Actually python was the problem. In Visual C++ you can set libraries in the code itself with #pragma directives. Python sets in its header files to link to the python24_d.lib if _DEBUG is defined. If I #undef it just before I include Python.h it compiles and works. I still have to rename _plplotcmodule.dll to _plplotc.dll and it must be in the same directory as the python script, it doesn't work if the dll is only in the PATH. So, I either have to find where we get the python24_d.lib or have to hack the cmake files to not set _DEBUG for the Visual C++ case. Thanks, Werner Alan W. Irwin wrote: > On 2006-11-25 22:47+0100 Werner Smekal wrote: > >> I searched the whole plplot tree where we would set python24_d.lib, but I >> couldn't find anything like that. > > We set PYTHON_LIBRARIES in cmake/modules/python.cmake, and I am virtually > positive that is how python24_d.lib is found. If cmake did not find a > python library, then it would have disabled python completely. To build the > two python interfaces on windows you need to link to PYTHON_LIBRARIES. (See > /bindings/python/CMakeLists.txt.) So I suspect the real question is why > python24_d.lib is not accessible to the linker on bare windows even though > cmake found it. > > Hope that background information helps, and thanks very much for your > continued windows/python efforts. > > 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 Yorick front-end to PLplot (yplot.sf.net); the > Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __ > > Linux-powered Science > __ > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: [EMAIL PROTECTED] web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Issue with 5.7.1 and h2def.py on Fedora
/usr/share/pygtk/2.0/codegen/h2def.py on Fedora is not executable. The
following patch fixes. If there is a variable for the python
executable, presumably you want to use that instead.
--- plplot-5.7.1/bindings/gnome2/python/CMakeLists.txt.pygtk2
2006-11-26 19:27:01.0 -0700
+++ plplot-5.7.1/bindings/gnome2/python/CMakeLists.txt 2006-11-27
13:59:49.0 -0700
@@ -30,8 +30,9 @@
# Use sed to rename PLINT and PLFLT so that h2def.py knows what to do.
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/gcw.defs
-COMMAND ${codegen}/h2def.py
+COMMAND python
ARGS
+${codegen}/h2def.py
${CMAKE_SOURCE_DIR}/include/gcw.h
| sed -e s/PLINT/gint32/ -e s/PLFLT/double/
> ${CMAKE_CURRENT_BINARY_DIR}/gcw.defs
@@ -61,8 +62,9 @@
# Use sed to rename PLINT and PLFLT so that h2def.py knows what to do.
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/plplotcanvas.defs
-COMMAND ${codegen}/h2def.py
+COMMAND python
ARGS
+${codegen}/h2def.py
${CMAKE_SOURCE_DIR}/include/plplotcanvas.h
| sed -e s/PLINT/gint32/ -e s/PLFLT/double/
> ${CMAKE_CURRENT_BINARY_DIR}/plplotcanvas.defs
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane [EMAIL PROTECTED]
Boulder, CO 80301 http://www.cora.nwra.com
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] SVG driver
Hi Hazen, I tried to turn off the svg driver here in Windows with -DPLD_svg=ON. Cmake lists the drivers, it gets compiled, but doesn't show up in the driver list in the examples. Any ideas? Werner [EMAIL PROTECTED] wrote: > Hello, > > I've added a SVG driver to PLplot (http://www.w3.org/Graphics/SVG/). > SVG (Scalable Vector Graphics) is a XML graphical language that is > supported natively or as a plug in most modern browsers. In theory it > is anti-aliased and uses truetype fonts, but the reality will depend > on the capabilities of your SVG renderer. Since this driver is still > a bit rough, primarily with regard to text placement, it is off by > default. > > If you choose to play with it, you should be aware of the following > issues: > (1) The S in SVG might also stand for "Simple". If the plot is at all > complicated then you might find rendering to be painfully slow. I'd > recommend starting with example 3 before jumping to something > complicated like example 8. I'm not sure exactly why it is so slow. > The generated files are similar in size to their postscript > equivalents. Perhaps this is due to the fact that, at least in a > browser, a DOM tree is being constructed during rendering so that you > can manipulate every element with javascript? > > (2) As mentioned above, vertical text placement still leaves > something to be desired. I think this is because SVG is scanning each > text element and deciding based on the glyphs in that element what > the baseline of the element should be. You can see this in example2 > where the numbers are all centered slightly differently in their > boxes. It would be preferable from our point of view if it always > used the same baseline for a particular font. > > (3) On OS-X in Firefox and Camino the font-family "serif" comes out > looking like the font-style "italic". I'm pretty puzzled by that one. > > Anyway, thanks to our CBS I was delighted to find that I only had to > add one line to each of two files to build PLplot with this driver. > > -Hazen > > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: [EMAIL PROTECTED] web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
Hi, > Hmm... It's interesting [...] > > 1) It adds parallel maintenance that Werner and Arjen have to apply to > the jim scripts any time there is a change to plplot-test.sh and the > other test*.sh scripts. This is all fairly trivial stuff (adding new > examples, finding better ways to configure the tests), but there is a fair > amount of churn, and it will be irritating to keep the two systems in sync. > > 2) There is also a maintenance burden for jim itself. Werner and Arjen have > to keep track of new jim releases, make judgement calls about the stability of > those releases, and decide when to deploy them into the PLplot code base. > > The first of these reservations also applies to all other parallel scripting > systems (with python, perl, or whatever) which is why my opinion _now_ is we > should reject all of them. I only brought up the idea of parallel scripts > originally because I was under the impression no bash solutions were > available for windows, but it appears that such solutions exist. In fact, > Werner was able to get all but the java ctests passed with the windows bash > solution he found, and I doubt a solution is far away in that case. I think, Arjen ment that we replace the sh-scripts with jim/tcl-scripts. So for Linux, we don't need to compile jim, since tcl might be available most of the times, and for Windows we use jim. So this might be a good solution. > > It appears the only downside to the windows bash solution is our windows > developers and users will need to independently install bash if they want to > use ctest and/or the install-tree plplot-test.sh tests. I doubt installing > a windows bash is going to be a difficult burden for Arjen or any other > windows developer that wants to contribute to PLplot since Werner has > already been successful at this, and almost by definition our developers are > good at installing PLplot dependencies. That leaves only the question of > our users. To make life easier for them, I think we should put together a > test to look for bash. If that test fails we should give the appropriate > warning message, force BUILD_TEST to OFF, and not configure or install > plplot-test.sh and the test*.sh scripts. Also, Werner should expand our > wiki a bit more giving a reference to windows bash and perhaps a sentence or > two about how to install it if that is not obvious. I can do that (the wiki stuff), but have to mention, that the bash is really not a good solution in the moment. e.g. cmake doesn't like sh.exe in the path if I use MinGW/CLI combination, I have to rename it, run cmake, rename sh again to run the tests. And then we would need still some tweaking - it works far from perfect in the moment, and all tweaks are actually hacks, since you always need to program around the fact, that bash isn't actually meant to be there. > > With those changes it should be straightforward for our windows users to > install bash, but if they choose not to do so, all that will happen is they > will receive a CMake warning and the ctest functionality will be missing and > install tree tests not available. So it will be exactly like any other > component of PLplot. If you want a particular PLplot component you have to > pay the price of installing the relevant software. > > In sum, I have given my reasons why I prefer a uniform bash solution for all > platforms (especially since it apparently already works on bare windows > except for one minor Java issue). However, if the windows developers still > prefer the jim/tcl alternative (and are willing to develop it and more > importantly maintain it), I will go along since windows developers know > a lot more about windows than I do. :-) We may should do some test first, if the jim solution is really the best one, since we might run into the same trouble as with bash - don't know how good tcl/jim is with the filenames. Werner - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] How to use the installed PLplot libraries
On 2006/11/27, at 23:19, Arjen Markus wrote: > hiroyasu yasuda wrote: > >> Hello Arjen: >> - Are you using the latest release (PLplot 5.7.1) or version 5.6.1? >>> >> >> I was using PLplot 5.7.0. yesterday. >> >> - Are you using the ./configure script to build the libraries or are you using the CMake build system? >>> >> >> I followed 'INSTALL' document below: >> >>> 3) With g95: [Fortran 95 (GCC) 4.2.0 20060512 (experimental)] >>> ./configure --disable-wxwidgets --enable-f95 FC=gfortran >>> F77=gfortran >>> make FFLAGS="-Wl,-single_module" FCFLAGS="-Wl,-single_module" >>> make install >>> make check >> >> >> >> When I tried 'make install' and 'make check' last week, their command >> returned some 'Error'. But I tried installation using 'sudo' >> yesterday, did >> not return Error message. Is my PLplot libraries on OSX OK? > > Hm, that sound sas if you do not have sufficient permissions to > install > files in the default directory. > >> >> And please tell me how to compile fortran source with PLplot >> libraries ? > > You could try the following: > > - Copy, say, x01f.f90 to a separate directory > - Then compile it and link it like this: > > gfortran -o example x01f.f90 -I/directory/with/modules -L/ > directory/with/libraries -lplplotf95d -lplplotf95cd -lplplotd I gave above-command Include directory and Libraries directory on my system, I could succeed compiling. Since I can not find 'plplot.mod' in /usr/local/include/, I give unziped plplot directory as Include directory temporally. How to produce 'plplot.mod' ? Where should be modules file 'plplot.mod' ? Regards, Hiroyasu. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] SWIG on Windows
Alan W. Irwin wrote: > > I assume that is NumPy rather than numpy. > There is some confusion over the various names. numpy came out around > python 1.5 but was eventually renamed Numeric, then Old Numeric. Numarray > came out later, but was eventually renamed Old Numarray. Finally, NumPy > came out (version 1.0 just released) which is easy for old-timers to confuse > with the original numpy, but it supersedes all the others I have mentioned. Be careful with this. While the web page calls the new package "NumPy", the tar file is "numpy" and so the Fedora package is also called "numpy". This may be the case on other distros as well. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] How to use the installed PLplot libraries
On 2006-11-27 22:29+0900 hiroyasu yasuda wrote: > Hello Arjen: > >>> - Are you using the latest release (PLplot 5.7.1) or version 5.6.1? > > I was using PLplot 5.7.0. yesterday. > > >>> - Are you using the ./configure script to build the libraries or >>> are you >>> using the CMake build system? > > I followed 'INSTALL' document below: >> 3) With g95: [Fortran 95 (GCC) 4.2.0 20060512 (experimental)] >> ./configure --disable-wxwidgets --enable-f95 FC=gfortran F77=gfortran >> make FFLAGS="-Wl,-single_module" FCFLAGS="-Wl,-single_module" >> make install >> make check I suggest you use PLplot 5.7.1 and follow the CMake build system instructions at http://www.miscdebris.net/plplot_wiki. The instructions in INSTALL are for our deprecated autotools (./configure) build system which is no longer maintained. > And please tell me how to compile fortran source with PLplot libraries ? Make sure you have pkg-config installed on your computer before you run cmake the first time. Then after "make" and "make install" look at $INSTALL_PREFIX/share/plplot5.7.1/examples/f77 (or f95). The Makefiles in those two directories show exactly how to build fortran 77 or fortran 95 executables using the pkg-config approach. 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
On 2006-11-27 12:12+0100 Werner Smekal wrote: > Hi, > >> >> I'm unhappy about requiring python (or anything else non-standard) for >> running the tests. This adds another significant dependency to the build >> process. We're already asking users to install a fair bit. I guess this >> is particularly an issue for windows users. > > Yes, windows user need to spend quite a time to have everything setup. > That's the reason why I thought we should provide a binary package for > Windows with libraries for MinGW and Visual C++ 6.0 (which can be used > for all other Visual C++ as well, I think). Together with the headers > and data files. This is actually all you need for c/c++ development on > Windows. > > Apart from that, it may be the smartest than to write Windows batch > files or jim/tcl files. From the jim website I think it should be no > problem that jim compiles on most compilers - I'll write a cmake file > and test it on various Windows compilers. Hmm... It's interesting how my comment about a parallel windows scripting system for ctest has sparked so much interest. A consensus seems to have formed for building jim/tcl as part of PLplot and making jim scripts with the same functionality as plplot-test.sh and the various test*.sh scripts, but I have two reservations about this solution. 1) It adds parallel maintenance that Werner and Arjen have to apply to the jim scripts any time there is a change to plplot-test.sh and the other test*.sh scripts. This is all fairly trivial stuff (adding new examples, finding better ways to configure the tests), but there is a fair amount of churn, and it will be irritating to keep the two systems in sync. 2) There is also a maintenance burden for jim itself. Werner and Arjen have to keep track of new jim releases, make judgement calls about the stability of those releases, and decide when to deploy them into the PLplot code base. The first of these reservations also applies to all other parallel scripting systems (with python, perl, or whatever) which is why my opinion _now_ is we should reject all of them. I only brought up the idea of parallel scripts originally because I was under the impression no bash solutions were available for windows, but it appears that such solutions exist. In fact, Werner was able to get all but the java ctests passed with the windows bash solution he found, and I doubt a solution is far away in that case. It appears the only downside to the windows bash solution is our windows developers and users will need to independently install bash if they want to use ctest and/or the install-tree plplot-test.sh tests. I doubt installing a windows bash is going to be a difficult burden for Arjen or any other windows developer that wants to contribute to PLplot since Werner has already been successful at this, and almost by definition our developers are good at installing PLplot dependencies. That leaves only the question of our users. To make life easier for them, I think we should put together a test to look for bash. If that test fails we should give the appropriate warning message, force BUILD_TEST to OFF, and not configure or install plplot-test.sh and the test*.sh scripts. Also, Werner should expand our wiki a bit more giving a reference to windows bash and perhaps a sentence or two about how to install it if that is not obvious. With those changes it should be straightforward for our windows users to install bash, but if they choose not to do so, all that will happen is they will receive a CMake warning and the ctest functionality will be missing and install tree tests not available. So it will be exactly like any other component of PLplot. If you want a particular PLplot component you have to pay the price of installing the relevant software. In sum, I have given my reasons why I prefer a uniform bash solution for all platforms (especially since it apparently already works on bare windows except for one minor Java issue). However, if the windows developers still prefer the jim/tcl alternative (and are willing to develop it and more importantly maintain it), I will go along since windows developers know a lot more about windows than 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business top
Re: [Plplot-devel] How to use the installed PLplot libraries
hiroyasu yasuda wrote: > Hello Arjen: > >>> - Are you using the latest release (PLplot 5.7.1) or version 5.6.1? >> > > I was using PLplot 5.7.0. yesterday. > > >>> - Are you using the ./configure script to build the libraries or >>> are you >>> using the CMake build system? >> > > I followed 'INSTALL' document below: > >> 3) With g95: [Fortran 95 (GCC) 4.2.0 20060512 (experimental)] >> ./configure --disable-wxwidgets --enable-f95 FC=gfortran F77=gfortran >> make FFLAGS="-Wl,-single_module" FCFLAGS="-Wl,-single_module" >> make install >> make check > > > > When I tried 'make install' and 'make check' last week, their command > returned some 'Error'. But I tried installation using 'sudo' > yesterday, did > not return Error message. Is my PLplot libraries on OSX OK? Hm, that sound sas if you do not have sufficient permissions to install files in the default directory. > > And please tell me how to compile fortran source with PLplot libraries ? You could try the following: - Copy, say, x01f.f90 to a separate directory - Then compile it and link it like this: gfortran -o example x01f.f90 -I/directory/with/modules -L/directory/with/libraries -lplplotf95d -lplplotf95cd -lplplotd (Or: gfortran -o examples x01f.f90 `pkg-config --cflags --libs plplot-f95 but I am not sure that already works properly) Regards, Arjen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] How to use the installed PLplot libraries
Hello Arjen: >> - Are you using the latest release (PLplot 5.7.1) or version 5.6.1? I was using PLplot 5.7.0. yesterday. >> - Are you using the ./configure script to build the libraries or >> are you >> using the CMake build system? I followed 'INSTALL' document below: > 3) With g95: [Fortran 95 (GCC) 4.2.0 20060512 (experimental)] > ./configure --disable-wxwidgets --enable-f95 FC=gfortran F77=gfortran > make FFLAGS="-Wl,-single_module" FCFLAGS="-Wl,-single_module" > make install > make check When I tried 'make install' and 'make check' last week, their command returned some 'Error'. But I tried installation using 'sudo' yesterday, did not return Error message. Is my PLplot libraries on OSX OK? And please tell me how to compile fortran source with PLplot libraries ? Regards, Hiroyasu. On 2006/11/27, at 17:12, Arjen Markus wrote: > Hiroyasu Yasuda wrote: > >> Hi all; >> I'm beginner of Unix system on Mac OSX. I really want to use >> PLplot libraries. >> >> I read 'INSTALL' and then I conducted installation procedures. I >> think probably installation of the libraries was succeeded. >> Because 'Make check' did not return error message, the libraries >> files were copied in /usr/local/, and compiled execute files >> existed. >> >> I have two primitive questions. >> 1) How to check the success of installation ? >> 2) How to use the installed PLplot libraries with gfort ? >> I could find some builded file in /usr/local/lib/*.dylib. Which do >> I use lib files ? And how to compile with the libraies file and >> gfort fortran ? >> Thank you very much, >> with best wishes. >> >> >> > Hello, > > I would like to ask you a few questions first: > - Are you using the latest release (PLplot 5.7.1) or version 5.6.1? > - Are you using the ./configure script to build the libraries or > are you > using the CMake build system? > > This matters as far as several details are concerned. > > However, the general procedure is: > > (Autotools, PLplot version 5.6.1 and 5.7.1): > ./configure --with-prefix=/my/own/install/dir > make > make install > > (CMake, PLplot 5.7.1, build in a different directory than the source): > cd /my/own/install/dir > cmake /my/source/dir > make > make install > > During the make phase, the system will produce a lot of messages, but > to check if it was successful, just look at the last few. Similarly > for the > make install part. > > Try running the examples first to make sure everything was successful. > > As I have no access to OSX, I can not help out with the details for > that platform, but this is the general idea. > > Regards, > > Arjen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
Hi, > > I'm unhappy about requiring python (or anything else non-standard) for > running the tests. This adds another significant dependency to the build > process. We're already asking users to install a fair bit. I guess this > is particularly an issue for windows users. Yes, windows user need to spend quite a time to have everything setup. That's the reason why I thought we should provide a binary package for Windows with libraries for MinGW and Visual C++ 6.0 (which can be used for all other Visual C++ as well, I think). Together with the headers and data files. This is actually all you need for c/c++ development on Windows. Apart from that, it may be the smartest than to write Windows batch files or jim/tcl files. From the jim website I think it should be no problem that jim compiles on most compilers - I'll write a cmake file and test it on various Windows compilers. Regards, Werner > > Andrew > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: [EMAIL PROTECTED] web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
Andrew Ross wrote: >I'm unhappy about requiring python (or anything else non-standard) for >running the tests. This adds another significant dependency to the build >process. We're already asking users to install a fair bit. I guess this >is particularly an issue for windows users. > > > Which is why I would like to experiment with Jim. It is small enough to be part of the PLplot distribution, it in fact already is, and it can be built as just another component of PLplot for those platforms that require it. Regards, Arjen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
On Mon, Nov 27, 2006 at 10:59:56AM +0100, Werner Smekal wrote: > Hi, > > > Sorry to pop in at the end of this discussion. When I first implemented > > the ctest stuff I wondered about doing away with the scripts and doing > > all the work in ctest. > > Actually using only ctest would be a good idea, especially if we ever > use dashboard. Maybe we should investigate this more thoroughly. > > > > Advantages: > > Should be more platform independent. > > You would be able to see at a glance precisely which tests failed rather > > than just knowing one of the tests for a given language failed. > > > > Disadvantages: > > More work for me in the first instance. > > We want the scripts anyway for installing in the examples tree so users > > can test the examples easily. > > Especially the test for the user is an important point on the other hand. > > > > The scripts are not terribly sophisticated on the whole. The most > > important requirement is just to set the right paths for libraries etc. > > Perhaps a batch file will do. At least we know that will run on every > > windows system then. > > I also think it's no problem to write a windows batch file. The CLI is > actually quite capable ( > http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=true > > ), but it's not bash ;). And we would have to maintain two versions of > the test, a unix and a windows one. Using python or jim (which actually > looks very interesting, Arjen) would mean to only maintain one version. > > I actually have no strong opinion here, using win-bash and so on is > definitely the least wanted, since problematic. I'm unhappy about requiring python (or anything else non-standard) for running the tests. This adds another significant dependency to the build process. We're already asking users to install a fair bit. I guess this is particularly an issue for windows users. Andrew - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
Hi, > Sorry to pop in at the end of this discussion. When I first implemented > the ctest stuff I wondered about doing away with the scripts and doing > all the work in ctest. Actually using only ctest would be a good idea, especially if we ever use dashboard. > > Advantages: > Should be more platform independent. > You would be able to see at a glance precisely which tests failed rather > than just knowing one of the tests for a given language failed. > > Disadvantages: > More work for me in the first instance. > We want the scripts anyway for installing in the examples tree so users > can test the examples easily. Especially the test for the user is an important point on the other hand. > > The scripts are not terribly sophisticated on the whole. The most > important requirement is just to set the right paths for libraries etc. > Perhaps a batch file will do. At least we know that will run on every > windows system then. I also think it's no problem to write a windows batch file. The CLI is actually quite capable ( http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=true ), but it's not bash ;). And we would have to maintain two versions of the test, a unix and a windows one. Using python or jim (which actually looks very interesting, Arjen) would mean to only maintain one version. I actually have no strong opinion here, using win-bash and so on is definitely the least wanted, since problematic. Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: [EMAIL PROTECTED] web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
On Mon, Nov 27, 2006 at 09:15:22AM +0100, Arjen Markus wrote: > Werner Smekal wrote: > > > > >So, long story short, ctest works now, with small problems though. I > >wasn't actually successful running the plplot-test.sh script in the > >examples folder of the install directory (share/plplot-5.7.1), but this > >would need also minor tweaking. > > > >Arjen, would you willing to also try to install this to make ctest work? > > > > > > > Yes, I will look into this part. Pity about the possibility of running > shell scripts under > Windows, but such is life. Sorry to pop in at the end of this discussion. When I first implemented the ctest stuff I wondered about doing away with the scripts and doing all the work in ctest. Advantages: Should be more platform independent. You would be able to see at a glance precisely which tests failed rather than just knowing one of the tests for a given language failed. Disadvantages: More work for me in the first instance. We want the scripts anyway for installing in the examples tree so users can test the examples easily. The scripts are not terribly sophisticated on the whole. The most important requirement is just to set the right paths for libraries etc. Perhaps a batch file will do. At least we know that will run on every windows system then. Andrew - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] new wxwidgets driver
Hi Hazen, > /Users/hbabcock/Documents/OpenSource/PLplot/plplot-cvs/drivers/ > wxwidgets.cpp: In function 'void plD_init_wxwidgets(PLStream*)': > /Users/hbabcock/Documents/OpenSource/PLplot/plplot-cvs/drivers/ > wxwidgets.cpp:499: error: 'antialized' was not declared in this scope > /Users/hbabcock/Documents/OpenSource/PLplot/plplot-cvs/drivers/ > wxwidgets.cpp:500: error: 'smooth_text' was not declared in this scope > /Users/hbabcock/Documents/OpenSource/PLplot/plplot-cvs/drivers/ > wxwidgets.cpp:501: error: 'freetype' was not declared in this scope > make[2]: *** [drivers/CMakeFiles/wxwidgets.dir/wxwidgets.o] Error 1 > make[1]: *** [drivers/CMakeFiles/wxwidgets.dir/all] Error 2 > make: *** [all] Error 2 thank you very much for the bug report. I forgot to check the driver if freetype is not available. The bug is now fixed in cvs. Could you make another version of plplot 5.7.2? No, just joking :) Thanks for the work on the releases. I hope the wxwigdets driver will now work also in Mac OSX. The wxwidgets driver should be convenient for Mac Users, since for Mac OSX 10.5 the new release of wxwidgets 2.8.0 is already preinstalled. So Mac users don't need to compile and install the wxwidgets library. Please, let me know if the driver works now for you. I have a Mac available, but no time in the moment to test it on the machine here. Thanks, Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: [EMAIL PROTECTED] web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
Hi Arjen, > No, Tcl/Tk is fine without MinGW. I just noticed the condition that we > only set > the output path on Windows, unless we are using Cygwin. I am not sure if > MinGW > handles the rpath option in the same way as Cygwin. If it does, then for > MinGW > we do not need the output path either. Ah, ok, now I get it. MinGW would be fine here, since rpaths doesn't work here either. I should explain this in more detail. There are actually two "versions" of MinGW available for Windows. One provides just the compilers and some tools (make, etc.) which you need, but nothing else (not bash), and it is meant to be used in the Windows Shell/CLI cmd.exe. Here nothing unix like (rpath, etc.) works, it behaves exactly the same as you would use Visual C++ in a Windows Shell. The second version is called msys, and here though the exactly same compiler executables are used on top of that is a port of bash and some other tools (automake, etc.) and you don't use the Windows CLI at all. The second version behaves very much like Unix or Cygwin, e.g. the filenames are /home/user/whatever and not C:\Program Files\firefox. Msys makes it easier to port Unix programs, since you can use the configure and so on. To my knowledge (e.g. from the wxWidgets mailing list) not many Windows people use Msys - most use the MinGW tools in the Windows CLI. The reason is to my opinion, apart from msys being damn slow: because of the very same reason I failed with bash just before. At some point you want to use a Windows executable which accepts only Windows filenames and voila, you are in devils kitchen. So, Arjen, you are right, we need to also take care of MinGW, but only for msys. But since CMake doesn't provide an easy way to distinguish between MinGW in CLI and Mingw in Msys (both have MINGW set to 1) it's not that easy. I recently found out, that we can check which generator is used (cmake uses "MinGW Makefiles" for the MinGW/CLI version and "MSYS Makefiles" for msys), but I didn't test this yet. > > Anyway, that is a territory still left open. Yes, you are right, some work is still to be done here. Thanks, Werner - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PLplot 5.7.1 is now available
On 2006-11-26 22:33-0500 [EMAIL PROTECTED] wrote: > > Hello, > > PLplot 5.7.1 is now available at Sourceforge. This is the first > official (development) version of PLplot using the new cmake build > system. While it can still be built the "old" way (i.e. using > configure) we recommend getting the latest version of cmake (2.4.4) > and using that instead. We hope that Windows user in particular will > have a much easier time installing PLplot. Other changes include (1) > Modifying PLplot core to buffer plot commands in memory rather than > via a unix pipe/temporary file for increased speed (2) Numerous > improvements to the wxWidgets driver and (3) The addition of a new > driver that creates scalable vector graphics files (SVG). > Note, complete instructions for the new CMake Build System (CBS) for PLplot are given at http://www.miscdebris.net/plplot_wiki/. This new build system is much easier for PLplot developers to understand, maintain, and extend. For both PLplot users and developers our new build system gives more complete windows builds than our previous (in sys/win32/msdev) home-grown windows build system, gives excellent results on Linux and Mac OS X, and gives faster builds than our previous autotools build system (./configure ). Since nobody wants to maintain the autotools build system any more it is now officially deprecated. We will probably (see Arjen's previous post about that) deprecate the home-grown windows build system as well. Therefore, we urge all PLplot users to start using our new CBS to build PLplot. Your platform coverage is much more varied than what the developers have access to so your feedback will 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
Werner Smekal wrote: > > As written before, it is possible, but with problems. With Vista also > a new powershell was developed also for windows xp, but I don't want > to learn another syntax - and as you said not nearly compatible to > unix scripts but super powerful with objects and classes > I am not looking forward to learning yet another such language either. And Windows Vista may be just over the horizon, it is not a common platform as yet, so we should not target it. >> I would opt for Tcl :). Or Jim, a very lean implementation of Tcl, >> which I used >> already for the old build system. This is lean enough to distribute >> along with the >> PLplot source, so that would make testing independent of the presence >> of Python, >> Perl or Tcl or whatever on the system. > > > Tcl is also not commonly used in the Windows world, I think, but if > jim is distributed with the plplot source and compiles with most of > the compilers used, this should also be okay, I think. I will see what can be done here. The source code for Jim is very clean, so that should be no problem. Perhaps we can simply revert to DOS batch files, but that is something I need to look into. Anyway, it would be great to unify this aspect of PLplot too. Regards, Arjen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
Werner Smekal wrote: > >> - I get a failure for the Tcl examples, but I have not been able yet >> to trace what is >> causing it (did not have the time). I will look into this ASAP. > > > You said in former emails, that you need the plserver.exe or so, and > this exe files are not in the path, since only the libs are copied > into the dll directory. No, that is (I think) with the Tk device. > We could also set the EXE_OUTPUT_PATH or so, but than all exe files > would be copied into the directory, also all examples, and this would > make the dll folder a little bit crowded, not structured and ctest > wouldn't work anymore I think. Because of that I did not change this, > but if you think it is necessary we could try it. I would not go for that: it would mean all examples will be put there as well :( > >> - We may need to include MinGW somehow in the condition, but I am not >> sure how ... > > > Why, do you think you need MinGW, when you use Visual C++ 6.0? Is > TCL/TK depending somehow on MinGW? > No, Tcl/Tk is fine without MinGW. I just noticed the condition that we only set the output path on Windows, unless we are using Cygwin. I am not sure if MinGW handles the rpath option in the same way as Cygwin. If it does, then for MinGW we do not need the output path either. Anyway, that is a territory still left open. Regards, Arjen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
Hi Arjen, > They won't. Windows uses DOS batchfiles and I know there is a command > language > slightly more powerful than that, which I have never used, but it is > completely > incompatible with UNIX shell scripts. As written before, it is possible, but with problems. With Vista also a new powershell was developed also for windows xp, but I don't want to learn another syntax - and as you said not nearly compatible to unix scripts but super powerful with objects and classes > I would opt for Tcl :). Or Jim, a very lean implementation of Tcl, which > I used > already for the old build system. This is lean enough to distribute > along with the > PLplot source, so that would make testing independent of the presence of > Python, > Perl or Tcl or whatever on the system. Tcl is also not commonly used in the Windows world, I think, but if jim is distributed with the plplot source and compiles with most of the compilers used, this should also be okay, I think. Regards, Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: [EMAIL PROTECTED] web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
Werner Smekal wrote: > >So, long story short, ctest works now, with small problems though. I >wasn't actually successful running the plplot-test.sh script in the >examples folder of the install directory (share/plplot-5.7.1), but this >would need also minor tweaking. > >Arjen, would you willing to also try to install this to make ctest work? > > > Yes, I will look into this part. Pity about the possibility of running shell scripts under Windows, but such is life. Regards, Arjen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
Hi Arjen, > Hi Werner, > > I checked your changes using bare Windows (MSVC 6.0 and ordinary makefiles > but that should not really matter): > - It works for C and Fortran 95 - all relevant DLLs are stored in the > dll subdirectory and > by expanding the PATH, the examples work fine. > - The directory I have to set PLPLOT_LIB to is the one in the _source_ > tree - we need > to install/copy the font files to a "data" subdirectory in the > build/install tree Yes, sorry, I wrote >> set PLPLOT_LIB=path_to_plplot_dir\data and I meant path_to_plplot_dir should be the plplot source dir and not the build dir. Since the data is not changing with the build this maybe not necessary, so you just could set the PLPLOT_LIB variable to the data directory of the source dir. "make install" than copies the files anyway into the install directory correctly. > - I get a failure for the Tcl examples, but I have not been able yet to > trace what is > causing it (did not have the time). I will look into this ASAP. You said in former emails, that you need the plserver.exe or so, and this exe files are not in the path, since only the libs are copied into the dll directory. We could also set the EXE_OUTPUT_PATH or so, but than all exe files would be copied into the directory, also all examples, and this would make the dll folder a little bit crowded, not structured and ctest wouldn't work anymore I think. Because of that I did not change this, but if you think it is necessary we could try it. > - We may need to include MinGW somehow in the condition, but I am not > sure how ... Why, do you think you need MinGW, when you use Visual C++ 6.0? Is TCL/TK depending somehow on MinGW? > Anyway: this is a big step forward. Cool, Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: [EMAIL PROTECTED] web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] How to use the installed PLplot libraries
Hiroyasu Yasuda wrote: >Hi all; > >I'm beginner of Unix system on Mac OSX. I really want to use >PLplot libraries. > >I read 'INSTALL' and then I conducted installation >procedures. I think probably installation of the libraries >was succeeded. Because 'Make check' did not return error >message, the libraries files were copied in /usr/local/, >and compiled execute files existed. > >I have two primitive questions. > 1) How to check the success of installation ? > 2) How to use the installed PLplot libraries with gfort ? > I could find some builded file in /usr/local/lib/*.dylib. >Which do I use lib files ? And how to compile with the >libraies file and gfort fortran ? > >Thank you very much, >with best wishes. > > > > Hello, I would like to ask you a few questions first: - Are you using the latest release (PLplot 5.7.1) or version 5.6.1? - Are you using the ./configure script to build the libraries or are you using the CMake build system? This matters as far as several details are concerned. However, the general procedure is: (Autotools, PLplot version 5.6.1 and 5.7.1): ./configure --with-prefix=/my/own/install/dir make make install (CMake, PLplot 5.7.1, build in a different directory than the source): cd /my/own/install/dir cmake /my/source/dir make make install During the make phase, the system will produce a lot of messages, but to check if it was successful, just look at the last few. Similarly for the make install part. Try running the examples first to make sure everything was successful. As I have no access to OSX, I can not help out with the details for that platform, but this is the general idea. Regards, Arjen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] convenient windows developing
Hi Alan,
> This build-tree change is a nice first step toward getting ctest working on
> windows. Of course, the problem still remains that the current ctest uses
> the shell scripts plplot-test.sh and test*.sh, and I assume (but correct me
> if I am wrong) those scripts will not work on bare windows.
No, I just was able to make them work. There are some bash-ports
available (apart from cygwin, msys), but the problem here is (also see
below), that you always run into problems sooner or later regarding
filenames and so on. I was always looking for a bash I can use in
Windows, but after a long series of failings, I came to the conclusion,
that it is better to always use the native tools of the OS you are
working on. Anyway, one exception are the GNUWin32 Tools you can find
here: gnuwin32.sf.net . They provide ports of various gnu tools, and
they did a good job, they just work also in the Windows CLI without
problems, and regardless if you use \ or / or whatever. I think for the
test scripts you need at least the core utils and sed (on the gnuwin32
homepage click left packages). Just download the binary package and the
dependency package as zips and unzip them somewhere (e.g. C:\GNUWin32)
and add the path to the environment variable (set
PATH=C:\GNUWin32\bin;%PATH%). But GNUWin32 doesn't provide a bash, so we
need to use win-bash: winbash.sf.net . At least it is a recent port, but
accepts for example only linux style pathnames. Anyway, download
win-bash.exe and copy it into GNUWin32\bin as bash.exe and sh.exe. So
this should do the trick, if another gnu tool is needed get it from
gnuwin32.
If I run now ctest in my plplot build directory it runs the c and c++
test successfully. But the java test fails, because of the same
problems I always failed so far. Bash handles everything like in Linux
and the Gnuwin32 tools except that, but Java expects Windows like syntax
In test_java.sh the important command line is:
java -classpath ${javadir}:${PLPLOT_CLASSPATH} .
The colon between javadir and PLPLOT_CLASSPATH is good for Linux, but
for Windows obviously not (e.g. C:\ :), but if I replace the colon with
a semicolon, which would be windows style, bash chokes up, since this
ends a command or similar (I'm not a bash guru). So, again another
failure to use bash in a Windows environemnt. Sigh. Anyway, I think we
might be able to fix this, but I don't want to change this on my own.
Alan, could you think of a solution here, which would work for Linux and
Windows? Actually I would only need PLPLOT_CLASSPATH since it contains
the full path to plplot.jar.
> I am completely
> unfamiliar with the windows scripting constraints, but if there is no easy
> way to modify those scripts so they will also work on windows, then perhaps
> we should use the equivalent of those scripts in python or perl for the
> windows case? (I mentioned python first because I understand it and don't
> understand perl, but if the windows developers are more familiar with perl,
> that is the scripting language they should probably use.)
In the long run, I think python scripts would be much better. Perl is
not too much used in Windows I think. Python is very easy to install and
is cross platform, so this would be my first option here (though I never
did anything in python). But since I came that far with the bash scripts
and it is kind of easy, and the normal plplot user shouldn't need it
anyway, we should stick with the bash scripts, since this minimizes our
efforts. We just need a little tweaking here and there.
>
> This build-tree enhancement for windows developers is great, and I look
> forward to ctest eventually working for windows as a result, but it leads to
> the question of whether the equivalent of "make install" is supported on
> windows.
Yes, "make install" works, for all "make"s I tested so far (nmake,
wmake, mingw32-make, ...)
> I hope it is since "make install" collects all essential data and
> builds in a convenient and compact way for the user. If the equivalent of
> make install is supported, then you should check whether you have to modify
> all the INSTALL commands for the windows case to be consistent with the new
> build-tree location of libraries or whether cmake automatically knows what
> to do when LIBRARY_OUTPUT_PATH is set.
Cmake knows where it put the dll and exe files, regardless where they
are (if you set the LIBRARY_OUTPUT_PATH), no problems here.
So, long story short, ctest works now, with small problems though. I
wasn't actually successful running the plplot-test.sh script in the
examples folder of the install directory (share/plplot-5.7.1), but this
would need also minor tweaking.
Arjen, would you willing to also try to install this to make ctest work?
Werner
--
Dipl. Ing. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
email: [EMAIL PROTECTED]
web: http://www.iap.tuwien.ac.at
