plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] testing plplot

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

Maurice LeBrun writes:
 > Robert Schwebel writes:
 >  > automake: Version 1.5
 >  > autoconf: Version 2.52
 >  > aclocal:  Version 1.5
 >  > m4:       Version 1.4o
 > 
 > Please let me know what you get back from "m4 --version".  E.g. on my system:
 > 
 > $ m4 --version
 > GNU m4 1.4.1

Well, probably doesn't matter.  I've verified the problem on my system when
using autoconf 2.52.  Shouldn't take long to find the cause (famous last
words :).

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

Re: [Plplot-devel] testing plplot

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

Robert Schwebel writes:
 > automake: Version 1.5
 > autoconf: Version 2.52
 > aclocal:  Version 1.5
 > m4:       Version 1.4o

Please let me know what you get back from "m4 --version".  E.g. on my system:

$ m4 --version
GNU m4 1.4.1

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

Re: [Plplot-devel] testing plplot

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

Robert Schwebel writes:
 > Hi,
 > 
 > I just gave the CVS version of plplot a try. This is mostly a SuSE 7.2
 > system.
 > 
 > If I understand the instructions correctly I have to run autoconf in the
 > cf/ directory to generate the configure script. But autoconf breaks here:
 > 
 > ----------8<----------8<----------8<----------8<----------
 > callisto:/usr/local/plplot/cf # autoconf
 > /usr/bin/m4: configure.in: 362: Non-numeric argument to built-in `divert'
 > ...
 > automake: Version 1.5
 > autoconf: Version 2.52
 > aclocal:  Version 1.5
 > m4:       Version 1.4o

Wow, big changes in autoconf-land.  On my RedHat 7.1 I have

ged$ autoconf --version
Autoconf version 2.13

The bit of plplot code that's implicated is pretty ancient.  So I figure it's
a compatibility problem with the latest autoconf.. checking it out, thanks.

BTW I noticed the autoconf 2.52 .m4 files look really great in xemacs
font-lock mode (for the first time ever IIRC).

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

[Plplot-devel] testing plplot

[Robert S. <ro...@sc...>]

Hi,

I just gave the CVS version of plplot a try. This is mostly a SuSE 7.2
system.

If I understand the instructions correctly I have to run autoconf in the
cf/ directory to generate the configure script. But autoconf breaks here:

----------8<----------8<----------8<----------8<----------
callisto:/usr/local/plplot/cf # autoconf
/usr/bin/m4: configure.in: 362: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 365: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 368: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 371: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 374: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 377: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 380: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 383: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 386: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 389: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 392: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 395: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 400: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 403: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 406: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 409: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 412: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 415: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 418: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 421: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 424: Non-numeric argument to built-in `divert'
/usr/bin/m4: configure.in: 474: Bad regular expression
`[[[\([[`""]]\)]]]': Unmatched ) or \)
[configure.in:474[: error: [[[back quotes and double quotes should not be
escaped in: [[$as_me:__oline__: result: $prefix]]]]]]
]/usr/bin/m4: configure.in: 474: ERROR: Recursion limit of 1024 exceeded,
use -L<N> to change it
callisto:/usr/local/plplot/cf #
----------8<----------8<----------8<----------8<----------

automake: Version 1.5
autoconf: Version 2.52
aclocal:  Version 1.5
m4:       Version 1.4o

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

[Plplot-devel] configuration error

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

In building the code under IRIX I found & fixed a nasty configuration bug that
may have been responsible for snafus on other systems as well.  So please try
the latest code if you've been having any problems.

Everything checks out on IRIX now.

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

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

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

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

> No, if using gnu make-3.74 (in my home bin dir) everything runs OK.

Good.  That is all that is required.

As I understand Geoff and Maurice's posts on this issue, we no longer
accomodate our Makefiles to account for everybody's different variations of
the make command.  Instead, our policy (which I will state in the release
notes so everybody is clear about this ) is we demand our users use Gnu
make. So each of our non-Linux users will be faced with exactly your
situation on OSF1, and the solution for them is to download Gnu make and
install and use it.  I am glad it seems to be working well on OSF1.

Alan

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

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

On Monday 21 January 2002 20:21, Geoffrey Furnish wrote:
| Joao Cardoso writes:
|  > The problem seems to be the shell again, or the make program, as
|  > no drivers object files are included in LIBS_OBJ. The offending
|  > statment seems to be:
|  >
|  >    static_drivers_obj :=3D $(STATIC_DRIVERS:%=3D%$(O))
|  >
|  > static_drivers_obj is empty, although STATIC_DRIVERS is not.
|  >
|  > Is any cure for this?
|
| That's a GNU make-ism.  We agreed a while back to allow GNU make
| features in our makefiles.  I don't remember typing that in
| specifically, but its probably mine.  Anyway, for sure, it is an
| example of a GNU make pattern expansion.  I'm gonna guess that your
| make is treating the % as a literal, and finding none in the
| STATIC)DRIVERS macro, it simply makes no change.  Hmm, no, that
| doesn't explain your symptom.
|
| I dunno, are you using GNU make?  If so, what version?

No, if using gnu make-3.74 (in my home bin dir) everything runs OK.=20
Using alpha-osf1-v4.0 make(s) (there are *tree* versions of them)=20
don't work; they are

/usr/bin/posix/make,
/usr/opt/ultrix/usr/bin/make,
/sbin/make,
/usr/bin/make (link to /usr/ccs/bin/make)
/bin/make (link to /usr/ccs/bin/make)

Using the make man page, I got it working using

static_drivers_obj =3D $(STATIC_DRIVERS/$/.o)

Gnu make accepts this construct! Can this be a solution?

Joao

Re: [Plplot-devel] polishing

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

Geoffrey Furnish writes:
 > I'm just a wee bit annoyed by the following:
 > 
 >  > /home/furnish> /lss/sw/fastflow/SuSE-7.2/bin/plrender 
 >  > 
 >  > Cannot open library file: drivers/drivers.db
 >  > lib dir="/lss/sw/fastflow/SuSE-7.2/lib/plplot5.1.0/data"
 >...
 > What do people think?  Should pllibopen really whine verbosely in a
 > situation like this?  Or should we shut off the warning?  Or should we
 > switch to pldebug or something like that?

Probably the whine should be shut off, with actual error checking added by
anything that uses pllibopen(), if it's not doing so already.

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

[Plplot-devel] polishing

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

I'm just a wee bit annoyed by the following:

 > /home/furnish> /lss/sw/fastflow/SuSE-7.2/bin/plrender 
 > 
 > Cannot open library file: drivers/drivers.db
 > lib dir="/lss/sw/fastflow/SuSE-7.2/lib/plplot5.1.0/data"
 > 
 > No filename specified.
 > 
 > Usage:
 >         plrender [options] [files]
 > ...

This was for a brand new checkout/build/install.  The part I don't
like, is the diagnostic about can't find "drivers/drivers.db", and the
lib dir quote.

I thought originally that probably this was some debugging output that
I must've left around during the dyndrv merge without cleaning up, but
now from my research with cvs log on plctrl.c, it looks like this has
been there for years.  What is new, is that in the dispatch init,
we're effectively using pllibopen in a "try and see" semantic.

What do people think?  Should pllibopen really whine verbosely in a
situation like this?  Or should we shut off the warning?  Or should we
switch to pldebug or something like that?

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

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

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

Geoffrey Furnish writes:
 > Joao Cardoso writes:
 >  > The problem seems to be the shell again, or the make program, as no drivers 
 >  > object files are included in LIBS_OBJ. The offending statment seems to be:
 >  > 
 >  >    static_drivers_obj := $(STATIC_DRIVERS:%=%$(O))
 >  > 
 >  > static_drivers_obj is empty, although STATIC_DRIVERS is not.
 >  > 
 >  > Is any cure for this?
 > 
 > That's a GNU make-ism.  We agreed a while back to allow GNU make
 > features in our makefiles.  

Yup.  BTW I have no problems with the new version on Alpha-OSF1, using GNU
make.

Also my major plplot app (gts) works fine with the latest plplot, on Linux at
least.

There are, however, problems on IRIX.  I'll come up with some fixes
shortly.

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

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

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

Joao Cardoso writes:
 > The problem seems to be the shell again, or the make program, as no drivers 
 > object files are included in LIBS_OBJ. The offending statment seems to be:
 > 
 >    static_drivers_obj := $(STATIC_DRIVERS:%=%$(O))
 > 
 > static_drivers_obj is empty, although STATIC_DRIVERS is not.
 > 
 > Is any cure for this?

That's a GNU make-ism.  We agreed a while back to allow GNU make
features in our makefiles.  I don't remember typing that in
specifically, but its probably mine.  Anyway, for sure, it is an
example of a GNU make pattern expansion.  I'm gonna guess that your
make is treating the % as a literal, and finding none in the
STATIC)DRIVERS macro, it simply makes no change.  Hmm, no, that
doesn't explain your symptom.  

I dunno, are you using GNU make?  If so, what version?

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

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

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

On Monday 21 January 2002 7:07 pm, Geoffrey Furnish wrote:
> Joao Cardoso writes:
>  > This also happens on an OSF1 alpha. Your solution also works here (b=
ut
>  > it is not yet cvs commited, isn't it?).
>  >
>  > But, after 'make'
>  >
>  > ...
>  > ar: Warning: creating libplplot.a
>  > ranlib libplplot.a
>  >
>  > cc -std -c          -O1    -I. plrender.c
>  > cc -std   plrender.o -L. -lplplot  -o plrender  -lX11 -lm
>  > ld:
>  > Unresolved:
>  > plD_dispatch_init_xw
>  > plD_dispatch_init_xterm
>  > plD_dispatch_init_tekt
>  > plD_dispatch_init_tek4107t
>  > plD_dispatch_init_mskermit
>  > ...
>  >
>  > A plain ./configure was issued, and no dynamic libs was built.
>
> Mmm, well, there's bazillions of configure bugs, we'll be fixing them
> forever.  If you can see how to patch up the OSF support, go ahead,
> but I wouldn't let this platform deter us from a release.

Neither I was saying so.

The problem seems to be the shell again, or the make program, as no drive=
rs=20
object files are included in LIBS_OBJ. The offending statment seems to be=
:

   static_drivers_obj :=3D $(STATIC_DRIVERS:%=3D%$(O))

static_drivers_obj is empty, although STATIC_DRIVERS is not.

Is any cure for this?

Joao

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

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

On Mon, 21 Jan 2002, Geoffrey Furnish wrote:

> Geoffrey Furnish writes:
>  > OTOH, I did learn that PLplot's configure support for Solaris leaves a
>  > lot to be desired.  Besides the problem with shell syntax, it also
>  > somehow dropped -lm from all the link lines, causing every C prog link
>  > to fail (but notice that the f77 links above all worked).
>
> I've done about all I can stand to fix various configure bugs for
> now.
>
> Solaris is always a touchy situation.  I have one solaris box here
> where CC is detected by PLplot configure, but cc doesn't work, and
> that causes all kinds of horrific screwups downstream.  I dunno, maybe
> we should someday think to improve the compiler detection to check for
> a "working compiler", not merely a compiler seen in the path.  Sheesh,

I ran into this solaris problem also (in the 5.0.3, era, I believe), and the
solution was to put the directory with the working (!) cc higher in the path
than the directory for the non-working one.

> I can't imagine how Sun has stayed in business all these years.
I can't imagine either.

>
> Anyway, I have another Solaris box where the cc works, also with KCC
> and g77.  On this box, I've been able to test SMP builds for C, C++
> and F77 components, and everything seems to work, including we now use
> KCC to form .a's as well as .so's.
> [...] So, I'd call the current CVS head the most stable, correct PLplot I've
> seen in a while.
>
> Great work, everybody.

Seconded!

>
> BTW, compiling with Sun cc is I suppose, what Alan was really driving
> at earlier.

Yes, sun/solaris compilation problems were the number one bug report for
5.0.4.  It looks like we will avoid that this time (assuming our solaris
users can find a working compiler!)

Alan

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

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

Geoffrey Furnish writes:
 > OTOH, I did learn that PLplot's configure support for Solaris leaves a
 > lot to be desired.  Besides the problem with shell syntax, it also
 > somehow dropped -lm from all the link lines, causing every C prog link
 > to fail (but notice that the f77 links above all worked).

I've done about all I can stand to fix various configure bugs for
now.  

Solaris is always a touchy situation.  I have one solaris box here
where CC is detected by PLplot configure, but cc doesn't work, and
that causes all kinds of horrific screwups downstream.  I dunno, maybe
we should someday think to improve the compiler detection to check for
a "working compiler", not merely a compiler seen in the path.  Sheesh,
I can't imagine how Sun has stayed in business all these years.

Anyway, I have another Solaris box where the cc works, also with KCC
and g77.  On this box, I've been able to test SMP builds for C, C++
and F77 components, and everything seems to work, including we now use
KCC to form .a's as well as .so's. 

Well, on Linux we use KCC to form .so's, but on Solaris we don't
support shared libs at this time.  I s'pose we shoudl come back and
fix /that/ one of these days too, but not today.  :-).

So, I'd call the current CVS head the most stable, correct PLplot I've
seen in a while.

Great work, everybody.

BTW, compiling with Sun cc is I suppose, what Alan was really driving
at earlier.  I'm not inclined to worry about POSIX-but-not-ANSI stuff
in PLplot.  Maurice and I went through that argument years ago.  I
think the main thing is we need to keep extension syntax out of the
code base, and the current sources seem to do that well enough.

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

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

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

Joao Cardoso writes:
 > This also happens on an OSF1 alpha. Your solution also works here (but it is 
 > not yet cvs commited, isn't it?).
 > 
 > But, after 'make'
 > 
 > ...
 > ar: Warning: creating libplplot.a
 > ranlib libplplot.a
 > 
 > cc -std -c          -O1    -I. plrender.c
 > cc -std   plrender.o -L. -lplplot  -o plrender  -lX11 -lm 
 > ld:
 > Unresolved:
 > plD_dispatch_init_xw
 > plD_dispatch_init_xterm
 > plD_dispatch_init_tekt
 > plD_dispatch_init_tek4107t
 > plD_dispatch_init_mskermit
 > ...
 > 
 > A plain ./configure was issued, and no dynamic libs was built.

Mmm, well, there's bazillions of configure bugs, we'll be fixing them
forever.  If you can see how to patch up the OSF support, go ahead,
but I wouldn't let this platform deter us from a release.  I was
futzing with the Solaris support today, we still don't support shared
libs on Solaris (the original ELF system, upon which LIinux shared
libs are modelled).  So there's lots to do in this area, over time.

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

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

On Monday 21 January 2002 4:50 pm, Geoffrey Furnish wrote:
> 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=3Dyes
> for option; do
>     case "$option" in
>     -with-defaults | --with-defaults | -with-defaults=3Dyes |
> --with-defaults=3Dyes )
> =09=09        with_defaults=3Dyes
> =09=09=09;;
> =09=09=09-without-defaults | --without-defaults |
> -with-defaults=3Dno | --with-defaults=3Dno )
> =09=09      with_defaults=3Dno
> =09=09      ;;
>     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.

This also happens on an OSF1 alpha. Your solution also works here (but it=
 is=20
not yet cvs commited, isn't it?).

But, after 'make'

=2E..
ar: Warning: creating libplplot.a
ranlib libplplot.a

cc -std -c          -O1    -I. plrender.c
cc -std   plrender.o -L. -lplplot  -o plrender  -lX11 -lm=20
ld:
Unresolved:
plD_dispatch_init_xw
plD_dispatch_init_xterm
plD_dispatch_init_tekt
plD_dispatch_init_tek4107t
plD_dispatch_init_mskermit
=2E..

A plain ./configure was issued, and no dynamic libs was built.

Joao

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

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

On Mon, 21 Jan 2002, Joao Cardoso wrote:

> That's fine now, thanks.

I am *very* happy to get this resolved.

Alan

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

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

On Monday 21 January 2002 6:05 pm, Alan W. Irwin wrote:
> > I can't however avoid "symbols" to be expanded by m4, by quoting it, =
as
> > in `symbols'. The quick cure for the release is to just remove the
> > word--after all it is just a comment. Comments?
>
> Try my curly brace fix just now committed.  You were right on track, bu=
t if
> you dig deeper into what we have done, the m4 escape character has been
> changed from quotes to curly braces since quotes interfere with other
> fortran stuff.

That's fine now, thanks.

Joao

[Plplot-devel] Re: STATUS QUESTION

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

On Mon, 21 Jan 2002, Geoffrey Furnish wrote:

> 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.

I have a conflict of interest here between my interest in seeing more work
done on the Java API and my release/testing manager role.  Also, I am well
aware I put you in the soup by doing so many java template changes late with
perhaps even more to come today.  But I consider java to be "experimental"
until all the API is complete.  Since there is no chance of that happening
for this release, I think that takes all the pressure off to jam in more API
at the last minute before the release.  Also, I would rather have you
configuration debugging on solaris, see below.  Also, while I am testing on
Tuesday and Wednesday my plate will be absolutely full so I would prefer no
distractions. Thus, weighing everything up I would feel most comfortable if
we stick to the Tuesday morning deadline for the soft freeze.  So if you can
do a bit more today on java (after you are happy with solaris configuration)
that would be great, but if not, that is fine as well. That is exactly the
same low-pressure approach I am taking to my own last-minute work on the
example unification today.


>
> 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.

From your subsequent posts, it sounds like you solved this problem but are
still working on another solaris configuration problem.  I *really*
appreciate this work because it means I am not going to be sandbagged when I
attempt to build and test on the compile farm solaris machine.

Looking forward to your configuration commit.

Alan

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

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

> I can't however avoid "symbols" to be expanded by m4, by quoting it, as in
> `symbols'. The quick cure for the release is to just remove the word--after
> all it is just a comment. Comments?

Try my curly brace fix just now committed.  You were right on track, but if
you dig deeper into what we have done, the m4 escape character has been
changed from quotes to curly braces since quotes interfere with other
fortran stuff.

Alan

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

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

On Mon, 21 Jan 2002, Joao Cardoso wrote:

> ! Displays the plotter
> AND,CMP,COMPLEX,DREAL,FALSE,IMAG,IMPLICIT_REAL,INCLUDED_FMACS,NO,OFF,ON,OR,REAL,REAL_FUN,SYSTEM,TRUE,YES,__file__,__gnu__,__line__,__m4_version__,__unix__,builtin,cdefine,cexpand,changecom,changequote,changesyntax,concat,debugfile,debugmode,decr,define,defn,divert,divnum,dnl,dumpdef,errprint,esyscmd,eval,format,getstring,if_aix,if_bsd,if_dbl,if_dgux,if_false,if_hpux,if_linux,if_sunos,if_sx,if_sysv,if_true,if_ultrix,ifdef,ifelse,ifndef,ignore,implicit_none,include,incr,index,indir,len,m4exit,m4wrap,macro_do,maketemp,patsubst,popdef,pushdef,regexp,shift,sinclude,substr,symbols,syncoutput,syscmd,sysval,traceoff,traceon,translit,undef,undefine,undivert
> for PLPOIN <--- from the comment until here is a one comment line!

It appears the SuSe m4 is interpreting "symbols" as an m4 command.  I have
just committed some *.fm4 changes that change symbols ==> {symbols}. The
curly braces mean that m4 ignores what is inside and passes it on untouched
to *.f.  The *.f results here are identical, and I hope this fix solves your
problem.

I am anxious to hear whether my fixup worked for you.

Alan

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

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

On Monday 21 January 2002 5:09 pm, Joao Cardoso wrote:
> On Monday 21 January 2002 7:28 am, Alan W. Irwin wrote:
> > 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 wit=
h
> > > | the m4 pre-processing that occurs on your machine.
>
> In the x06f.f file, after m4 processing, appears indeed a very long lin=
e as
> the first fortran source line:
>
> ! Displays the plotter
> AND,CMP,COMPLEX,DREAL,FALSE,IMAG,IMPLICIT_REAL,INCLUDED_FMACS,NO,OFF,ON=
,OR,
>REAL,REAL_FUN,SYSTEM,TRUE,YES,__file__,__gnu__,__line__,__m4_version__,_=
_uni
>x__,builtin,cdefine,cexpand,changecom,changequote,changesyntax,concat,de=
bugf
>ile,debugmode,decr,define,defn,divert,divnum,dnl,dumpdef,errprint,esyscm=
d,ev
>al,format,getstring,if_aix,if_bsd,if_dbl,if_dgux,if_false,if_hpux,if_lin=
ux,i
>f_sunos,if_sx,if_sysv,if_true,if_ultrix,ifdef,ifelse,ifndef,ignore,impli=
cit_
>none,include,incr,index,indir,len,m4exit,m4wrap,macro_do,maketemp,patsub=
st,p
>opdef,pushdef,regexp,shift,sinclude,substr,symbols,syncoutput,syscmd,sys=
val,
>traceoff,traceon,translit,undef,undefine,undivert for PLPOIN <--- from t=
he
> comment until here is a one comment line! implicit none <--- this is
> another line
>       integer i, j, k
>       real*4 x, y
>
>       character*3 text
>
> ! Full sized page for display
>
> So it seems that this is a m4 problem. But suse-7.2 is not that old, an=
d my
> suse system is updated with the last changes... (rpm says that m4 was
> "Build Date: Fri 11 May 2001")
>
> The problem seem to be the word "symbols" in the comments and in the la=
st
> plmtex() arguments of file x06f.fm4; if I remove the word "symbols" fro=
m
> the comments, the lines will be no more expanded by m4 as above. What i=
s
> the real cure for this?
>
> Joao

'info m4' says that:

   Getting the defined macro names
   =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D

      The name of the currently defined macro can be accessed by `symbols=
':
     symbols

      which results in a sorted list of quoted strings.  This contrasts w=
ith
   `dumpdef' which output can not be accessed by `m4' programs.

      When given arguments, `symbols' returns the sorted subset of the
      symbols currently defined:
        symbols(`ifndef', `ifdef', `define', `undef')
        =3D>define,ifdef

I can't however avoid "symbols" to be expanded by m4, by quoting it, as i=
n=20
`symbols'. The quick cure for the release is to just remove the word--aft=
er=20
all it is just a comment. Comments?

Joao

>
> > > 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
> > of config message were identical to yours.  The driver lists looked t=
he
> > same (although that should not matter). My system found f77 rather th=
an
> > 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 th=
ey
> > 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 g7=
7
> > compiler compared to mine.  Maybe there is too long a line (as mentio=
ned
> > 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 and split it into two lines (by using almost any character i=
n
> > the 6th column for 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=
=2E
> >
> > I don't want this to drag on so while Joao is doing further tests wit=
h
> > 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 th=
is
> > one to solve it, and I am hamstrung because I cannot reproduce it.
> >
> > Thanks in advance.
> >
> > Alan
> >
> >
> > _______________________________________________
> > 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

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

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

On Sunday 20 January 2002 4:00 am, Maurice LeBrun wrote:
> Alan W. Irwin writes:
>  > > | Could somebody please volunteer to do a final comprehensive chec=
k
>  > > | 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 th=
ere
>  > > | 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()=
=2E
>  > > It's only purpose is to "Don't kill plserver on a ^C if
>  > > pls->server_nokill is set", and can safely be conditionaly compile=
d
>  > > within a #ifndef  __STRICT_ANSI__/#endif block. I don't commit thi=
s
>  > > 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 gl=
ad
>  > 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.

The problem is that the compiler can't find the function prototypes, but=20
worse, the "sigset_t" type does not exists in ansi, and the compilation f=
ails.

Joao

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

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

On Monday 21 January 2002 7:28 am, Alan W. Irwin wrote:
> 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.

In the x06f.f file, after m4 processing, appears indeed a very long line =
as=20
the first fortran source line:

! Displays the plotter=20
AND,CMP,COMPLEX,DREAL,FALSE,IMAG,IMPLICIT_REAL,INCLUDED_FMACS,NO,OFF,ON,O=
R,REAL,REAL_FUN,SYSTEM,TRUE,YES,__file__,__gnu__,__line__,__m4_version__,=
__unix__,builtin,cdefine,cexpand,changecom,changequote,changesyntax,conca=
t,debugfile,debugmode,decr,define,defn,divert,divnum,dnl,dumpdef,errprint=
,esyscmd,eval,format,getstring,if_aix,if_bsd,if_dbl,if_dgux,if_false,if_h=
pux,if_linux,if_sunos,if_sx,if_sysv,if_true,if_ultrix,ifdef,ifelse,ifndef=
,ignore,implicit_none,include,incr,index,indir,len,m4exit,m4wrap,macro_do=
,maketemp,patsubst,popdef,pushdef,regexp,shift,sinclude,substr,symbols,sy=
ncoutput,syscmd,sysval,traceoff,traceon,translit,undef,undefine,undivert=20
for PLPOIN <--- from the comment until here is a one comment line!
      implicit none <--- this is another line
      integer i, j, k
      real*4 x, y

      character*3 text

! Full sized page for display

So it seems that this is a m4 problem. But suse-7.2 is not that old, and =
my=20
suse system is updated with the last changes... (rpm says that m4 was "Bu=
ild=20
Date: Fri 11 May 2001")

The problem seem to be the word "symbols" in the comments and in the last=
=20
plmtex() arguments of file x06f.fm4; if I remove the word "symbols" from =
the=20
comments, the lines will be no more expanded by m4 as above. What is the =
real=20
cure for this?

Joao

> > 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 e=
nd
> of 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 mentione=
d 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.fm=
4
> and split it into two lines (by using almost any character in the 6th
> column for the continued line as you can see from other *.fm4 files tha=
t
> 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=
=2Efm4
> 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 mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

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

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

Geoffrey Furnish writes:
 > 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.
 > 
 > 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.

Well, I was on a slowaris box just to see if I could duplicate Joao's
problem with Fortran.  We have a g77 here called:

> g77 -v
g77 version 2.95.2 19991024 (release) (from FSF-g77 version 0.5.25
19991024 (release))

which I was hoping would be similar enough to Joao's to show the
problem (albeit this is a solaris build, not Linux).  However, I
experience no problem:

m4 -S2000 -B8192  x06f.fm4 >x06f.f
g77 -c           -O  x06f.f
g77  x06f.o \
       -L. -lplplot -ltclmatrix -o x06f  -L/usr/local/lib -ltk8.2
-ltcl8.2 -lX11 -ldl 
m4 -S2000 -B8192  x07f.fm4 >x07f.f
g77 -c           -O  x07f.f
g77  x07f.o \
       -L. -lplplot -ltclmatrix -o x07f  -L/usr/local/lib -ltk8.2
-ltcl8.2 -lX11 -ldl 

And the examples work as expected.


OTOH, I did learn that PLplot's configure support for Solaris leaves a
lot to be desired.  Besides the problem with shell syntax, it also
somehow dropped -lm from all the link lines, causing every C prog link
to fail (but notice that the f77 links above all worked).

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