plplot-general — PLplot user discussion group

Re: [Plplot-general] A call for pre-release testing of PLplot in the next few days

[Valery P. <pi...@is...>]

Dear Alan,

I found another problem which I did not mention previously.
It is related with agg interface. The version of agg is 2.5. If I turned it on 
then it breaks the compilation of wx interface. It complain about abcense some 
of the headers files,  like *font*.h.  Indeed, I did not find such header 
files inside ours libagg2.5-devel package. 

> the octave issue that you found.
I made the same test on fedora-10 and confim this issue for octave-3.0.3

all the best
Valery

Re: [Plplot-general] A call for pre-release testing of PLplot in the next few days

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

Hi Valery:

Thanks very much for your detailed report on the results of "make test" in
the installed examples tree.  I am hoping Andrew will be able to deal with
the octave issue that you found. I will deal with all the other issues you
reported off list with you, and then summarize the resolution of them on
this list.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] A call for pre-release testing of PLplot in the next few days

[Valery P. <pi...@is...>]

Dear List,

I have tried the plplot version from trunk( updated  today morning, ie 
15/01/09).
The system is altlinux. Some problems are 
1) octave-3.0.2  has problem in compilation.  So for the test
below I compile with 
cmake . -DPL_FREETYPE_FONT_PATH:PATH="/usr/share/fonts/ttf/freefont" -
DENABLE_octave=OFF

The final output of cmake is 
CMAKE_BUILD_TYPE:
CMAKE_C_COMPILER CMAKE_C_FLAGS:                 /usr/bin/gcc 
CMAKE_CXX_COMPILER CMAKE_CXX_FLAGS:             /usr/bin/c++ 
CMAKE_Fortran_COMPILER CMAKE_Fortran_FLAGS:     /usr/bin/gfortran 
Target Fortran:                                                   
PYTHON_EXECUTABLE:                              /usr/bin/python2.5
PYTHON_INCLUDE_PATH:                            
/usr/include/python2.5;/usr/lib64/python2.5/site-
packages/numpy/core/include/numpy                                                        
PYTHON_LIBRARIES:                               /usr/lib64/libpython2.5.so                   
LIB_TAG:                d                                                                    

ENABLE_DYNDRIVERS:      ON
DRIVERS_LIST: cairo;gd;hpgl;mem;null;pbm;ps;psttf;svg;wxwidgets;xfig;xwin
DEVICES_LIST: 
pdfcairo;pngcairo;pscairo;svgcairo;xcairo;gif;jpeg;png;hp7470;hp7580;lj_hpgl;mem;null;pbm;ps;psttf;svg;wxwidgets;xfig;xwin                                                  

Library options:
BUILD_SHARED_LIBS:      ON              PL_DOUBLE:      ON

Optional libraries:
HAVE_QHULL:             ON              WITH_CSA:       ON
HAVE_FREETYPE:          ON              HAVE_PTHREAD:   ON
HAVE_AGG:               OFF

Language Bindings:
ENABLE_f77:             ON              ENABLE_f95:             ON
ENABLE_cxx:             ON              ENABLE_java:            ON
ENABLE_python:          ON              ENABLE_octave:          OFF
ENABLE_tcl:             ON              ENABLE_itcl:            OFF
ENABLE_tk:              OFF             ENABLE_itk:             OFF
ENABLE_pdl:             OFF             ENABLE_wxwidgets:       ON
ENABLE_gnome2:       OFF             ENABLE_pygcw:           OFF
ENABLE_ada:             OFF             ENABLE_d:
ENABLE_ocaml:           OFF

-- Configuring done
-- Generating done
-- Build files have been written to: /home/va/RPM/BUILD/plplot-5.9.2




In attachment some of the output files. 
If  I understand correctly  the tests suppose that   $DEBUG_CMD ${OUTPUT_DIR} 
are defined somewhere. On other hand all the test seems to work if to run them 
separately.  

The question of octave.  I have octave-3.0.2 (and devel files as well).
Cmake diagnostic is 
##########
- OCTAVE = /usr/bin/octave                                                                  
-- MKOCTFILE = /usr/bin/mkoctfile                                                            
-- OCTAVE_VERSION = 3.0.2                                                                    
-- OCTAVE_LIBRARIES = /usr/lib64/liboctave.so                                                
-- OCTINTERP_LIBRARIES = /usr/lib64/liboctinterp.so                                          
-- OCTAVE_INCLUDE_PATH = 
/usr/include/octave-3.0.2;/usr/include/octave-3.0.2/octave          
-- MATWRAP = /home/va/RPM/BUILD/plplot-5.9.2/bindings/octave/matwrap/matwrap                 
-- MATWRAP_PATH = /home/va/RPM/BUILD/plplot-5.9.2/bindings/octave/matwrap                    
-- PLPLOT_OCTAVE_DIR = /usr/local/share/plplot_octave                                        
-- OCTAVE_M_DIR = /usr/local/share/octave/site/m                                             
-- OCTAVE_OCT_DIR = /usr/local/share/plplot_octave                                           
-- Looking for include paths and libraries for Tcl/Tk                                        
-- Looking for include paths and libraries for Tcl/Tk - found                                
#####

Scanning dependencies of target massage                                                      
[ 30%] Building C object bindings/octave/CMakeFiles/massage.dir/massage.o                    
Linking C executable massage                                                                 
[ 30%] Built target massage                                                                  
[ 30%] Generating plplot_octave.cc, tmp_stub                                                 
Warning: unrecognized text:                                                                  

So compilation gives: 
void c_plcont(PLFLT **f, PLINT nx, PLINT ny, PLINT kx, PLINT lx,
  PLINT ky, PLINT ly, PLFLT *clevel, PLINT nlevel,              
  void (*pltr) (PLFLT, PLFLT, PLFLT *, PLFLT *, PLPointer),     
  PLPointer pltr_data);                                         
%nowrap                                                         
void plfcont(PLFLT (*f2eval) (PLINT, PLINT, PLPointer),         
 PLPointer f2eval_data,





best regards and many thanks for keeping  plplot the best!
Valery

[Plplot-general] A call for pre-release testing of PLplot in the next few days

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

I have just confirmed with our release manager, Hazen Babcock, that the
development release of PLplot-5.9.2 is going ahead next weekend. The PLplot
core developers get good results for the svn/trunk version (what will become
the PLplot-5.9.2 release), but our testing is necessarily limited because we
don't have access to the wide variety of hardware platforms, operating
systems, library versions, and configurations that our users have access to.
Thus, we would appreciate testing help from our users in the next few days
on all the operating systems we support (traditional Unix, Linux, Mac OS X,
and Windows [Cygwin, MinGW/MSYS, MinGW, and bare Windows]) to give us the
best chance of shaking out any remaining bugs in this forthcoming release.

If you would like to help us out this way, please download the svn/trunk
version of PLplot following the directions at
http://sourceforge.net/svn/?group_id=2915.  (Especially note the warning
about appending "/trunk" to the URL so you only get the trunk version as
opposed to _all_ of our historical releases and branches as well as the
trunk version.) Then follow the build instructions in the INSTALL file and
the test directions (for both the build tree and install tree versions of
PLplot) in the README.testing file. See also
http://www.miscdebris.net/plplot_wiki/index.php?title=Building_PLplot and
http://www.miscdebris.net/plplot_wiki/index.php?title=Testing_PLplot from
where those files were recently copied.

Note, our testing procedures have recently been updated to be quite
comprehensive. They test our complete API for all language interfaces and
devices that we support. If you get through the tests without any errors on
your platform, then you can be virtually guaranteed that the forthcoming
PLplot-5.9.2 release will be robust on your platform.  Note, the tests take
only a few minutes to run on an entry level PC because PLplot is quite
efficient. However, you do need lots of disk space (typically 2GB in the
build tree and 2GB in the install tree) to store all the plot results that
are generated by the tests.

Please report any issues you find back to this list.

Alan.
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] Closing the graphics window

[<Han...@sh...>]

Werner,

Sorry for not mentioning that.I am running on Linux using the "xwin" driver. Any suggestion is appreciated.

Thanks,
Hans

-----Original Message-----
From: Werner Smekal [mailto:sm...@ia...]
Sent: Tuesday, December 23, 2008 8:54 PM
To: Rijneke, Hans H SIEP-EPT-RIS
Cc: plp...@li...
Subject: Re: [Plplot-general] Closing the graphics window


Hi,

which driver to you use, xwin? I'm not sure about the xwin driver, but 
in wxWidgets is possible to veto a close event. So it should also be 
possible to do the same for the xwin driver, but I think you have to 
change the driver code.

If you tell me which driver you are using I could have a look in the 
driver code and propose a patch.

Regards,
Werner

Han...@sh... wrote:
> L.S.,
>
> Some of our users have the habit of closing the graphics window, which will lead to a crash if the next plot command comes.
>
> Is there a way of preventing users to close the graphics window ?
>
> Thanks in advance,
> Hans Rijneke
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>   


-- 
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886

email: sm...@ia...
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

Re: [Plplot-general] Closing the graphics window

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

Hi,

which driver to you use, xwin? I'm not sure about the xwin driver, but 
in wxWidgets is possible to veto a close event. So it should also be 
possible to do the same for the xwin driver, but I think you have to 
change the driver code.

If you tell me which driver you are using I could have a look in the 
driver code and propose a patch.

Regards,
Werner

Han...@sh... wrote:
> L.S.,
>
> Some of our users have the habit of closing the graphics window, which will lead to a crash if the next plot command comes.
>
> Is there a way of preventing users to close the graphics window ?
>
> Thanks in advance,
> Hans Rijneke
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
>   


-- 
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886

email: sm...@ia...
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

[Plplot-general] Closing the graphics window

[<Han...@sh...>]

L.S.,

Some of our users have the habit of closing the graphics window, which will lead to a crash if the next plot command comes.

Is there a way of preventing users to close the graphics window ?

Thanks in advance,
Hans Rijneke

Re: [Plplot-general] enabling pthreads for xwin by default

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

On 2008-12-22 20:55-0000 Andrew Ross wrote:

>
> Hi Derek,
>
> There is no real reason not to enable pthreads on a Linux system. I
> maintain the Debian / Ubuntu packages and we certainly build them with
> pthread support.

Derek, we set if OFF by default originally because thread support was pretty
awful when we first introduced this feature.  Our inertia meant we never
thought much about turning HAVE_PTHREAD=ON by default until now. :-(

Thanks for your suggestion to do that which I have just implemented
(revision 9215).  This should be fine for Linux systems (from Andrew's
comments above and also my Linux testing experience), but we will see how it
goes for other platforms.  The CMake support behind cross-platform threading
seens fairly extensive so other platforms may be fine as well. If those
testing the svn trunk version of PLplot with non-Linux platforms report no
problems everybody will get this feature for the next release, but otherwise
I will make an additional change so its only ON by default for Linux.  In
any case HAVE_PTHREAD=ON will eventually propagate to Linux distributions.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] enabling pthreads for xwin by default

[Derek L. <de...@bo...>]

Thanks, Andrews and Alan.  Good to know about the Debian/Ubuntu 
distibutions. The propagation to others may help with PDL's migration 
from PGPLOT to PLplot as well (certainly my own...).  We'll be looking 
out for 5.9.2 and 5.10!

cheers,
Derek

Alan W. Irwin wrote:
> On 2008-12-22 20:55-0000 Andrew Ross wrote:
>
>>
>> Hi Derek,
>>
>> There is no real reason not to enable pthreads on a Linux system. I
>> maintain the Debian / Ubuntu packages and we certainly build them with
>> pthread support.
>
> Derek, we set if OFF by default originally because thread support was 
> pretty
> awful when we first introduced this feature.  Our inertia meant we never
> thought much about turning HAVE_PTHREAD=ON by default until now. :-(
>
> Thanks for your suggestion to do that which I have just implemented
> (revision 9215).  This should be fine for Linux systems (from Andrew's
> comments above and also my Linux testing experience), but we will see 
> how it
> goes for other platforms.  The CMake support behind cross-platform 
> threading
> seens fairly extensive so other platforms may be fine as well. If those
> testing the svn trunk version of PLplot with non-Linux platforms 
> report no
> problems everybody will get this feature for the next release, but 
> otherwise
> I will make an additional change so its only ON by default for Linux.  In
> any case HAVE_PTHREAD=ON will eventually propagate to Linux 
> distributions.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state 
> implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting 
> software
> package (plplot.org); the libLASi project (unifont.org/lasi); the 
> Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________

Re: [Plplot-general] enabling pthreads for xwin by default

[Andrew R. <and...@us...>]

Hi Derek,

There is no real reason not to enable pthreads on a Linux system. I
maintain the Debian / Ubuntu packages and we certainly build them with
pthread support.

Andrew

On Mon, Dec 22, 2008 at 12:45:50PM -0500, Derek Lamb wrote:
> Hi all,
> 
> I've been experimenting with PLplot for awhile.  Mainly I use PDL, and
> thus interactive plotting with the xwin driver and the
> PDL::Graphics::PLplot module.  But until now I was not able to get over
> one hurdle: that whenever I covered up the window, the contents would
> disappear until the next plotting command was issued.  Just last week I
> was searching the email lists and found that setting the HAVE_PTHREAD
> option to cmake resolves this, in quite a satisfactory way.  However, I
> usually just install PLplot from my distro's package manager, especially
> on a new machine, because of the considerable dependencies.
> 
> Is there any (good) reason that pthreads is not enabled by default, and
> thus enabled in the version downloaded from each distribution's
> repository?  I don't know how that would work for packaging, how often
> pthreads are installed by default, or if that would generate a huge
> dependency, but it seems so convenient...
> 
> cheers,
> Derek
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general
> 

[Plplot-general] enabling pthreads for xwin by default

[Derek L. <de...@bo...>]

Hi all,

I've been experimenting with PLplot for awhile.  Mainly I use PDL, and
thus interactive plotting with the xwin driver and the
PDL::Graphics::PLplot module.  But until now I was not able to get over
one hurdle: that whenever I covered up the window, the contents would
disappear until the next plotting command was issued.  Just last week I
was searching the email lists and found that setting the HAVE_PTHREAD
option to cmake resolves this, in quite a satisfactory way.  However, I
usually just install PLplot from my distro's package manager, especially
on a new machine, because of the considerable dependencies.

Is there any (good) reason that pthreads is not enabled by default, and
thus enabled in the version downloaded from each distribution's
repository?  I don't know how that would work for packaging, how often
pthreads are installed by default, or if that would generate a huge
dependency, but it seems so convenient...

cheers,
Derek

Re: [Plplot-general] Confused...

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

On 2008-12-18 16:24+0100 Werner Smekal wrote:

> Hi,
>
> by default only 16 colors are available. You need to change the number
> of colors in map0
>
> http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.0/plscmap0n.html
>
> Then it should be straight forwarded to set the colors in the map with
>
> http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.0/plscmap0.html
>

I have some additional references for you.
http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.0/color.html
provides overall general background on the PLplot colour systems. Also,
please look at examples/perl/x02.pl, the Perl/PDL implementation of our
second standard example.  It has 116 colours.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-general] Confused...

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

Hi,

by default only 16 colors are available. You need to change the number  
of colors in map0

http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.0/plscmap0n.html

Then it should be straight forwarded to set the colors in the map with

http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.0/plscmap0.html

HTH,
Werner

On 18.12.2008, at 15:39, Kåre Edvardsen wrote:

> Hi all.
>
> I'd like to set up a colormap in the way that when I call for a  
> color it should follow the rainbow style by increasing number in the  
> range 0-255, like:
>
> plcol0(0): black
> plcol(255): white
>
> and in between: blue -> green -> yellow -> red
>
> I've tried looking into the plcmap0 stuff, but I cant get it to work  
> in my perl code.
>
> Cheers,
> Kare
>
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,  
> Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to  
> help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/_______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: sm...@ia...
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

[Plplot-general] Confused...

[Kåre E. <ke...@ni...>]

Hi all.

I'd like to set up a colormap in the way that when I call for a color it
should follow the rainbow style by increasing number in the range 0-255,
like:

plcol0(0): black
plcol(255): white

and in between: blue -> green -> yellow -> red 

I've tried looking into the plcmap0 stuff, but I cant get it to work in
my perl code.

Cheers,
Kare

Re: [Plplot-general] Solved [Re: Access violation: PLplot 5.9.0, wxWidgets 2.8.0 (Debug build), MINGW]

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

Hi Philipp,

> In short, the only change I did was to upgrade to PLplot 5.9.1 - and now it works!

The wxWidgets code in PLplot 5.9.1 was tested on lot more compiler/OS
combinations so there were good chances that your problems were already
fixed - as it was the case.

> >> I've a problem with configuring, building and running a debug build of
> >> PLplot 5.9.0 with a debug build of wxWidgets 2.8.0 under MINGW (using GCC
> >> 3.4.5).
> >
> > You working with the MinGW compiler in a MSYS environment, right?
> 
> Right.

Good to know that PLplot with wxWidgets also works on MSYS since this
toolkit I didn't test so far!


> >> My configuration and building steps are as follows (from the root dir of
> >> the PLplot distribution):
> >>
> >> PATH=/c/Program\ Files/CMake/bin:$PATH
> >> export PATH
> 
> By the way: PLplot 5.9.1 needs the wxWidgets dlls in the PATH already at this point in time. I'm not sure whether 5.9.0 really didn't or whether I just forget "documenting" it in my last email.

The reason is, that we implemented dynamic drivers now also on Windows -
that means that every driver is compiled into it's own dll. From this
dll during the build a config file will be built, therefore we already
need to find the dll during compilation. Mind though, that I never
tested this case (dynamic drivers) outside of the build tree. If you
give your code to the user problems might occur. As long as the dynamic
driver dlls are in the same directory as the executable or in the PATH
it should work. You can turn off the dynamic drivers with
-DENABLE_DYNDRIVERS=OFF during the cmake configuration step. The drivers
are then linked into the plplot dll.

Great, that it worked for you.

Regards,
Werner

-- 
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: sm...@ia...
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

[Plplot-general] Solved [Re: Access violation: PLplot 5.9.0, wxWidgets 2.8.0 (Debug build), MINGW]

[Philipp B. <bac...@we...>]

Hi Werner, hi all,

thank you very much for the quick answer. It took a while to get back to you because of a backlog of higher priority tasks.

In short, the only change I did was to upgrade to PLplot 5.9.1 - and now it works!

The long answer below just for the curious...

>> I've a problem with configuring, building and running a debug build of
>> PLplot 5.9.0 with a debug build of wxWidgets 2.8.0 under MINGW (using GCC
>> 3.4.5).
>
> You working with the MinGW compiler in a MSYS environment, right?

Right.

> Are you
> using wxWidgets 2.8.0 for a special reason? There is already wxWidgets 2.8.9
> available, which I use without problems.

I already implemented tons of stuff on top of wxWidgets. My code also works with 2.8.9, but there is a small issue with grids of the more recent version (either with my code or with wxWidgets). In large grids wxGrid seems to scroll back to the first column after some cell was edited, and this is not what I wanted to give to the users of my code, so I downgraded to 2.8.0. Of course, as soon as I have more time, I will change my code such that it does circumwind this issue with 2.8.9.

> Which version of cmake are you
> using?

2.6.2.

>> My configuration and building steps are as follows (from the root dir of
>> the PLplot distribution):
>>
>> PATH=/c/Program\ Files/CMake/bin:$PATH
>> export PATH

By the way: PLplot 5.9.1 needs the wxWidgets dlls in the PATH already at this point in time. I'm not sure whether 5.9.0 really didn't or whether I just forget "documenting" it in my last email.

>...

>> "wxWidgets_USE_DEBUG" is described in the CMake manual. Everything seems
>> to work fine. I can use MS Dependency Walker to check whether PLplot linked
>> against the correct wxWidgets dlls, and it looks good, i.e. wx-config knows
>> of both my release and my debug build of wxWidgets.
>
> Does it link against the debug libraries (libwxcore2.8d.dll or similar) if
> you use -DwxWidgets_USE_DEBUG=ON.

Yes, iff wx-config can find it. . I checked that with MS Dependency Walker.

> And does it link against the release
> libraries (libwxcore2.8.dll) if you skip this option.

Yes, iff wx-config can find it. I also checked this with MS Dependency Walter. According to the CMake manual, -DwxWidgets_USE_DEBUG=OFF does the same.

> For that reason I usually use the release version of the wxWidgets library,
> even if I compile the plplot library in debug mode. Usually I don't need to
> debug the wxWidgets code, so no problem here. If this is acceptable for you,
> I would also just do it that way.

This would have been my last resort.

Thank you again, cheers,
Philipp.

____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört? 
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123

[Plplot-general] PLplot 5.9.1 is now available

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

Hello,

The 5.9.1 development release of PLplot is now available. This  
release includes large number of improvements from 5.9.0, of which  
the following is a brief list:
1) A new PLplot function, plimagefr.
2) Improvements to the cairo driver family.
3) wxWidgets driver improvements.
4) pdf driver improvements.
5) svg driver improvements.
6) Ada language support improvements.
7) OCaml language support improvements.
8) Perl/PDL language support improvements.
9) Updates to various language bindings.
10) Updates to various examples.
11) Rename test subdirectory to plplot_test.
12) Website support files updated.
13) Internal changes to function visibility.
14) Dynamic driver support in Windows.
15) Documentation updates.

Development releases in the 5.9.x series will be available in the  
coming months and the next stable release will be 5.10.0.

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] build in separate directory

[Alexy K. <del...@gm...>]

Ah, I see what the issue was -- I first called

cmake .

-- in the source directory; then calling cmake /path/to/source from a  
separate build directory still placed the Makefile in the original  
source.

I guess the desired behavior would be to notice we're in a new build  
directory and switch to it, instead of clinging to the source.

I had to move aside the old source and checkout anew to be able to  
follow the wiki...  But now it all built fine.  One snag was, I had  
Intel Fortran with an expired trial, and cmake choked on that -- it  
could call ifort, but it returned error on exit.  This is basically  
not worse than not having it, so it should have simply been disabled  
(and I do have gfortran on which cmake could have fallen back, but  
didn't).

Overall, an interesting thing, cmake.  I used ccmake to tweak its  
settings, and it's rather amusing.  The make is with colors and  
progress percentages, very cool.
Cheers,
Alexy

Re: [Plplot-general] Access violation: PLplot 5.9.0, wxWidgets 2.8.0 (Debug build), MINGW

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

Hi Philipp,

I just need more information to be of any help.

On 11.12.2008, at 11:21, Philipp Bachmann wrote:

> I've a problem with configuring, building and running a debug build  
> of PLplot 5.9.0 with a debug build of wxWidgets 2.8.0 under MINGW  
> (using GCC 3.4.5).

You working with the MinGW compiler in a MSYS environment, right? Are  
you using wxWidgets 2.8.0 for a special reason? There is already  
wxWidgets 2.8.9 available, which I use without problems. Which version  
of cmake are you using?
>

> My configuration and building steps are as follows (from the root  
> dir of the PLplot distribution):
>
> PATH=/c/Program\ Files/CMake/bin:$PATH
> export PATH
>
> $ mkdir gxxBuild-mingw-Debug
> $ cd gxxBuild-mingw-Debug
> cmake .. -G "MSYS Makefiles" -DBUILD_TEST=ON \
> -DCMAKE_VERBOSE_MAKEFILE=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON \
> -DENABLE_wxwidgets=ON -DwxWidgets_USE_DEBUG=ON - 
> DCMAKE_BUILD_TYPE=Debug
> make

Some remarks: you don't need CMAKE_VERBOSE_MAKEFILE=ON, just skip that  
and if you want verbose output run

make VERBOSE=1

So far I didn't know about -DwxWidgets_USE_DEBUG=ON, but I never used  
MSYS, since I don't like it. I practically only use MinGW in Windows  
CLI.
>
>
> "wxWidgets_USE_DEBUG" is described in the CMake manual. Everything  
> seems to work fine. I can use MS Dependency Walker to check whether  
> PLplot linked against the correct wxWidgets dlls, and it looks good,  
> i.e. wx-config knows of both my release and my debug build of  
> wxWidgets.

Does it link against the debug libraries (libwxcore2.8d.dll or  
similar) if you use -DwxWidgets_USE_DEBUG=ON. And does it link against  
the release libraries (libwxcore2.8.dll) if you skip this option.
>
>
> Then I wanted to test it:
> I copy the *.fnt files to the respective example directory and let  
> PATH additionally point to gxxBuild-mingw-Debug/dll (because I did  
> not yet "make install" PLplot) and to the wxWidgets dlls.

sounds good.

> Then regardless of the example (e.g. c++/x10 or c++/wxPLplotDemo)  
> very soon a crash occurs (Access Violation).

When does it crash? Before you can select a driver? Does the wingcc  
driver work?

> I can simulate a run with MS Dependency Walker - there I see the  
> crash happens in NTDLL soon after the dll the example depends on  
> have been loaded. This crash also happens without - 
> DENABLE_wxwidgets=ON, but with -DwxWidgets_USE_DEBUG=ON.

If the wxWidgets bindings are disabled, wxPLplotDemo shouldn't be  
build, but the wxWidgets driver should still be available.
>
>
> This does not happen iff I configure without -DwxWidgets_USE_DEBUG=ON.

I have problems with cmake, since if you want to use the debug version  
of the wxwidgets library, cmake links to the correct debug library,  
but doesn't define the WXDEBUG macro in the command line (I don't know  
about MSYS, since wx-config should actually provide the correct  
settings). Therefore the wxWidgets code in the plplot library  
"believes" that it will be linked against the release library. Usually  
you get a message box at the startup telling you, that the code and  
the wxWidgets library don't fit and exits. I already asked the cmake  
developers to change that, but this didn't happen so far. It crashes  
maybe for you, since you use an older wxWidgets version.

For that reason I usually use the release version of the wxWidgets  
library, even if I compile the plplot library in debug mode. Usually I  
don't need to debug the wxWidgets code, so no problem here. If this is  
acceptable for you, I would also just do it that way.

One other proposal: You could run the example in gdb and print out the  
backtrace to see where it exactly crashes.

In any case I would suggest, that you use the latest cmake version  
(2.6.2 or 2.6.3?) and the latest wxWidgets version (2.8.9). You could  
also try a "newer" PLplot version, we provide weekly source packages  
here

http://www.miscdebris.net/plplot_weeklies/

There were a lot of improvements/changes especially for the wxWidgets  
driver, so you may try one of the later source packages or wait until  
next week, when PLplot 5.9.1 should be released.

Best Regards,
Werner

>
>
> Is there a cure to this problem?
>
> Thanks in advance, cheers,
> Philipp.
>
> _______________________________________________________________________
> Sensationsangebot verlängert: WEB.DE FreeDSL - Telefonanschluss + DSL
> für nur 16,37 Euro/mtl.!* http://dsl.web.de/? 
> ac=OM.AD.AD008K15039B7069a
>
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,  
> Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to  
> help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Plplot-general mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-general

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: sm...@ia...
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

[Plplot-general] Access violation: PLplot 5.9.0, wxWidgets 2.8.0 (Debug build), MINGW

[Philipp B. <bac...@we...>]

Dear experts,

I've a problem with configuring, building and running a debug build of PLplot 5.9.0 with a debug build of wxWidgets 2.8.0 under MINGW (using GCC 3.4.5).

My configuration and building steps are as follows (from the root dir of the PLplot distribution):

PATH=/c/Program\ Files/CMake/bin:$PATH
export PATH

$ mkdir gxxBuild-mingw-Debug
$ cd gxxBuild-mingw-Debug
cmake .. -G "MSYS Makefiles" -DBUILD_TEST=ON \
-DCMAKE_VERBOSE_MAKEFILE=ON -DDEFAULT_NO_BINDINGS=ON -DENABLE_cxx=ON \
-DENABLE_wxwidgets=ON -DwxWidgets_USE_DEBUG=ON -DCMAKE_BUILD_TYPE=Debug
make

"wxWidgets_USE_DEBUG" is described in the CMake manual. Everything seems to work fine. I can use MS Dependency Walker to check whether PLplot linked against the correct wxWidgets dlls, and it looks good, i.e. wx-config knows of both my release and my debug build of wxWidgets.

Then I wanted to test it:
I copy the *.fnt files to the respective example directory and let PATH additionally point to gxxBuild-mingw-Debug/dll (because I did not yet "make install" PLplot) and to the wxWidgets dlls. Then regardless of the example (e.g. c++/x10 or c++/wxPLplotDemo) very soon a crash occurs (Access Violation). I can simulate a run with MS Dependency Walker - there I see the crash happens in NTDLL soon after the dll the example depends on have been loaded. This crash also happens without -DENABLE_wxwidgets=ON, but with -DwxWidgets_USE_DEBUG=ON.

This does not happen iff I configure without -DwxWidgets_USE_DEBUG=ON.

Is there a cure to this problem?

Thanks in advance, cheers,
Philipp.

_______________________________________________________________________
Sensationsangebot verlängert: WEB.DE FreeDSL - Telefonanschluss + DSL
für nur 16,37 Euro/mtl.!* http://dsl.web.de/?ac=OM.AD.AD008K15039B7069a

Re: [Plplot-general] build in separate directory

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

On 2008-12-11 00:57-0500 Alexy Khrabrov wrote:

> I've checked plplot out of svn, and followed instructions from the
> wiki at
>
> http://www.miscdebris.net/plplot_wiki/index.php?title=Building_PLplot
>
> Now there's no plplot_cmake at the top level of the svn distro.  If I
> just specify the plplot directory, cmake does generate a Makefile --
> in the source directory.  Trying to run it form a separate build
> directory doesn't work.

The last option of the svn checkout command is the name of the (initially
empty) directory where you want the source tree to be downloaded.  So it
appears from above that you specified plplot rather than plplot_cmake, but
you can use any name you desire.

Then to build in an initially empty build tree do the following

1. Create the empty build directory and cd to it.

N.B. the "build_dir" name is arbitrary and you can use anything for that so
long as you are consistent and you don't mind the directory being initially
destroyed by the rm -rf command.

rm -rf build_dir
mkdir build_dir
cd build_dir

2. Do the configuration, build, and install.

# Replace ../plplot_cmake with whatever you have named your svn checkout
# directory.  -Doptions can be a lot of things mentioned in the wiki.
cmake -Doptions ../plplot_cmake

make

#ctest is optional and requires -DBUILD_TEST=ON cmake option above
ctest

# Installs in prefix directory you specify by appropriate -D option for
# above cmake command.
make install

Hope this overview helps.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] build in separate directory

[Alexy K. <del...@gm...>]

I've checked plplot out of svn, and followed instructions from the  
wiki at

http://www.miscdebris.net/plplot_wiki/index.php?title=Building_PLplot

Now there's no plplot_cmake at the top level of the svn distro.  If I  
just specify the plplot directory, cmake does generate a Makefile --  
in the source directory.  Trying to run it form a separate build  
directory doesn't work.

Can you please show the command sequence necessary to build in a  
separate directory?

Cheers,
Alexy

Re: [Plplot-general] plplot on mac osx with macports +no_x11

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

On 2008-12-10 11:24-0500 Alexy Khrabrov wrote:

> Greetings -- I've built the whole gnome thing in macports with
> +no_x11, using gtk-osx.  Which configuration options should be given
> to plplot so that it doesn't use X11 at all, but only the quartz?
> Apparently the portfile for plplot in the current macports doesn't
> include the variant +no_x11, and I'd like to concoct one myself after
> I thoroughly understand what it needs to hear.

Our CMake-based build system looks for X, but if it is not present the build
system sets certain CMake variables which are then used to automatically
exclude the X-dependent components such as Tk language support and the
xwin and tk device drivers.

So I suspect you don't have to do anything at all.  If you do try a PLplot
build in an environment without X, and our build system logic tries to build
an X-dependent component of PLplot in error, please let us know so we can
fix that build-system bug.

Note you also have complete hands-on control of what components of PLplot
are built, if you don't like these build decisions to be made automatically.
For example, if you want to specifically disable the tk language then
specify -DENABLE_tk=OFF as a cmake option.  (That should automatically
disable the tk device as well.) If you want to specifically disable the xwin
device, then specify -DPLD_xwin=OFF as a cmake option.

Hope this response to your question helps, and good luck with your use of
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 libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-general] plplot on mac osx with macports +no_x11

[Alexy K. <del...@gm...>]

Greetings -- I've built the whole gnome thing in macports with
+no_x11, using gtk-osx.  Which configuration options should be given
to plplot so that it doesn't use X11 at all, but only the quartz?
Apparently the portfile for plplot in the current macports doesn't
include the variant +no_x11, and I'd like to concoct one myself after
I thoroughly understand what it needs to hear.

Cheers,
Alexy

Re: [Plplot-general] Installation problem on Linux RH3

[<Han...@sh...>]

Werner,

I already updated the code to do what you just described and that works fine for me. Hopefully we will get rid of these older OS's at the end of the year (but you never know), so then the problem won't be there anymore.

Thanks for the quick response,
Hans

-----Original Message-----
From: Werner Smekal [mailto:sm...@ia...]
Sent: Wednesday, December 10, 2008 12:33
To: Rijneke, Hans H SIEP-EPT-RIS
Cc: and...@us...;
plp...@li...
Subject: Re: [Plplot-general] Installation problem on Linux RH3


Hi Hans,

I just commited a change to svn, although I couldn't test it. Anyway,  
I think there was a function definition still not encompassed by the  
correct #ifdef/#endif code. Either check out the latest svn or change  
the following lines in drivers/gd.c:

from line 233 on:

int plToGdAlpha( PLFLT a ) {
   int tmp = (int)((1.0-a)*gdAlphaMax);
   return tmp;
}

to

#if GD2_VERS >= 2
int plToGdAlpha( PLFLT a ) {
   int tmp = (int)((1.0-a)*gdAlphaMax);
   return tmp;
}
#endif

Let us know if this works for you, since nobody here still has gd 1.8.

Thanks,
Werner

On 10.12.2008, at 11:44, <Han...@sh...> <Han...@sh... 
 > wrote:

> Andrew,
>
> I just downloaded the 5.9.0 release and get the same error about the  
> alpha channel again. Did the fix not make it into this release and  
> if not in which release will it be ?
>
> Thanks,
> Hans
>
>

--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria

email: sm...@ia...
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