plplot-devel — Technical discussion about PLplot development

[Plplot-devel] Re: [Plplot-cvs] CVS update notice (plplot/src)

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

On Thursday 14 March 2002 8:59 pm, Joao Cardoso wrote:
| Update of /cvsroot/plplot/plplot/src
| In directory usw-pr-cvs1:/tmp/cvs-serv19126/src
|
| Modified Files:
| =09plstripc.c
| Log Message:
| Solve out of bonds bug,

Bonds... I corrected it!

Joao

| "For the first call to the c_plstripa function, stripc->npts[p]-2
| value is -1 and generates an out of bound access in table
| stripc->x[p]."
|
| _______________________________________________
| Plplot-cvs mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-cvs

[Plplot-devel] RE: Plplot Ada binding

[Geoffrey F. <fu...@ga...>]

Hello Bernard,

Sorry about the mixed messages, but we've had some more discussion
about your Ada binding submission, and thought it would be useful to
revise our last communication to you on the subject.

First of all, let me just thank you again for your work.  As Alan
mentioned previously, however, none of the current PLplot developers
have any experience with or substantive knowledge of Ada, which leaves
us ill equipped to support--much less extend--the code over the long
term. 

We are in principle willing to add your Ada code to the core
distribution, alongside the other language bindings, in
plplot/bindings/ada.  I say "in principle" because in practice, we
would hope for more than just an initial shot of code when setting up
a new language binding.  What we would really like to see is roughly:
  A) A reliable, available point of contact for the long term.
  B) Configure support
  C) The standard examples implemented.

Are you willing and able to volunteer to serve in the A) capacity?  We
realize B) might be unobvious, we would be willing to help, even help
substantially with this, as long as you are involved.  And for C) we
would really need to rely on you, since none of us knows Ada.  

Note, this does not mean that B) and C) need to happen immediately at
the outset.  There are clearly timelines in all software development
that relate to the personal time availability and extant professional
committments of the contributors, for any OSS project such as PLplot.
Many of our existing language bindings are still in formative stages.
But they are all basically supported by someone who is involved
materially in the PLplot development community, and available to
answer questions from users.  

If you think you could help support the Ada binding for PLplot in a
similar fashion, we'd be happy to create the plplot/bindings/ada
directory, and accept the initial submission.  Besides working on the
code, joining the plp...@li... mailing list
would also be useful.

As a final note, all PLPlot code must be under the LGPL (the "Library
Gnu Public License"), so it would be necessary to add an annotation to
this effect for any new submission such as this.  (Clearer annotation
of all files in the distribution is one of our open tasks).

Please let me know how you feel about this.  If you feel this is too
much commitment, we would understand (we all have pressures in our
respective life situations), but in such a case, Alan's prior
suggestion about setting up an independent project, perhaps at
SourceForge or one of the other OSS sponsor sites, would seem to be
the best option.  As Alan mentioned, even though he is one of our core
developers, he manages one of his own projects, a PLplot binding to
the Yorick language, in this same way, so there is precedant.

Let me know which path you think works best for you.

Best regards,

-- 
Geoffrey Furnish         fu...@ga...

Re: [Plplot-devel] gnuplot to PLplot translation

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

On Wednesday 13 March 2002 4:46 pm, Alan W. Irwin wrote:
| I have just heard a rumor from one of my Debian contacts that gnuplot
| may adopt a non-free license.  If that happens, we may be getting
| some gnuplot refugees starting to use PLplot, and it might be worth
| our while to encourage this by implementing a programme to translate
| gnuplot scripts into PLplot (python?) scripts.
|
| Do we have the (gnuplot) expertise here to make such an "import"
| programme? My own memory of gnuplot is pretty vague since I last used
| that package 5 or 6 years ago.

Octave uses gnuplot as its plotting program. The plplot bindings to=20
octave, besides the API entry points, also has octave scripts that=20
emulate most of the octave plotting commands. I had difficulties=20
emulating some gnuplot features, and some are even impossible to=20
emulate.

Gnuplot is interactive, and if you say "title blabla" the old title=20
will disappear and the one appears. The same if you change axis scales=20
or types, etc. This kind of features poses some problems. Not to talk=20
about the gnuplot "processing" features (minimization...)

I don't think that writing a program to emulate gnuplot should be a=20
target to plplot development. But gnuplot users could write it!

Joao
|
| Alan
|
| email: ir...@be...
| phone: 250-727-2902=09FAX: 250-721-7715
| snail-mail:
| Dr. Alan W. Irwin
| Department of Physics and Astronomy,
| University of Victoria, P.O. Box 3055,
| Victoria, British Columbia, Canada, V8W 3P6
| __________________________
|
| Linux-powered astrophysics
| __________________________
|
|
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Tcl FAQ needs correction

[Maurice L. <mj...@ga...>]

Could someone email Larry Virden with the updated info on plplot for the Tcl
FAQ?  It still refers to the old mailing list on dino, sheesh.

http://www.geocities.com/lvirden/tcl-faq/part2.html

-- 
Maurice LeBrun    mj...@ga...

RE: [Plplot-devel] gnuplot to PLplot translation

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

On Wed, 13 Mar 2002, Geoffrey Furnish wrote:

> Are they going to drop the Gnu from their name?

My understanding is the "gnu" part of gnuplot name is a happy (for them)
historical accident, and gnuplot has no connection with the FSF's GNU
packages.  So, IF gnuplot changes to a non-free license, I expect they will
leave the name the same.

But regardless of what they do on the licensing or name, it is still
interesting to think about implementing an import filter from a gnuplot
script to a plplot script to ease the transition for those gnuplot users who
want to give plplot a try.  So I would like to hear from anybody here who
will admit (;-) to recent gnuplot experience whether they think such an
import filter is even possible.

Alan

RE: [Plplot-devel] gnuplot to PLplot translation

[Geoffrey F. <fu...@ga...>]

Alan W. Irwin writes:
 > I have just heard a rumor from one of my Debian contacts that gnuplot may
 > adopt a non-free license.  If that happens, we may be getting some gnuplot
 > refugees starting to use PLplot, and it might be worth our while to encourage
 > this by implementing a programme to translate gnuplot scripts into PLplot
 > (python?) scripts.
 > 
 > Do we have the (gnuplot) expertise here to make such an "import" programme?
 > My own memory of gnuplot is pretty vague since I last used that package 5 or
 > 6 years ago.

Are they going to drop the Gnu from their name?  

I'm afraid I don't know gnuplot scripting well enough to be much help here.

[Plplot-devel] gnuplot to PLplot translation

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

I have just heard a rumor from one of my Debian contacts that gnuplot may
adopt a non-free license.  If that happens, we may be getting some gnuplot
refugees starting to use PLplot, and it might be worth our while to encourage
this by implementing a programme to translate gnuplot scripts into PLplot
(python?) scripts.

Do we have the (gnuplot) expertise here to make such an "import" programme?
My own memory of gnuplot is pretty vague since I last used that package 5 or
6 years ago.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] Compiling plplot 5.1.0 on python2.2

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > One other concern I have is your use of a SuSe package for python-numpy.
 > The one I used for RH6.2 (and 7.1) is called python-numpy-15.3-1.i386.rpm. I
 > cannot remember the exact URL where I got it (perhaps RedHat contrib), but I
 > have just done another search for that rpm, and one location is right at the
 > numpy site itself,
 > http://prdownloads.sourceforge.net/numpy/python-numpy-15.3-1.i386.rpm.
 > That's not an identical build to the one I used, but I think that is
 > probably the most trustworthy location.

Thanks, I was a little surprised myself that's what I had installed.  

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Compiling plplot 5.1.0 on python2.2

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

I will probably have to wait a number of days to investigate this directly
because the RH7.2 systems our astrogroup sysadmin installed last week are
incomplete (no devel packages). It will take a while to straighten this out
because he has higher priorities at the moment (dealing with some hard disk
drive problems that have suddenly shown up).

So here are my questions/comments from the (temporary) sidelines:

On my Debian woody system, /usr/lib/python2.1/config/Setup.config exists,
and is part of the python2.1-dev package.  On the RH 7.1 system where I
built PLplot 5.1.0 rpm's /usr/lib/python1.5/config/Setup.config does not
exist. Nevertheless, the pl python module built cleanly there so I suspect
that file is internal to python 2.1.  Therefore, I suspect that the PLplot
configuration is getting confused between the 2.1 and 1.5 devel packages on
your system, and it is looking for the 2.1 file, Setup.config, in the 1.5
location.  I am hopeful of knowing more by the end of this week when I
should be able to get my hands on a RH7.2 system with all the devel packages
installed.  But meanwhile, you might be able to get things to build properly
using environment variables to force your system to always use the 1.5
versions of everything.  Those work well in the RH7.1 case.

One other concern I have is your use of a SuSe package for python-numpy.
The one I used for RH6.2 (and 7.1) is called python-numpy-15.3-1.i386.rpm. I
cannot remember the exact URL where I got it (perhaps RedHat contrib), but I
have just done another search for that rpm, and one location is right at the
numpy site itself,
http://prdownloads.sourceforge.net/numpy/python-numpy-15.3-1.i386.rpm.
That's not an identical build to the one I used, but I think that is
probably the most trustworthy location.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Sat, 9 Mar 2002, Maurice LeBrun wrote:

> Jef Spaleta writes:
>  > Hi I've been trying to compile plplot on a redhat 7.2 base system with
>  > python 2.2-7 installed  and I can't seem to get the install of plplot to
>  > work.
>  >
>  > First i noticed that the configure script that comes with plplot does
>  > not know how to find the /usr/lib/python2.2 directory tree.
>
> I recently upgraded my laptop computer to RH7.2 and just got a chance to
> test this.  I'm seeing a similar problem with the python configuration.
> The output looks like:
>
> ...
> Building PyQt Python module.
>
> echo 'pyqt_pl pyqt_plmodule.c -I. -I/usr/include/python2.1 -I/usr/include/python1.5/Numeric -L.. -L. -lplplot -ltclmatrix -L/home/mjl/gts/lib -litk3.2 -ltk8.3 -litcl3.2 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lm -Wl,-rpath -Wl,/home/mjl/dev/plplot/latest/tmp' >> python_dynamic/Setup.in
> cd python_dynamic ; make -s -f Makefile.pre.in boot ; make -s ; \
> mv -f pyqt_plmodule.so ..
> cat: /usr/lib/python1.5/config/Setup.config: No such file or directory
> cat: /usr/lib/python1.5/config/Setup.config: No such file or directory
>
> The python related packages I've got installed are:
>
> rpheus$ rpm -qa |grep python
> rpm-python-4.0.3-1.03
> mod_python-2.7.6-1
> python2-2.1.1-2
> python-numpy-17.3.0-1suse
> python-tools-1.5.2-35
> python2-devel-2.1.1-2
> python-devel-1.5.2-35
> python-docs-1.5.2-35
> python-xmlrpc-1.5.1-7.x.3
> python-1.5.2-35
>
> All the latest patched rpm's for 7.2 from a RedHat mirror site.  Note both
> python1.5 and python2 come with RH 7.2 and don't interfere dependency-wise
> so presumably they are supposed to coexist peacefully.
>
> I haven't seen any other problems under 7.2 but I haven't done extensive
> testing either.
>
> --
> Maurice LeBrun    mj...@ga...
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Compiling plplot 5.1.0 on python2.2

[Maurice L. <mj...@ga...>]

Jef Spaleta writes:
 > Hi I've been trying to compile plplot on a redhat 7.2 base system with
 > python 2.2-7 installed  and I can't seem to get the install of plplot to
 > work.
 > 
 > First i noticed that the configure script that comes with plplot does
 > not know how to find the /usr/lib/python2.2 directory tree.

I recently upgraded my laptop computer to RH7.2 and just got a chance to
test this.  I'm seeing a similar problem with the python configuration.
The output looks like:

...
Building PyQt Python module.
 
echo 'pyqt_pl pyqt_plmodule.c -I. -I/usr/include/python2.1 -I/usr/include/python1.5/Numeric -L.. -L. -lplplot -ltclmatrix -L/home/mjl/gts/lib -litk3.2 -ltk8.3 -litcl3.2 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lm -Wl,-rpath -Wl,/home/mjl/dev/plplot/latest/tmp' >> python_dynamic/Setup.in
cd python_dynamic ; make -s -f Makefile.pre.in boot ; make -s ; \
mv -f pyqt_plmodule.so ..
cat: /usr/lib/python1.5/config/Setup.config: No such file or directory
cat: /usr/lib/python1.5/config/Setup.config: No such file or directory

The python related packages I've got installed are:

rpheus$ rpm -qa |grep python
rpm-python-4.0.3-1.03
mod_python-2.7.6-1
python2-2.1.1-2
python-numpy-17.3.0-1suse
python-tools-1.5.2-35
python2-devel-2.1.1-2
python-devel-1.5.2-35
python-docs-1.5.2-35
python-xmlrpc-1.5.1-7.x.3
python-1.5.2-35

All the latest patched rpm's for 7.2 from a RedHat mirror site.  Note both
python1.5 and python2 come with RH 7.2 and don't interfere dependency-wise
so presumably they are supposed to coexist peacefully.

I haven't seen any other problems under 7.2 but I haven't done extensive
testing either.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Compiling plplot 5.1.0 on python2.2

[Jef S. <jsp...@pr...>]

Actually this isnt a stock redhat 7.2 install...the python 2.2 is out of
rawhide....so whatever problem im having im sure its particularly nasty.

-jef
On Thu, 2002-03-07 at 17:26, Alan W. Irwin wrote:
> Hello Jef:
> 
> Your message is timely because in the last few days I have finally gotten
> guest access on a RH 7.2 system.  I am tied up with something else at the
> moment, but I will try to take a look at this situation early next week. If
> some tweaks have to be made to plplot-5.1.0 to get RH 7.2 to work, I will
> publish a patch.
> 
> Alan
> 
> email: ir...@be...
> phone: 250-727-2902	FAX: 250-721-7715
> snail-mail:
> Dr. Alan W. Irwin
> Department of Physics and Astronomy,
> University of Victoria, P.O. Box 3055,
> Victoria, British Columbia, Canada, V8W 3P6
> __________________________
> 
> Linux-powered astrophysics
> __________________________
> 
> On 7 Mar 2002, Jef Spaleta wrote:
> 
> > Hi I've been trying to compile plplot on a redhat 7.2 base system with
> > python 2.2-7 installed  and I can't seem to get the install of plplot to
> > work.
> >
> > First i noticed that the configure script that comes with plplot does
> > not know how to find the /usr/lib/python2.2 directory tree.
> >
> > To get around that I changed the configure script and added a set of 2.2
> > directories similar to the python2.1 listings....now configure enables
> > python modules to be built...unfortunately  I have a problem trying to
> > build the python modules
> >
> > the make process places a symlink in tmp/python_dynamic
> > Makefile.pre.in  -> /usr/lib/python2.2/config/Makefile.pre.in
> >
> > I do not have a file named
> > /usr/lib/python2.2/config/Makefile.pre.in
> >
> >
> > is this a problem with my python2.2 install or is something amiss with
> > the plplot configure/make scripts?
> >
> > I have the Numeric modules for python2.2 compiled and installed without
> > a hitch..and it looks like they work from very basic testing.
> >
> >
> > Any clues as to what I need to work around this would be great.
> >
> > -jef
> >
> > --
> >   Thursday, March 07, 2002 04:22 PM
> >   ----------------------------------------------------------------
> >   	   	Jef Spaleta (jsp...@pr...)
> >       	PPPL: (609)243-2941		Home: (609)688-8655
> >       	PO Box 451, MS30 	    	221A Halsey St.
> >       	Princeton, NJ 08543		Princeton, NJ 08540
> >   ----------------------------------------------------------------
> >   Press any key... no, no, no, NOT THAT ONE!
> >
> > _______________________________________________
> > Plplot-devel mailing list
> > Plp...@li...
> > https://lists.sourceforge.net/lists/listinfo/plplot-devel
> >
> 
-- 
  Thursday, March 07, 2002 05:27 PM
  ----------------------------------------------------------------
  	   	Jef Spaleta (jsp...@pr...)
      	PPPL: (609)243-2941		Home: (609)688-8655
      	PO Box 451, MS30 	    	221A Halsey St.
      	Princeton, NJ 08543		Princeton, NJ 08540
  ----------------------------------------------------------------
  I'm sure it's clearly explained in the Zmodem DOC's

Re: [Plplot-devel] Compiling plplot 5.1.0 on python2.2

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

Hello Jef:

Your message is timely because in the last few days I have finally gotten
guest access on a RH 7.2 system.  I am tied up with something else at the
moment, but I will try to take a look at this situation early next week. If
some tweaks have to be made to plplot-5.1.0 to get RH 7.2 to work, I will
publish a patch.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On 7 Mar 2002, Jef Spaleta wrote:

> Hi I've been trying to compile plplot on a redhat 7.2 base system with
> python 2.2-7 installed  and I can't seem to get the install of plplot to
> work.
>
> First i noticed that the configure script that comes with plplot does
> not know how to find the /usr/lib/python2.2 directory tree.
>
> To get around that I changed the configure script and added a set of 2.2
> directories similar to the python2.1 listings....now configure enables
> python modules to be built...unfortunately  I have a problem trying to
> build the python modules
>
> the make process places a symlink in tmp/python_dynamic
> Makefile.pre.in  -> /usr/lib/python2.2/config/Makefile.pre.in
>
> I do not have a file named
> /usr/lib/python2.2/config/Makefile.pre.in
>
>
> is this a problem with my python2.2 install or is something amiss with
> the plplot configure/make scripts?
>
> I have the Numeric modules for python2.2 compiled and installed without
> a hitch..and it looks like they work from very basic testing.
>
>
> Any clues as to what I need to work around this would be great.
>
> -jef
>
> --
>   Thursday, March 07, 2002 04:22 PM
>   ----------------------------------------------------------------
>   	   	Jef Spaleta (jsp...@pr...)
>       	PPPL: (609)243-2941		Home: (609)688-8655
>       	PO Box 451, MS30 	    	221A Halsey St.
>       	Princeton, NJ 08543		Princeton, NJ 08540
>   ----------------------------------------------------------------
>   Press any key... no, no, no, NOT THAT ONE!
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] Compiling plplot 5.1.0 on python2.2

[Jef S. <jsp...@pr...>]

Hi I've been trying to compile plplot on a redhat 7.2 base system with
python 2.2-7 installed  and I can't seem to get the install of plplot to
work.

First i noticed that the configure script that comes with plplot does
not know how to find the /usr/lib/python2.2 directory tree.

To get around that I changed the configure script and added a set of 2.2
directories similar to the python2.1 listings....now configure enables
python modules to be built...unfortunately  I have a problem trying to
build the python modules

the make process places a symlink in tmp/python_dynamic
Makefile.pre.in  -> /usr/lib/python2.2/config/Makefile.pre.in

I do not have a file named
/usr/lib/python2.2/config/Makefile.pre.in


is this a problem with my python2.2 install or is something amiss with
the plplot configure/make scripts?

I have the Numeric modules for python2.2 compiled and installed without
a hitch..and it looks like they work from very basic testing. 


Any clues as to what I need to work around this would be great.

-jef

-- 
  Thursday, March 07, 2002 04:22 PM
  ----------------------------------------------------------------
  	   	Jef Spaleta (jsp...@pr...)
      	PPPL: (609)243-2941		Home: (609)688-8655
      	PO Box 451, MS30 	    	221A Halsey St.
      	Princeton, NJ 08543		Princeton, NJ 08540
  ----------------------------------------------------------------
  Press any key... no, no, no, NOT THAT ONE!

Re: [Plplot-devel] Plplot Ada binding

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

Hello Bernard:

Thank you for your c_plstripa bug report below which should be dealt with
separately.

Also, thank you for your efforts in making an Ada front-end or binding to
PLplot which I will respond to here.

I have checked with the other plplot core developers, and it seems that none
of us have experience with Ada.  Therefore, we would have difficulty
maintaining your contribution.

I think the best thing to do in a case like this is for you to establish an
independent Ada front-end project for PLplot.  One example of this sort of
approach is yplot, which is the Yorick front end to PLplot. yplot, which I
help to independently maintain, has its own web site (yplot.sf.net),
developer page, and release schedule, and most importantly any change to
yplot does not back-react on to PLplot.  If you decide to take this
independent approach for your Ada front end of Plplot, I would highly
recommend applying to sourceforge.net to provide facilities for your
project.

BTW, we no longer support PLplot version 5.0.3.  The stable release that we
support instead is 5.1.0 (see the announcement at
http://plplot.sourceforge.net/announce-plplot-5.1.0.html).

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Mon, 4 Mar 2002, Bernard WEISSER wrote:

> Hi,
>
> For my personal use I needed to have an Ada binding to the Plplot 5.0.3
> plotting library. So I developped such a binding with a reduced set of
> interface functions.
>
> As a small contribution to the overall product I send this binding with
> 2 simple testing programs that perhaps you will find interesting for
> somebody else. Feel free to use them as you wish.
>
> While porting the Plplot core source on another UNIX computer, I found a
> small bug in the stripchart management, in the c_plstripa() function,
> which produces a SIGSEGV error. The context of the error is at line 252
> of file plstripc.c:
>
>                 plcol(stripc->colline[p]); pllsty(stripc->styline[p]);
>                 plP_movwor(stripc->x[p][stripc->npts[p]-2],
> stripc->y[p][stripc->npts[p]-2]);            <----------- here
>                 plP_drawor(stripc->x[p][stripc->npts[p]-1],
> stripc->y[p][stripc->npts[p]-1]);
>                 plflush();
>
> For the first call to the c_plstripa function, stripc->npts[p]-2 value
> is -1 and generates an out of bound access in table stripc->x[p].
>
> I personally replaced the line:
>
>                 plP_movwor(stripc->x[p][stripc->npts[p]-2],
> stripc->y[p][stripc->npts[p]-2]);
>
> by:
>
>                 if ((stripc->npts[p]-2) < 0)
>                         plP_movwor(0.0, 0.0) ;
>                 else
>                         plP_movwor(stripc->x[p][stripc->npts[p]-2],
> stripc->y[p][stripc-npts[p]-2]);
>
> I hope this will help.

[Plplot-devel] I have just converted public API plP_gvpd and plP_gvpw to common API plgvpd and plgvpw

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

For years plmodule.c has had a wrapper for plP_gvpw so that python users
could get access to the world coordinate limits of the current viewport, and
I have just received a well-justified request to wrap plP_gvpd so that
python users could get access to the normalized device coordinate limits of
the current viewport.

I prefer to avoid special API for particular front ends as much as possible
so accordingly, I have converted plP_gvpd and plP_gvpw to the common API
functions plgvpd and plgvpw, wrapped both these common API functions for
python, converted Plplot code to use the new common API names, and also
provided access to the old names of everything to support legacy
applications which depend on them.

DocBook documentation to follow.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] Locate mode improvements, (was Other problems with -locate option on x01c)

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > Maurice, you are more expert than me on these kind of questions so I am
 > tempted to just go along with your vision of supporting 3 separate locate
 > modes at the device level.  But my gut instinct tells me that the device
 > level should be making minimum decisions. Instead, my view is it should pass
 > back data to the PLplot library level in sufficiently general form so that
 > the decisions (possibly including the 3 options above) could be done in that
 > more centralized place. I believe we should discuss simplifying the device
 > level handling of locate mode because it makes it much easier to have the
 > same minimum locate mode behaviour for all interactive drivers that support
 > it. 

Moving all of the locate control logic up to the core is not realistic in my
opinion, not while preserving existing functionality.  OTOH there are some
sections of code that could be hoisted up to core functions that could be
shared among multiple driver locate implementations.  If I find myself doing
any signficant changes to that section of code I'll look into it.

 > Furthermore, once we decide on what parts can be done at the PLplot
 > library level versus what must be done at the device level (even if that
 > turns out to be the status quo for what goes on with the xwin device driver
 > now), then we should document the device driver requirements, and review
 > each interactive driver to make sure it provides what is required.
 > ...
 > In your opinion, is such a common API (with variables and arrays in argument
 > lists as opposed to structs) straightforward to write based on our current
 > public (as opposed to common) API for locate mode?  If so, I am willing to
 > write such a common API, but of course I would probably need a lot of help
 > from you.

Sure, just (a) see that the struct contains everything you will ever want to
return to the user (we talked about adding a window index parameter), and then
just (b) flatten it out into an argument list of pointers.

-- 
Maurice LeBrun    mj...@ga...

[Plplot-devel] Plplot Ada binding

[Bernard W. <Ber...@wa...>]

Hi,

For my personal use I needed to have an Ada binding to the Plplot 5.0.3
plotting library. So I developped such a binding with a reduced set of
interface functions.

As a small contribution to the overall product I send this binding with
2 simple testing programs that perhaps you will find interesting for
somebody else. Feel free to use them as you wish.

While porting the Plplot core source on another UNIX computer, I found a
small bug in the stripchart management, in the c_plstripa() function,
which produces a SIGSEGV error. The context of the error is at line 252
of file plstripc.c:

                plcol(stripc->colline[p]); pllsty(stripc->styline[p]);
                plP_movwor(stripc->x[p][stripc->npts[p]-2],
stripc->y[p][stripc->npts[p]-2]);            <----------- here
                plP_drawor(stripc->x[p][stripc->npts[p]-1],
stripc->y[p][stripc->npts[p]-1]);
                plflush();

For the first call to the c_plstripa function, stripc->npts[p]-2 value
is -1 and generates an out of bound access in table stripc->x[p].

I personally replaced the line:

                plP_movwor(stripc->x[p][stripc->npts[p]-2],
stripc->y[p][stripc->npts[p]-2]);

by:

                if ((stripc->npts[p]-2) < 0)
                        plP_movwor(0.0, 0.0) ;
                else
                        plP_movwor(stripc->x[p][stripc->npts[p]-2],
stripc->y[p][stripc-npts[p]-2]);

I hope this will help.

Re: [Plplot-devel] Locate mode improvements, (was Other problems with -locate option on x01c)

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

On Mon, 4 Mar 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > (1) Currently, there are actually two kinds of locate mode. One of them
>  > ("driver" locate mode) prints out x and y, but otherwise does not allow the
>  > data to be retrieved by the programme. The other ("user" locate mode) does
>  > allow programme access to the data, but it is only available from the C front
>  > end.
>
> Actually 3 kinds.  The third is when the user provides a locate handler, to
> take the place of the default handler.
>
> The best place to look for info on this stuff really is the source code.
> Stuff I personally have written is often very well commented, because
> it's a lot better than nothing when there's no time to write real
> documentation.  An example from xwin.c:
>
> /*--------------------------------------------------------------------------*\
>  * Locate()
>  *
>  * Handles locate mode events.
>  *
>  * In locate mode: move cursor to desired location and select by pressing a
>  * key or by clicking on the mouse (if available).  Typically the world
>  * coordinates of the selected point are reported.
>  *
>  * There are two ways to enter Locate mode -- via the API, or via a driver
>  * command.  The API entry point is the call plGetCursor(), which initiates
>  * locate mode and does not return until input has been obtained.  The
>  * driver entry point is by entering a 'L' while the driver is waiting for
>  * events.
>  *
>  * Locate mode input is reported in one of three ways:
>  * 1. Through a returned PLGraphicsIn structure, when user has specified a
>  *    locate handler via (*pls->LocateEH).
>  * 2. Through a returned PLGraphicsIn structure, when locate mode is invoked
>  *    by a plGetCursor() call.
>  * 3. Through writes to stdout, when locate mode is invoked by a driver
>  *    command and the user has not supplied a locate handler.
>  *
>  * Hitting <Escape> will at all times end locate mode.  Other keys will
>  * typically be interpreted as locator input.  Selecting a point out of
>  * bounds will end locate mode unless the user overrides with a supplied
>  * Locate handler.
> \*--------------------------------------------------------------------------*/

Thanks for pointing out that documentation in the xwin driver.

Maurice, you are more expert than me on these kind of questions so I am
tempted to just go along with your vision of supporting 3 separate locate
modes at the device level.  But my gut instinct tells me that the device
level should be making minimum decisions. Instead, my view is it should pass
back data to the PLplot library level in sufficiently general form so that
the decisions (possibly including the 3 options above) could be done in that
more centralized place. I believe we should discuss simplifying the device
level handling of locate mode because it makes it much easier to have the
same minimum locate mode behaviour for all interactive drivers that support
it. Furthermore, once we decide on what parts can be done at the PLplot
library level versus what must be done at the device level (even if that
turns out to be the status quo for what goes on with the xwin device driver
now), then we should document the device driver requirements, and review
each interactive driver to make sure it provides what is required.

>
>  > The driver locate mode in its present form is not useful for my needs
>  > because my programmes need access to the locate-mode data (x and y and
>  > especially the key or mouse button that was pressed since that allows the
>  > user to enter a wide variety of commands to help in interactive reduction of
>  > spectra).  The user locate mode sounds more promising in that respect, but
>  > it needs to make x, y, and key available to all front ends (i.e., probably
>  > python in my case). Following what currently is possible with driver locate
>  > mode, you should be able to enter or leave user locate mode at will by
>  > pressing the appropriate keys, i.e., it should be available for all examples
>  > for all front ends if an interactive driver with the right capabilities is
>  > specified.
>
> I agree, this one needs to be better supported in the bindings.  Sounds like
> you'll be doing the python binding. :)

Yes.  ;-) But I want to emphasize we should take the general approach of
having common interactive API that is simple for every front end to wrap.

In your opinion, is such a common API (with variables and arrays in argument
lists as opposed to structs) straightforward to write based on our current
public (as opposed to common) API for locate mode?  If so, I am willing to
write such a common API, but of course I would probably need a lot of help
from you.

>
>  > Thus, what I am really pressing for is a single coherent locate mode that
>
> I don't see anything incoherent about it fundamentally.  The docs, yeah, and
> a tutorial wouldn't be a bad idea.

Sorry for my poor choice of words here.  Drop the "coherent" from above.

>
> There is a default locate behavior without the user having to do a thing but
> press "L" and start clicking away.  There is a way to invoke locate explicitly
> from the [C/C++] API's.  And a way to replace the low-level locate handler.
> I believe these are all well-considered features of the locator support.
>
>  > combines the best features of our two present locate modes plus a bit more.
>  > I really need these improvements if I am going to use interactive PLplot for
>  > my next research project, but there may be other improvements to locate mode
>  > that we need to discuss as well so I would welcome such discussion.
>
> --
> Maurice LeBrun    mj...@ga...
>

Re: [Plplot-devel] Locate mode improvements, (was Other problems with -locate option on x01c)

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > (1) Currently, there are actually two kinds of locate mode. One of them
 > ("driver" locate mode) prints out x and y, but otherwise does not allow the
 > data to be retrieved by the programme. The other ("user" locate mode) does
 > allow programme access to the data, but it is only available from the C front
 > end.

Actually 3 kinds.  The third is when the user provides a locate handler, to
take the place of the default handler.

The best place to look for info on this stuff really is the source code.
Stuff I personally have written is often very well commented, because 
it's a lot better than nothing when there's no time to write real
documentation.  An example from xwin.c:

/*--------------------------------------------------------------------------*\ 
 * Locate() 
 * 
 * Handles locate mode events. 
 * 
 * In locate mode: move cursor to desired location and select by pressing a 
 * key or by clicking on the mouse (if available).  Typically the world 
 * coordinates of the selected point are reported. 
 * 
 * There are two ways to enter Locate mode -- via the API, or via a driver 
 * command.  The API entry point is the call plGetCursor(), which initiates 
 * locate mode and does not return until input has been obtained.  The 
 * driver entry point is by entering a 'L' while the driver is waiting for 
 * events.   
 * 
 * Locate mode input is reported in one of three ways: 
 * 1. Through a returned PLGraphicsIn structure, when user has specified a 
 *    locate handler via (*pls->LocateEH). 
 * 2. Through a returned PLGraphicsIn structure, when locate mode is invoked 
 *    by a plGetCursor() call. 
 * 3. Through writes to stdout, when locate mode is invoked by a driver 
 *    command and the user has not supplied a locate handler. 
 * 
 * Hitting <Escape> will at all times end locate mode.  Other keys will 
 * typically be interpreted as locator input.  Selecting a point out of 
 * bounds will end locate mode unless the user overrides with a supplied 
 * Locate handler. 
\*--------------------------------------------------------------------------*/ 

 > The driver locate mode in its present form is not useful for my needs
 > because my programmes need access to the locate-mode data (x and y and
 > especially the key or mouse button that was pressed since that allows the
 > user to enter a wide variety of commands to help in interactive reduction of
 > spectra).  The user locate mode sounds more promising in that respect, but
 > it needs to make x, y, and key available to all front ends (i.e., probably
 > python in my case). Following what currently is possible with driver locate
 > mode, you should be able to enter or leave user locate mode at will by
 > pressing the appropriate keys, i.e., it should be available for all examples
 > for all front ends if an interactive driver with the right capabilities is
 > specified.

I agree, this one needs to be better supported in the bindings.  Sounds like
you'll be doing the python binding. :) I had planned on eventually adding some
kind of menu support from the TK driver, but it never materialized.. I guess I
haven't really needed it yet.

 > Thus, what I am really pressing for is a single coherent locate mode that

I don't see anything incoherent about it fundamentally.  The docs, yeah, and
a tutorial wouldn't be a bad idea.  

There is a default locate behavior without the user having to do a thing but
press "L" and start clicking away.  There is a way to invoke locate explicitly
from the [C/C++] API's.  And a way to replace the low-level locate handler.
I believe these are all well-considered features of the locator support.

 > combines the best features of our two present locate modes plus a bit more.
 > I really need these improvements if I am going to use interactive PLplot for
 > my next research project, but there may be other improvements to locate mode
 > that we need to discuss as well so I would welcome such discussion.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Re: [Plplot-cvs] CVS update notice (plplot/examples/c)

[Maurice L. <mj...@ga...>]

Joao Cardoso writes:
 > On Sunday 03 March 2002 23:25, Alan W. Irwin wrote:
 > | Update of /cvsroot/plplot/plplot/examples/c
 > | In directory usw-pr-cvs1:/tmp/cvs-serv23143
 > |
 > | Modified Files:
 > | 	x16c.c
 > | Log Message:
 > | Conditionally drop exclusion page (fifth page) since no front end
 > | other than C
 > 
 > Yes, but it is a C demo... and there are other C demos that use 
 > non-common API calls -- the "x01c -locate" demo recently discussed is 
 > an example.

I don't see the need to chop out the exclusion plot either.

-- 
Maurice LeBrun    mj...@ga...

[Plplot-devel] Re: [Plplot-cvs] CVS update notice (plplot/examples/c)

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

On Sunday 03 March 2002 23:25, Alan W. Irwin wrote:
| Update of /cvsroot/plplot/plplot/examples/c
| In directory usw-pr-cvs1:/tmp/cvs-serv23143
|
| Modified Files:
| =09x16c.c
| Log Message:
| Conditionally drop exclusion page (fifth page) since no front end
| other than C

Yes, but it is a C demo... and there are other C demos that use=20
non-common API calls -- the "x01c -locate" demo recently discussed is=20
an example.

Joao

| can use the exclusion API.  If we ever revisit
| exclusion, this page can easily be reinstated.
|
| Add an additional page that demonstrates a polar shade plot.
|
| These two changes make the 16th C example, the prototype that all
| front ends should be able to emulate, and which I hope to implement
| for at least the python, tcl, yorick, and java front ends shortly.
|
|
|
| _______________________________________________
| Plplot-cvs mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-cvs

[Plplot-devel] Locate mode improvements, (was Other problems with -locate option on x01c)

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

On Sun, 3 Mar 2002, Maurice LeBrun wrote:

> Maybe the message about locate mode terminated would be ok, as long as it's to
> stderr and not stdout.  As for restarting using "L" ... it's not the same
> thing.  Locate mode invoked by the driver just outputs the two world
> coordinates, whereas locate mode invoked by the user can do anything desired
> with the info.  And in fact the x01c example does present the info in
> different format, just to underscore that difference.

I draw a number of conclusions from what Maurice and Joao have said.

(1) Currently, there are actually two kinds of locate mode. One of them
("driver" locate mode) prints out x and y, but otherwise does not allow the
data to be retrieved by the programme. The other ("user" locate mode) does
allow programme access to the data, but it is only available from the C front
end.

The driver locate mode in its present form is not useful for my needs
because my programmes need access to the locate-mode data (x and y and
especially the key or mouse button that was pressed since that allows the
user to enter a wide variety of commands to help in interactive reduction of
spectra).  The user locate mode sounds more promising in that respect, but
it needs to make x, y, and key available to all front ends (i.e., probably
python in my case). Following what currently is possible with driver locate
mode, you should be able to enter or leave user locate mode at will by
pressing the appropriate keys, i.e., it should be available for all examples
for all front ends if an interactive driver with the right capabilities is
specified.

Thus, what I am really pressing for is a single coherent locate mode that
combines the best features of our two present locate modes plus a bit more.
I really need these improvements if I am going to use interactive PLplot for
my next research project, but there may be other improvements to locate mode
that we need to discuss as well so I would welcome such discussion.

(2) Whatever we decide to do with the present locate mode API, we need good
documentation of it.  I was very gratified to hear that Joao had such plans
and once he gets some words down I will be happy to turn it into docbook.
One thing that should be included in such documentation is the driver
requirements for locate mode. Of course, all the user-side locate mode stuff
we have been discussing should be documented as well.

Alan

Re: [Plplot-devel] Other problems with -locate option on x01c

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > I am now only mildly unhappy with this since I can always use L to get into
 > locate mode again.  However, it might be worth changing it to put in some
 > warning message (e.g., "Locate mode is terminated because you are outside a
 > viewport.  To restart use L") so that if, e.g., plwarn works, then the user
 > will get this message.

Maybe the message about locate mode terminated would be ok, as long as it's to
stderr and not stdout.  As for restarting using "L" ... it's not the same
thing.  Locate mode invoked by the driver just outputs the two world
coordinates, whereas locate mode invoked by the user can do anything desired
with the info.  And in fact the x01c example does present the info in
different format, just to underscore that difference.

 > > The internally recognized keys in normal (plotting) mode in the xwin driver
 > > are featured in xwin.c:ProcessKey().  These are:
 > > ...
 > 
 > Thanks for this.  I have noticed experimentally, that right-clicking the
 > mouse when outside locate mode advances to the next page like CR, but I
 > don't see that right-click implemented above.  Also, from the above I don't
 > see how <ESC> is used to leave locate mode.  So the above code must only be
 > part of the interactive story.

Well like I said, those were the recognized *keys* in *normal* (plotting)
mode.  The mouse is handled elsewhere, as is locate mode input.  See xwin.c:
Locate() and ProcessButton().  Also good to look at: MasterEH(), ButtonEH(),
KeyEH().

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Other problems with -locate option on x01c

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

On Sunday 03 March 2002 17:01, Alan W. Irwin wrote:
| On Sun, 3 Mar 2002, Maurice LeBrun wrote:
| > Alan W. Irwin writes:
| >  > Thanks for answering my questions/comments.
| >  >
| >  > I suggest you could improve the design by printing a warning
| >  > message when outside a viewport but continue to stay in locate
| >  > mode for that situation so that subsequent clicks inside
| >  > viewports still work (without having to reinvoke L).=20
| >  > Otherwise, for an example like x01c with lots of area outside
| >  > viewports, the first impression is that locate mode is
| >  > severely broken. (At least that was my impression....;-)) Of
| >  > course to finish locate mode you don't have to click on an
| >  > area with no viewport.  Instead, simply type <ESC> as now.
| >
| > I only just now got around to looking into this.  As it stands,
| > "it's a feature, not a bug".
| >
| > When I was putting this in, Geoff and I discussed the issue and
| > decided the best course on invalid input -- i.e. clicking outside
| > a viewport/window -- was to simply turn off locate mode.  The
| > program's stdout (or stderr) isn't always handy so it's handy to
| > have a graphical cue that you're giving bogus input, and aborting
| > locate mode at that point seems reasonable.  I'm still happy with
| > this decision, but I'll admit documentation is a problem (has
| > been, for a while, but better recently :).
|
| I am now only mildly unhappy with this since I can always use L to
| get into locate mode again.  However, it might be worth changing it
| to put in some warning message (e.g., "Locate mode is terminated
| because you are outside a viewport.  To restart use L") so that if,
| e.g., plwarn works, then the user will get this message.

There is a difference -- when the xhairs appear as a result of a call=20
to plGetCursor() (using -locate in x01c), the user program will=20
receive the button events, while when the xhairs appear as a result=20
of typing 'L', the event are just printed, and the user program has=20
no knowledge of that.

And I think that the visual clue, disappearing of the xhairs, is=20
enought (the xwin driver is not fully interactive -- it hasn't a=20
message area, e.g.): the user program knows that plGetCursor() has=20
failed and the xhairs have disapeared, and if necessary it will=20
invoke the call again, while if invoked via the 'L' key, the user=20
sees the xhair disappearing, and will reinvoke the xhairs again.

Joao

| >  > By the way, before you (and recently somebody else also)
| >  > mentioned the L command and now <ESC> I had never heard of
| >  > them and had no idea you could use locate mode for any of the
| >  > examples other than x01c.
| >  >
| >  > Part of the reason it is taking me so long to get up to speed
| >  > on this interactive stuff is I cannot find any documentation.=20
| >  > Are there any other "locate" commands besides L and <ESC>?  Do
| >  > all interactive drivers have this capability?

Yes, the tk driver share those "driver invoked" capabilities, but has=20
other capabilities as well, use the button Help->on keys

| >  >  Is there some
| >  > documentation that I have missed?  If you point me to some
| >  > documentation or provide me with some, I will put it in the
| >  > docbook documentation form so everybody can easily find it.=20
| >  > Probably the best place would be
| >  > http://plplot.sourceforge.net/resources/docbook-manual/plplotd
| >  >oc-html-0.4.3/interactive-devices.html.

I have several empty drivers/README.<driver> in my local plplot cvs=20
copy, but I had not yet the time to write them. I intend to give an=20
overview of the common cmd line options for all drivers, the driver=20
specific cmd line options, driver capabilities and special uses,=20
required libs, etc. Those can then be incorporated in a drivers=20
manual chapter.


| >
| > The internally recognized keys in normal (plotting) mode in the
| > xwin driver are featured in xwin.c:ProcessKey().  These are:
| >
| > /* Handle internal events */
| >
| >     switch (gin->keysym) {
| >
| >     case PLK_Return:
| >     case PLK_Linefeed:
| >     case PLK_Next:
| >     /* Advance to next page (i.e. terminate event loop) on a
| > <eol> */ /* Check for both <CR> and <LF> for portability, also a
| > <Page Down> */ dev->exit_eventloop =3D TRUE;
| >         break;
| >
| >     case 'Q':
| >     /* Terminate on a 'Q' (not 'q', since it's too easy to hit by
| > mistake) */ pls->nopause =3D TRUE;
| >         plexit("");
| >         break;
| >
| >     case 'L':
| >     /* Begin locate mode */
| >         dev->locate_mode =3D LOCATE_INVOKED_VIA_DRIVER;
| >         CreateXhairs(pls);
| >         break;
| >     }
|
| Thanks for this.  I have noticed experimentally, that
| right-clicking the mouse when outside locate mode advances to the
| next page like CR, but I don't see that right-click implemented
| above.

The above code is for the keys, other code deal with mouse events.

|  Also, from the above I don't see how <ESC> is used to leave
| locate mode.  So the above code must only be part of the
| interactive story.

Yes, while in locate mode you can also use the cursor keys (with=20
SHIT, CTRL, ALT, etc modifiers) to move the cursor.

Joao

|
| Alan

Re: [Plplot-devel] Other problems with -locate option on x01c

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

On Sun, 3 Mar 2002, Maurice LeBrun wrote:

> Joao Cardoso writes:
>  > On Friday 01 March 2002 9:52 pm, Alan W. Irwin wrote:
>  > > With -dev tk you get identical bad results when clicking outside a
>  > > viewport. However, if you stick inside viewports there is an extra twist;
>  > > you get two (!) sets of coordinates for every mouse click.
>  >
>  > I can't reproduce this one.
>
> Nor I.

I cannot reproduce it either at this point.  I don't think anything
significant has changed in PLplot since I got this result so it is possible
something was going sour with my X on Friday, and restarting X since has
"fixed" it.  I will keep an eye out for these symptoms again and do a lot
more experimentation when they occur.

Alan