plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Next release

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

On Friday 28 February 2003 13:51, Rafael Laboissiere wrote:
| * Christophe TROESTLER <deb...@ti...> [2003-02-28 13:49]:
| > Wouldn't the better solution be that the author of libnn agrees to
| > merge the patch in his sources?  Has this been asked?

I sent him the patch, but he didn't show much interest. He is using 
"triangle", which he thinks is more robust than Qhull, and would have 
to maintain code he is not familiar with.

| Probably, but there will be still the problem of asking the users to
| build and install libnn in their system.  I think that this is the
| most important concern.  If we integrate libnn in our source tree, I
| can quickly generate a Makefile.am with Libtool support for it.
|
| Actually, it is already done.  Here is the Makefile.am:
|
|     lib_LTLIBRARIES = libnn.la
|     libnn_la_SOURCES = delaunay.c hash.c istack.c linear.c minell.c \
|                        nnai.c nnpi.c nncommon.c triangle.c
|     libnn_la_LDFLAGS = -version 0:0:0 -lm
|     AM_CPPFLAGS = -I. -DME_UTIL -DTRILIBRARY

hmm, I was thinking to put the new libraries object files into 
libplplot, to easy the linking of users apps. But if we install libnn 
and libcsa the user can use the libraries independently. What do you 
think about this?

Joao

| And here is the configure.ac:
|
|     AC_INIT(nn.h)
|     AC_CONFIG_HEADERS(nnconfig.h)
|     AM_INIT_AUTOMAKE(nn, 1.23)
|     AM_PROG_CC_STDC
|     AM_PROG_LIBTOOL
|     AC_OUTPUT(Makefile)
|
| This will produce the libraries libnn.a and libnn.so.0.0.0

Re: [Plplot-devel] Next release

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

* Christophe TROESTLER <deb...@ti...> [2003-02-28 13:49]:

> Wouldn't the better solution be that the author of libnn agrees to
> merge the patch in his sources?  Has this been asked?

Probably, but there will be still the problem of asking the users to build
and install libnn in their system.  I think that this is the most important
concern.  If we integrate libnn in our source tree, I can quickly generate a
Makefile.am with Libtool support for it. 

Actually, it is already done.  Here is the Makefile.am:

    lib_LTLIBRARIES = libnn.la
    libnn_la_SOURCES = delaunay.c hash.c istack.c linear.c minell.c \
                       nnai.c nnpi.c nncommon.c triangle.c
    libnn_la_LDFLAGS = -version 0:0:0 -lm
    AM_CPPFLAGS = -I. -DME_UTIL -DTRILIBRARY

And here is the configure.ac:

    AC_INIT(nn.h)
    AC_CONFIG_HEADERS(nnconfig.h)
    AM_INIT_AUTOMAKE(nn, 1.23)
    AM_PROG_CC_STDC
    AM_PROG_LIBTOOL
    AC_OUTPUT(Makefile)

This will produce the libraries libnn.a and libnn.so.0.0.0

-- 
Rafael

Re: [Plplot-devel] Next release

[Christophe T. <deb...@ti...>]

On Fri, 28 Feb 2003, Joao Cardoso <jc...@fe...> wrote:
> 
> On Thursday 27 February 2003 20:49, Rafael Laboissiere wrote:
> > * João Cardoso <jc...@fe...> [2003-02-27 19:07]:
> > > I think that the most effective way of using libnn and libcsa is
> > > to incorporate them into our source tree. I have already asked
> > > to libcsa and libnn author's permission, and he agreed.
> >
> > I would avoid this if possible.
> 
> Me too, but we would have to distribute nn and csa ourself, which
> would put an extra configuration/maintenance burden on ourself.
> Also, libnn needs a patch, and it is not reasonable in the
> auto-everything world to ask users to do it for us ;-)

Wouldn't the better solution be that the author of libnn agrees to
merge the patch in his sources?  Has this been asked?

ChriS

Re: [Plplot-devel] Configuration defaults

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

Alan W. Irwin writes:
 > Could we have some discussion about what the configuration defaults should be?
 > 
 > I suspect most of the following are completely ignored at the moment with some
 > superseded by variables set up by autotools.  Shouldn't the ignored ones
 > be completely removed from configure.ac (including the configuration
 > printout at the end which prints them out even though they are
 > meaningless)?
 > 
 > with_debug=no
 > with_opt=yes
 > with_profile=no
 > with_shlib=yes
 > with_warn=no
 > with_dbmalloc=no
 > with_fseek=no
 > with_pkgdir=
 > 
 > Below are some additional options along with how I feel they should be
 > changed (or not).  I lean toward a default of with_double=yes, but if a
 > ...
 > with_double=no				yes?
 > with_gcc=no				?
 > with_freetype=no			yes?
 > enable_dyndrivers=no			yes
 > enable_java=no				no?
 > enable_octave=no			yes
 > enable_gnome=no				no
 > enable_ntk=no				yes?
 > 
 > Are there any other defaults that should be changed?

These are fine with me personally, yes even with_double.  Although in that
case you may trip up some people who are used to the old behavior.

with_debug
with_opt
with_profile
with_warn

Should all stay, as I will get to support them again one of these days.
Probably won't be until April.  

with_shlib should probably also stay if it is currently supported -- does
anyone know?

with_dbmalloc can go AFAIAC.  These days we have access to better tools
(e.g. valgrind) and it has been some years since I've used a debugging
malloc.

BTW I will soon (?) add a few more: with_readline and with_libtecla, both for
supporting command line editing in the pltcl shell.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] Proposed change to xwin.c

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

Alan W. Irwin writes:
 >...
 > Alessandro assures me this option is required for his application.  I
 > presume this is for second and subsequent calls to the xwin driver after the
 > colours have been set in the first call.  I think it is probably worth
 > putting in this option since it may be useful to others and has zero impact
 > otherwise.
 > 
 > If there are no objections to this additional xwin driver option, I propose
 > to commit this later today.

Cool with me.

-- 
Maurice LeBrun    mj...@ga...
Research Organization for Information Science and Technology of Japan (RIST)

Re: [Plplot-devel] Next release

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

On Fri, 28 Feb 2003, Joao Cardoso wrote:

> On Thursday 27 February 2003 23:11, Alan W. Irwin wrote:
> > A related issue is this may be a good opportunity to generalize our
> > argument lists....

>
> I really don't want to mess with some plot functions internals.  [...]
> This does not means that it can't be done, perhaps in an elegant way, I don't
> know, as I never looked at them from that perspective.

OK.  After the next release (which will presumably contain your current
set of changes) I will look into the additional issue I have brought up.

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
__________________________

Re: [Plplot-devel] Next release

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

On Thursday 27 February 2003 23:11, Alan W. Irwin wrote:
> On Thu, 27 Feb 2003, [iso-8859-1] Jo=E3o Cardoso wrote:
> > My question is if we should not abandon the bug fix release, and take
> > the April opportunity to make a new real release instead.
>
> I agree 100 per cent with Rafael's response on this question.  What is =
in
> CVS at release time defines whether the release is bug-fix or not.
>
> > [...]I have a new API
> > entry to submit. It's an utility function to grid data, removing the
> > limitation that our 3D data plots have of using regularly sampled dat=
a.
>
> How does this compare with the pltr1 and pltr2 interpolation that alrea=
dy
> exists for the plcont and plshade(s) part of our 3D API? I don't mind
> adding an additional interpolation scheme possibility so long as it
> can be used in the same way pltr1 and pltr2 are used now.

I didn't take the approach of provinding another pltr*().

Instead, if the user has irregularly sampled data he must call plgriddata=
() to=20
obtain gridded data; after that he can use the usual 3D data APIs, whatev=
er=20
they are, from plshade() to plot3d(), plsurf3d() or whatsoever.
That's why I call plgriddata() an utility function, as the user can use i=
ts=20
own gridding algorithm instead.

This is the relevant plplot.h section:

  /* grid irregularly sampled data */

void
plgriddata(PLFLT *x, PLFLT *y, PLFLT *z, int npts,
=09   PLFLT *xg, int nptsx, PLFLT *yg,  int nptsy,
=09   PLFLT **zg, int type, PLFLT data);

  /* type of gridding algorithm for plgriddata() */

#define GRID_CSA    1 /* Bivariate Cubic Spline approximation  */
#define GRID_DTLI   2 /* Delaunay Triangulation Linear Interpolation */
#define GRID_NNI    3 /* Natural Neighbors Interpolation  */
#define GRID_NNIDW  4 /* Nearest Neighbors Inverse Distance Weighted */
#define GRID_NNLI   5 /* Nearest Neighbors Linear Interpolation */
#define GRID_NNAIDW 6 /* Nearest Neighbors Around Inverse Distance Weight=
ed =20
*/

GRID_CSA uses libcsa, GRID_DTLI and GRID_NNI  uses nn (that uses Qhull), =
while=20
GRID_NNIDW, GRID_NNLI and GRID_NNAIDW are implemented in plgriddata.c.

x, y and z are ntps sized input arrays; xg[ntpsx] and yg[ntpsy] define th=
e=20
desired grid size and spacing, while zg[nptsx][nptsy] is the output gridd=
ed=20
data.

> A related issue is this may be a good opportunity to generalize our
> argument lists for all our 3D functions. For now plcont and plshades al=
low
> PLcGrid or PLcGrid2 style arguments to pass the x,y information and
> interpolate with pltr1, pltr2, or any other interpolation function
> specified by the user. Those arguments have enough generality so that t=
he
> x,y surface can be irregular in shape (something I need for my research=
 for
> all the 3D API). Thus, I would like to see the plcont and plshade(s) sc=
heme
> for passing the x,y information adopted for plsurf3d and the rest of ou=
r 3D
> API.

I really don't want to mess with some plot functions internals. Often the=
y=20
were designed with a certain objective in mind, and changing them with=20
another objective can turns the code confusing.
This does not means that it can't be done, perhaps in an elegant way, I d=
on't=20
know, as I never looked at them from that perspective.

> This additional facility should, of course, be implemented as added API
> rather than changed API.  There is certainly a place for simple 3D API
> calls where x and y appear as separate arrays rather than as part of a
> PLcGrid or PLcGrid2 structure.  But I (and presumably many other users)
> need the other more general alternative as well.  To be blunt about thi=
s,
> gnuplot has allowed irregular shaped x,y domains for all their 3D API s=
ince
> 1996, and I think it is long past time that PLplot caught up.

I don't know how gnuplot does it internally, I only know that irregular=20
gridded data is allowed.

Joao

>
> Alan
> __________________________
> Alan W. Irwin
> email: ir...@be...
> phone: 250-727-2902
>
> Astronomical research affiliation with Department of Physics and Astron=
omy,
> 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
> __________________________
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Next release

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

On Thursday 27 February 2003 20:49, Rafael Laboissiere wrote:
> * Jo=E3o Cardoso <jc...@fe...> [2003-02-27 19:07]:
> > But now I'm starting to think that a newer release will only happen i=
n
> > within a year, as we usually only release once a year, given our
> > limited human resources.
> > I thus think that's a pity that my improvements will only reach users=
 in
> > 2004. Also, the "bug fix" turned out to be a major configuration
> > redesign.
> >
> > My question is if we should not abandon the bug fix release, and take
> > the April opportunity to make a new real release instead.
>
> I think that Alan will agree with me on this: what determines the relea=
se
> number is the improvement in CVS, not the reverse.  So, if your changes=
 are
> integrated and if they build and work correctly until April, I do not s=
ee
> any problem in committing it.  We should just be careful to not put HEA=
D in
> a severe bad state.

Well, they were working after 5.2.0 but before your configuration changes=
=2E As=20
a matter of fact I'm expecting  your help with the configuration issue.

> > plgriddata() takes non-uniformly sampled data and will resample it us=
ing
> > several techniques, returning gridded data ready for use with our 3D
> > data APIs.
> >
> > The new function requires access to an well know external library, Qh=
ull
> >  (that Rafael knows well), http://www.thesa.com/software/qhull/,
> > and to other simple libraries, libnn and libcsa,
> > http://www.marine.csiro.au/~sakov/
>
> Sounds great.
>
> > libnn and libcsa are small libraries not widely know and its
> > configuration does not supports shared libraries. libnn also needs a
> > patch to work with Qhull, because by default it works with "triangle"=
,
> > http://www-2.cs.cmu.edu/~quake/triangle.html, which is a non-free
> > program.
> >
> > I think that the most effective way of using libnn and libcsa is to
> > incorporate them into our source tree. I have already asked to libcsa=
 and
> > libnn author's permission, and he agreed.
>
> I would avoid this if possible.

Me too, but we would have to distribute nn and csa ourself, which would p=
ut an=20
extra configuration/maintenance burden on ourself.
Also, libnn needs a patch, and it is not reasonable in the auto-everythin=
g=20
world to ask users to do it for us ;-)

>  I took a look at libnn.  It compiles fine,
> but generates only a static lib.  I agree with you that integrating it =
in
> our source tree is probably the best thing to do.

The way how I setup them in my sources was to create two subdirectories i=
n=20
src, one to hold a striped version of nn and another subdir to hold a str=
iped=20
csa. csa can always be built, as it depends on nothing, while nn should o=
nly=20
be built if Qhull is available. In the src directory there is a new file,=
=20
plgriddata.c, which is always built.

As I said in another mail, I don't have much time now, but I can try to u=
se=20
the Carnival holiday to update my setup to your configuration changes (th=
at=20
you will latter hopefully fix :) and commit them.

I will commit my other changes latter.

Joao

Re: [Plplot-devel] Next release

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

On Thu, 27 Feb 2003, [iso-8859-1] Jo=E3o Cardoso wrote:

> My question is if we should not abandon the bug fix release, and take
> the April opportunity to make a new real release instead.

I agree 100 per cent with Rafael's response on this question.  What is in
CVS at release time defines whether the release is bug-fix or not.

> [...]I have a new API
> entry to submit. It's an utility function to grid data, removing the
> limitation that our 3D data plots have of using regularly sampled data.

How does this compare with the pltr1 and pltr2 interpolation that already
exists for the plcont and plshade(s) part of our 3D API? I don't mind
adding an additional interpolation scheme possibility so long as it
can be used in the same way pltr1 and pltr2 are used now.

A related issue is this may be a good opportunity to generalize our argumen=
t
lists for all our 3D functions. For now plcont and plshades allow PLcGrid o=
r
PLcGrid2 style arguments to pass the x,y information and interpolate with
pltr1, pltr2, or any other interpolation function specified by the user.
Those arguments have enough generality so that the x,y surface can be
irregular in shape (something I need for my research for all the 3D API).
Thus, I would like to see the plcont and plshade(s) scheme for passing the
x,y information adopted for plsurf3d and the rest of our 3D API.

This additional facility should, of course, be implemented as added API
rather than changed API.  There is certainly a place for simple 3D API call=
s
where x and y appear as separate arrays rather than as part of a PLcGrid or
PLcGrid2 structure.  But I (and presumably many other users) need the other
more general alternative as well.  To be blunt about this, gnuplot has
allowed irregular shaped x,y domains for all their 3D API since 1996, and I
think it is long past time that PLplot caught up.

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 softwar=
e
package (plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Next release

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

* João Cardoso <jc...@fe...> [2003-02-27 19:07]:

> But now I'm starting to think that a newer release will only happen in 
> within a year, as we usually only release once a year, given our 
> limited human resources.
> I thus think that's a pity that my improvements will only reach users in 
> 2004. Also, the "bug fix" turned out to be a major configuration 
> redesign.
> 
> My question is if we should not abandon the bug fix release, and take 
> the April opportunity to make a new real release instead.

I think that Alan will agree with me on this: what determines the release
number is the improvement in CVS, not the reverse.  So, if your changes are
integrated and if they build and work correctly until April, I do not see
any problem in committing it.  We should just be careful to not put HEAD in
a severe bad state.

> plgriddata() takes non-uniformly sampled data and will resample it using  
> several techniques, returning gridded data ready for use with our 3D 
> data APIs.
> 
> The new function requires access to an well know external library, Qhull
>  (that Rafael knows well), http://www.thesa.com/software/qhull/,
> and to other simple libraries, libnn and libcsa, 
> http://www.marine.csiro.au/~sakov/

Sounds great.

> libnn and libcsa are small libraries not widely know and its 
> configuration does not supports shared libraries. libnn also needs a 
> patch to work with Qhull, because by default it works with "triangle", 
> http://www-2.cs.cmu.edu/~quake/triangle.html, which is a non-free 
> program.
>
> I think that the most effective way of using libnn and libcsa is to 
> incorporate them into our source tree. I have already asked to libcsa and
> libnn author's permission, and he agreed.

I would avoid this if possible.  I took a look at libnn.  It compiles fine,
but generates only a static lib.  I agree with you that integrating it in
our source tree is probably the best thing to do.

-- 
Rafael

[Plplot-devel] Next release

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

Hi,

I have a certain amount of improvements in my sources that I'm reserving 
to commit for a future (not the April) release. The reasoning is that 
the April release will be to fix bugs.

But now I'm starting to think that a newer release will only happen in 
within a year, as we usually only release once a year, given our 
limited human resources.
I thus think that's a pity that my improvements will only reach users in 
2004. Also, the "bug fix" turned out to be a major configuration 
redesign.

My question is if we should not abandon the bug fix release, and take 
the April opportunity to make a new real release instead.

Most of my changes are only small improvements, but I have a new API 
entry to submit. It's an utility function to grid data, removing the 
limitation that our 3D data plots have of using regularly sampled data.
The new function, plgriddata(), does no plotting at all and implies no 
changes to any other plplot function, and so it will not break 
anything.
plgriddata() takes non-uniformly sampled data and will resample it using  
several techniques, returning gridded data ready for use with our 3D 
data APIs.

The new function requires access to an well know external library, Qhull
 (that Rafael knows well), http://www.thesa.com/software/qhull/,
and to other simple libraries, libnn and libcsa, 
http://www.marine.csiro.au/~sakov/

libnn and libcsa are small libraries not widely know and its 
configuration does not supports shared libraries. libnn also needs a 
patch to work with Qhull, because by default it works with "triangle", 
http://www-2.cs.cmu.edu/~quake/triangle.html, which is a non-free 
program.

I think that the most effective way of using libnn and libcsa is to 
incorporate them into our source tree. I have already asked to libcsa 
and libnn author's permission, and he agreed.

Comments?

Joao

[Plplot-devel] Proposed change to xwin.c

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

One of our users (Alessandro Mirone) has a huge pyqt-based PLplot GUI
application his group has developed which he has just ported from
plplot-5.1.0 to recent CVS (in anticipation of 5.2.1).  However, to get his
application to work, he needs to have an option to not initialize the colors
in xwin.

Here is his proposed change to xwin.c. (I have also taken the opportunity to
clean up some commentary on the other xwin options.)

--- xwin.c_old	Thu Feb 27 06:55:28 2003
+++ xwin.c	Thu Feb 27 07:40:54 2003
@@ -20,7 +20,10 @@
                                 /* Use "-drvopt sync" cmd line option to set. */

 static int nobuffered = 0;      /* make it a buffered device by default */
-                                /* use "-drvopt buffered=0" to make it unbuffered */
+                                /* use "-drvopt unbuffered" to make it unbuffered */
+
+static int noinitcolors = 0;    /* Call InitColors by default */
+                                /* use "-drvopt noinitcolors" to leave colors uninitialized */

 /* When USE_DEFAULT_VISUAL is defined, DefaultVisual() is used to get the
  * visual.  Otherwise, the visual is obtained using XGetVisualInfo() to make a
@@ -161,6 +164,7 @@

 static DrvOpt xwin_options[] = {{"sync", DRV_INT, &synchronize, "Synchronized X server operation (0|1)"},
 				{"nobuffered", DRV_INT, &nobuffered, "Sets unbuffered operation (0|1)"},
+				{"noinitcolors", DRV_INT, &noinitcolors, "Sets cmap0 allocation (0|1)"},
 				{NULL, DRV_INT, NULL, NULL}};

 void plD_dispatch_init_xw( PLDispatchTable *pdt )
@@ -820,7 +824,7 @@

 /* Initialize colors */

-    InitColors(pls);
+    if (noinitcolors == 0) InitColors(pls);
     XSetWindowColormap( xwd->display, dev->window, xwd->map );

 /* Set up GC for ordinary draws */

I have checked that this builds and executes without problems.

Alessandro assures me this option is required for his application.  I
presume this is for second and subsequent calls to the xwin driver after the
colours have been set in the first call.  I think it is probably worth
putting in this option since it may be useful to others and has zero impact
otherwise.

If there are no objections to this additional xwin driver option, I propose
to commit this later today.

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] Next version and soname numbers

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

Alan and I (and Joao, occasionally) have been working on polishing the rough
edges of the Autotools configuration system of PLplot.  If you are listening
to plplot-cvs, you will see that a lot of commits have been done lately.
Most of them concerned the AT configuration, but there was also the
inclusion of a new driver ("mem", to be used by the PDL bindings) and some
improvements in the documentation.

Alan scheduled the next release for April.  It is still a little bit too
early, but I would like to discuss about the next soname and release
numbers.

First, the soname.  Since the API changed (inclusion of plsmem) but is
backward compatiblity with the latest release, the version-info string
should be updated to 8:0:3. In Linux, we will end up with libraries like
lib*.so.5.3.0. This may be different for other platforms.

As regards the next PLplot version number, I would suggest 5.2.1 if nothing
radically new happens to the CVS sources until April.  Almost all changes
that are now in CVS are transparent to the user, most of them concern just
the configuration scheme.  We should not make a greater bump like 5.3.0,
because this would create the false expectation of lots of new features
added, which is not the case.

If nobody objects, I will change the SOVERSION value in configure.ac as
indicated above.  Of course, this may change before the next release.

-- 
Rafael

[Plplot-devel] Configuration defaults

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

Could we have some discussion about what the configuration defaults should be?

I suspect most of the following are completely ignored at the moment with some
superseded by variables set up by autotools.  Shouldn't the ignored ones
be completely removed from configure.ac (including the configuration
printout at the end which prints them out even though they are
meaningless)?

with_debug=no
with_opt=yes
with_profile=no
with_shlib=yes
with_warn=no
with_dbmalloc=no
with_fseek=no
with_pkgdir=

Below are some additional options along with how I feel they should be
changed (or not).  I lean toward a default of with_double=yes, but if a
consensus forms to keep it the same I will go along.  I am not sure about
with_gcc=no.  It may be meaningless, and I don't know how it fits with the
autoconf way of setting compiler precedence. We might actually want
everybody to use gcc if they have it on their system. Is it time to turn
freetype on by default? That of course means it will only be used if
installed on the user's system. I think dyndrivers should be on by default.
I think the java interface is ready for extensive testing, but since that
testing hasn't occurred yet I lean toward no in that case, but probably yes
for the next release after this one.  I cannot judge octave that well, but
it has seemed stable to me for a long time so I think we should change it to
yes. gnome has problems so should continue to be no.  ntk seems stable to
me, so I lean toward yes.  It doesn't have all the features of tk, but on
the other hand that is true of the rest of our drivers as well.

with_double=no				yes?
with_gcc=no				?
with_freetype=no			yes?
enable_dyndrivers=no			yes
enable_java=no				no?
enable_octave=no			yes
enable_gnome=no				no
enable_ntk=no				yes?

Are there any other defaults that should be changed?

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
__________________________

Re: [Plplot-devel] octave is broken by recent changes

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

* Alan W. Irwin <ir...@be...> [2003-02-26 08:02]:

> configure and make are okay, but in the installed examples directory
> please try the following:
> 
> ./plplot-test.sh --front-end=octave
> 
> error: plplot_octave' undefined near line 922 column 10

This works in my Debian installation, because the Octave goes into standard
locations (i.e. I use --prefix=/usr).  That is the reason I never went
accros this bug.

Below is the (untested) patch that should fixes the problem:

--- plplot-test.sh.in-orig	2003-02-26 19:14:24.000000000 +0100
+++ plplot-test.sh.in	2003-02-26 19:20:04.000000000 +0100
@@ -39,7 +39,7 @@
 export pythondir
 tcldir=tcl
 export tcldir
-octavedir=@prefix@/share/plplot_octave//:@prefix@/@DATA_DIR@/../examples/octave
+octavedir=@PLPLOT_OCTAVE_DIR@//:@OCTAVE_M_DIR@//:@OCTAVE_OCT_DIR@//:@prefix@/@DATA_DIR@/../examples/octave//:
 export octavedir
 installbindir=@prefix@/bin
 export installbindir
--- test_octave.sh-orig	2003-02-26 19:16:24.000000000 +0100
+++ test_octave.sh	2003-02-26 19:19:42.000000000 +0100
@@ -7,7 +7,7 @@
 # WARNING, 'octave' can be defined at 'configure' time, to
 # allow for different installed versions. (work in progress)
 
-octave -f -q -p $octavedir//: <<EOF
+octave -f -q -p $octavedir <<EOF
 plplot_stub;
 t = split("$options", "-"); t(1,:)="";
 for i=1:rows(t)

 
Test it please, Alan.

I have to change something in use_plplot.m in order to have it working in
non-standard installation, but this is another story.

-- 
Rafael

Re: [Plplot-devel] octave is broken by recent changes

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

On Tue, 25 Feb 2003, Rafael Laboissiere wrote:

> I tested it with Octave
> 2.0 and it works fine here.  Could you test it again, please?

Just tried that with fresh checkout including your recent docbook fix, and
there are still problems.

configure and make are okay, but in the installed examples directory
please try the following:

./plplot-test.sh --front-end=octave

error: plplot_octave' undefined near line 922 column 10
error: evaluating index expression near line 922, column 10
error: evaluating assignment expression near line 922, column 8
error: called from plgstrm'
error: evaluating argument list element number 1
error: called from figure' in file
/usr/local/plplot_at/share/plplot_octave/figure.m'

Apparently octavedir is set wrong for your new install location.
If I attempt to fix that problem in the local script file using
octavedir=/usr/local/plplot_at/lib/octave/site/oct/i386-pc-linux-gnu/:/usr/local/plplot_at/lib/plplot5.2.0/data/../examples/octave

then the following error results:

./plplot-test.sh --front-end=octave
error: plplot_stub' undefined near line 1 column 1
error: evaluating expression near line 1, column 1

I suspect an additional directory is needed for octavedir, but which one?

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
__________________________

Re: [Plplot-devel] octave is broken by recent changes

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

On Tuesday 25 February 2003 18:40, Alan W. Irwin wrote:
> Fresh checkout today at 17:09 UTC (there have been two commits
> since, but they are only concerned with docbook).
>
> ./configure --prefix=3D/usr/local/plplot_at --with-double --enable-dynd=
rivers
> --enable-octave --enable-gnome --enable-ntk --enable-java
> --with-www-user=3Dairwin > & ! configure.out
>
> gives the following message:
>
> checking for octave... yes
> error: structure has no member localoctfiledir'
> error: evaluating expression
> error: evaluating argument list element number 2
> error: evaluating index expression near line 2, column 9
>
> Although this message says error, the configuration continued without
> problems afterward, and I was also able to build and install everything
> without any obvious error message.
>
> However, later I ran plplot-test.sh in the installed examples area and
> there were severe octave problems.  I therefore looked closer at the ma=
ke
> install output, and I found this command was executed:
>
> /usr/bin/install -c plplot_octave-libdir.oct \
>   /usr/local/plplot_at//plplot_octave.oct
>
> So clearly, plplot_octave.oct is being installed in the wrong place
> (probably something to do with the above configuration error message).
>
> Rafael, if you cannot confirm the configure error message, please try a=
gain
> using octave-2.0.16.92-7 from Debian woody.  It is probably best to alw=
ays
> check your changes with that version since Joao has stated within the l=
ast
> few months that it is important to continue support for octave-2.0.16.

I still think that we must support octave-2.0.16/17, as that is the *offi=
cial=20
stable* release. Even if RH ships a 2.1 version, which means nothing -- R=
H=20
also shipped a non-existent gcc version, what caused a lot of problems to=
 its=20
users.

There are a *lot* of improvements in plplot_octave that could be done if =
we=20
stick to the 2.1.x series, but I don't think that to be wise, as there is=
=20
many people still using 2.0.16 -- that's enough to read the octave mailii=
ng=20
lists to understand that.

I don't have time in the next weeks to do anything for plplot.

Joao

>
> Alan
> __________________________
> Alan W. Irwin
> email: ir...@be...
> phone: 250-727-2902
>
> Astronomical research affiliation with Department of Physics and Astron=
omy,
> 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
> __________________________
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] octave is broken by recent changes

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

* Alan W. Irwin <ir...@be...> [2003-02-25 13:56]:

> I would wait to see what Joao says before you make these changes.  He may
> have changed his mind by now about supporting 2.0, and I certainly don't
> mind if we insist on 2.1 by the appropriate octave version test in our
> configuration.

Too late.  The change is done and CVS committed.  I tested it with Octave
2.0 and it works fine here.  Could you test it again, please?

-- 
Rafael

Re: [Plplot-devel] octave is broken by recent changes

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

On Tue, 25 Feb 2003, Rafael Laboissiere wrote:

> The localoctfiledir has been introduced in octave 2.1.  Sorry for not
> testing my changes with Octave 2.0.  IMHO, we should not insist in
> supporting Octave 2.0.  The 2.1 series is fully stable and I frequently hear
> in of Octave users mailing lists that 2.0 should be abandoned.

I just checked and RH7.3 and 8.0 use octave 2.1, but Debian woody does not.
Although that is my distribution, I don't care since supporting old versions
is often more trouble than it is worth.  If we decide not to support octave
2.0, then we should put in a configuration test for octave version.  Debian
woody tarball users (probably a pretty small group of users) who want octave
can always download the latest version.

>
> However, I will try to find a fix to have the configuration working with
> Octave 2.0 (here we go: more cruft in confiugre.ac ...)

I would wait to see what Joao says before you make these changes.  He may
have changed his mind by now about supporting 2.0, and I certainly don't
mind if we insist on 2.1 by the appropriate octave version test in our
configuration.

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
__________________________

Re: [Plplot-devel] octave is broken by recent changes

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

* Alan W. Irwin <ir...@be...> [2003-02-25 10:40]:

> Fresh checkout today at 17:09 UTC (there have been two commits
> since, but they are only concerned with docbook).
> 
> ./configure --prefix=/usr/local/plplot_at --with-double --enable-dyndrivers
> --enable-octave --enable-gnome --enable-ntk --enable-java
> --with-www-user=airwin > & ! configure.out
> 
> gives the following message:
> 
> checking for octave... yes
> error: structure has no member localoctfiledir'
> error: evaluating expression
> error: evaluating argument list element number 2
> error: evaluating index expression near line 2, column 9

The localoctfiledir has been introduced in octave 2.1.  Sorry for not
testing my changes with Octave 2.0.  IMHO, we should not insist in
supporting Octave 2.0.  The 2.1 series is fully stable and I frequently hear
in of Octave users mailing lists that 2.0 should be abandoned.

However, I will try to find a fix to have the configuration working with
Octave 2.0 (here we go: more cruft in confiugre.ac ...)

-- 
Rafael

Re: [Plplot-devel] plGetcursor (mouse and plplot)

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

On Tue, 25 Feb 2003 ba...@ph... wrote:

> Hi,
>
> I am thinking of converting from pgplot to plplot and I have
> a question concerning using the mouse in plplot:
>
> Namely, in Python I would like to wait for a mouse-click and get its
> coordinates. With ppgplot and the "/xwin" this works via
>         ch=pgcurs(x, y)       # wait for mouse-click
>         x,y=ch[0],ch[1]
>
> I could not find a pendant for this in plplot.
> Digging a bit it turns out that there
> is a  plGetcursor in bindings/python/plmodule.c.

I am impressed with how far you dug for this!  We have just undergone the
transition from a hand-crafted interface (plmodule.c) to a swig-generated
one.  We only keep plmodule.c around for historical reasons, but it has paid
off this time.  I had no clue that plGetcursor was in plmodule.c until you
pointed it out.

> However, in plplotcapi.i the corresponding section is commented out
> (quite at the end of the text ...).

This file together with plplotcmodule.i provides the input to swig that it
needs to generate the plplot interface.  I just tried uncommenting that
section in plplotcapi.i, and it generated a reasonable-looking interface
file that built and installed okay so I am committing the change to CVS.

I did one crude test, where this functionality seemed to work, but the
result needs further testing. Could you give that a try and let me know (off
list) how it goes?

Note, you will need swig-1.3.17.  Earlier versions won't work.

>
> This leaves me with several questions:
>   - is it save to uncomment this part and give it a try ?

Yes, with swig-1.3.17.

>   - what is the reason for excluding this routine ?

I wanted to limit the API to the so-called common API, that subset of the
public API that we make available for all interfaces.  However, that is not
a hard and fast rule, and certainly with the swig-generated interfaces it is
possible with some effort to wrap all the public API, not just the common
API subset.  Certainly if the API was available before in the old plmodule.c
it should be available in the swig-generated interface.

>   - if it works with an xwin under Linux, would it also work in
>     M$Windows ?

You should ask Olof Svensson who is in charge of that effort.

>
> Generally I think that the possibility of interactively using
> the mouse is quite important.

I agree.  Our C front end with the xwin driver has some capability in this
direction (see the locate mode in the examples/c/x01c.c example).  It should
be straightforward to generalize examples/python/xw01.py to test this xwin
driver capability in the same way.

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] octave is broken by recent changes

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

Fresh checkout today at 17:09 UTC (there have been two commits
since, but they are only concerned with docbook).

./configure --prefix=/usr/local/plplot_at --with-double --enable-dyndrivers
--enable-octave --enable-gnome --enable-ntk --enable-java
--with-www-user=airwin > & ! configure.out

gives the following message:

checking for octave... yes
error: structure has no member localoctfiledir'
error: evaluating expression
error: evaluating argument list element number 2
error: evaluating index expression near line 2, column 9

Although this message says error, the configuration continued without
problems afterward, and I was also able to build and install everything
without any obvious error message.

However, later I ran plplot-test.sh in the installed examples area and there
were severe octave problems.  I therefore looked closer at the make install
output, and I found this command was executed:

/usr/bin/install -c plplot_octave-libdir.oct \
  /usr/local/plplot_at//plplot_octave.oct

So clearly, plplot_octave.oct is being installed in the wrong place (probably
something to do with the above configuration error message).

Rafael, if you cannot confirm the configure error message, please try again
using octave-2.0.16.92-7 from Debian woody.  It is probably best to always
check your changes with that version since Joao has stated within the last
few months that it is important to continue support for octave-2.0.16.

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
__________________________

Re: [Plplot-devel] plplot_python_start.py: executable-not-elf-or-script

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

On Tue, 25 Feb 2003, Rafael Laboissiere wrote:

> This is for the PLplot Python wizards:
>
> Lintian, the Debian package checker is complaining that the installed
> plplot_python_start.py is "executable-not-elf-or-script". I see two ways of
> fixing this:
>
> 1) Moving plplot_python_start.py form examples_python_SCRIPTS to
>    examples_python_DATA in examples/python/Makefile.am
>
> 2) Adding "#/usr/bin/env python" at the beginning of plplot_python_start.py.
>
> I am going to implement one of these.  Which do you prefer?

Use (1).  plplot_python_start.py is not a standalone script.  Instead, it is
a python module that you import just like xw??.py.

Alan, "python wizard in training"....;-)

__________________________
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] plGetcursor (mouse and plplot)

[<ba...@ph...>]

Hi,

I am thinking of converting from pgplot to plplot and I have
a question concerning using the mouse in plplot:

Namely, in Python I would like to wait for a mouse-click and get its
coordinates. With ppgplot and the "/xwin" this works via
        ch=pgcurs(x, y)       # wait for mouse-click
        x,y=ch[0],ch[1]

I could not find a pendant for this in plplot.
Digging a bit it turns out that there
is a  plGetcursor in bindings/python/plmodule.c.
However, in plplotcapi.i the corresponding section is commented out
(quite at the end of the text ...).

This leaves me with several questions:
  - is it save to uncomment this part and give it a try ?
  - what is the reason for excluding this routine ?
  - if it works with an xwin under Linux, would it also work in
    M$Windows ?

Generally I think that the possibility of interactively using
the mouse is quite important. There seem to be very few
packages available which do this in an easy way.
(for example some tools which can do this keep an id for any plotted
point, which leads to problems when plotting several 10000 points ...)

((Side remark:
More generally I would find it nice to have routine which does not wait
for a mouse-click but just returns the corresponding information (button
and position) whenever you invoke the routine (of course only if there was
a mouse-event).
But for the moment the above functionality would be fine ...))

Many thanks,

Arnd

[Plplot-devel] plplot_python_start.py: executable-not-elf-or-script

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

This is for the PLplot Python wizards:

Lintian, the Debian package checker is complaining that the installed
plplot_python_start.py is "executable-not-elf-or-script". I see two ways of
fixing this:

1) Moving plplot_python_start.py form examples_python_SCRIPTS to
   examples_python_DATA in examples/python/Makefile.am

2) Adding "#/usr/bin/env python" at the beginning of plplot_python_start.py.

I am going to implement one of these.  Which do you prefer?

-- 
Rafael