plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] done with config changes + STATUS QUESTION

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

Geoffrey Furnish writes:
 > 2) I just found that I can't run configure on a slowaris box.  That
 > seems significant to me, and I'll be looking into it now.

The problem is near the top:

with_defaults=yes
for option; do
    case "$option" in
    -with-defaults | --with-defaults | -with-defaults=yes |
--with-defaults=yes )
		        with_defaults=yes
			;;
			-without-defaults | --without-defaults |
-with-defaults=no | --with-defaults=no )
		      with_defaults=no
		      ;;
    esac
done

Sun sh flips out saying the ; after "option" in the for clause, is
unexpected.  Yet Sun man sh says:

     for  name [ in word ... ] do list done
               Each time a for  command is executed, name is  set
               to  the  next word taken from the in word list. If
               in word ... is omitted, then the for  command exe-
               cutes the do list once for each positional parame-
               ter that is set (see Parameter  Substitution  sec-
               tion below). Execution ends when there are no more
               words in the list.

But, evidently, it doesn't actually work as documented.  I'm cahnging
this to:

for option in $*; do

which it seems to accept.  Sheesh.

This is a Sunos 5.7 box, fyi.

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

Re: [Plplot-devel] done with config changes + STATUS QUESTION

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

Alan W. Irwin writes:
 > STATUS QUESTION:
 > 
 > So is there anything left on our plates other than the fortran problems that
 > Joao has found?  

Well, uhh, here's a couple of things on my mind.

1) I'm not really done with the plshade api wrappers for Java.  I just
did the double with no coord xforms, needed for x15.java.  If you
implement the other java demos (16 and 18), I'll have some more api
work to do to get them displaying, and even if not, I kinda need to at
least do the float prec version of what I did Friday night for one of
the double cases.  Will /try/ to do this today, but would appreciate
being allowed to slipstream some changes to javabind.c in later if I
can't get it done before 8 am tomorrow.  Doubt I'll be hacking from
home tonight.

2) I just found that I can't run configure on a slowaris box.  That
seems significant to me, and I'll be looking into it now.

Re: [Plplot-devel] done with config changes + STATUS QUESTION

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

On Mon, 21 Jan 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > All these devices worked fine, but I don't understand why --disable-drivers
>  > is not affecting cgm. ...
>
> It's because of the following lines in configure.in, near the top:
>
> #explicit default values must be specified here for library and header
> #searching to work right for the following variables.  Note these variables
> #also have a driver role to play, but unlike these, pure-driver variables
> #(e.g., enable_tek4010) do not require a default to be specified here.
> enable_gnome=no
> enable_ntk=no
> enable_png=yes
> enable_jpeg=yes
> enable_cgm=yes
> enable_tk=yes
> enable_xwin=yes
>
> --disable-drivers only sets the default to "no", and doesn't override any
> explicitly enabled devices, which these are (equivalent to command line
> settings).  Apparently they do serve a purpose for getting library linkage
> right under Linux -- I just tried without them and the build failed (to my
> surprise).  There may be a better way to fix it, I dunno.  But anyway
> apparently works as expected.  You can always use explicit disabling of
> devices, which I do, from my ~/config/cf_plplot.in file.

I woke up this morning (apparently close to when you finished working hard
all night.... thanks!) with the same idea that it had something to do with
the extra library configuration that occurs for certain drivers.  Thanks for
investigating further to determine this special configuration was still
necessary.  I agree, let's continue to live with it.

>  > tk.o(.text+0x1c70): the use of tmpnam' is dangerous, better use mkstemp'
>  >
>  > I suspect this message means our use of tmpnam is opening a security hole.
>  > I don't know how serious this is, but, Maurice, if you know how to use
>  > mkstemp then you may want to switch to it from tmpnam.
>
> Theoretically there is a problem, but I'm not worrying about it.  tmpnam is
> POSIX, mkstemp is not.  Maybe eventually I'll do some configure stuff to use
> mkstemp where available, otherwise tmpnam, just to shut up gcc.  But not that
> important to me.

Thanks for looking into this.

STATUS QUESTION:

So is there anything left on our plates other than the fortran problems that
Joao has found?  (BTW, I view that bug as serious.  For now, Joao has to
deal with this bug on his own. Since I cannot reproduce it on my system, I
am reduced to helping him only with guess work.  Those with some fortran
knowledge, please do take a few minutes to attempt reproducing the bug on your
systems on the off chance that you can give him some help to solve this
quickly.)

Alan

Re: [Plplot-devel] problem with x01c.c

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

On Mon, 21 Jan 2002, Maurice LeBrun wrote:

> You're right, it was just a slip, and gcc didn't complain so I missed it.

Since both Andrew and Maurice are agreed, and this change causes no problems
for me, I made the commit.

Alan

Re: [Plplot-devel] problem with x01c.c

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

On Mon, 21 Jan 2002, Maurice LeBrun wrote:

> You're right, it was just a slip, and gcc didn't complain so I missed it.

Since both Andrew and Maurice are agreed, and this change causes no problems
for me, I made the commit.

Alan

Re: [Plplot-devel] done with config changes

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

Alan W. Irwin writes:
 > On Sun, 20 Jan 2002, Maurice LeBrun wrote:
 > I also tried
 > 
 > ./configure --disable-drivers --enable-png --enable-dyndrivers
 > 
 > and I got
 > 
 > devices:         png jpeg cgm xwin tk
 > 
 > Available device drivers
 > static:          xwin tk
 > dynamic:         gd cgm
 > 
 > All these devices worked fine, but I don't understand why --disable-drivers
 > is not affecting cgm. ...

It's because of the following lines in configure.in, near the top:

#explicit default values must be specified here for library and header  
#searching to work right for the following variables.  Note these variables 
#also have a driver role to play, but unlike these, pure-driver variables 
#(e.g., enable_tek4010) do not require a default to be specified here. 
enable_gnome=no 
enable_ntk=no 
enable_png=yes 
enable_jpeg=yes 
enable_cgm=yes 
enable_tk=yes 
enable_xwin=yes 
 
--disable-drivers only sets the default to "no", and doesn't override any
explicitly enabled devices, which these are (equivalent to command line
settings).  Apparently they do serve a purpose for getting library linkage
right under Linux -- I just tried without them and the build failed (to my
surprise).  There may be a better way to fix it, I dunno.  But anyway
apparently works as expected.  You can always use explicit disabling of
devices, which I do, from my ~/config/cf_plplot.in file.

 > Finally, I noticed the following compilation messages for the first
 > configuration (but none of the others, interestingly).
 > 
 > tk.o(.text+0x1c70): the use of tmpnam' is dangerous, better use mkstemp'
 > tk.o(.text+0x1c70): the use of tmpnam' is dangerous, better use mkstemp'
 > plframe.o(.text+0x291d): the use of tmpnam' is dangerous, better use mkstemp'
 > 
 > I suspect this message means our use of tmpnam is opening a security hole.
 > I don't know how serious this is, but, Maurice, if you know how to use
 > mkstemp then you may want to switch to it from tmpnam.

Theoretically there is a problem, but I'm not worrying about it.  tmpnam is
POSIX, mkstemp is not.  Maybe eventually I'll do some configure stuff to use
mkstemp where available, otherwise tmpnam, just to shut up gcc.  But not that
important to me.

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

Re: [Plplot-devel] problem with x01c.c

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

Andrew Roach writes:
 > Starting line 8 it has:
 > 
 > #if HAVE_UNISTD_H
 > # include <unistd.h>
 > #endif
 > ...
 > I don't understand why it was only #if
 > in the first place, since that should (by my read) be illegal. Perhaps
 > later version of GCC support it ? Either way, i believe it should be an
 > #ifdef, not an #if. I have not made the change to the CVS in case it is
 > doing something I don't understand.

You're right, it was just a slip, and gcc didn't complain so I missed it.

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

[Plplot-devel] problem with x01c.c

[Andrew R. <ar...@ge...>]

Hello,
    I was doing a final check of the CVS on DOS before heading away for a
week, and found a small problem with x01c.c 

Starting line 8 it has:

#if HAVE_UNISTD_H
# include <unistd.h>
#endif

Under DJGPP and gcc version 2.7.2.1 I get an error with the first line.
Changing it to:

#ifdef HAVE_UNISTD_H
# include <unistd.h>
#endif


fixes the problem at least for me. I don't understand why it was only #if
in the first place, since that should (by my read) be illegal. Perhaps
later version of GCC support it ? Either way, i believe it should be an
#ifdef, not an #if. I have not made the change to the CVS in case it is
doing something I don't understand.

- Andrew

Re: [Plplot-devel] done with config changes

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

On Sun, 20 Jan 2002, Maurice LeBrun wrote:

> My last round of commits fixed all the config problems I mentioned
> previously.

Thanks, Maurice.

> Please try it out.

The results of the near-default

./configure --disable-java --without-shlib

that I did for Joao seemed to be fine.  (In fact too fine because I could
not reproduce his problem.)

I also tried

./configure --disable-drivers --enable-png --enable-dyndrivers

and I got

devices:         png jpeg cgm xwin tk

Available device drivers
static:          xwin tk
dynamic:         gd cgm

All these devices worked fine, but I don't understand why --disable-drivers
is not affecting cgm.  I worked really hard to make all the cgm stuff in
plplot/cf/*.in files identical to what was done for gd or png/jpeg as
appropriate.  Also, I just checked that again, and I cannot find anything.
Nevertheless something is wrong for cgm (and perhaps also for jpeg and png
or gd since cgm follows them), and I hope you find it.  Perhaps there is a
more mundane reason why xwin and tk are still there despite the
--disable-drivers option, but again I don't understand this.

(I tried the same thing with default static drivers and got the same result,
all 5 devices were available.)

Finally, I tried a super-kill of everything but device png.

configure --disable-drivers --disable-jpeg --disable-cgm \
--disable-tk --disable-xwin --enable-png --enable-dyndrivers

That worked to isolate just the png device for the gd driver with none of
the other 4 devices that were active before, but I don't see why a simple
--disable-drivers wouldn't have given the same thing.

Finally, I noticed the following compilation messages for the first
configuration (but none of the others, interestingly).

tk.o(.text+0x1c70): the use of tmpnam' is dangerous, better use mkstemp'
tk.o(.text+0x1c70): the use of tmpnam' is dangerous, better use mkstemp'
plframe.o(.text+0x291d): the use of tmpnam' is dangerous, better use mkstemp'

I suspect this message means our use of tmpnam is opening a security hole.
I don't know how serious this is, but, Maurice, if you know how to use
mkstemp then you may want to switch to it from tmpnam.

Alan

Re: [Plplot-devel] Release Status -- Still looking good for Thursday

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

On Mon, 21 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> On Sunday 20 January 2002 16:59, Alan W. Irwin wrote:
> | [...]But you may have some different configuration
> | that did not work as expected or there may be something wrong with
> | the m4 pre-processing that occurs on your machine.
>
> Nothing at all, almost a plain "configure"
>
> (cd ../cf; autoconf; mv configure ..); ../configure --disable-java
> --without-shlib
>
> command:        ../configure --disable-java --without-shlib
> system:         Linux-2.2.18
> prefix:         /usr/local
> CC:             gcc -c          -O
> LDC:            gcc
> CXX:            g++ -c            -O
> LDCXX:          g++
> F77:            g77 -c           -O
> LDF:            g77
> INCS:            -I.
> LIBS:            -litk3.1 -ltk8.3 -litcl3.1 -ltcl8.3 -L/usr/X11R6/lib
> -lX11 -lgd -lpng -ljpeg -lz -ldl -lm -lg2c
> LIB_TAG:
> devices:         plmeta null xterm tek4010 tek4010f tek4107 tek4107f
> mskermit conex vlt versaterm dg300 png jpeg ps psc xfig ljii hp7470
> hp7580 lj_hpgl ljiip imp xwin tk pbm pstex
>
> Available device drivers
> static:          plmeta null tek dg300 gd ps xfig ljii hpgl ljiip
> impress xwin tk pbm pstex
> dynamic:
>
> with_shlib:     no              with_double:    no
> with_debug:     no              with_opt:       yes
> with_warn:      no              with_profile:   no
> with_gcc:       yes             with_rpath:     yes
>
> enable_xwin:    yes             enable_tcl:     yes
> enable_tk:      yes             enable_itcl:    yes
> enable_cxx:     yes             enable_python:  no
> enable_f77:     yes             enable_java:    no
> enable_octave:  no              enable_gnome:   no
>
> jcard@rick:~/tmp/plplot/tmp > g77 --version
> GNU Fortran 0.5.25 19991024 (release)
>
> jcard@rick:~/tmp/plplot/tmp > m4 --version
> GNU m4 1.4o
>

Again, I cannot reproduce the problem you have reported. I configured
exactly as you above on a clean checkout.  All the major flags at the end o=
f
config message were identical to yours.  The driver lists looked the same
(although that should not matter). My system found f77 rather than g77, but
on Debian woody that is a symlink to g77.

I get the following:

f77 --version
GNU Fortran 0.5.25 20010319 (prerelease)
[+ lots of stuff about the lack of warranty, etc.]

m4 --version
GNU m4 1.4

make fdemos works like a charm, and I even tried x06f and x07f and they
produced the same boring (;-) results as always.

I can think of two possibilities.

(1) Somehow your plplot system is confused by
a mix of old and new results.  Please try again with a clean checkout (if
you didn't have that already).

(2) I am also somewhat concerned about the two-yr old date on your g77
compiler compared to mine.  Maybe there is too long a line (as mentioned in
one of your error messages) for your old compiler.  In that case, find the
longest line in your x06f.f source, find the equivalent line in x06f.fm4 an=
d
split it into two lines (by using almost any character in the 6th column fo=
r
the continued line as you can see from other *.fm4 files that have
continuations) and try again.  If a line split solves the problem, go ahead
and commit the modified x06f.fm4 results.  And similarly for x07f.fm4
assuming that problem is due to the same cause.

I don't want this to drag on so while Joao is doing further tests with
clean checkouts/and or line splitting will others please take a few
minutes to try to reproduce the bug?  We may need more eyeballs on this
one to solve it, and I am hamstrung because I cannot reproduce it.

Thanks in advance.

Alan

[Plplot-devel] documentation rebuilt and uploaded to our web site.

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

Today I rebuilt our documentation on Debian woody, checked the man, info,
dvi, postscript, html, and pdf results, and uploaded those results to our
live web site.  The effort was non-trivial because I had to find and install
all the many packages that are needed.  I was also concerned that with all
the package updates that had occurred between potato and woody, that
something would be broken in our documentation build, but all was well.

I also was hoping to build the documentation on a RH 7.1 system I have
access to, but I don't know the easy way to install the many perl modules
that are required.  I don't want to end up fighting between tarball and rpm
installs of those modules. (Joao may have run into this problem as well on
his SuSe system.) Thus, I will put off a build of our docs on RedHat systems
until (much?) after the release.

Since I no longer have access to a RH 6.2 system and that distribution and
probably the Cygnus DocBook rpm's we used on that distribution are quite
dated, I decided to remove everything referring to RH and Cygnus from
README.developers. I also completely reorganized this file and updated it to
refer to docbook2X version 0.7 (we use that package to generate man and info
results) and Debian woody.  The resulting README.developers is much better
than the previous dog's breakfast.  (And I can say that because I was
responsible for that bad organization.)

This completes my documentation effort for this release.

The only things remaining on my wishlist are the unification work for
examples 16 and 18. I will try to get to that tomorrow, but will stop all
such work by the test period start (8 AM PST = 16:00 UT on Tuesday) and will
also ask you to refrain from non bug-fixing commits after that time.

I just talked with the sysadmin of the University's astrogroup, and he was
kind enough to give me root access to a RedHat 7.1 machine there. This will
substantially widen our testing environment and will also allow me to
release RH 7.1 rpms at the same time as our tarball of 5.1.0.  The RH 7.2
rpm's will come later once one of our astrogroup computers is upgraded to
that version in a few weeks from now.

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] Release Status -- Still looking good for Thursday

[<jca...@in...>]

On Sunday 20 January 2002 16:59, Alan W. Irwin wrote:
| On Sat, 19 Jan 2002, Alan W. Irwin wrote:
| > On Sun, 20 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
| > > 2-Fortran examples x06f.f and x07f.f don't compile, eg:
| >
| > Fortran has worked forever for me, but I just tried again, and no
| > problem. Thus, I cannot confirm your bug report.  Did you
| > configure with --with-double?  That is required for fortran.
|
| I woke up this morning realizing that last sentence was wrong.=20
| IIRC, Maurice fixed up single precision and fortran at some point.=20
| Anyhow, Joao, please give lots more particulars about the
| configuration that lead to the problem.  I don't see it here at all
| using --with-double.  But you may have some different configuration
| that did not work as expected or there may be something wrong with
| the m4 pre-processing that occurs on your machine.

Nothing at all, almost a plain "configure"

(cd ../cf; autoconf; mv configure ..); ../configure --disable-java=20
--without-shlib

command:        ../configure --disable-java --without-shlib
system:         Linux-2.2.18
prefix:         /usr/local
CC:             gcc -c          -O =20
LDC:            gcc   =20
CXX:            g++ -c            -O=20
LDCXX:          g++     =20
F77:            g77 -c           -O=20
LDF:            g77   =20
INCS:            -I.
LIBS:            -litk3.1 -ltk8.3 -litcl3.1 -ltcl8.3 -L/usr/X11R6/lib=20
-lX11 -lgd -lpng -ljpeg -lz -ldl -lm -lg2c
LIB_TAG:       =20
devices:         plmeta null xterm tek4010 tek4010f tek4107 tek4107f=20
mskermit conex vlt versaterm dg300 png jpeg ps psc xfig ljii hp7470=20
hp7580 lj_hpgl ljiip imp xwin tk pbm pstex

Available device drivers
static:          plmeta null tek dg300 gd ps xfig ljii hpgl ljiip=20
impress xwin tk pbm pstex
dynamic:       =20

with_shlib:     no              with_double:    no
with_debug:     no              with_opt:       yes
with_warn:      no              with_profile:   no
with_gcc:       yes             with_rpath:     yes

enable_xwin:    yes             enable_tcl:     yes
enable_tk:      yes             enable_itcl:    yes
enable_cxx:     yes             enable_python:  no
enable_f77:     yes             enable_java:    no
enable_octave:  no              enable_gnome:   no

jcard@rick:~/tmp/plplot/tmp > g77 --version
GNU Fortran 0.5.25 19991024 (release)

jcard@rick:~/tmp/plplot/tmp > m4 --version
GNU m4 1.4o

configuring the same as above, but adding "--with-double
" does not solve the problem. Again, it is:

m4 -S2000 -B8192  x06f.fm4 >x06f.f
g77 -c           -O  x06f.f
Line too long as of (?) [info -f g77 M LEX]
x06f.f: In program `MAIN__':
x06f.f:29: warning:
           call plmtex('b', real (1.5), real (0.1*i+0.05),
                1
x06f.f:52: (continued):
         call plmtex('t', real (1.5), real (0.5), real (0.5),
              2
Too few arguments for `plmtex' at (2) versus invocation at (1) [info=20
-f g77 M GLOBALS]
x06f.f:52:=20
         call plmtex('t', real (1.5), real (0.5), real (0.5),
              1                                              2
Invalid token at (2) in expression or subexpression at (1)
make: *** [x06f.o] Error 1

This is in suse-7.0; in suse-7.2 the same error occurs. Sorry I can't=20
help more,

Joao

Re: [Plplot-devel] Release Status -- Still looking good for Thursday

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

On Sat, 19 Jan 2002, Alan W. Irwin wrote:

> On Sun, 20 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
> > 2-Fortran examples x06f.f and x07f.f don't compile, eg:
>
> Fortran has worked forever for me, but I just tried again, and no problem=
=2E
> Thus, I cannot confirm your bug report.  Did you configure with
> --with-double?  That is required for fortran.

I woke up this morning realizing that last sentence was wrong.  IIRC,
Maurice fixed up single precision and fortran at some point.  Anyhow, Joao,
please give lots more particulars about the configuration that lead to the
problem.  I don't see it here at all using --with-double.  But you may have
some different configuration that did not work as expected or there may
be something wrong with the m4 pre-processing that occurs on your machine.

Alan

[Plplot-devel] done with config changes

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

My last round of commits fixed all the config problems I mentioned 
previously.  Please try it out. 

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

Re: [Plplot-devel] Release Status -- Still looking good for Thursday

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

Alan W. Irwin writes:
 > >
 > > | Could somebody please volunteer to do a final comprehensive check
 > > | that the C code is ansi-compliant?  This would take some release
 > > | burden off me.  (I think I can recall how to check it, but if there
 > > | are warnings, I wouldn't know how to fix up the problems except for
 > > | the // commentary that screws up the Slowaris compiler.)
 > >
 > > I'm afraid that tk.c, around line 1229, uses some POSIX, non-ansi
 > > system calls, such as sigemptyset(), sigaddset() and sigprocmask().
 > > It's only purpose is to "Don't kill plserver on a ^C if
 > > pls->server_nokill is set", and can safely be conditionaly compiled
 > > within a #ifndef  __STRICT_ANSI__/#endif block. I don't commit this
 > > as I'm no ansi/posix expert, and it might be gcc (linux) specific.
 > >
 > > All other source files compiled OK, except for two warnings in
 > > plframe.c. It looks like that fdopen() and fileno() are not ansi
 > > compliant?
 > 
 > Thanks very much for that comprehensive check.  I am particularly glad there
 > are no // commentary issues this time.  Could a C expert here deal with the
 > remaining non-ANSI problems that Joao has found?

There's no problem with non-ANSI, but POSIX, function calls AFAIK.

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

Re: [Plplot-devel] Release Status -- Still looking good for Thursday

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

On Sun, 20 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> No, I concluded that the cvs version is more stable than my current
> version.

OK.

>
> | Could somebody please volunteer to do a final comprehensive check
> | that the C code is ansi-compliant?  This would take some release
> | burden off me.  (I think I can recall how to check it, but if there
> | are warnings, I wouldn't know how to fix up the problems except for
> | the // commentary that screws up the Slowaris compiler.)
>
> I'm afraid that tk.c, around line 1229, uses some POSIX, non-ansi
> system calls, such as sigemptyset(), sigaddset() and sigprocmask().
> It's only purpose is to "Don't kill plserver on a ^C if
> pls->server_nokill is set", and can safely be conditionaly compiled
> within a #ifndef  __STRICT_ANSI__/#endif block. I don't commit this
> as I'm no ansi/posix expert, and it might be gcc (linux) specific.
>
> All other source files compiled OK, except for two warnings in
> plframe.c. It looks like that fdopen() and fileno() are not ansi
> compliant?

Thanks very much for that comprehensive check.  I am particularly glad ther=
e
are no // commentary issues this time.  Could a C expert here deal with the
remaining non-ANSI problems that Joao has found?

Alan

Re: [Plplot-devel] Release Status -- Still looking good for Thursday

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

On Sun, 20 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> Hi,
>
> Some problems that I detected during a pause:
>
> 1-Java (as well as Python and Octave) can't be build without shared
> libraries. "configure" does not check for this and enables java if,
> by accident, java exists and JAVA_HOME is defined.

=2E.. and if you explicitly enable java.  It is not on by default because j=
ava
is still judged to be experimental; the API is not yet complete---although
getting closer, and I am sure there are probably still a number of Java
configuration issues to sort out. Thus, my judgement is these are minor
configuration issues that are far from release critical, and I have higher
priorities at the moment.  However, if somebody else wants to tackle these
issues (before Tuesday) that is fine with me.

>
> 2-Fortran examples x06f.f and x07f.f don't compile, eg:

Fortran has worked forever for me, but I just tried again, and no problem.
Thus, I cannot confirm your bug report.  Did you configure with
--with-double?  That is required for fortran.

Joao, although I don't view your first report as a particularly serious
problem, and I could not confirm your second report, I very much appreciate
your continued tests, and your "Devil's Advocate" attitude that there has
got to be something seriously wrong with this release if you dig deeply
enough. Without that attitude something serious might in fact slip by.  By
now, I am probably a lousy tester because I don't expect to find anything
wrong because it so rarely happens in my non-interactive tests. So throw
everything you got (especially interactive tests) at this latest version of
PLplot!

Alan

Re: [Plplot-devel] Release Status -- Still looking good for Thursday

[<jca...@in...>]

On Saturday 19 January 2002 18:23, Alan W. Irwin wrote:
| On Sat, 19 Jan 2002, Maurice LeBrun wrote:
=2E..
| From above, my impression is that the tk driver is now ready for
| the release.  Yesterday, I finished all I wanted to do (the
| README's) in this cycle of the documentation work. Thanks to
| Geoffrey's recent API work we have example 9 and example 15
| compatible between Java and the other front ends.=20

Hi,

Some problems that I detected during a pause:

1-Java (as well as Python and Octave) can't be build without shared=20
libraries. "configure" does not check for this and enables java if,=20
by accident, java exists and JAVA_HOME is defined.

2-Fortran examples x06f.f and x07f.f don't compile, eg:

g77 -c           -O  x06f.f
Line too long as of (?) [info -f g77 M LEX]
x06f.f: In program `MAIN__':
x06f.f:29: warning:
           call plmtex('b', real (1.5), real (0.1*i+0.05),
                1
x06f.f:52: (continued):
         call plmtex('t', real (1.5), real (0.5), real (0.5),
              2
Too few arguments for `plmtex' at (2) versus invocation at (1) [info=20
-f g77 M GLOBALS]
x06f.f:52:=20
         call plmtex('t', real (1.5), real (0.5), real (0.5),
              1                                              2
Invalid token at (2) in expression or subexpression at (1)

Sorry, I make no ideia about what's going on.

Joao

Re: [Plplot-devel] Release Status -- Still looking good for Thursday

[<jca...@in...>]

On Saturday 19 January 2002 18:23, you wrote:
| On Sat, 19 Jan 2002, Maurice LeBrun wrote:
=2E..

| Joao, my impression from what you said is you decided to commit
| your plimage stuff.

No, I concluded that the cvs version is more stable than my current=20
version.

Also, I have more than one undred examinations to correct during the=20
week-end, and I have no time for further developments.

| Could somebody please volunteer to do a final comprehensive check
| that the C code is ansi-compliant?  This would take some release
| burden off me.  (I think I can recall how to check it, but if there
| are warnings, I wouldn't know how to fix up the problems except for
| the // commentary that screws up the Slowaris compiler.)

I'm afraid that tk.c, around line 1229, uses some POSIX, non-ansi=20
system calls, such as sigemptyset(), sigaddset() and sigprocmask().=20
It's only purpose is to "Don't kill plserver on a ^C if=20
pls->server_nokill is set", and can safely be conditionaly compiled=20
within a #ifndef  __STRICT_ANSI__/#endif block. I don't commit this=20
as I'm no ansi/posix expert, and it might be gcc (linux) specific.

All other source files compiled OK, except for two warnings in=20
plframe.c. It looks like that fdopen() and fileno() are not ansi=20
compliant?

| Does anybody else here have work they want to get in before
| Tuesday?  I would like to call a CVS "soft" freeze (nothing but bug
| fixes allowed) starting Tuesday 8 a.m. PST.
|
| I plan to start the comprehensive non-interactive testing on
| Tuesday for the various platforms that are available to me and
| Joao.

That's OK for me.
Joao

| This will take some time because there are a lot of images to
| look at, and there may still be some bugs that need squashing.=20
| Nevertheless, I believe we are still on schedule for releasing on
| Thursday with a hard CVS freeze starting Thursday 8.am. PST.
|
| Alan
|
|
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Release Status -- Still looking good for Thursday

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

On Sat, 19 Jan 2002, Maurice LeBrun wrote:

>  > ./x01c -dev plmeta -o x01c.meta
>  > ./plrender -i x01c.meta -dev tk
>  > TCL command "
>  >          invalid command name "
>  >
>  > Can this bug be fixed before the release?
>
> With dyndrivers enabled, I don't see it.

> So I'm pretty much stuck on that point.
> Hmm.. maybe it is related to the devlist bug.

You are right.  The problem was still there yesterday, but now it is
solved.  Thanks very much for this effort!

Release Status:

From above, my impression is that the tk driver is now ready for the
release.  Yesterday, I finished all I wanted to do (the README's) in this
cycle of the documentation work. Thanks to Geoffrey's recent API work we
have example 9 and example 15 compatible between Java and the other front
ends.  That still leaves my compatibility work (probably a day or two more)
for examples 16 and 18. After that I will work on coaxing the documentation
to build for the first time on Debian woody. (That's probably just a matter
of getting the right documentation packages installed.) Anyhow, I plan to
terminate my wishlist before Tuesday.

Joao, my impression from what you said is you decided to commit your plimage
stuff.  I haven't seen that yet, but I assume that will happen before Tuesday.

Could somebody please volunteer to do a final comprehensive check that the C
code is ansi-compliant?  This would take some release burden off me.  (I
think I can recall how to check it, but if there are warnings, I wouldn't
know how to fix up the problems except for the // commentary that screws
up the Slowaris compiler.)

Does anybody else here have work they want to get in before Tuesday?  I
would like to call a CVS "soft" freeze (nothing but bug fixes allowed)
starting Tuesday 8 a.m. PST.

I plan to start the comprehensive non-interactive testing on Tuesday for the
various platforms that are available to me and Joao. This will take some
time because there are a lot of images to look at, and there may still be
some bugs that need squashing.  Nevertheless, I believe we are still on
schedule for releasing on Thursday with a hard CVS freeze starting Thursday
8.am. PST.

Alan

Re: [Plplot-devel] Wish list for the release--various thoughts.

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

Alan W. Irwin writes:
 > > [...] what else?... I can't use "plrender"
 > > with device tk,..
 > 
 > Neither can I, but this is the first I have heard of it!  (I tend to
 > do strictly non-interactive tests, and leave the interactive stuff to
 > the rest of you.)  I must have missed your bug report to the list....;-)
 > 
 > Here is mine....
 > 
 > Maurice, here are the symptoms (with dynamic drivers configured if that
 > makes a difference)
 > 
 > There is no problem if I executed
 > 
 > ./x01c -dev tk
 > 
 > However,
 > 
 > ./x01c -dev plmeta -o x01c.meta
 > ./plrender -i x01c.meta -dev tk
 > TCL command "
 >          invalid command name "
 > 
 > Can this bug be fixed before the release?

With dyndrivers enabled, I don't see it.

ged$ ./x01c -dev plmeta -o x01c.meta
Plplot library version: 5.1.0
Opened x01c.meta
ged$ ./plrender -i x01c.meta -dev tk
ged$ 

So I'm pretty much stuck on that point.
Hmm.. maybe it is related to the devlist bug.
Please try again with the latest sources.

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

RE: [Plplot-devel] Sequence numbers (was Remove the deprecated sections in drivers.h and plcore.h?)

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

On Fri, 18 Jan 2002, Geoffrey Furnish wrote:

> The only thing sequence numbers do, is determine the order of
> presentation of devices in the device list.

Thanks very much for this quick information.  So I guess the inconsistencies
I found simply meant that the device ordering was different for the static
(used the plplot/drivers/*.c sequence numbers?) and dynamic (used the
configure.in sequence numbers?) cases.  So a pretty minor issue, but it is
now fixed.

I have also just removed the "#if 0" code blocks mentioned before in this
thread because I believe the documentation I just finished in
plplot/drivers/README.drivers combined with the already existing general
documentation of drivers and devices provides the same or better
information.

Alan

Re: [Plplot-devel] next release

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

Geoffrey Furnish writes:
 > My really truly final viewpoint on this, is that I don't think we
 > should have a release with a broken tk driver.  I would call that a
 > showstopper.  I just hope I'm not the guilty party on that one...

Oh well, too bad, it was all your fault after all. :)

Well, dyndrivers, at least.  The problem is multifold:

 - the "plgdevlst:  too many devices" was from a limit I set a long time ago
on 20 file oriented devices in the tk widget.  Braindead, I know, but easily
fixed and was actually instrumental in finding the real problems, which are..

 - in the tk03 demo, only the second window opened gives that message.  Why?
Because in the first window, the device list is completely empty!  This is
because the dispatch table is now (with dyn drivers) being asked for before
it's created.  I've fixed this by finally introducing a "library-opening"
call, pllib_init(), that is called by any plplot routine that the user might
call first.

 - the old limit of 20 devices would still have been fine if there was some
distinction in the new dispatch table between interactive and non-interactive
drivers.  That entry from the old dispatch table is simply.. gone.  Why?  Kind
of silly to provide menu entries to save to a host of terminal emulators.
I'll take it as just an oversight and see how I might provide a "terminal"
flag as was present before.

 - ditto if devices were excluded properly by the configuration script.  Still
looking into this one.

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

RE: [Plplot-devel] Sequence numbers (was Remove the deprecated sections in drivers.h and plcore.h?)

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

Alan W. Irwin writes:
 > Thanks, Geoffrey, for your quick reply.  I will resolve this by documenting
 > well enough so I feel comfortable removing those code blocks.
 > 
 > I have been attempting to document what is going on with the drivers, and in
 > fact I have found a mess with the sequence numbers.  The driver code values
 > are discordant with configure.in. For example, configure.in says the null
 > device is 42 while null.c says it is 41, and vice versa for pstex.  I have
 > found a fair number of other cases as well.  Obviously things are working
 > okay right now, but there may be some subtle errors from this discordance
 > between configure.in numbers and the drivers/*.c numbers.  Therefore, I have
 > decided to make configure.in the definitive source of these numbers and
 > change the drivers/*.c values appropriately.  Hope this is the right thing
 > to do since I don't have deep understanding of how the sequence numbers are
 > actually used.

The only thing sequence numbers do, is determine the order of
presentation of devices in the device list.  The only reason to have
them, is so this display is consistent over time.  My first work on
dyndrv didn't preserve them, and I wound up with something other than
xwin at the top of the list, which immediately motivated me to put the
sequence numbers back in.  However, I doubt anything would go
particularly "wrong" if they were messed up.  It's just a
stability-of-public-image thing.  And somewhat a utility thing, since
we use them to try to get the interactive devices high on the list,
and the non-interactive devices (file oriented devices) low on the
list.

The "right" fix, would involve somehow the creation of a new file, a
device registry, which would contain the sequence number for each
device, and then configure.in would use that file, rather than having
the numbers hard coded into its gross autoconf jumble monstrosity.

But I cannot commit to build such a fastidious system on any
particuolar timescale.  

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

[Plplot-devel] Sequence numbers (was Remove the deprecated sections in drivers.h and plcore.h?)

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

Thanks, Geoffrey, for your quick reply.  I will resolve this by documenting
well enough so I feel comfortable removing those code blocks.

I have been attempting to document what is going on with the drivers, and in
fact I have found a mess with the sequence numbers.  The driver code values
are discordant with configure.in. For example, configure.in says the null
device is 42 while null.c says it is 41, and vice versa for pstex.  I have
found a fair number of other cases as well.  Obviously things are working
okay right now, but there may be some subtle errors from this discordance
between configure.in numbers and the drivers/*.c numbers.  Therefore, I have
decided to make configure.in the definitive source of these numbers and
change the drivers/*.c values appropriately.  Hope this is the right thing
to do since I don't have deep understanding of how the sequence numbers are
actually used.

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 Fri, 18 Jan 2002, Geoffrey Furnish wrote:

> This is the only message I can promise to generate before Monday.
>
> The issue to which you refer, has a recent origin in the sense that
> the "authoritative source in cf/configure.in" only appeared recently,
> in the timeframe of the dyndrv work.  Before that, plcore.h and
> drivers.h is where the stuff was authoritatively stored.
>
> I don't myself view this as a particularly significant issue for a
> release, since /users/ of the library can be oblivious to such
> things.  Functionality matters for a release, style is of secondary
> importance.
>
> Clearly we want this cleaned up.  I left it in (the header files) as a
> record, since we have to keep refering back to it from time to time.
> Maybe the transition is mostly complete by now, I don't know.  But for
> sure, there needs to be a clear, and documented procedure for adding a
> driver, which covers all the points.  If such exists, then I'm for
> eliminating all the junk code.  But if not, then lets don't prune the
> code before the production of suitable documentation.
>
> I haven't reviewed the documentation lately, so do not actually know
> where we stand on that.
>
> I'll /try/ to read email this weekend in case anyone follows up to this,
> but can't promise to respond before Monday.
>
> Alan W. Irwin writes:
>  > This is mostly directed to Geoffrey.
>  >
>  > When I was trying to understand the cgm driver a while back, I noticed the
>  > huge
>  >
>  > #if 0
>  >
>  > #endif
>  >
>  > blocks in include/drivers.h and include/plcore.h.
>  >
>  > Any objection to me just completely removing these code blocks?  In the latter
>  > case (at least) some of the drivers are missing so I got the device number
>  > wrong for cgm the first time I tried it.  The definitive source of device
>  > numbers is actually cf/configure.in so to have it also (sorta) in plcore.h
>  > is not good.
>  >
>  > Geoffrey, if this is a no-brainer, I would appreciate an immediate response
>  > so I can get on with things.  If you need more time to think about this, I
>  > will try to remember not to take any action on this until late tomorrow.
>  >
>  > 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
>  > __________________________
>  >
>  >
>  > _______________________________________________
>  > Plplot-devel mailing list
>  > Plp...@li...
>  > https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>