plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Error when extracting Octave docs from api.xml

[Rafael L. <lab...@ps...>]

* João Cardoso <jc...@fe...> [2003-03-07 15:26]:

> 
> Hi,
> 
> I got the following error with a clean cvs.
> 
> ...
> mkdir -p plplot_octave_txt
> cp etc/plplot.doc plplot_octave_txt/plplot.doc
> cd plplot_octave_txt; \
> ../../../doc/docbook/bin/api2text.pl \
> ../../../doc/docbook/src/plplotdoc.xml.in \
> ../../../doc/docbook/src/api.xml
> 
> undefined entity at line 2858, column 62, byte 84237 at 
> /usr/lib/perl5/site_perl
> /5.8.0/i586-linux-thread-multi/XML/Parser.pm line 185
> make[4]: *** [plplot_octave_txt/plplot.doc] Error 255
> 
> 
> I never was able to build the docbook documentation, but there was no 
> problem in running the scripts that generated the online Octave docs.

It works fine here.  To prove it, I am attaching below the resulting file
plgriddata.txt, which never existed before.  I need more information in
order to understand where your bug comes from.

-- 
Rafael

[Plplot-devel] Error when extracting Octave docs from api.xml

[<jc...@fe...>]

Hi,

I got the following error with a clean cvs.

...
mkdir -p plplot_octave_txt
cp etc/plplot.doc plplot_octave_txt/plplot.doc
cd plplot_octave_txt; \
../../../doc/docbook/bin/api2text.pl \
../../../doc/docbook/src/plplotdoc.xml.in \
../../../doc/docbook/src/api.xml

undefined entity at line 2858, column 62, byte 84237 at 
/usr/lib/perl5/site_perl
/5.8.0/i586-linux-thread-multi/XML/Parser.pm line 185
make[4]: *** [plplot_octave_txt/plplot.doc] Error 255


I never was able to build the docbook documentation, but there was no 
problem in running the scripts that generated the online Octave docs.

Joao

[Plplot-devel] Re: Debian + tarball announcements

[Rafael L. <lab...@ps...>]

* Rafael Laboissiere <lab...@ps...> [2003-03-06 17:23]:

> Two good news for today:
> 
> 1) I succeeded to generated the first release candidate tarball from the CVS
>    sources using "make dist".  I tested it in the context of my Debian
>    packaging, so I have no idea if it will work corectly elsewhere
>    (actually, I would be surprised if it work perfectly).  Please, test it.
>    The URL is:
>    
>        http://people.debian.org/~rafael/plplot-5.2.0.cvs.20030306.tar.gz 

Since I will upload new tarballs from time to time, the file name in the url
will, of course, change.  I have setup an HTML redirect at:

    http://people.debian.org/~rafael/plplot.html

This URL will always point to the latest version.
 
-- 
Rafael

[Plplot-devel] Debian package for woody

[Rafael L. <lab...@ps...>]

PLplot CVS snapshopt packages for Debian woody are made available by 
Christian Steigies <ct...@de...>.  They are apt-getable with:

    deb http://people.debian.org/~cts/ dists/woody/main/binary-$(ARCH)/
    deb http://people.debian.org/~cts/ dists/woody/main/binary-all/
    deb-src http://people.debian.org/~cts/ woody main

$(ARCH) will expand to the correct architecture, so put the lines above
as-is in /etc/apt/sources.list.  For now, Christian is making i386 and m68k
packages available.  Unfortunately, python-plplot is not available (yet).

A big thanks to Christian.

-- 
Rafael

[Plplot-devel] Re: Debian + tarball announcements

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-03-06 11:06]:

> A practical question.  How do we do this for ourselves?  make won't work
> until you configure.

This is the recipe:

    cvs co plplot
    cd plplot
    ./bootstrap.sh
    ./configure --enable-docbook --enable-python
    make dist

Of course, for that to work you must have the Docbook tools, the latest Swig
and the appropriate version of the Autotools.  The recipe above should
produce the same tarball as mine, apart the version number. I apply a little
trick to change the version string based on the current date.  The gory
details are in scripts/make-cvs-tarball.sh.

> Is the tarball result completely independent of what the configuration
> options are? For example, if you disable all drivers except null and
> disable all front ends do you still get the same tarball result? Also, what
> happens if you do/don't enable the documentation building?

There are two issues here.  First, the resulting tarball should contain at
least all the files that are in CVS (except the evident exclusions like
new/, tmp/, and friends) regardless of the configure options. This is a
matter of having the EXTRA_DIST variables (and others associated with them)
declared outside the Automake conditionals.  This is not the case at
present.  I tried to fix some cases, but there are some old style stuff in
some of the Makefile.am's.  I will try to sort out the problems.

The second issue is about the things that are built to be included in the
tarball, like the printable, html, info, and man forms of documentation and
the Swig related stuff (for now, I just tried Python, not Java).  I am not
yet sure that my logic in the relevant Makefile.am's is fully correct.

At any rate, the recipe above should work for now.

> Excellent news.  And I second your thanks to David for keeping this going
> while you were otherwise engaged.  That is a long and impressive list of
> Debian bug reports that this release addresses, [...]

Actually, David _fixed_ a lot of those reported bugs.  I just _closed_ them
with the upload because only the official maintainer can close bugs through
the dinstall (Debian installer) interface.

> [...] and I expect the additional bug reports from the Debian community on
> your new packages will be a great benefit to PLplot as a whole.  Also, for
> this same reason I hope your packages will shortly migrate to testing where
> there are many more Debian users/testers.

There is a another Debian developer who is currently backporting my packages
to woody. More on that later, keep tuned.

-- 
Rafael

Re: [Plplot-devel] Debian + tarball announcements

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

On Thu, 6 Mar 2003, Rafael Laboissiere wrote:

> Two good news for today:
>
> 1) I succeeded to generated the first release candidate tarball from the CVS
>    sources using "make dist".  I tested it in the context of my Debian
>    packaging, so I have no idea if it will work corectly elsewhere
>    (actually, I would be surprised if it work perfectly).  Please, test it.
>    The URL is:
>
>        http://people.debian.org/~rafael/plplot-5.2.0.cvs.20030306.tar.gz

Thanks for all your efforts in getting make dist to work.

A practical question.  How do we do this for ourselves?  make won't work
until you configure.  Is the tarball result completely independent of what
the configuration options are?  For example, if you disable all drivers
except null and disable all front ends do you still get the same tarball
result? Also, what happens if you do/don't enable the documentation
building?

Side note: I don't have much time for PLplot at the moment, but my highest
priority is to get the documentation builds working on RedHat (and
eventually SuSe with Joao's cooperation).  (I have decided to put off
worrying about libpthread linking until after the release since it is turned
off by default in any case.) So soon I hope others besides the Debian users
here (Rafael, Andrew, and me) should be able to make a tarball with this
approach.

>
> 2) The new set of PLplot Debian packages has been accepted in the
>    distribution.See message in:
>
>        http://lists.debian.org/debian-devel-changes/2003/debian-devel-changes-200303/msg00420.html

Excellent news.  And I second your thanks to David for keeping this going
while you were otherwise engaged.  That is a long and impressive list of
Debian bug reports that this release addresses, and I expect the additional
bug reports from the Debian community on your new packages will be a great
benefit to PLplot as a whole.  Also, for this same reason I hope your
packages will shortly migrate to testing where there are many more Debian
users/testers.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

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

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

[Plplot-devel] Debian + tarball announcements

[Rafael L. <lab...@ps...>]

Two good news for today:

1) I succeeded to generated the first release candidate tarball from the CVS
   sources using "make dist".  I tested it in the context of my Debian
   packaging, so I have no idea if it will work corectly elsewhere
   (actually, I would be surprised if it work perfectly).  Please, test it.
   The URL is:
   
       http://people.debian.org/~rafael/plplot-5.2.0.cvs.20030306.tar.gz 

2) The new set of PLplot Debian packages has been accepted in the
   distribution.  See message in:

       http://lists.debian.org/debian-devel-changes/2003/debian-devel-changes-200303/msg00420.html

    The packages will be soon available at the following urls:
    
       htpp://packages.debian.org/<package>
       
    where <package> is one of:
    
       libplplot5
       libplplot-dev
       plplot-xwin
       plplot-gnome
       plplot-tcl
       plplot-gd
       python-plplot
       octave-plplot
       libplplot-dev
       plplot-tcl-dev
       plplot-doc
    
-- 
Rafael

Re: [Plplot-devel] --with-pthreads: Use pthreads with the xwin driver!

[<jc...@fe...>]

On Wednesday 05 March 2003 00:06, Joao Cardoso wrote:
| Hi,
|
| The xwin driver has been plagued for ages with a severe problem:
| whenever the user program goes to lengthly calculations, without
| doing any calls to PLplot, the plot window couldn't be refreshed if
| obscured by other windows. Nor resized.
|
| You can quickly watch this behavior if you insert a getchar()
| statement just before plend() in x01c.c. The getchar() call simulates
| the user program doing other jobs and not calling any plplot API. If
| you now obscure the plot window you will see that it is not redrawn
| (of course).
|
| This behaviour is most inconvenient for interactive languages like
| Octave or python, where the same behaviour is observed while the user
| is typing commands at the prompt.
|
| The obvious solution would be to write a xwin server or daemon, like
| the tk driver plserver, but that means a lot of work. Instead, I have
| implemented, and cvs commit, a threaded xwin driver. It updates and
| resizes the plot window, if needed.
|
| This feature is disabled by default at configure time.
|
| For most compiled programs, it can be safely turned on, even if the
| host program is not threads aware.
| For already build programs that somehow use PLplot, usually loading
| it as an extension, as Octave or python or tk does, things are a bit
| complicated, as those programs must themself be linked with the
| pthread library, even if not thread aware!
|
| For example, in my system Octave is build by default without being
| linked with pthreads, because Octave is not threads aware. To use the
| new threads enabled xwin driver, I have to *relink* (only) octave
| with -lpthread, and after that all goes well.
|
| Python, by contrary, is already linked with the pthreads library, so
| nothing special needs to be done -- the threads enabled xwin driver
| works without a problem with python.
|
| This is the reason why --with-pthreads=no by default, and should not
| be turned on.

Perhaps in a future development it will be enabled  by default at 
configure time but disabled by default at run-time. To enable it at 
run-time one could use a driver-specific option, like -drvopt pthreads.
This would be the best of both words.

Joao

Re: [Plplot-devel] a small patch to PLplot

[Rafael L. <lab...@ps...>]

* Doug Hunt <dh...@uc...> [2003-03-05 14:43]:

> >Great.  When is the next release of PDL (or your module) expected to come
> >out?
> >
> Hopefully soon, but no date has been set.  I would guess 1-2 months.

Super.  That will coincide with the next release of PLplot.

> OK, I now changed my auto-detector in Makefile.PL to do a test compile and
> check the allowed number of args in plpoly3 instead of looking at the
> library version.  I can't assume that any target system will have
> pkg-config installed.

You might also use the plgver API function.

> All: Please keep the API-breaking changes to an absolute minimum!  The 
> code for perl/PDL to detect different versions is ugly and takes much time
> to maintain.  It would have been preferable to just create a new plpoly3
> function with the extra argument instead of changing the old one.

I agree 100 % with you.  I think that the changes in the API were
inappropriate, both in plpoly3 and plend1/plend.  This was done probably
because we thought that PLplot were not yet a so big and important project
and that users usually recompile their applications for every release. We
wrongly thought then that "improving" the API by breaking backward
compatibility would be a service to the community.

However, since PLplot is marching towards ubiquitous presence (call it World
domination, if you want :-) we have to be careful with this kind of
breakage. Indeed, there will be users around not willing to upgrade from
5.1.1 to 5.2.0, but wanting to install bindings like the PDL one.
Fortunately, you detected the problem and will cope with it in your PDL
module.  We have only to apologize our users for this mess.

Even worse, in the last release we were not careful enough as regards the
soname versioning.  With 5.2.0 installed, the system dynamic linker/loader
will happily link programs compiled for 5.1.1 with the new library and these
applications are likely to crash.  The system loader does this (at least the
ld.so of Linux) because the libraries in version 5.1.1 and 5.2.0 have the
same soname (libplplot5), although there are backward incompatibilities.
Actually, the soname for 5.2.0 must have been libplplot6.  Too late, too
bad...

We will try to be more careful on these issues in the future.

-- 
Rafael

Re: [Plplot-devel] a small patch to PLplot

[Doug H. <dh...@uc...>]

Rafael:


>* Doug Hunt <dh...@uc...> [2003-03-05 10:03]:
>
>  
>
>>I just checked the PDL::Graphics::PLplot interface (I dropped the 'OO') 
>>into the PDL CVS.  There are some bugs still which I plan on fixing 
>>today.  It has conditional compile support for both plplot versions 
>>5.1.1 and 5.2.0.
>>    
>>
>
>Great.  When is the next release of PDL (or your module) expected to come
>out?
>
Hopefully soon, but no date has been set.  I would guess 1-2 months.

>
>  
>
>>BTW:  Is there a better way of determining the version of plplot 
>>installed on a system besides looking at the file name that the 
>>libplplotd.so symlink points to?
>>    
>>
>
>Please, never, never, NEVER, do this.  Although the library soname have
>coincided with the package version up to now, this is not going to be
>necessarily the case in the future.
>

OK, I now changed my auto-detector in Makefile.PL to do a test compile 
and check the allowed number of
args in plpoly3 instead of looking at the library version.  I can't 
assume that any target system
will have pkg-config installed.

All:  Please keep the API-breaking changes to an absolute minimum!  The 
code for perl/PDL to detect
different versions is ugly and takes much time to maintain.  It would 
have been preferable to just create
a new plpoly3 function with the extra argument instead of changing the 
old one.

Thanks!

  Doug Hunt

>
>If you have pkg-config installed, you can use 
>
>    pkg-config plplot-double --modversion
>
>if PLplot was build --with-double, or
>
>    pkg-config plplot --modversion
>
>if not.
>
>For more information on pkg-config, see:
>
>    http://www.freedesktop.org/software/pkgconfig/
>
>  
>

Re: [Plplot-devel] a small patch to PLplot

[Rafael L. <lab...@ps...>]

* Doug Hunt <dh...@uc...> [2003-03-05 10:03]:

> I just checked the PDL::Graphics::PLplot interface (I dropped the 'OO') 
> into the PDL CVS.  There are some bugs still which I plan on fixing 
> today.  It has conditional compile support for both plplot versions 
> 5.1.1 and 5.2.0.

Great.  When is the next release of PDL (or your module) expected to come
out?

> BTW:  Is there a better way of determining the version of plplot 
> installed on a system besides looking at the file name that the 
> libplplotd.so symlink points to?

Please, never, never, NEVER, do this.  Although the library soname have
coincided with the package version up to now, this is not going to be
necessarily the case in the future.

If you have pkg-config installed, you can use 

    pkg-config plplot-double --modversion

if PLplot was build --with-double, or

    pkg-config plplot --modversion

if not.

For more information on pkg-config, see:

    http://www.freedesktop.org/software/pkgconfig/

-- 
Rafael

Re: [Plplot-devel] a small patch to PLplot

[Doug H. <dh...@uc...>]

Thanks, Rafael!

I just checked the PDL::Graphics::PLplot interface (I dropped the 'OO') 
into the PDL CVS.  There are some bugs still which I plan on fixing 
today.  It has conditional compile support for both plplot versions 
5.1.1 and 5.2.0.

BTW:  Is there a better way of determining the version of plplot 
installed on a system besides looking at the file name that the 
libplplotd.so symlink points to?

Regards,

  Doug

Rafael Laboissiere wrote:

>* Doug Hunt <dh...@uc...> [2003-03-04 15:32]:
>
>  
>
>>The patch is attached, along with the complete new version of plsym.c. 
>>This patch affects the plmtex() function.  Currently one can plot left and
>>right of the axis, with text parallel or perpendicular to the axis by
>>specifying 'side' = ('l', 'r', 'lv' or 'bv').  One cannot, however, plot 
>>with text perpendicular to the axis on the top or bottom.  My patch adds
>>the 'tv' and 'bv' specifiers.  I have tested this under linux and it seems
>>to work.
>>
>>Could you apply this patch to the current CVS?
>>    
>>
>
>I applied your patch and it seems to work correctly.  Since it does not
>break anything and does not introduce backwards incompatibilities, I went on
>and CVS committed it.  The documentation in doc/docboook/src/api.xml has
>been also updated accordingly.
>
>Thanks for your contribution.
>
>How is the work on the PLplotOO module going?
>
>  
>

Re: [Plplot-devel] --with-pthreads: Use pthreads with the xwin driver!

[<jc...@fe...>]

On Wednesday 05 March 2003 01:16, Alan W. Irwin wrote:
| On Wed, 5 Mar 2003, Joao Cardoso wrote:
| > For most compiled programs, it can be safely turned on, even if the
| > host program is not threads aware.
| > For already build programs that somehow use PLplot, usually loading
| > it as an extension, as Octave or python or tk does, things are a
| > bit complicated, as those programs must themself be linked with the
| > pthread library, even if not thread aware!
|
| I believe the best solution here is simply to link xwin with
| -lpthread consistent with the hierarchichal linking paradigm we are
| using. That way, all pthread symbols in the xwin driver should be
| resolved, and you shouldn't have to do any special linking of octave,
| wish, tclsh, etc.  This is for the dynamic drivers case.  In the
| static drivers case it is a little bit more complicated; the xwin
| driver becomes part of libplplot, and therefore, libplplot has to be
| linked with -lpthread.
|
| The short story: make Makefile.am changes for the xwin driver
| following what happens for the gd driver special libraries (libgd,
| libpng, etc) as a model both for the dynamic and static drivers
| cases.
|
| If you or Rafael don't have time to fiddle with this, I will have a
| look this weekend.  If it works out, then perhaps you will not have
| to turn off pthreading by default.

I don't things are as simple as that.

Adding the pthread library to a program not only adds more 
functionalities to it but also changes the way how it is executed and 
how certain global variables (errno, e.g.) are acessed.

When a program not linked with pthreads loads the xwin driver, and 
implicitly the pthreads library, as you suggest, it is too late for it 
to adapt to the new execution model.

But you can try. I'm no threads expert.
Don't forget to try with already compiled programs that load plplot, 
octave or python, e.g., and are/are not linked with pthreads by 
default.
Please report your experiences before commiting things.

Joao

|
| Alan
| __________________________
| Alan W. Irwin
| email: ir...@be...
| phone: 250-727-2902
|
| Astronomical research affiliation with Department of Physics and
| Astronomy, University of Victoria (astrowww.phys.uvic.ca).
|
| Programming affiliations with the Canadian Centre for Climate
| Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot
| scientific plotting software package (plplot.org).
|
| __________________________
|
| Linux-powered Science
| __________________________

[Plplot-devel] pkg-config files

[Rafael L. <lab...@ps...>]

I recently moved the files plplot-double.pc and plplot.pc into the pkgcfg
directory.  This files used to be at the top_builddir.  I would prefer to
call the directory pkg-config or pkgconfig, but I am sticking to shorter
names, as ususal in our source tree.

If we need to add more *.pc files to the project, we will use from now the
pkgcfg directory, instead of polluting the top_builddir.  Since we are now
distributing the nn and csa libraries, we may in the future provide nn.pc
and csa.pc files.  Also, I may in the future provide a pkg-config file
plplot-tcl.pc, for specific compilation of PLplot Tcl/Tk stuff.

If you are completely lost and do not know about what I am talking about,
take a look at 

    http://www.freedesktop.org/software/pkgconfig/

pkg-config is a powerful tool that is a replacement for all those *-config
scripts that several projects used to have to provide compilation and link
flags, among other things.  I am glad that David Schleef has added
pkg-config files to PLplot.  This obsoletes complete my old plplot-config
script and will also probably obsolete Alan's plplot_libtool hack.

-- 
Rafael

Re: [Plplot-devel] a small patch to PLplot

[Rafael L. <lab...@ps...>]

* Doug Hunt <dh...@uc...> [2003-03-04 15:32]:

> The patch is attached, along with the complete new version of plsym.c. 
> This patch affects the plmtex() function.  Currently one can plot left and
> right of the axis, with text parallel or perpendicular to the axis by
> specifying 'side' = ('l', 'r', 'lv' or 'bv').  One cannot, however, plot 
> with text perpendicular to the axis on the top or bottom.  My patch adds
> the 'tv' and 'bv' specifiers.  I have tested this under linux and it seems
> to work.
> 
> Could you apply this patch to the current CVS?

I applied your patch and it seems to work correctly.  Since it does not
break anything and does not introduce backwards incompatibilities, I went on
and CVS committed it.  The documentation in doc/docboook/src/api.xml has
been also updated accordingly.

Thanks for your contribution.

How is the work on the PLplotOO module going?

-- 
Rafael

Re: [Plplot-devel] If Octave is disabled, "make install" fails

[Rafael L. <lab...@ps...>]

* Joao Cardoso <jc...@fe...> [2003-03-04 18:42]:

> If Octave is disabled, "make install" fails:
> 
> ...
> make[3]: Entering directory `/home/jcard/plplot/doc/docbook'
> Making all in src
> make  install-data-hook
> make[5]: Entering directory `/home/jcard/plplot/bindings/octave'
> make[5]: *** No rule to make target `install-data-hook'.  Stop.
> make[5]: Leaving directory `/home/jcard/plplot/bindings/octave'
> make[4]: [install-data-am] Error 2 (ignored)
> make[4]: Leaving directory `/home/jcard/plplot/bindings/octave'
> ...
> 
> The above "Error 2 (ignored)"  just happens because I "make -i install"

Fixed in CVS, hopefully.

> Couldn't all language bindings directories be recursed based on an 
> AM_CONDITIONALs based on with_<lang>, just as I did in lib/Makefile.am?
> Or are there reasons to not do it?

Compilation of the octave bindings in bindings/octave/Makefile.am is done
conditionally on enable_octave, as you are suggesting above.  Only the stuff
needed for "make dist" is put outside the AM conditional.  The bug you
reported above is due to an intricacy of Automake: even if the
install-data-hook is declared inside a conditional, it is included as an
indirect dependency of the install target.

Just an aside thought: Since I am quite busy with the Debian packaging and
and make dist, I cannot test the configuration system under all imaginable
conditions.  Since I always enable octave in my buildings, the kind of
problem you reported would be hardly detected by me.

Please, keep testing things.

-- 
Rafael

Re: [Plplot-devel] The infamous "missing" strikes again

[Rafael L. <lab...@ps...>]

* Joao Cardoso <jc...@fe...> [2003-03-04 19:10]:

> But to "make dist" I have to configure, right?

Yes, but beware that the resulting tarball may lack some important files.  I
am working on this now.  Also, you should always configure
--enable-docbook=no (and also --enable-python=no, if you do not have the
appropriate version of swig).

-- 
Rafael

Re: [Plplot-devel] --with-pthreads: Use pthreads with the xwin driver!

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

On Wed, 5 Mar 2003, Joao Cardoso wrote:

> For most compiled programs, it can be safely turned on, even if the host
> program is not threads aware.
> For already build programs that somehow use PLplot, usually loading it as an
> extension, as Octave or python or tk does, things are a bit complicated, as
> those programs must themself be linked with the pthread library, even if not
> thread aware!

I believe the best solution here is simply to link xwin with -lpthread
consistent with the hierarchichal linking paradigm we are using. That way,
all pthread symbols in the xwin driver should be resolved, and you shouldn't
have to do any special linking of octave, wish, tclsh, etc.  This is for the
dynamic drivers case.  In the static drivers case it is a little bit more
complicated; the xwin driver becomes part of libplplot, and therefore,
libplplot has to be linked with -lpthread.

The short story: make Makefile.am changes for the xwin driver following what
happens for the gd driver special libraries (libgd, libpng, etc) as a model
both for the dynamic and static drivers cases.

If you or Rafael don't have time to fiddle with this, I will have a look
this weekend.  If it works out, then perhaps you will not have to turn off
pthreading by default.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

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

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

[Plplot-devel] --with-pthreads: Use pthreads with the xwin driver!

[Joao C. <jc...@fe...>]

Hi,

The xwin driver has been plagued for ages with a severe problem: whenever=
 the=20
user program goes to lengthly calculations, without doing any calls to=20
PLplot, the plot window couldn't be refreshed if obscured by other window=
s.=20
Nor resized.

You can quickly watch this behavior if you insert a getchar() statement j=
ust=20
before plend() in x01c.c. The getchar() call simulates the user program d=
oing=20
other jobs and not calling any plplot API. If you now obscure the plot wi=
ndow=20
you will see that it is not redrawn (of course).

This behaviour is most inconvenient for interactive languages like Octave=
 or=20
python, where the same behaviour is observed while the user is typing=20
commands at the prompt.

The obvious solution would be to write a xwin server or daemon, like the =
tk=20
driver plserver, but that means a lot of work. Instead, I have implemente=
d,=20
and cvs commit, a threaded xwin driver. It updates and resizes the plot=20
window, if needed.

This feature is disabled by default at configure time.

For most compiled programs, it can be safely turned on, even if the host=20
program is not threads aware.
For already build programs that somehow use PLplot, usually loading it as=
 an=20
extension, as Octave or python or tk does, things are a bit complicated, =
as=20
those programs must themself be linked with the pthread library, even if =
not=20
thread aware!

For example, in my system Octave is build by default without being linked=
 with=20
pthreads, because Octave is not threads aware. To use the new threads ena=
bled=20
xwin driver, I have to *relink* (only) octave with -lpthread, and after t=
hat=20
all goes well.

Python, by contrary, is already linked with the pthreads library, so noth=
ing=20
special needs to be done -- the threads enabled xwin driver works without=
 a=20
problem with python.

This is the reason why --with-pthreads=3Dno by default, and should not be=
 turned=20
on.
But users must know that this feature is available and why it is turned o=
ff,=20
so they can turn it on if that is the appropriate action for them.

Enjoy,
Joao

[Plplot-devel] a small patch to PLplot

[Doug H. <dh...@uc...>]

Hi Rafael:  I was wondering if you could do me a favor.  I have a small 
patch
to PLplot 5.2.0 which should not cause any problems.  I don't have 
developer CVS access
and in any case I don't have all the GNU autoconf tools up to the right 
version to get the CVS
source to build.

The patch is attached, along with the complete new version of plsym.c. 
 This patch affects the plmtex() function.  Currently one can plot left 
and right of the axis, with text parallel or perpendicular to the axis by
specifying 'side' = ('l', 'r', 'lv' or 'bv').  One cannot, however, plot 
with text perpendicular to
the axis on the top or bottom.  My patch adds the 'tv' and 'bv' 
specifiers.  I have tested this
under linux and it seems to work.

Could you apply this patch to the current CVS?

Thanks much!

--Doug Hunt

NaN issues, please help test on non-linux [was: Re: [Plplot-devel] The infamous "missing" strikes again]

[Joao C. <jc...@fe...>]

On Tuesday 04 March 2003 03:21, Joao Cardoso wrote:
> On Tuesday 04 March 2003 01:13, Joao Cardoso wrote:
> > On Monday 03 March 2003 23:52, Alan W. Irwin wrote:
> > > On Mon, 3 Mar 2003, Rafael Laboissiere wrote:
> > > > * Joao Cardoso <jc...@fe...> [2003-03-03 20:53]:
> > > > > After a fresh cvs checkout, running bootstrap.sh
>
> ...
>
> > I don't want to make a distro, just be able to quickly test on anothe=
r
> > architecture (I'm concerned with NaN stuff in nn/csa/plgridd.c).
>
> As I was afraid, under OSF1-V4.0 libcsa has trouble because of NaNs. li=
bnn
> must have the same problem.
>
> I ended up trying libcsa with its own test programs, but they fail, and=
 I
> trace the problem down to NaNs handling
>
> It is increadible how ieee-754 is still "vendor dependent"! Cray is kno=
w to
> be not conformant, but OSF...

I add some logic in sysloc.in to add the correct CFLAGS when compiling on=
 a=20
alpha/OSF -- please check it, it occurred to me just now that I did it th=
e=20
wrong way, as the problem is not only related with the hardware but also =
with=20
the OS. I *think* that linux running in an alpha might not have the probl=
em,=20
I'm not sure.

It would be nice if you guys with non-linux system could test this new co=
de.=20
After the normal configure/make/install, try examples/x21c and report bac=
k

Thanks,
Joao

Re: [Plplot-devel] The infamous "missing" strikes again

[Joao C. <jc...@fe...>]

On Tuesday 04 March 2003 09:35, Rafael Laboissiere wrote:
> [Out of order:]
>
> * Joao Cardoso <jc...@fe...> [2003-03-04 01:13]:
> > Alan receipt, "touch plConfig.h.in  plDevs.h.in", is enough for my ne=
eds.
>
> This is one of the things that is automatically done by "make dist".  T=
here
> are problem other hidden problems that Alan's make_tarball.sh script do=
es
> not address, but "make dist" will.
>
> I will try to put high priority on making "make dist" work.
>
> > I don't want to make a distro, just be able to quickly test on anothe=
r
> > architecture (I'm concerned with NaN stuff in nn/csa/plgridd.c).
>
> It is not a matter of making a distro.  What "make dist" does for you i=
s to
> generate a tarball ready for configure/make, circumventing all those na=
sty
> "touch me" problems.  Look at it as a sophisticated tar command (you ha=
d to
> do a "tar" before trying on the alpha machine, hadn't you? :-)

OK, OK, I was just in a hurry :)

But to "make dist" I have to configure, right?

Joao

[Plplot-devel] CFLAGS and CC not working

[Joao C. <jc...@fe...>]

Hi,

It looks like CFLAGS and CC, given at configure time don't work:

CFLAGS=3D"-mieee" ./configure
=2E..
config.status: executing depfiles commands
configure: configuring in libltdl
configure: running /bin/bash './configure'=20
--prefix=3D/usr/users1/deec/jcard/test  '--prefix=3D/usr/users1/deec/jcar=
d/test'=20
'--disable-octave' '--disable-static' '--enable-shared' '--disable-f77'=20
'--disable-cxx' 'CFLAGS=3D-mieee' --enable-ltdl-convenience=20
--cache-file=3D/dev/null --srcdir=3D.
configure: warning: CFLAGS=3D-mieee: invalid host type


 CC=3Dcc CFLAGS=3D"-ieee" ./configure
=2E..
configure: running /bin/bash './configure'=20
--prefix=3D/usr/users1/deec/jcard/test  '--prefix=3D/usr/users1/deec/jcar=
d/test'=20
'--disable-octave' '--disable-static' '--enable-shared' '--disable-f77'=20
'--disable-cxx' 'CC=3Dcc' 'CFLAGS=3D-ieee' --enable-ltdl-convenience=20
--cache-file=3D/dev/null --srcdir=3D.
configure: warning: CC=3Dcc: invalid host type

Joao

[Plplot-devel] If Octave is disabled, "make install" fails

[Joao C. <jc...@fe...>]

Hi,

If Octave is disabled, "make install" fails:

=2E..
make[3]: Entering directory `/home/jcard/plplot/doc/docbook'
Making all in src
make  install-data-hook
make[5]: Entering directory `/home/jcard/plplot/bindings/octave'
make[5]: *** No rule to make target `install-data-hook'.  Stop.
make[5]: Leaving directory `/home/jcard/plplot/bindings/octave'
make[4]: [install-data-am] Error 2 (ignored)
make[4]: Leaving directory `/home/jcard/plplot/bindings/octave'
=2E..

The above "Error 2 (ignored)"  just happens because I "make -i install"

Couldn't all language bindings directories be recursed based on an=20
AM_CONDITIONALs based on with_<lang>, just as I did in lib/Makefile.am?
Or are there reasons to not do it?

Joao

Re: [Plplot-devel] The infamous "missing" strikes again

[Rafael L. <lab...@ps...>]

[Out of order:]

* Joao Cardoso <jc...@fe...> [2003-03-04 01:13]:

> Alan receipt, "touch plConfig.h.in  plDevs.h.in", is enough for my needs.

This is one of the things that is automatically done by "make dist".  There
are problem other hidden problems that Alan's make_tarball.sh script does
not address, but "make dist" will.

I will try to put high priority on making "make dist" work.

> I don't want to make a distro, just be able to quickly test on another 
> architecture (I'm concerned with NaN stuff in nn/csa/plgridd.c).

It is not a matter of making a distro.  What "make dist" does for you is to
generate a tarball ready for configure/make, circumventing all those nasty
"touch me" problems.  Look at it as a sophisticated tar command (you had to
do a "tar" before trying on the alpha machine, hadn't you? :-)

-- 
Rafael