plplot-general — PLplot user discussion group

Re: [Plplot-general] plplot build error

[winson <roa...@ya...>]

Alan, thank you so much for the explanation.


--- "Alan W. Irwin" <ir...@be...> wrote:

> On 2007-04-06 10:41-0700 winson wrote:
> 
> > With the information from the build log, I have
> > managed to generate file "plhershey-unicode.h" by
> > launching plhershey-unicode.exe with parameters on
> > command-line. Then I copied the file manually to
> the
> > "include" directory. My question now is, is it
> what
> > this perticular build process all about?
> 
> Yes.
> 
> > In other
> > words, will the file "plhershey-unicode.h" affect
> the
> > subsequent build of other files? I looked through
> > other "CMakeLists.txt" files, it seems okay. But I
> am
> > not sure. Thanks.
> 
> The short answer was above, but if you want to
> follow the logic (which is
> actually pretty easy to do if you also look at the
> CMake documentation at
> http://cmake.org/HTML/Documentation.html) the
> relevant section of CMake
> logic is as follows:
> 
> add_executable(plhershey-unicode-gen
> ${plhershey-unicode-gen_SRCS})
> 
> add_custom_command(
> OUTPUT
> ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode.h
> COMMAND
>
${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT}
> ${CMAKE_SOURCE_DIR}/fonts/plhershey-unicode.csv
> plhershey-unicode.h
> DEPENDS
>
${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT}
> ${CMAKE_SOURCE_DIR}/fonts/plhershey-unicode.csv
> )
> 
> # For cross-directory dependencies....
> add_custom_target(
> plhershey-unicode.h_built
> DEPENDS
> ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode.h
> )
> 
> This is the implementation of an important chain of
> dependencies.  The
> custom command depends on the add_executable via the
> DEPENDS
>
${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT}.
>  In turn, the
> custom target depends on the custom command via
> DEPENDS
> ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode.h.
> Furthermore, if you look at
> src/CMakeLists.txt, you will see our core library
> depends on the above
> custom target via the
> 
> add_dependencies(plplot${LIB_TAG}
> plhershey-unicode.h_built)
> 
> command.  Through this chain of dependencies, the
> timing of various builds
> is enforced.
>
${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT}
> always gets built first, then
> ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode.h is
> built, then finally the
> plplot${LIB_TAG} core library is built in the build
> tree.  Also, and just as
> important, no unnecessary builds of
>
${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT},
> ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode.h, or
> the library are done.
> 
> If you are trying to mimic any of this by hand (due
> to some platform
> problem), then be sure to keep the same order and
> place your results in the
> appropriate build-tree subdirectory (which normally
> is separate from the
> corresponding source tree directory).
> 
> 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
> __________________________
> 



 
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news

Re: [Plplot-general] plplot build error

[Alan W. I. <ir...@be...>]

On 2007-04-06 10:41-0700 winson wrote:

> With the information from the build log, I have
> managed to generate file "plhershey-unicode.h" by
> launching plhershey-unicode.exe with parameters on
> command-line. Then I copied the file manually to the
> "include" directory. My question now is, is it what
> this perticular build process all about?

Yes.

> In other
> words, will the file "plhershey-unicode.h" affect the
> subsequent build of other files? I looked through
> other "CMakeLists.txt" files, it seems okay. But I am
> not sure. Thanks.

The short answer was above, but if you want to follow the logic (which is
actually pretty easy to do if you also look at the CMake documentation at
http://cmake.org/HTML/Documentation.html) the relevant section of CMake
logic is as follows:

add_executable(plhershey-unicode-gen ${plhershey-unicode-gen_SRCS})

add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode.h
COMMAND ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT}
${CMAKE_SOURCE_DIR}/fonts/plhershey-unicode.csv
plhershey-unicode.h
DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT}
${CMAKE_SOURCE_DIR}/fonts/plhershey-unicode.csv
)

# For cross-directory dependencies....
add_custom_target(
plhershey-unicode.h_built
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode.h
)

This is the implementation of an important chain of dependencies.  The
custom command depends on the add_executable via the DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT}.  In turn, the
custom target depends on the custom command via DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode.h. Furthermore, if you look at
src/CMakeLists.txt, you will see our core library depends on the above
custom target via the

add_dependencies(plplot${LIB_TAG} plhershey-unicode.h_built)

command.  Through this chain of dependencies, the timing of various builds
is enforced. ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT}
always gets built first, then
${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode.h is built, then finally the
plplot${LIB_TAG} core library is built in the build tree.  Also, and just as
important, no unnecessary builds of
${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT},
${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode.h, or the library are done.

If you are trying to mimic any of this by hand (due to some platform
problem), then be sure to keep the same order and place your results in the
appropriate build-tree subdirectory (which normally is separate from the
corresponding source tree directory).

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
__________________________

Re: [Plplot-general] plplot build error

[winson <roa...@ya...>]

With the information from the build log, I have
managed to generate file "plhershey-unicode.h" by
launching plhershey-unicode.exe with parameters on
command-line. Then I copied the file manually to the
"include" directory. My question now is, is it what
this perticular build process all about? In other
words, will the file "plhershey-unicode.h" affect the
subsequent build of other files? I looked through
other "CMakeLists.txt" files, it seems okay. But I am
not sure. Thanks.

Winson 


--- Werner Smekal <sm...@ia...> wrote:

> Hi,
> 
> could you run "nmake VERBOSE=1" and send the output
> to the list? And do 
> you use the "NMake Makefiles" Generator or are you
> using the project 
> files? The latter was never tested and very likely
> not to work at all.
> 
> Regards,
> Werner
> 
> winson wrote:
> > Hello there,
> >
> > I used VC++ 2005 Express to build plplot library
> from
> > files created by cmake. I got 8 succeeded and 1
> > failed. Error message is as following.
> >
> > Generating plhershey-unicode.h
> > 'plhershey-unicode-gen.exe' is not recognized as
> an
> > internal or external command,
> > operable program or batch file.
> > Project : error PRJ0019: A tool returned an error
> code
> > from "Generating plhershey-unicode.h"
> >
> > The build log is attached. How could I fix it?
> Thanks
> > in advance.
> >
> > Winson    
> >
> > --------------------------------------------------
> > Build Log 
> > Build started: Project: plhershey-unicode.h_built,
> > Configuration: Debug|Win32
> >
> > Command Lines 
> > Creating temporary file
> > "E:\APPLIC~1\Temp\BAT0000512968340.bat" with
> contents
> > [
> > @echo off
> >
> > plhershey-unicode-gen.exe "E:/My
> >
>
Documents/Downloads/plplot-5.7.3/fonts/plhershey-unicode.csv"
> > plhershey-unicode.h
> >
> > if errorlevel 1 goto VCReportError
> >
> > goto VCEnd
> >
> > :VCReportError
> >
> > echo Project : error PRJ0019: A tool returned an
> error
> > code from "Generating plhershey-unicode.h"
> >
> > exit 1
> >
> > :VCEnd
> > ]
> > Creating command line
> > "E:\APPLIC~1\Temp\BAT0000512968340.bat"
> >
> > Output Window 
> > Generating plhershey-unicode.h
> > 'plhershey-unicode-gen.exe' is not recognized as
> an
> > internal or external command,
> > operable program or batch file.
> > Project : error PRJ0019: A tool returned an error
> code
> > from "Generating plhershey-unicode.h"
> >
> > Results 
> > Build log was saved at "file://e:\My
> >
>
Documents\Downloads\plPlot\include\plhershey-unicode.h_built.dir\Debug\BuildLog.htm"
> > plhershey-unicode.h_built - 1 error(s), 0
> warning(s)
____________________________________________________________________________________



 
____________________________________________________________________________________
Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

Re: [Plplot-general] plplot build error

[winson <roa...@ya...>]

Werner,

Thanks for the response. I was using the project files
created by cmake. I did not use "NMake Makefiles". 

I am using VC++ 2005 Express on Windows XP. I was
totally lost with cmake. When I used command-line
version of cmake, just as described on plplot wiki, it
just does not work. It sometimes looks for the free
version of VC++ (VC++ 2003), which I have never
installed. Or sometimes, it looks my system as a 64bit
system which is also wrong. I could not figure out
what the problem is. 

Then I decided to try the GUI-version of cmake. When I
choose building for "NMake Makefiles", it just could
not find "cl" and "rc", even after I have explicitly
selected the cl.exe and rc.exe in options. When I
switch to building for VC++ 2005, it works oddly: When
I clicked on the "config" button the 1st time, it gave
the error message. But when I clicked on "config"
button again, the "Ok" button would be enabled. I
clicked on "OK", and got all the project files for
VC++ 2005. So I compiled these project files with
VC++. The major part of the build seems fine except
the one fail. It seems to me that cmake is problematic
with VC++ 2005.       

I am still confused... Thanks for your help anyway.


Winson

--- Werner Smekal <sm...@ia...> wrote:

> Hi,
> 
> could you run "nmake VERBOSE=1" and send the output
> to the list? And do
> you use the "NMake Makefiles" Generator or are you
> using the project
> files? The latter was never tested and very likely
> not to work at all.
> 
> Regards,
> Werner
> 
> winson wrote:
> > Hello there,
> >
> > I used VC++ 2005 Express to build plplot library
> from
> > files created by cmake. I got 8 succeeded and 1
> > failed. Error message is as following.
> >
> > Generating plhershey-unicode.h
> > 'plhershey-unicode-gen.exe' is not recognized as
> an
> > internal or external command,
> > operable program or batch file.
> > Project : error PRJ0019: A tool returned an error
> code
> > from "Generating plhershey-unicode.h"
> >
> > The build log is attached. How could I fix it?
> Thanks
> > in advance.
> >
> > Winson    
> >
> > --------------------------------------------------
> > Build Log 
> > Build started: Project: plhershey-unicode.h_built,
> > Configuration: Debug|Win32
> >
> > Command Lines 
> > Creating temporary file
> > "E:\APPLIC~1\Temp\BAT0000512968340.bat" with
> contents
> > [
> > @echo off
> >
> > plhershey-unicode-gen.exe "E:/My
> >
>
Documents/Downloads/plplot-5.7.3/fonts/plhershey-unicode.csv"
> > plhershey-unicode.h
> >
> > if errorlevel 1 goto VCReportError
> >
> > goto VCEnd
> >
> > :VCReportError
> >
> > echo Project : error PRJ0019: A tool returned an
> error
> > code from "Generating plhershey-unicode.h"
> >
> > exit 1
> >
> > :VCEnd
> > ]
> > Creating command line
> > "E:\APPLIC~1\Temp\BAT0000512968340.bat"
> >
> > Output Window 
> > Generating plhershey-unicode.h
> > 'plhershey-unicode-gen.exe' is not recognized as
> an
> > internal or external command,
> > operable program or batch file.
> > Project : error PRJ0019: A tool returned an error
> code
> > from "Generating plhershey-unicode.h"
> >
> > Results 
> > Build log was saved at "file://e:\My
> >
>
Documents\Downloads\plPlot\include\plhershey-unicode.h_built.dir\Debug\BuildLog.htm"
> > plhershey-unicode.h_built - 1 error(s), 0
> warning(s)
> >
> >
> >  
> >
>
____________________________________________________________________________________
> > The fish are biting. 
> > Get more visitors on your site using Yahoo! Search
> Marketing.
> >
>
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
> >
> >
>
-------------------------------------------------------------------------
> > 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-general mailing list
> > Plp...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/plplot-general
> >   
> 
> 
> 
>
-------------------------------------------------------------------------
> 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-general mailing list
> Plp...@li...
>
https://lists.sourceforge.net/lists/listinfo/plplot-general
> 




 
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091

Re: [Plplot-general] plplot build error

[Werner S. <sm...@ia...>]

Hi,

could you run "nmake VERBOSE=1" and send the output to the list? And do
you use the "NMake Makefiles" Generator or are you using the project
files? The latter was never tested and very likely not to work at all.

Regards,
Werner

winson wrote:
> Hello there,
>
> I used VC++ 2005 Express to build plplot library from
> files created by cmake. I got 8 succeeded and 1
> failed. Error message is as following.
>
> Generating plhershey-unicode.h
> 'plhershey-unicode-gen.exe' is not recognized as an
> internal or external command,
> operable program or batch file.
> Project : error PRJ0019: A tool returned an error code
> from "Generating plhershey-unicode.h"
>
> The build log is attached. How could I fix it? Thanks
> in advance.
>
> Winson    
>
> --------------------------------------------------
> Build Log 
> Build started: Project: plhershey-unicode.h_built,
> Configuration: Debug|Win32
>
> Command Lines 
> Creating temporary file
> "E:\APPLIC~1\Temp\BAT0000512968340.bat" with contents
> [
> @echo off
>
> plhershey-unicode-gen.exe "E:/My
> Documents/Downloads/plplot-5.7.3/fonts/plhershey-unicode.csv"
> plhershey-unicode.h
>
> if errorlevel 1 goto VCReportError
>
> goto VCEnd
>
> :VCReportError
>
> echo Project : error PRJ0019: A tool returned an error
> code from "Generating plhershey-unicode.h"
>
> exit 1
>
> :VCEnd
> ]
> Creating command line
> "E:\APPLIC~1\Temp\BAT0000512968340.bat"
>
> Output Window 
> Generating plhershey-unicode.h
> 'plhershey-unicode-gen.exe' is not recognized as an
> internal or external command,
> operable program or batch file.
> Project : error PRJ0019: A tool returned an error code
> from "Generating plhershey-unicode.h"
>
> Results 
> Build log was saved at "file://e:\My
> Documents\Downloads\plPlot\include\plhershey-unicode.h_built.dir\Debug\BuildLog.htm"
> plhershey-unicode.h_built - 1 error(s), 0 warning(s)
>
>
>  
> ____________________________________________________________________________________
> The fish are biting. 
> Get more visitors on your site using Yahoo! Search Marketing.
> http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
>
> -------------------------------------------------------------------------
> 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-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>   

[Plplot-general] plplot build error

[winson <roa...@ya...>]

Hello there,

I used VC++ 2005 Express to build plplot library from
files created by cmake. I got 8 succeeded and 1
failed. Error message is as following.

Generating plhershey-unicode.h
'plhershey-unicode-gen.exe' is not recognized as an
internal or external command,
operable program or batch file.
Project : error PRJ0019: A tool returned an error code
from "Generating plhershey-unicode.h"

The build log is attached. How could I fix it? Thanks
in advance.

Winson    

--------------------------------------------------
Build Log 
Build started: Project: plhershey-unicode.h_built,
Configuration: Debug|Win32

Command Lines 
Creating temporary file
"E:\APPLIC~1\Temp\BAT0000512968340.bat" with contents
[
@echo off

plhershey-unicode-gen.exe "E:/My
Documents/Downloads/plplot-5.7.3/fonts/plhershey-unicode.csv"
plhershey-unicode.h

if errorlevel 1 goto VCReportError

goto VCEnd

:VCReportError

echo Project : error PRJ0019: A tool returned an error
code from "Generating plhershey-unicode.h"

exit 1

:VCEnd
]
Creating command line
"E:\APPLIC~1\Temp\BAT0000512968340.bat"

Output Window 
Generating plhershey-unicode.h
'plhershey-unicode-gen.exe' is not recognized as an
internal or external command,
operable program or batch file.
Project : error PRJ0019: A tool returned an error code
from "Generating plhershey-unicode.h"

Results 
Build log was saved at "file://e:\My
Documents\Downloads\plPlot\include\plhershey-unicode.h_built.dir\Debug\BuildLog.htm"
plhershey-unicode.h_built - 1 error(s), 0 warning(s)


 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

Re: [Plplot-general] PLplot has switched to Subversion

[Alan W. I. <ir...@be...>]

On 2007-03-30 11:59+0200 Arjen Markus wrote:

> Alan,
>
> what version of SVN should we use? I have had some issues with an installed
> version in a completely unrelated project - it claimed that the
> repository was made
> by a newer version of SVN, and I had to use other means to get access.

That question is answered in part if you follow links from
http://sourceforge.net/svn/?group_id=2915 to http://sourceforge.net/docs/E09
to http://sourceforge.net/docs/B01/en/svn_client#svn_client.  Those links
all have useful information.  The last link mentions "TortoiseSVN 1.2.6 and
above, for Microsoft Windows", and "The official SVN client, included in
most Linux and BSD distributions; available for Linux, BSD, Mac OS X, and
Windows."

My Linux experience is even as old a Linux client as that available on
Debian stable works fine for our SF repository accessed with the https://
method.  Apparently, there are important differences in subversion
repository format between the various subversion versions. However, there is
an apache subversion module that understands all these different repository
formats which makes it a seamless experience for users like me with an old
svn client version when they access the SF repository with the the https://
method.

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
__________________________

Re: [Plplot-general] PLplot has switched to Subversion

[Arjen M. <arj...@wl...>]

Alan W. Irwin wrote:

>I am happy to announce I just got the job completed of converting our
>SF repository to Subversion.
>
>The goal of the Subversion project is "to build a version control system
>that is a compelling replacement for CVS in the open source community."
>Because the argument for Subversion over CVS is now so compelling, and
>because SourceForge supports Subversion, the PLplot core developers have had
>the conversion of our SourceForge repository from CVS to Subversion on our
>minds for the last couple of years or so.  But it was a big, complicated
>job (especially the checking) so its only recently that we decided to
>go ahead with this conversion.
>
>
>
>What does SVN mean to the ordinary PLplot user who wants to try out our
>lastest software?  Well, first, follow the directions at
>http://sourceforge.net/svn/?group_id=2915.  When setting up our svn
>repository I have followed the common and recommended SVN practice of
>organizing the repository at the top-level into the TTB (trunk, tags, and
>branches) top-level directories. Thus, pay special attention to the warning
>at the above URL about checking out just the trunk.  (If you check out from
>one directory level above trunk, then you will get trunk, tags, and
>branches, and the latter two have the source code of _all_ the tags and
>branches, and therefore will consume a lot of your bandwidth and disk
>space.)
>  
>
For Windows users:
There is a very convenient subversion client available:
    tortoisesvn - http://www.tortoisesvn.net
It works via the Windows Explorer and similar programs

Alan,

what version of SVN should we use? I have had some issues with an installed
version in a completely unrelated project - it claimed that the 
repository was made
by a newer version of SVN, and I had to use other means to get access.

Regards,

Arjen

[Plplot-general] PLplot has switched to Subversion

[Alan W. I. <ir...@be...>]

I am happy to announce I just got the job completed of converting our
SF repository to Subversion.

The goal of the Subversion project is "to build a version control system
that is a compelling replacement for CVS in the open source community."
Because the argument for Subversion over CVS is now so compelling, and
because SourceForge supports Subversion, the PLplot core developers have had
the conversion of our SourceForge repository from CVS to Subversion on our
minds for the last couple of years or so.  But it was a big, complicated
job (especially the checking) so its only recently that we decided to
go ahead with this conversion.

The heart of the procedure I used for the conversion was the cvs2svn script.
That script allowed me to preserve all the PLplot history (all commits
including the associated commit message, tags, and branches going back to
May 1992 (!) when Geoffrey Furnish made the first CVS checkin for PLplot).
The rest of my work has consisted of doing a whole bunch of sanity checks
for the trunk (used for principal development), tags (used for snapshots
that are often released), and branches (used for experimental development
that is kept separate from the trunk).  These sanity checks consisted of
comparing CVS and SVN files for the HEAD of trunk, various tags, and various
branches.  Also, I made comparisons of complete ChangeLogs for the trunk and
the various branches.  The cvs2svn script clobbers binary files unless they
are properly identified under CVS and the diffs showed those binary file
differences quite spectacularly.  So there were quite a few iterations to
complete to get that right, but ultimately I was satisfied with the results.

What does SVN mean to the ordinary PLplot user who wants to try out our
lastest software?  Well, first, follow the directions at
http://sourceforge.net/svn/?group_id=2915.  When setting up our svn
repository I have followed the common and recommended SVN practice of
organizing the repository at the top-level into the TTB (trunk, tags, and
branches) top-level directories. Thus, pay special attention to the warning
at the above URL about checking out just the trunk.  (If you check out from
one directory level above trunk, then you will get trunk, tags, and
branches, and the latter two have the source code of _all_ the tags and
branches, and therefore will consume a lot of your bandwidth and disk
space.)

If you want to go beyond the simple instructions at the above URL, I can
highly recommend the subversion documentation you get with (a) the "svn
help" command and (b) the "Version Control with Subversion".  That book can
be freely downloaded from http://svnbook.red-bean.com.  An appendix of that
book gives a useful summary of svn from the CVS user's perspective, but
there are many other worthwhile areas of it to read as well from an svn
user's perspective.

Happy Subversioning with PLplot!

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
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-general] 5.7.3 Release

[Hazen B. <hba...@ma...>]

Hello,

PLplot 5.7.3 is now available at SourceForge. Highlights include  
updated documentation of the API, wxWidgets application bindings, ADA  
language bindings, the return of the LaTeX driver and two new  
functions for drawing text on 3D plots.

As always, (1) Please refer to our wiki for the latest build and  
install instructions (http://www.miscdebris.net/plplot_wiki/index.php? 
title=Main_Page) and (2) Let us know of any problems / bugs that you  
run across while installing / using PLplot.

best,
-Hazen

Re: [Plplot-general] PLplot installation problem with VC++ 2005 Express

[Werner S. <sm...@ia...>]

Hi,

Cmake is looking for/finding the free VC compiler, but VC++ 2005 Express 
is not this free compiler (which was the VC++2003 command line tools, 
which are not available any more). So my guess is, that you have 
installed this free command line tools in the past and maybe they are 
still installed or during deinstallation not all traces in the registry 
were removed. If you have installed them, please deinstall them or make 
them invisible by

* looking for and removing traces in the registry
* check if the PATH environment variable is still pointing to the VC++ 
2003 tools

Apart from that, you may have sdk nor setup up correctly. I normally 
have no global variables set, I use a batch file which I run when i call 
cmd.exe, which looks like this:

set CMAKEDIR=%ROOTDIR%\cmake-2.4.6-win32-x86
set PATH=C:\Programme\Microsoft Platform SDK\Bin;%CMAKEDIR%\bin;;%PATH%
set INCLUDE=C:\Programme\Microsoft Platform SDK\Include;%INCLUDE%
set LIB=C:\Programme\Microsoft Platform SDK\Lib;%LIB%

rem run setup for Visual C++ 2005 compiler
"%VS80COMNTOOLS%vsvars32.bat"

HTH,
Werner

winson wrote:
> I am using VC++ 2005 Express. I have installed PSDK
> for Windows Server 2003 R2 and wxWidget 2.8.2. I
> downloaded cmake 2.4.6 and PLplot5.7.2. I followed the
> steps described on PLplot wiki to install PLplot. I
> got the following error message.
>
> ------------------------------------------
> Determining if this is a free VC compiler failed with
> the following output:
> CMakeTestForFreeVC.cxx
> D:\Program Files\CMake
> 2.4\share\cmake-2.4\Modules\CMakeTestForFreeVC.cxx(1)
> : fatal error C1034: iostream: no include path set
>
> Determining if the C compiler works failed with the
> following output:
> 	"D:\Program Files\Microsoft Visual Studio
> 8\VC\bin\nmake.exe" -f
> CMakeFiles\cmTryCompileExec.dir/build.make /nologo -L 
>                 CMakeFiles\cmTryCompileExec.dir\build
>
> 	"D:\Program Files\CMake 2.4\bin\cmake.exe" -E
> cmake_progress_report
> D:\plplot-5.7.2\buildnmake\CMakeFiles\CMakeTmp\CMakeFiles
> 1
>
> Building C object
> CMakeFiles/cmTryCompileExec.dir/testCCompiler.obj
>
> 	D:\PROGRA~1\MICROS~2\VC\bin\cl.exe 
> @E:\APPLIC~1\Temp\nm1C0.tmp
>
> testCCompiler.c
>
> D:\plplot-5.7.2\buildnmake\CMakeFiles\CMakeTmp\testCCompiler.c(4)
> : fatal error C1034: stdio.h: no include path set
>
> NMAKE : fatal error U1077:
> 'D:\PROGRA~1\MICROS~2\VC\bin\cl.exe' : return code
> '0x2'
>
> Stop.
>
> NMAKE : fatal error U1077: '"D:\Program
> Files\Microsoft Visual Studio 8\VC\bin\nmake.exe"' :
> return code '0x2'
>
> Stop.
> ----------------------------------------
>
> It seems that the include path of stdio.h is missing.
> However, when I launched VC++ and wrote a testing C++
> program with stdio.h included, I got no problem at
> compilation at all. This indicates that VC++ setting
> is fine. I also tested putting the 'include' path in
> system environment setting, but that does not help
> either. Any idea on what could be the cause of the
> problem?
>
> I am thinking that maybe I can put source files into
> VC++, and compile the library directly with VC++
> instead of cmake. However, I had little experience
> with library building. Could anyone give me a rough
> procedure on how to do it? I appreciate any help.
>
> Regards,
>
> Winson Mao
>
>
>
>
>  
> ____________________________________________________________________________________
> Need Mail bonding?
> Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
> http://answers.yahoo.com/dir/?link=list&sid=396546091
>
> -------------------------------------------------------------------------
> 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-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>   

[Plplot-general] PLplot installation problem with VC++ 2005 Express

[winson <roa...@ya...>]

I am using VC++ 2005 Express. I have installed PSDK
for Windows Server 2003 R2 and wxWidget 2.8.2. I
downloaded cmake 2.4.6 and PLplot5.7.2. I followed the
steps described on PLplot wiki to install PLplot. I
got the following error message.

------------------------------------------
Determining if this is a free VC compiler failed with
the following output:
CMakeTestForFreeVC.cxx
D:\Program Files\CMake
2.4\share\cmake-2.4\Modules\CMakeTestForFreeVC.cxx(1)
: fatal error C1034: iostream: no include path set

Determining if the C compiler works failed with the
following output:
	"D:\Program Files\Microsoft Visual Studio
8\VC\bin\nmake.exe" -f
CMakeFiles\cmTryCompileExec.dir/build.make /nologo -L 
                CMakeFiles\cmTryCompileExec.dir\build

	"D:\Program Files\CMake 2.4\bin\cmake.exe" -E
cmake_progress_report
D:\plplot-5.7.2\buildnmake\CMakeFiles\CMakeTmp\CMakeFiles
1

Building C object
CMakeFiles/cmTryCompileExec.dir/testCCompiler.obj

	D:\PROGRA~1\MICROS~2\VC\bin\cl.exe 
@E:\APPLIC~1\Temp\nm1C0.tmp

testCCompiler.c

D:\plplot-5.7.2\buildnmake\CMakeFiles\CMakeTmp\testCCompiler.c(4)
: fatal error C1034: stdio.h: no include path set

NMAKE : fatal error U1077:
'D:\PROGRA~1\MICROS~2\VC\bin\cl.exe' : return code
'0x2'

Stop.

NMAKE : fatal error U1077: '"D:\Program
Files\Microsoft Visual Studio 8\VC\bin\nmake.exe"' :
return code '0x2'

Stop.
----------------------------------------

It seems that the include path of stdio.h is missing.
However, when I launched VC++ and wrote a testing C++
program with stdio.h included, I got no problem at
compilation at all. This indicates that VC++ setting
is fine. I also tested putting the 'include' path in
system environment setting, but that does not help
either. Any idea on what could be the cause of the
problem?

I am thinking that maybe I can put source files into
VC++, and compile the library directly with VC++
instead of cmake. However, I had little experience
with library building. Could anyone give me a rough
procedure on how to do it? I appreciate any help.

Regards,

Winson Mao




 
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091

Re: [Plplot-general] Window resize with gnome driver

[<hba...@ma...>]

On Mar 7, 2007, at 9:34 PM, James Frye wrote:

> Hi,
>
> I want to use plplot to draw plots within a gtk user interface.   
> When I
> run the examples (C language version) with the gnome driver,  
> however, the
> plots remain a fixed size when the window size is changed.  That  
> is, if I
> start with a plot that just fills the window, and enlarge that  
> window, the
> plot doesn't change, but just gets a larger border around it.  I can't
> find anything in the manual or mailing list archives that seems to  
> relate
> to this problem.  Is there a way to fix it?
>
> Another option would be to use the xwin driver, and use reparenting  
> to get
> the contents into a GTK widget, but I don't see any sort of  
> mechanism for
> user feedback.

I'm not so familiar with the gnome driver, but my guess is that it is  
up to you to detect that the window size has changed and redraw the  
plot.

> What I want to do is display a large set of data, and allow the  
> user to
> zoom in on areas of interest by clicking on the plot.  Have I missed
> seeing an example that shows how to do this?

There is a function for getting the location of mouse clicks called  
plGetCursor. Unfortunately it doesn't seem to be in the  
documentation, but it is used in example1 (examples/x/x01.c).

-Hazen

Re: [Plplot-general] How to remove an old version

[Jerry <lan...@qw...>]

Yeehaw! That fixes my problem. Thanks, Alan.
Jerry

On Mar 7, 2007, at 8:30 PM, Alan W. Irwin wrote:

> On 2007-03-07 18:36-0700 Jerry wrote:
>
>> I actually thought I did the right thing when I installed 5.7.2. But
>> for a sanity check I just re-did everything from scratch with the
>> same results.
>>
>> I made a new directory at /usr/local/plplot_run_ccmake_from_here and
>> cd-ed to it and ran ccmake from there. From ccmake, I specified
>> CMAKE_INSTALL_PREFIX to be /usr/local/plplot-5.7.2.
>
> Sorry about this problem which by coincidence also came up today  
> for libLASi
> (which has a similar install location system).  I have just made a  
> change
> for both projects so this bad human-engineering issue should be  
> eliminated.
>
> The short story is if you start with a clean source tree and  
> initially empty
> (separate) build tree (so no stale files from previous builds are  
> hanging
> around) then cmake or ccmake with the command-line option
> -DCMAKE_INSTALL_PREFIX=whatever always works fine.  However,  
> inconsistencies
> in install locations can occur, if you have a stale cache hanging  
> around or
> if you do not specify the -DCMAKE_INSTALL_PREFIX option when invoking
> ccmake, and you attempt to change CMAKE_INSTALL_PREFIX from the  
> ccmake GUI
> instead.
>
> What happens internally is that the value of CMAKE_INSTALL_PREFIX  
> is cached
> and its also taken as the _default_ value of the install prefix for  
> every
> other install location variable before they are cached as well.   
> Once they
> are cached, then ccmake gives you the opportunity to change them to
> something else, but if you don't specify the -DCMAKE_INSTALL_PREFIX  
> option
> for the ccmake command, then the cached values will all refer to / 
> usr/local,
> and will _all_ have to be changed consistently by the user.
>
> Now we get to the bad human engineering part.  Before I used
> MARK_AS_ADVANCED for all those generated install locations.  Thus,  
> they were
> by default (unless they hit the t option) hidden from ccmake users  
> so they
> could not see when they were inconsistent with what they wanted.   
> So that
> was a nasty trap inadvertently set for the user.  With  
> MARK_AS_ADVANCED
> removed, they are now diplayed in all circumstances, and the users  
> therefore
> have a chance to specify the desired install locations. And, of  
> course, if
> they ever get tired of doing that, they can also avoid the problem
> altogether by specifying the -DCMAKE_INSTALL_PREFIX option for the  
> ccmake
> command.
>
> Sorry, Jerry, you were caught by this (inadvertent) trap, but I  
> hope it is
> all straightened out for you now.
>
> Alan
> __________________________
> Alan W. Irwin

Re: [Plplot-general] How to remove an old version

[Alan W. I. <ir...@be...>]

On 2007-03-07 18:36-0700 Jerry wrote:

> I actually thought I did the right thing when I installed 5.7.2. But
> for a sanity check I just re-did everything from scratch with the
> same results.
>
> I made a new directory at /usr/local/plplot_run_ccmake_from_here and
> cd-ed to it and ran ccmake from there. From ccmake, I specified
> CMAKE_INSTALL_PREFIX to be /usr/local/plplot-5.7.2.

Sorry about this problem which by coincidence also came up today for libLASi
(which has a similar install location system).  I have just made a change
for both projects so this bad human-engineering issue should be eliminated.

The short story is if you start with a clean source tree and initially empty
(separate) build tree (so no stale files from previous builds are hanging
around) then cmake or ccmake with the command-line option
-DCMAKE_INSTALL_PREFIX=whatever always works fine.  However, inconsistencies
in install locations can occur, if you have a stale cache hanging around or
if you do not specify the -DCMAKE_INSTALL_PREFIX option when invoking
ccmake, and you attempt to change CMAKE_INSTALL_PREFIX from the ccmake GUI
instead.

What happens internally is that the value of CMAKE_INSTALL_PREFIX is cached
and its also taken as the _default_ value of the install prefix for every
other install location variable before they are cached as well.  Once they
are cached, then ccmake gives you the opportunity to change them to
something else, but if you don't specify the -DCMAKE_INSTALL_PREFIX option
for the ccmake command, then the cached values will all refer to /usr/local,
and will _all_ have to be changed consistently by the user.

Now we get to the bad human engineering part.  Before I used 
MARK_AS_ADVANCED for all those generated install locations.  Thus, they were
by default (unless they hit the t option) hidden from ccmake users so they
could not see when they were inconsistent with what they wanted.  So that
was a nasty trap inadvertently set for the user.  With MARK_AS_ADVANCED
removed, they are now diplayed in all circumstances, and the users therefore
have a chance to specify the desired install locations. And, of course, if
they ever get tired of doing that, they can also avoid the problem
altogether by specifying the -DCMAKE_INSTALL_PREFIX option for the ccmake
command.

Sorry, Jerry, you were caught by this (inadvertent) trap, but I hope it is
all straightened out for you now.

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
__________________________

[Plplot-general] Window resize with gnome driver

[James F. <fr...@cs...>]

Hi,

I want to use plplot to draw plots within a gtk user interface.  When I 
run the examples (C language version) with the gnome driver, however, the 
plots remain a fixed size when the window size is changed.  That is, if I 
start with a plot that just fills the window, and enlarge that window, the 
plot doesn't change, but just gets a larger border around it.  I can't 
find anything in the manual or mailing list archives that seems to relate 
to this problem.  Is there a way to fix it?

Another option would be to use the xwin driver, and use reparenting to get 
the contents into a GTK widget, but I don't see any sort of mechanism for 
user feedback.

What I want to do is display a large set of data, and allow the user to 
zoom in on areas of interest by clicking on the plot.  Have I missed 
seeing an example that shows how to do this?

Thanks,
James

Re: [Plplot-general] How to remove an old version

[Jerry <lan...@qw...>]

I actually thought I did the right thing when I installed 5.7.2. But  
for a sanity check I just re-did everything from scratch with the  
same results.

I made a new directory at /usr/local/plplot_run_ccmake_from_here and  
cd-ed to it and ran ccmake from there. From ccmake, I specified  
CMAKE_INSTALL_PREFIX to be /usr/local/plplot-5.7.2.

The result was that only three non-directory items (.m files) were  
stored in /usr/local/plplot-5.7.2 and they are in /usr/local/ 
plplot-5.7.2/share/octave/site/m/PLplot.

Also, a whole lot of stuff was stored in /usr/local/ 
plplot_run_ccmake_from_here and another whole lot of stuff was stored  
in subdirectories of /usr/local, and therein lies the problem because  
as you said /usr/local was where I installed 5.5.3 and is also the  
default for some other things that I have installed. (It seems like a  
dumb policy to put everything side by side so I'm wondering why it's  
so popular.)

Here is the configuration info from ccmake that I set up. As you can  
see, I set CMAKE_INSTALL_PREFIX to /usr/local/plplot-5.7.2 but to my  
eyes the next few lines indicate pending trouble.






Summary of CMake build system results for PLplot

Install location variables which can be set by the user:
CMAKE_INSTALL_PREFIX:      /usr/local/plplot-5.7.2
CMAKE_INSTALL_EXEC_PREFIX  /usr/local
CMAKE_INSTALL_BINDIR    /usr/local/bin
CMAKE_INSTALL_DATADIR    /usr/local/share
CMAKE_INSTALL_LIBDIR    /usr/local/lib
CMAKE_INSTALL_INCLUDEDIR   /usr/local/include
CMAKE_INSTALL_INFODIR    /usr/local/share/info
CMAKE_INSTALL_MANDIR    /usr/local/share/man

Derived install location variables:
DATA_DIR     /usr/local/share/plplot5.7.2
LIB_DIR     /usr/local/lib
INCLUDE_DIR  /usr/local/include/plplot
BIN_DIR     /usr/local/bin
TCL_DIR     /usr/local/share/plplot5.7.2/tcl
DRV_DIR     /usr/local/lib/plplot5.7.2/driversd
DOC_DIR     /usr/local/share/doc/plplot
MAN_DIR      /usr/local/share/man
INFO_DIR     /usr/local/share/info

Other important CMake variables:

CMAKE_SYSTEM_NAME:Darwin
UNIX:1
WIN32:
APPLE:1
MSVC:(MSVC_VERSION:)
MINGW:
MSYS:
CYGWIN:
BORLAND:
WATCOM:

SWIG_FOUND:0
PERL_FOUND:YES
X11_FOUND:1

CMAKE_BUILD_TYPE:
CMAKE_C_COMPILER CMAKE_C_FLAGS:/usr/bin/gcc
CMAKE_CXX_COMPILER CMAKE_CXX_FLAGS:/usr/bin/c++
LIB_TAG:d

ENABLE_DYNDRIVERS:ON
DEVICES_LIST: aqt;mem;null;pbm;plmeta;ps;svg;tk;tkwin;xwin
DRIVERS_LIST: aqt;mem;null;pbm;plmeta;ps;svg;tk;tkwin;xwin

Library options:
BUILD_SHARED_LIBS:ONPL_DOUBLE:ON





In fact, things were installed in the /usr/local tree instead of /usr/ 
local/plplot-5.7.2 as I expected. Here are a few indicative lines  
from /usr/local/plplot_run_ccmake_from_here/install_manifest.txt:


/usr/local/include/plplot/plConfig.h
/usr/local/include/plplot/plDevs.h
/usr/local/lib/libplplotd.dylib
/usr/local/lib/libplplotd.9.dylib
/usr/local/lib/libplplotd.9.2.1.dylib
/usr/local/share/plplot5.7.2/cglobe.map
/usr/local/share/plplot5.7.2/globe.map



Jerry


On Mar 7, 2007, at 10:24 AM, Alan W. Irwin wrote:

> On 2007-03-07 03:42-0700 Jerry wrote:
>
>> I just installed 5.7.2 whereas my previous installation was 5.5.3.
>> How do I get rid of the old versions of everything now that they
>> exist in directories alongside the new version? Or should I have
>> uninstalled the the old version before installing the new version? Or
>> should I just ignore the problem?
>
> Hi Jerry:
>
> In general it is not a good idea to mix versions together with the  
> same
> install-tree prefix.  So specify unique install-tree prefixes  
> (using the
> -DCMAKE_INSTALL_PREFIX cmake option) for each different version you  
> want to
> keep.  Without doubt, -DCMAKE_INSTALL_PREFIX is the most important  
> cmake
> option, and you should use it every time you invoke cmake.
>
> Furthermore, suppose you have installed 5.7.2 in the past with the  
> unique
> install-tree prefix /home/jerry/plplot-5.7.2_install.  Now you may not
> recall the exact configuration you had for that install so that old  
> install
> tree might be filled with plplot files that are irrelevant (or  
> which may
> even interfere) with your new 5.7.2 install.  Of course, one way to  
> avoid
> this stale install file problem is to use a separate install tree  
> prefix
>
> (e.g.,
> /home/jerry/plplot-5.7.2_installa
> /home/jerry/plplot-5.7.2_installb
> /home/jerry/plplot-5.7.2_installb
> ...)
>
> for each separate PLplot-5.7.2 configure, build, and install that  
> you do.
> Probably a more practical course when you are rebuilding and  
> reinstalling a
> particular version of PLplot is simply to remove the whole install  
> tree
> (e.g., with the rm -rf command) before each invocation of "make  
> install".
> Such convenient wholesale removal is only possible because you used  
> a unique
> install-tree prefix such as /home/jerry/plplot-5.7.2_install.  (If  
> you had
> used a generic install prefix such as "/usr/local", then normally  
> there
> would be other files from non-PLplot installs that are mixed into  
> that tree
> which you would not want to remove.)
>
> Of course, that still leaves the question of what to do about your  
> current
> bad situation with various PLplot versions mixed together (possibly  
> with
> non-PLplot files) into the same install tree.  If you built and  
> installed
> PLplot-5.5.3 using the old ./configure; make; make install trio of  
> commands,
> then there is also a "make uninstall" command available to you.   
> However, I
> would only use that in an emergency (such as this) since blindly  
> removing
> files without reviewing them is considered to be dangerous. For modern
> PLplot, there is no "make uninstall" command for exactly this reason.
> Instead, there is a manifest of what was installed in  
> install_manifest.txt.
> Once you have looked at that list and are satisfied that removing  
> all those
> files will cause no harm, then you can conveniently go ahead with such
> removal with, e.g.,
>
> rm `cat install_manifest.txt`
>
> Alan
> __________________________

Re: [Plplot-general] How to remove an old version

[Alan W. I. <ir...@be...>]

On 2007-03-07 03:42-0700 Jerry wrote:

> I just installed 5.7.2 whereas my previous installation was 5.5.3.
> How do I get rid of the old versions of everything now that they
> exist in directories alongside the new version? Or should I have
> uninstalled the the old version before installing the new version? Or
> should I just ignore the problem?

Hi Jerry:

In general it is not a good idea to mix versions together with the same
install-tree prefix.  So specify unique install-tree prefixes (using the
-DCMAKE_INSTALL_PREFIX cmake option) for each different version you want to
keep.  Without doubt, -DCMAKE_INSTALL_PREFIX is the most important cmake
option, and you should use it every time you invoke cmake.

Furthermore, suppose you have installed 5.7.2 in the past with the unique
install-tree prefix /home/jerry/plplot-5.7.2_install.  Now you may not
recall the exact configuration you had for that install so that old install
tree might be filled with plplot files that are irrelevant (or which may
even interfere) with your new 5.7.2 install.  Of course, one way to avoid
this stale install file problem is to use a separate install tree prefix

(e.g., 
/home/jerry/plplot-5.7.2_installa
/home/jerry/plplot-5.7.2_installb
/home/jerry/plplot-5.7.2_installb
...)

for each separate PLplot-5.7.2 configure, build, and install that you do.
Probably a more practical course when you are rebuilding and reinstalling a
particular version of PLplot is simply to remove the whole install tree
(e.g., with the rm -rf command) before each invocation of "make install".
Such convenient wholesale removal is only possible because you used a unique
install-tree prefix such as /home/jerry/plplot-5.7.2_install.  (If you had
used a generic install prefix such as "/usr/local", then normally there
would be other files from non-PLplot installs that are mixed into that tree
which you would not want to remove.)

Of course, that still leaves the question of what to do about your current
bad situation with various PLplot versions mixed together (possibly with
non-PLplot files) into the same install tree.  If you built and installed
PLplot-5.5.3 using the old ./configure; make; make install trio of commands,
then there is also a "make uninstall" command available to you.  However, I
would only use that in an emergency (such as this) since blindly removing
files without reviewing them is considered to be dangerous. For modern
PLplot, there is no "make uninstall" command for exactly this reason.
Instead, there is a manifest of what was installed in install_manifest.txt.
Once you have looked at that list and are satisfied that removing all those
files will cause no harm, then you can conveniently go ahead with such
removal with, e.g.,

rm `cat install_manifest.txt`

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
__________________________

[Plplot-general] How to remove an old version

[Jerry <lan...@qw...>]

I just installed 5.7.2 whereas my previous installation was 5.5.3.  
How do I get rid of the old versions of everything now that they  
exist in directories alongside the new version? Or should I have  
uninstalled the the old version before installing the new version? Or  
should I just ignore the problem?

Jerry

Re: [Plplot-general] Octave driver

[NOEL B. <bru...@re...>]

SGVyZSB0aGUgYW5zd2VycyBmb3IgeW91ciBxdWVzdGlvbnMgOg0KDQpNYWMgT3MgeCBWZXJzaW9u
IGZvciBvY3RhdmUgaXMgMi45LjkgOw0KDQpJIGhhdmUgaW5zdGFsbGVkIG9jdGF2ZS0yLjEuNzIg
b24gY3lnd2luIHdpdGggdGhlIHNhbWUgcmVzdWx0cyA6IGVycm9yIDsNCg0KVGhlIGZpbGUgaW5j
bHVkZWQgaW4gdGhpcyBtYWlsIGlzIHRoZSB0ZXN0IHJlc3VsdHMgZnJvbSANCiJjdGVzdCAtLXZl
cmJvc2UgLS10ZXN0cy1yZWdleCBvY3RhdmUiIDogYWxsIG9mIGMrKyBhbmQgYyBtYW5hZ2VkIHRv
IGNyZWF0ZSANCnRoZSByaWdodCBmaWxlcyAoKi5wbmcsICoucGxtZXRhLCAqLnBzLCAqLnN2Zykg
YnV0IGluIGZhY3Qgbm9uZSB3YXMgY3JlYXRlZCANCmJ5IG9jdGF2ZSAhDQoNCkIuTi4NCg0KLS0t
LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJBbGFuIFcuIElyd2luIiA8aXJ3aW5A
YmVsdWdhLnBoeXMudXZpYy5jYT4NClRvOiAicGxwbG90X2dlbmVyYWwiIDxwbHBsb3QtZ2VuZXJh
bEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ+DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyNywgMjAw
NyA1OjA4IFBNDQpTdWJqZWN0OiBSZTogW1BscGxvdC1nZW5lcmFsXSBPY3RhdmUgZHJpdmVyDQoN
Cg0KPiBPbiAyMDA3LTAyLTI3IDEwOjI2KzAxMDAgTk9FTCBCUlVOTyB3cm90ZToNCj4NCj4+IEhl
bGxvLA0KPj4NCj4+IEhlcmUgYXJlIG15IGludGVybWVkaWF0ZSByZXN1bHRzIHVzaW5nIHBscGxv
dCB3aXRoIG9jdGF2ZSBvbiBjeWd3aW4gOg0KPj4gKiBjbWFrZS4yLjQuNiB1c2VkIDsNCj4+ICog
cGxwbG90NS43LjIgcmUtaW5zdGFsbGVkIGFuZCBjb21waWxhdGlvbiBzdWNjZXNzZnVsbCA7DQo+
PiAqIG9jdGF2ZTIuMS43MyBsYXVuY2hlZCBmcm9tICB0aGUgY21ha2UgYnVpbGRpbmcgDQo+PiBk
aXJlY3RvcnkvYmluZGluZ3Mvb2N0YXZlLw0KPj4gd2l0aCB0aGUgZm9sbG93aW5nIHJlc3VsdHMg
Og0KPj4NCj4+IG9jdGF2ZToxPiBwbHBsb3Rfc3R1YiA7DQo+PiBvY3RhdmU6Mj4gdmVyID0gcGxn
dmVyJw0KPj4gZXJyb3I6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkNCj4+IGVycm9yOiAncGxw
bG90X29jdGF2ZScgdW5kZWZpbmVkIG5lYXIgbGluZSAxNjA0IGNvbHVtbiA5DQo+PiBlcnJvcjog
ZXZhbHVhdGluZyBhc3NpZ25tZW50IGV4cHJlc3Npb24gbmVhciBsaW5lIDE2MDQsIGNvbHVtbiA3
DQo+PiBlcnJvcjogY2FsbGVkIGZyb20gJ3BsZ3ZlcicNCj4+IGVycm9yOiBldmFsdWF0aW5nIHBv
c3RmaXggb3BlcmF0b3IgJycnIG5lYXIgbGluZSAyLCBjb2x1bW4gNw0KPj4gZXJyb3I6IGV2YWx1
YXRpbmcgYXNzaWdubWVudCBleHByZXNzaW9uIG5lYXIgbGluZSAyLCBjb2x1bW4gNQ0KPj4gb2N0
YXZlOjI+IHBsaW5pdCA7DQo+PiBlcnJvcjogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQ0KPj4g
ZXJyb3I6ICdwbHBsb3Rfb2N0YXZlJyB1bmRlZmluZWQgbmVhciBsaW5lIDE2MDQgY29sdW1uIDkN
Cj4+IGVycm9yOiBldmFsdWF0aW5nIGFzc2lnbm1lbnQgZXhwcmVzc2lvbiBuZWFyIGxpbmUgMTg5
NSwgY29sdW1uIDENCj4+IGVycm9yOiBjYWxsZWQgZnJvbSAncGxpbml0Jw0KPj4NCj4+DQo+PiBB
cyBjb21wbGVtZW50YXJ5IHJlc3VsdHMsIGl0IHNob3VsZCBiZSBub3RpY2VkIHRoYXQgOg0KPj4g
KiBnbnVwbG90IHBsb3R0aW5nIHdvcmtzIHdlbGwgd2l0aCB0aGlzIGN5Z3dpbi9vY3RhdmUgdmVy
c2lvbg0KPj4gKiBidWlsZGluZyB0aGUgcGxwbG90LjUuNy4yIGRpc3RyaWJ1dGlvbiB3aXRoIHRo
ZSBzYW1lIGluc3RydWN0aW9ucywgYW5kDQo+PiB1c2luZyBvY3RhdmUgd2l0aCBpdCwgd29ya3Mg
d2VsbCBvbiBNYWMgT3MgMTAuNC4uLi4NCj4NCj4gV2UgaGF2ZSBoYWQgdHJvdWJsZXMgaW4gdGhl
IHBhc3Qgd2l0aCB0aGUgZXZlci1jaGFuZ2luZyBvY3RhdmUgQVBJLiAgV2hhdA0KPiB2ZXJzaW9u
IG9mIG9jdGF2ZSB3b3JrcyBmb3IgeW91IG9uIE1hYyBPUyBYPyAgQ291bGQgeW91IGFsc28gdHJ5
IHZlcnNpb24NCj4gMi4xLjcyIG9mIG9jdGF2ZSBvbiBDeWd3aW4/ICBJIGtub3cgdGhhdCB2ZXJz
aW9uIChhbHRob3VnaCBzdWJzdGFudGlhbGx5DQo+IHBhdGNoZWQpIHdvcmtzIG9uIFVidW50dSBE
YXBwZXIuDQo+DQo+Pg0KPj4gSW4gaG9wZSB5b3Ugd2lsbCBoYXZlIHNvbWUgaWRlYXMgb24gaG93
IHRvIHNvbHZlIHRoZXNlIHRyb3VibGVzLA0KPg0KPiBJdCBzb3VuZHMgbGlrZSBhIHJlYWwgQ3ln
d2luL29jdGF2ZSBpc3N1ZSBoZXJlLCBidXQgZm9yIHRoZSBwdXJwb3NlcyBvZg0KPiBjb21wYXJp
c29uIGNvdWxkIHlvdSBwbGVhc2UgcmVwb3J0IHRoZSByZXN1bHRzIG9mIHRoZSBzdGFuZGFyZCBi
dWlsZC10cmVlDQo+IHRlc3QgZm9yIG9jdGF2ZS0yLjEuNzIgb24gQ3lnd2luPw0KPg0KPiBUaGF0
IGlzLCB1c2UgdGhlIC1EQlVJTERfVEVTVD1PTiBvcHRpb24gdG8gY21ha2UsIGFuZCBhZnRlciB0
aGUgIm1ha2UiDQo+IGNvbW1hbmQgcnVuICJjdGVzdCAtLXZlcmJvc2UgLS10ZXN0cy1yZWdleCBv
Y3RhdmUiLg0KPg0KPiBPdGhlciBQbHBsb3QgZGV2ZWxvcGVycyBoZXJlIHdpdGggYWNjZXNzIHRv
IHRoZSBDeWd3aW4gcGxhdGZvcm0gc2hvdWxkIGRvDQo+IHRoZSBzYW1lIHRlc3QgdG8gYXR0ZW1w
dCB0byB2ZXJpZnkgdGhlIGlzc3VlLg0KPg0KPiBBbGFuDQo+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+IEFsYW4gVy4gSXJ3aW4NCj4NCj4gQXN0cm9ub21pY2FsIHJlc2VhcmNoIGFmZmls
aWF0aW9uIHdpdGggRGVwYXJ0bWVudCBvZiBQaHlzaWNzIGFuZCANCj4gQXN0cm9ub215LA0KPiBV
bml2ZXJzaXR5IG9mIFZpY3RvcmlhIChhc3Ryb3d3dy5waHlzLnV2aWMuY2EpLg0KPg0KPiBQcm9n
cmFtbWluZyBhZmZpbGlhdGlvbnMgd2l0aCB0aGUgRnJlZUVPUyBlcXVhdGlvbi1vZi1zdGF0ZSBp
bXBsZW1lbnRhdGlvbg0KPiBmb3Igc3RlbGxhciBpbnRlcmlvcnMgKGZyZWVlb3Muc2YubmV0KTsg
UExwbG90IHNjaWVudGlmaWMgcGxvdHRpbmcgDQo+IHNvZnR3YXJlDQo+IHBhY2thZ2UgKHBscGxv
dC5vcmcpOyB0aGUgWW9yaWNrIGZyb250LWVuZCB0byBQTHBsb3QgKHlwbG90LnNmLm5ldCk7IHRo
ZQ0KPiBMb2FkcyBvZiBMaW51eCBMaW5rcyBwcm9qZWN0IChsb2xsLnNmLm5ldCk7IGFuZCB0aGUg
TGludXggQnJvY2h1cmUgUHJvamVjdA0KPiAobGJwcm9qZWN0LnNmLm5ldCkuDQo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+DQo+IExpbnV4LXBvd2VyZWQgU2NpZW5jZQ0KPiBfX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRha2UgU3VydmV5
cy4gRWFybiBDYXNoLiBJbmZsdWVuY2UgdGhlIEZ1dHVyZSBvZiBJVA0KPiBKb2luIFNvdXJjZUZv
cmdlLm5ldCdzIFRlY2hzYXkgcGFuZWwgYW5kIHlvdSdsbCBnZXQgdGhlIGNoYW5jZSB0byBzaGFy
ZSANCj4geW91cg0KPiBvcGluaW9ucyBvbiBJVCAmIGJ1c2luZXNzIHRvcGljcyB0aHJvdWdoIGJy
aWVmIHN1cnZleXMtYW5kIGVhcm4gY2FzaA0KPiBodHRwOi8vd3d3LnRlY2hzYXkuY29tL2RlZmF1
bHQucGhwP3BhZ2U9am9pbi5waHAmcD1zb3VyY2Vmb3JnZSZDSUQ9REVWREVWDQo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFBscGxvdC1nZW5lcmFs
IG1haWxpbmcgbGlzdA0KPiBQbHBsb3QtZ2VuZXJhbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4g
aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcGxwbG90LWdlbmVy
YWwNCj4gDQoNCg0KLS0gRGlzY2xhaW1lciAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCkNlIG1lc3NhZ2UgYWluc2kgcXVlIGxlcyBldmVudHVlbGxlcyBwaWVjZXMgam9pbnRl
cyBjb25zdGl0dWVudCB1bmUgY29ycmVzcG9uZGFuY2UgcHJpdmVlIGV0IGNvbmZpZGVudGllbGxl
IGEgbCdhdHRlbnRpb24gZXhjbHVzaXZlIGR1IGRlc3RpbmF0YWlyZSBkZXNpZ25lIGNpLWRlc3N1
cy4gU2kgdm91cyBuJ2V0ZXMgcGFzIGxlIGRlc3RpbmF0YWlyZSBkdSBwcmVzZW50IG1lc3NhZ2Ug
b3UgdW5lIHBlcnNvbm5lIHN1c2NlcHRpYmxlIGRlIHBvdXZvaXIgbGUgbHVpIGRlbGl2cmVyLCBp
bCB2b3VzIGVzdCBzaWduaWZpZSBxdWUgdG91dGUgZGl2dWxnYXRpb24sIGRpc3RyaWJ1dGlvbiBv
dSBjb3BpZSBkZSBjZXR0ZSB0cmFuc21pc3Npb24gZXN0IHN0cmljdGVtZW50IGludGVyZGl0ZS4g
U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCBub3VzIHZvdXMgcmVtZXJj
aW9ucyBkJ2VuIGluZm9ybWVyIGwnZXhwZWRpdGV1ciBwYXIgdGVsZXBob25lIG91IGRlIGx1aSBy
ZXRvdXJuZXIgbGUgcHJlc2VudCBtZXNzYWdlLCBwdWlzIGQnZWZmYWNlciBpbW1lZGlhdGVtZW50
IGNlIG1lc3NhZ2UgZGUgdm90cmUgc3lzdGVtZS4NCioqKg0KVGhpcyBlLW1haWwgYW5kIGFueSBh
dHRhY2htZW50cyBpcyBhIGNvbmZpZGVudGlhbCBjb3JyZXNwb25kZW5jZSBpbnRlbmRlZCBvbmx5
IGZvciB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB5b3Ug
YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9yIHRoZSBhZ2VudCByZXNwb25zaWJsZSBm
b3IgZGVsaXZlcmluZyB0aGUgbWVzc2FnZSB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug
YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNjbG9zdXJlLCBkaXN0cmlidXRpb24gb3Ig
Y29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYg
eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90
aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3IgYnkgcmVwbHlpbmcgdGhpcyBtZXNzYWdlLCBhbmQg
dGhlbiBkZWxldGUgdGhpcyBtZXNzYWdlIGZyb20geW91ciBzeXN0ZW0uDQo=

Re: [Plplot-general] Octave driver

[Alan W. I. <ir...@be...>]

On 2007-02-27 10:26+0100 NOEL BRUNO wrote:

> Hello,
>
> Here are my intermediate results using plplot with octave on cygwin :
> * cmake.2.4.6 used ;
> * plplot5.7.2 re-installed and compilation successfull ;
> * octave2.1.73 launched from  the cmake building directory/bindings/octave/
> with the following results :
>
> octave:1> plplot_stub ;
> octave:2> ver = plgver'
> error: No such file or directory
> error: 'plplot_octave' undefined near line 1604 column 9
> error: evaluating assignment expression near line 1604, column 7
> error: called from 'plgver'
> error: evaluating postfix operator ''' near line 2, column 7
> error: evaluating assignment expression near line 2, column 5
> octave:2> plinit ;
> error: No such file or directory
> error: 'plplot_octave' undefined near line 1604 column 9
> error: evaluating assignment expression near line 1895, column 1
> error: called from 'plinit'
>
>
> As complementary results, it should be noticed that :
> * gnuplot plotting works well with this cygwin/octave version
> * building the plplot.5.7.2 distribution with the same instructions, and
> using octave with it, works well on Mac Os 10.4....

We have had troubles in the past with the ever-changing octave API.  What
version of octave works for you on Mac OS X?  Could you also try version
2.1.72 of octave on Cygwin?  I know that version (although substantially
patched) works on Ubuntu Dapper.

>
> In hope you will have some ideas on how to solve these troubles,

It sounds like a real Cygwin/octave issue here, but for the purposes of
comparison could you please report the results of the standard build-tree
test for octave-2.1.72 on Cygwin?

That is, use the -DBUILD_TEST=ON option to cmake, and after the "make"
command run "ctest --verbose --tests-regex octave".

Other Plplot developers here with access to the Cygwin platform should do
the same test to attempt to verify the 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 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
__________________________

Re: [Plplot-general] Octave driver

[NOEL B. <bru...@re...>]

SGVsbG8sDQoNCkhlcmUgYXJlIG15IGludGVybWVkaWF0ZSByZXN1bHRzIHVzaW5nIHBscGxvdCB3
aXRoIG9jdGF2ZSBvbiBjeWd3aW4gOg0KKiBjbWFrZS4yLjQuNiB1c2VkIDsNCiogcGxwbG90NS43
LjIgcmUtaW5zdGFsbGVkIGFuZCBjb21waWxhdGlvbiBzdWNjZXNzZnVsbCA7DQoqIG9jdGF2ZTIu
MS43MyBsYXVuY2hlZCBmcm9tICB0aGUgY21ha2UgYnVpbGRpbmcgZGlyZWN0b3J5L2JpbmRpbmdz
L29jdGF2ZS8gDQp3aXRoIHRoZSBmb2xsb3dpbmcgcmVzdWx0cyA6DQoNCm9jdGF2ZToxPiBwbHBs
b3Rfc3R1YiA7DQpvY3RhdmU6Mj4gdmVyID0gcGxndmVyJw0KZXJyb3I6IE5vIHN1Y2ggZmlsZSBv
ciBkaXJlY3RvcnkNCmVycm9yOiAncGxwbG90X29jdGF2ZScgdW5kZWZpbmVkIG5lYXIgbGluZSAx
NjA0IGNvbHVtbiA5DQplcnJvcjogZXZhbHVhdGluZyBhc3NpZ25tZW50IGV4cHJlc3Npb24gbmVh
ciBsaW5lIDE2MDQsIGNvbHVtbiA3DQplcnJvcjogY2FsbGVkIGZyb20gJ3BsZ3ZlcicNCmVycm9y
OiBldmFsdWF0aW5nIHBvc3RmaXggb3BlcmF0b3IgJycnIG5lYXIgbGluZSAyLCBjb2x1bW4gNw0K
ZXJyb3I6IGV2YWx1YXRpbmcgYXNzaWdubWVudCBleHByZXNzaW9uIG5lYXIgbGluZSAyLCBjb2x1
bW4gNQ0Kb2N0YXZlOjI+IHBsaW5pdCA7DQplcnJvcjogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9y
eQ0KZXJyb3I6ICdwbHBsb3Rfb2N0YXZlJyB1bmRlZmluZWQgbmVhciBsaW5lIDE2MDQgY29sdW1u
IDkNCmVycm9yOiBldmFsdWF0aW5nIGFzc2lnbm1lbnQgZXhwcmVzc2lvbiBuZWFyIGxpbmUgMTg5
NSwgY29sdW1uIDENCmVycm9yOiBjYWxsZWQgZnJvbSAncGxpbml0Jw0KDQoNCkFzIGNvbXBsZW1l
bnRhcnkgcmVzdWx0cywgaXQgc2hvdWxkIGJlIG5vdGljZWQgdGhhdCA6DQoqIGdudXBsb3QgcGxv
dHRpbmcgd29ya3Mgd2VsbCB3aXRoIHRoaXMgY3lnd2luL29jdGF2ZSB2ZXJzaW9uDQoqIGJ1aWxk
aW5nIHRoZSBwbHBsb3QuNS43LjIgZGlzdHJpYnV0aW9uIHdpdGggdGhlIHNhbWUgaW5zdHJ1Y3Rp
b25zLCBhbmQgDQp1c2luZyBvY3RhdmUgd2l0aCBpdCwgd29ya3Mgd2VsbCBvbiBNYWMgT3MgMTAu
NC4uLi4NCg0KSW4gaG9wZSB5b3Ugd2lsbCBoYXZlIHNvbWUgaWRlYXMgb24gaG93IHRvIHNvbHZl
IHRoZXNlIHRyb3VibGVzLA0KDQpCZXN0IHJlZ2FyZHMsDQoNCkIuTi4NCg0KDQotLS0tLSBPcmln
aW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsYW4gVy4gSXJ3aW4iIDxpcndpbkBiZWx1Z2Eu
cGh5cy51dmljLmNhPg0KVG86ICJwbHBsb3RfZ2VuZXJhbCIgPHBscGxvdC1nZW5lcmFsQGxpc3Rz
LnNvdXJjZWZvcmdlLm5ldD4NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjMsIDIwMDcgMTI6MjAg
QU0NClN1YmplY3Q6IFJlOiBbUGxwbG90LWdlbmVyYWxdIE9jdGF2ZSBkcml2ZXINCg0KDQo+IE9u
IDIwMDctMDItMjIgMDg6NTMrMDEwMCBOT0VMIEJSVU5PIHdyb3RlOg0KPg0KPj4gSGVsbG8sDQo+
Pg0KPj4gSSBhbSBhIGxvbmcgdGVybSBwbHBsb3QgdXNlciBvbiB3aXRoIEMrKyBiaW5kaW5ncy4g
QXMgSSB3b3VsZCBsaWtlIHRvDQo+PiBwcm90b3R5cGUgc29tZSBhcHBsaWNhdGlvbnMgd2l0aCBv
Y3RhdmUgdjIuMS43MywgSSBhbSB0cnlpbmcgdG8gdXNlIA0KPj4gcGxwbG90DQo+PiBhcyBncmFw
aGljYWwgb3V0cHV0IGVuZ2luZSBmb3Igb2N0YXZlIDoNCj4+IDEpIHBscGxvdC01LjcuMiBoYXMg
YmVlbiBkb3dsb2FkZWQgYW5kIHdlbGwgY29tcGlsZWQgb24gbXkgY3lnd2luIA0KPj4gcGxhdGZv
cm0NCj4+IDIpIHVzaW5nICdtYWtlIGNoZWNrJyA6IG5vIG91dHB1dCBmcm9tIG9jdGF2ZSBpcyBj
cmVhdGVkIGluIHRlc3QgDQo+PiBkaXJlY3RvcnkNCj4+IGJ1dCB0aGUgcmVzdWx0IGlzIDogJ0Fs
bCAxIHRlc3RzIHBhc3NlZCcgISEhDQo+PiAzKSB3aXRoIG9jdGF2ZSBhY3RpdmUsIGFmdGVyIHBs
cGxvdF9zdHViIGFjdGl2YXRlZCwgZWFjaCBwbHBsb3QgY29tbWFuZA0KPj4gY3Jhc2hlcyB0aGUg
b2N0YXZlIGFwcGxpY2F0aW9uIFtmaWd1cmUoKSwgcGxzZGV2KCd4eHgnKV0uLi4uLg0KPj4NCj4+
IERvIHlvdSBoYXZlIGFueSBzb2x1dGlvbiB0byB1c2Ugd2luZ2NjIGRyaXZlciBhdCBsZWFzdCB3
aXRoIE9jdGF2ZS4NCj4+DQo+PiBUaGFua3MgZm9yIHlvdXIgYWR2aWNlLA0KPg0KPiAibWFrZSBj
aGVjayIgaXMgZnJvbSB0aGUgaGlzdG9yaWNhbCBhdXRvdG9vbHMgYnVpbGQgc3lzdGVtIHdoaWNo
IGlzDQo+IGRlcHJlY2F0ZWQgYW5kIHRoZXJlZm9yZSBpbiBhIG1pbmltdW0gbWFpbnRlbmFuY2Ug
bW9kZSBub3cuIEkgYWR2aXNlIHVzaW5nDQo+IHRoZSByZWNvbW1lbmRlZCBDTWFrZSBidWlsZCBz
eXN0ZW0gZm9yIDUuNy4yIChvciBiZXR0ZXIgeWV0IHRoZSBDVlMgDQo+IHZlcnNpb24NCj4gb2Yg
UExwbG90IHdoaWNoIGlzIHN0YWJsZSBhdCB0aGUgbW9tZW50KSB3aGljaCBpcyBkb2N1bWVudGVk
IGF0DQo+IGh0dHA6Ly93d3cubWlzY2RlYnJpcy5uZXQvcGxwbG90X3dpa2kvIGFuZCB3aGljaCBn
ZW5lcmFsbHkgdGVuZHMgdG8gZG8gYQ0KPiBiZXR0ZXIgam9iIG9mIGJ1aWxkcyBvbiBDeWd3aW4g
Y29tcGFyZWQgdG8gb3VyIG9sZCBhdXRvdG9vbHMgYnVpbGQgc3lzdGVtLg0KPiBXZSBoYXZlIGF0
IGxlYXN0IHR3byBjb3JlIGRldmVsb3BlcnMgd2hvIGFyZSBmYW1pbGlhciB3aXRoIHRoZSBDTWFr
ZSBidWlsZA0KPiBzeXN0ZW0gZm9yIFBMcGxvdCBvbiBDeWd3aW4uDQo+DQo+IE91ciBDTWFrZSBi
dWlsZCBzeXN0ZW0gZ2VuZXJhdGVzIGEgZ29vZCBvY3RhdmUgYmluZGluZyBvbiBub24td2luZG93
cw0KPiBwbGF0Zm9ybXMgYXMgZXZpZGVuY2VkIGJ5IGJvdGggYnVpbGQtdHJlZSB0ZXN0cyAoY3Rl
c3QgLi4uKSBhbmQgDQo+IGluc3RhbGwtdHJlZQ0KPiB0ZXN0cyAocGxwbG90LXRlc3Quc2ggLS1m
cm9udC1lbmQ9b2N0YXZlIGZyb20gdGhlIGluc3RhbGwtdHJlZSBleGFtcGxlcw0KPiBkaXJlY3Rv
cnkpLiBIb3dldmVyLA0KPiBodHRwOi8vd3d3Lm1pc2NkZWJyaXMubmV0L3BscGxvdF93aWtpL2lu
ZGV4LnBocD90aXRsZT1PdmVydmlld19vZl90aGVfc3RhdHVzX29uX1dpbmRvd3MNCj4gZG9lcyBu
b3QgeWV0IG1lbnRpb24gb2N0YXZlIHNvIHlvdSBtYXkgYmUgdGhlIGZpcnN0IHRvIHRlc3QgdGhl
IG9jdGF2ZQ0KPiBpbnRlcmZhY2Ugb24gQ3lnd2luIGZvciBvdXIgQ01ha2UgYnVpbGQgc3lzdGVt
LiAgSG93ZXZlciwgeW91IGNhbiBhbHdheXMNCj4gcG9zdCB0byB0aGlzIGxpc3QgaWYgeW91IHJ1
biBpbnRvIGFueSB0cm91YmxlLg0KPg0KPiBBbGFuDQo+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+IEFsYW4gVy4gSXJ3aW4NCj4NCj4gQXN0cm9ub21pY2FsIHJlc2VhcmNoIGFmZmlsaWF0
aW9uIHdpdGggRGVwYXJ0bWVudCBvZiBQaHlzaWNzIGFuZCANCj4gQXN0cm9ub215LA0KPiBVbml2
ZXJzaXR5IG9mIFZpY3RvcmlhIChhc3Ryb3d3dy5waHlzLnV2aWMuY2EpLg0KPg0KPiBQcm9ncmFt
bWluZyBhZmZpbGlhdGlvbnMgd2l0aCB0aGUgRnJlZUVPUyBlcXVhdGlvbi1vZi1zdGF0ZSBpbXBs
ZW1lbnRhdGlvbg0KPiBmb3Igc3RlbGxhciBpbnRlcmlvcnMgKGZyZWVlb3Muc2YubmV0KTsgUExw
bG90IHNjaWVudGlmaWMgcGxvdHRpbmcgDQo+IHNvZnR3YXJlDQo+IHBhY2thZ2UgKHBscGxvdC5v
cmcpOyB0aGUgWW9yaWNrIGZyb250LWVuZCB0byBQTHBsb3QgKHlwbG90LnNmLm5ldCk7IHRoZQ0K
PiBMb2FkcyBvZiBMaW51eCBMaW5rcyBwcm9qZWN0IChsb2xsLnNmLm5ldCk7IGFuZCB0aGUgTGlu
dXggQnJvY2h1cmUgUHJvamVjdA0KPiAobGJwcm9qZWN0LnNmLm5ldCkuDQo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+DQo+IExpbnV4LXBvd2VyZWQgU2NpZW5jZQ0KPiBfX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRha2UgU3VydmV5cy4g
RWFybiBDYXNoLiBJbmZsdWVuY2UgdGhlIEZ1dHVyZSBvZiBJVA0KPiBKb2luIFNvdXJjZUZvcmdl
Lm5ldCdzIFRlY2hzYXkgcGFuZWwgYW5kIHlvdSdsbCBnZXQgdGhlIGNoYW5jZSB0byBzaGFyZSAN
Cj4geW91cg0KPiBvcGluaW9ucyBvbiBJVCAmIGJ1c2luZXNzIHRvcGljcyB0aHJvdWdoIGJyaWVm
IHN1cnZleXMtYW5kIGVhcm4gY2FzaA0KPiBodHRwOi8vd3d3LnRlY2hzYXkuY29tL2RlZmF1bHQu
cGhwP3BhZ2U9am9pbi5waHAmcD1zb3VyY2Vmb3JnZSZDSUQ9REVWREVWDQo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFBscGxvdC1nZW5lcmFsIG1h
aWxpbmcgbGlzdA0KPiBQbHBsb3QtZ2VuZXJhbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4gaHR0
cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcGxwbG90LWdlbmVyYWwN
Cj4gDQoNCg0KDQotLSBEaXNjbGFpbWVyIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQ0KQ2UgbWVzc2FnZSBhaW5zaSBxdWUgbGVzIGV2ZW50dWVsbGVzIHBpZWNlcyBqb2ludGVz
IGNvbnN0aXR1ZW50IHVuZSBjb3JyZXNwb25kYW5jZSBwcml2ZWUgZXQgY29uZmlkZW50aWVsbGUg
YSBsJ2F0dGVudGlvbiBleGNsdXNpdmUgZHUgZGVzdGluYXRhaXJlIGRlc2lnbmUgY2ktZGVzc3Vz
LiBTaSB2b3VzIG4nZXRlcyBwYXMgbGUgZGVzdGluYXRhaXJlIGR1IHByZXNlbnQgbWVzc2FnZSBv
dSB1bmUgcGVyc29ubmUgc3VzY2VwdGlibGUgZGUgcG91dm9pciBsZSBsdWkgZGVsaXZyZXIsIGls
IHZvdXMgZXN0IHNpZ25pZmllIHF1ZSB0b3V0ZSBkaXZ1bGdhdGlvbiwgZGlzdHJpYnV0aW9uIG91
IGNvcGllIGRlIGNldHRlIHRyYW5zbWlzc2lvbiBlc3Qgc3RyaWN0ZW1lbnQgaW50ZXJkaXRlLiBT
aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIG5vdXMgdm91cyByZW1lcmNp
b25zIGQnZW4gaW5mb3JtZXIgbCdleHBlZGl0ZXVyIHBhciB0ZWxlcGhvbmUgb3UgZGUgbHVpIHJl
dG91cm5lciBsZSBwcmVzZW50IG1lc3NhZ2UsIHB1aXMgZCdlZmZhY2VyIGltbWVkaWF0ZW1lbnQg
Y2UgbWVzc2FnZSBkZSB2b3RyZSBzeXN0ZW1lLg0KKioqDQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0
dGFjaG1lbnRzIGlzIGEgY29uZmlkZW50aWFsIGNvcnJlc3BvbmRlbmNlIGludGVuZGVkIG9ubHkg
Zm9yIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHlvdSBh
cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb3IgdGhlIGFnZW50IHJlc3BvbnNpYmxlIGZv
ciBkZWxpdmVyaW5nIHRoZSBtZXNzYWdlIHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBh
cmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGRpc3RyaWJ1dGlvbiBvciBj
b3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5
b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3Rp
ZnkgdGhlIHNlbmRlciBieSBwaG9uZSBvciBieSByZXBseWluZyB0aGlzIG1lc3NhZ2UsIGFuZCB0
aGVuIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgZnJvbSB5b3VyIHN5c3RlbS4NCg==

Re: [Plplot-general] Octave driver

[Alan W. I. <ir...@be...>]

On 2007-02-22 08:53+0100 NOEL BRUNO wrote:

> Hello,
>
> I am a long term plplot user on with C++ bindings. As I would like to
> prototype some applications with octave v2.1.73, I am trying to use plplot
> as graphical output engine for octave :
> 1) plplot-5.7.2 has been dowloaded and well compiled on my cygwin platform
> 2) using 'make check' : no output from octave is created in test directory
> but the result is : 'All 1 tests passed' !!!
> 3) with octave active, after plplot_stub activated, each plplot command
> crashes the octave application [figure(), plsdev('xxx')].....
>
> Do you have any solution to use wingcc driver at least with Octave.
>
> Thanks for your advice,

"make check" is from the historical autotools build system which is
deprecated and therefore in a minimum maintenance mode now. I advise using
the recommended CMake build system for 5.7.2 (or better yet the CVS version
of PLplot which is stable at the moment) which is documented at
http://www.miscdebris.net/plplot_wiki/ and which generally tends to do a
better job of builds on Cygwin compared to our old autotools build system.
We have at least two core developers who are familiar with the CMake build
system for PLplot on Cygwin.

Our CMake build system generates a good octave binding on non-windows
platforms as evidenced by both build-tree tests (ctest ...) and install-tree
tests (plplot-test.sh --front-end=octave from the install-tree examples
directory). However,
http://www.miscdebris.net/plplot_wiki/index.php?title=Overview_of_the_status_on_Windows
does not yet mention octave so you may be the first to test the octave
interface on Cygwin for our CMake build system.  However, you can always
post to this list if you run into any trouble.

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
__________________________

Re: [Plplot-general] plshades trouble

[Alan W. I. <ir...@be...>]

Hi K=E5re:

Glad the basic build-tree test (ctest) and the basic install-tree test are
working for you.  Note the library version shown by the latter should be
5.7.2 (corresponding to the CVS version of PLplot) rather than 5.6.1 as
implied by what you said.  I believe it is only the CVS version of PLplot
that configures the test_perl.sh file properly (via LD_LIBRARY_PATH) so tha=
t
you always get the PLplot library version that you just built and installed
as opposed to some system version.

On 2007-02-22 10:19+0100 K=E5re Edvardsen wrote:

>
> Syntax seem almost straight forward, but the it seems like the function
> call paramaters does not come in same order for c and perl
>
> C: plshades(z, nx, ny, NULL, -1., 1., -1., 1., ...and so on
>
> perl: plshades (z, -1., 1., -1., 1., ...and so on,
>
> and I've got some difficulties recognizing them, but I will look into it
> now.

Yes, that NULL C argument above stands for zdefined which is moved to a
different place in the PDL argument for probably historical reasons. Note,
the C API for both plshade (example 15) and plshades (example 16) is quite
tricky and hard to emulate in other languages so your best choice for these
two functions is to consult the implementation of the PDL interface to
PLplot. That project has been implemented independently of PLplot and is
separately maintained by Doug Hunt.  (Doug, if you are lurking on this list
please speak up.) Anyhow, K=E5re, you picked one of the most difficult case=
s
to deal with (plshades), and other PDL calls to PLplot functions usually
follow the general rules (dropped redundant dimension arguments as in nx an=
d
ny above) much better with no argument list rearranging.

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
__________________________

[Plplot-general] Octave driver

[NOEL B. <bru...@re...>]

SGVsbG8sDQoNCkkgYW0gYSBsb25nIHRlcm0gcGxwbG90IHVzZXIgb24gd2l0aCBDKysgYmluZGlu
Z3MuIEFzIEkgd291bGQgbGlrZSB0byANCnByb3RvdHlwZSBzb21lIGFwcGxpY2F0aW9ucyB3aXRo
IG9jdGF2ZSB2Mi4xLjczLCBJIGFtIHRyeWluZyB0byB1c2UgcGxwbG90IA0KYXMgZ3JhcGhpY2Fs
IG91dHB1dCBlbmdpbmUgZm9yIG9jdGF2ZSA6DQoxKSBwbHBsb3QtNS43LjIgaGFzIGJlZW4gZG93
bG9hZGVkIGFuZCB3ZWxsIGNvbXBpbGVkIG9uIG15IGN5Z3dpbiBwbGF0Zm9ybQ0KMikgdXNpbmcg
J21ha2UgY2hlY2snIDogbm8gb3V0cHV0IGZyb20gb2N0YXZlIGlzIGNyZWF0ZWQgaW4gdGVzdCBk
aXJlY3RvcnkgDQpidXQgdGhlIHJlc3VsdCBpcyA6ICdBbGwgMSB0ZXN0cyBwYXNzZWQnICEhIQ0K
Mykgd2l0aCBvY3RhdmUgYWN0aXZlLCBhZnRlciBwbHBsb3Rfc3R1YiBhY3RpdmF0ZWQsIGVhY2gg
cGxwbG90IGNvbW1hbmQgDQpjcmFzaGVzIHRoZSBvY3RhdmUgYXBwbGljYXRpb24gW2ZpZ3VyZSgp
LCBwbHNkZXYoJ3h4eCcpXS4uLi4uDQoNCkRvIHlvdSBoYXZlIGFueSBzb2x1dGlvbiB0byB1c2Ug
d2luZ2NjIGRyaXZlciBhdCBsZWFzdCB3aXRoIE9jdGF2ZS4NCg0KVGhhbmtzIGZvciB5b3VyIGFk
dmljZSwNCg0KQi5OLiANCg0KDQoNCi0tIERpc2NsYWltZXIgLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQpDZSBtZXNzYWdlIGFpbnNpIHF1ZSBsZXMgZXZlbnR1ZWxsZXMgcGll
Y2VzIGpvaW50ZXMgY29uc3RpdHVlbnQgdW5lIGNvcnJlc3BvbmRhbmNlIHByaXZlZSBldCBjb25m
aWRlbnRpZWxsZSBhIGwnYXR0ZW50aW9uIGV4Y2x1c2l2ZSBkdSBkZXN0aW5hdGFpcmUgZGVzaWdu
ZSBjaS1kZXNzdXMuIFNpIHZvdXMgbidldGVzIHBhcyBsZSBkZXN0aW5hdGFpcmUgZHUgcHJlc2Vu
dCBtZXNzYWdlIG91IHVuZSBwZXJzb25uZSBzdXNjZXB0aWJsZSBkZSBwb3V2b2lyIGxlIGx1aSBk
ZWxpdnJlciwgaWwgdm91cyBlc3Qgc2lnbmlmaWUgcXVlIHRvdXRlIGRpdnVsZ2F0aW9uLCBkaXN0
cmlidXRpb24gb3UgY29waWUgZGUgY2V0dGUgdHJhbnNtaXNzaW9uIGVzdCBzdHJpY3RlbWVudCBp
bnRlcmRpdGUuIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgbm91cyB2
b3VzIHJlbWVyY2lvbnMgZCdlbiBpbmZvcm1lciBsJ2V4cGVkaXRldXIgcGFyIHRlbGVwaG9uZSBv
dSBkZSBsdWkgcmV0b3VybmVyIGxlIHByZXNlbnQgbWVzc2FnZSwgcHVpcyBkJ2VmZmFjZXIgaW1t
ZWRpYXRlbWVudCBjZSBtZXNzYWdlIGRlIHZvdHJlIHN5c3RlbWUuDQoqKioNClRoaXMgZS1tYWls
IGFuZCBhbnkgYXR0YWNobWVudHMgaXMgYSBjb25maWRlbnRpYWwgY29ycmVzcG9uZGVuY2UgaW50
ZW5kZWQgb25seSBmb3IgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZCBhYm92
ZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvciB0aGUgYWdlbnQgcmVz
cG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdGhlIG1lc3NhZ2UgdG8gdGhlIGludGVuZGVkIHJlY2lw
aWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzY2xvc3VyZSwgZGlzdHJp
YnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hp
Yml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwg
cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHBob25lIG9yIGJ5IHJlcGx5aW5nIHRoaXMgbWVz
c2FnZSwgYW5kIHRoZW4gZGVsZXRlIHRoaXMgbWVzc2FnZSBmcm9tIHlvdXIgc3lzdGVtLg0K