plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Current plan is to release PLplot-5.2.0 on 18th January

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

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

> On Saturday 11 January 2003 21:50, Alan W. Irwin wrote:
> | Just a reminder that this time period for testing is now down to one
> | week since I still plan to release PLplot 5.2.0 next Saturday in the
> | morning (Pacific time =3D UTC - 8).
>
> The current cvs configure/compile/runs OK in suse-8.0 and 8.1 with most
> drivers and bindings (java not tested).
>
> On a "OSF1 V4.0 alpha" configure/compile/runs OK but the xwin driver
> seg-faults, either with static or shared libs; the ps driver works
> fine. This was with gcc 3.0.3. I was not able to use gdb, so I can't
> help more. Couldn't try the python, octave and tcl/tk bindings because
> the installed versions are "too old".

Thanks, Joao, for your further testing efforts.

Maurice, do you find a similar xwin problem on your OSF1 platform?

A potential clue to the problem might be the additional valgrind memory
management errors we get with the xwin driver on ia32 under Linux. IIRC,
those errors are deep within X so there is nothing much you can do directly
about them.  Nevertheless, those errors may be an indication that xwin is
using a non-standard way to set up or call X which might cause valgrind
issues (but no other obvious symptoms) on ia32 and segfaults on OSF1.

To sort that or any other possibility out I agree it is essential to have
gdb working on OSF1.  Also, gcc 3.0.3 is quite old and buggy I believe.
However, shouldn't it be straightforward to build new versions of gcc and
gdb? I haven't tried it lately, but in the old days it was straightforward
to build your own personal copy of the latest version of gcc (and presumabl=
y
gdb as well) using a bootstrap procedure from an earlier version of gcc. Th=
e
idea was you compiled the new gcc code with the older version, then used th=
e
resulting executable to compile the new gcc code again, and iterated to
consistency. You may not have time to pursue that option before the release=
,
but ultimately I think that is the only way we will be able to solve the
xwin on OSF1 issue.

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] plbop() crash caused by moronic tmpfile() implementation in M$ W2000

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

On Tuesday 14 January 2003 17:55, Alan W. Irwin wrote:
| On Tue, 14 Jan 2003, Joachim Wuttke wrote:
| > Observation:
| >    Load file foo.dat from D:\path, plbop(), plot, everything works.
| >    Load same file from V:\path, plbop(), application crashes:
| > "access violation". The only difference: drive V is read-only.
| > Explication:
| >    plbop() calls tmpfile(), which comes with libc. This is a posix
| > routine that creates a temporary file. It looks as if the W2k
| > implementation attempts to create the temporary file in just the
| > last directory the application was in contact with.
| > Proposal:
| >    If I see correctly, in the whole of plplot there is only one
| > call to tmpfile(). Therefore we could easily either replace
| > tmpfile() by an explicit fopen, or introduce a preprocessor switch
| > and replaced tmpfile for Windows only.
|
| Joachim, I can find no reference to tmpfile in CVS (to be released

drivers/plbuf.c

at plbuf_bop()  pls->plbufFile =3D tmpfile(); the file is created,
at plbuf_tidy() fclose(pls->plbufFile); the file is removed.

| Saturday as plplot-5.2.0) under src/*.c and certainly not in plbop.=20
| Could you please have a look at the CVS version (a) to make sure this
| specific problem is not occurring, and (b) for general testing before
| the release? Directions for anonymous CVS access are given at
| http://sourceforge.net/cvs/?group_id=3D2915.
|
| 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
| __________________________
|
|
|
| -------------------------------------------------------
| This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
| are you planning your Web Server Security? Click here to get a FREE
| Thawte SSL guide and find the answers to all your  SSL security
| issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] plbop() crash caused by moronic tmpfile() implementation in M$ W2000

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

On Tue, 14 Jan 2003, Joachim Wuttke wrote:

> Observation:
>    Load file foo.dat from D:\path, plbop(), plot, everything works.
>    Load same file from V:\path, plbop(), application crashes: "access violation".
>    The only difference: drive V is read-only.
> Explication:
>    plbop() calls tmpfile(), which comes with libc. This is a posix routine that
>    creates a temporary file. It looks as if the W2k implementation attempts to
>    create the temporary file in just the last directory the application was in
>    contact with.
> Proposal:
>    If I see correctly, in the whole of plplot there is only one call to tmpfile().
>    Therefore we could easily either replace tmpfile() by an explicit fopen, or
>    introduce a preprocessor switch and replaced tmpfile for Windows only.
>

Joachim, I can find no reference to tmpfile in CVS (to be released Saturday
as plplot-5.2.0) under src/*.c and certainly not in plbop.  Could you please
have a look at the CVS version (a) to make sure this specific problem is not
occurring, and (b) for general testing before the release? Directions for
anonymous CVS access are given at http://sourceforge.net/cvs/?group_id=2915.

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] Current plan is to release PLplot-5.2.0 on 18th January

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

On Saturday 11 January 2003 21:50, Alan W. Irwin wrote:
| On Thu, 2 Jan 2003, Alan W. Irwin wrote:
| > The core PLplot developers seem reasonably happy with a release
| > date of 18 January so we will go with that date.  That date will be
| > fairly rigidly enforced because I can only work on releases on
| > weekends, and we don't want it to slide to the next weekend unless
| > a really bad showstopper problem becomes evident.
| >
| > To avoid such a possibility, I strongly encourage you to test the
| > current CVS version over the next two weeks on as wide a variety of
| > platforms as possible.....
|
| Just a reminder that this time period for testing is now down to one
| week since I still plan to release PLplot 5.2.0 next Saturday in the
| morning (Pacific time =3D UTC - 8).

The current cvs configure/compile/runs OK in suse-8.0 and 8.1 with most=20
drivers and bindings (java not tested).

On a "OSF1 V4.0 alpha" configure/compile/runs OK but the xwin driver=20
seg-faults, either with static or shared libs; the ps driver works=20
fine. This was with gcc 3.0.3. I was not able to use gdb, so I can't=20
help more. Couldn't try the python, octave and tcl/tk bindings because=20
the installed versions are "too old".

Joao

|
| Alan
| __________________________
| Alan W. Irwin
| email: ir...@be...
| phone: 250-727-2902
|
| Astronomical research affiliation with Department of Physics and
| Astronomy, University of Victoria (astrowww.phys.uvic.ca).
|
| Programming affiliations with the Canadian Centre for Climate
| Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot
| scientific plotting software package (plplot.org).
|
| __________________________
|
| Linux-powered Science
| __________________________
|
|
|
| -------------------------------------------------------
| This SF.NET email is sponsored by:
| SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
| http://www.vasoftware.com
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] plbop() crash caused by moronic tmpfile() implementation in M$ W2000

[Joachim W. <wu...@cr...>]

Observation:
   Load file foo.dat from D:\path, plbop(), plot, everything works.
   Load same file from V:\path, plbop(), application crashes: "access =
violation".
   The only difference: drive V is read-only.
Explication:
   plbop() calls tmpfile(), which comes with libc. This is a posix =
routine that
   creates a temporary file. It looks as if the W2k implementation =
attempts to
   create the temporary file in just the last directory the application =
was in
   contact with.
Proposal:
   If I see correctly, in the whole of plplot there is only one call to =
tmpfile().
   Therefore we could easily either replace tmpfile() by an explicit =
fopen, or
   introduce a preprocessor switch and replaced tmpfile for Windows =
only.

Greetings, Joachim

  =20

Re: [Plplot-devel] Current plan is to release PLplot-5.2.0 on 18th January

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

On Thu, 2 Jan 2003, Alan W. Irwin wrote:

> The core PLplot developers seem reasonably happy with a release date of 18
> January so we will go with that date.  That date will be fairly rigidly
> enforced because I can only work on releases on weekends, and we don't want
> it to slide to the next weekend unless a really bad showstopper problem
> becomes evident.
>
> To avoid such a possibility, I strongly encourage you to test the current
> CVS version over the next two weeks on as wide a variety of platforms as
> possible.....

Just a reminder that this time period for testing is now down to one week
since I still plan to release PLplot 5.2.0 next Saturday in the morning
(Pacific time = UTC - 8).

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] Java consistency effort concluded for now

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

Thanks, Joao, for adding the visual interest to example 11 (and example 8
before that)!  I have just finished bringing the java examples into
consistency with these changes.

This concludes the Java consistency effort (at least until the next change
in the C examples).  Most java examples agree exactly with their C
counterpart.  The worst difference is a long-standing discrepancy in the
last page of example 9 where the potential plot contours are slightly but
visibly different between C and Java no matter what I try.  I believe there
is some programming mistake here (perhaps in the C example), but the
discrepancies are hard to track down. The two other example discrepancies
that show up with diff are quite minor and don't seem to correspond to
anything visible.

I may have time to also bring the tcl and python examples into consistency
with the C examples before the release.  The point of such effort is to make
sure our wrapper libraries are doing exactly what we think, and to make sure
our API is complete (at least to the extent of being able to reproduce the C
examples).

If somebody is looking for a straightforward way to help out with the
release, it would be nice to have consistent fortran and C++ examples as
well.  I am sure you will run into incomplete API in both cases, but it would
be great to get that fixed up.

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] Current plan is to release PLplot-5.2.0 on 18th January

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

The core PLplot developers seem reasonably happy with a release date of 18
January so we will go with that date.  That date will be fairly rigidly
enforced because I can only work on releases on weekends, and we don't want
it to slide to the next weekend unless a really bad showstopper problem
becomes evident.

To avoid such a possibility, I strongly encourage you to test the current
CVS version over the next two weeks on as wide a variety of platforms as
possible.  A very nice way to do this is simply to run the plplot-test.sh
script in the installed examples directory.  This exercises every non-GUI
example for every front end that you have configured and by default
generates postscript results using the psc device.  Subsequent tests at
later dates or for different platforms can be diffed against these results
to see what (if anything) has been changed in the results by any CVS
changes that have occurred.

On the day in question, my general plan is to make a release candidate CVS
tag early in the morning (UTC-8 hours), create a tarball, do my standard
tests from that tarball (probably take a number of hours) on Debian and
RH7.3, and if all goes well, retag as final and release the tarball and
corresponding RH7.3 source and binary rpm's at the SF site.

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] swig notice version for those developers who use CVS

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

Alan W. Irwin writes:
 > >From now on, those developers who use the CVS version of PLplot should use
 > the latest swig (currently 1.3.17) to build the python and java interfaces
 > to PLplot. It is possible swig versions back to 1.3.14 might work, but a lot
 > of bug fixing has gone on between swig versions, and I have only tested
 > building the new java interface and recently changed python interface on
 > version 1.3.17 so that is the version of swig that I recommend for building
 > both the python and java interfaces.

Thanks for straightening this out.  It didn't look like a big deal to fix but
finding just the right magic incantation can be such a chore.  I'm *really*
glad we're not going to release requiring 1.3.13 for the python bindings but
1.3.17 for java. :)

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

[Plplot-devel] Additional version number remarks

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

I just committed some changes so our plplot-test.sh script includes java in
the family of front ends that it tries.  I ran this revised script to
generate all our non-interactive examples, and I also ran a few interactive
tcl/tk tests.

All went well so I believe there are no Unix/Linux problems with the change
to the new version number (which potentially has implications throughout our
code).

The non-Unix (sys/dos/djgpp, sys/win-tk, and sys/win32) developers
(respectively Andrew, Vince, and Olof) are urged to give this new version
number a try to sort out any problems you might have.  If you are trying
to automate this for the future, look for version remarks in configure.ac.

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] Version updated to 5.2.0

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

I finally figured out how to change the version number (and commented about
my findings in configure.ac) so ignore my prior questions about this,
Rafael.

For now, I decided to change to 5.2.0 for both the package version and the
version numbers for our various libraries in anticipation of the forthcoming
release.  In order to use the new versions, you must either make a clean
checkout from CVS or else do a 'make distclean' before running bootstrap.sh
etc.

If we ever get serious about keeping track of binary compatibility issues
for our several libraries, and only updating the library version when
appropriate, then we will have to look at the version for each of our
libraries on a case-by-case basis.  Until somebody wants to take on that
responsibility, setting all our library versions to the package version
number is easier even though this goes directly contrary to the
advice/advocacy on library versioning that you can find using 'info
libtool'.

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] swig notice version for those developers who use CVS

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

From now on, those developers who use the CVS version of PLplot should use
the latest swig (currently 1.3.17) to build the python and java interfaces
to PLplot. It is possible swig versions back to 1.3.14 might work, but a lot
of bug fixing has gone on between swig versions, and I have only tested
building the new java interface and recently changed python interface on
version 1.3.17 so that is the version of swig that I recommend for building
both the python and java interfaces.

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] My effort on new Java interface has been completed for now.

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

> I am still having difficulty with the three functions (plgdev, plgfnam, and
> plgver) that return a string in their argument list, but that and some
> quickie documentation are all there is left that I want to do for now with
> the new raw java interface.

I gave up on these three functions.  Basically swig allows you to arrange
your wrapper C code any way you like so I did that to my best (limited)
knowledge of JNI.  Unfortunately, the hand-crafted javabind.c did not have a
template I could follow here.  Nevertheless, from my reading of the JNI
tutorial by Sun, I felt the generated code should have passed the string
back properly to the Java environment.  It didn't work (it seemed to build
okay, but it acted like a no-op).  Thus, I have now commented these 3
functions out of the interface and noted this limitation (and all other java
interface limitations I am aware of) in bindings/java/README.javaAPI.  I
have also put other documentation of the new interface in that file.  That
completes the "quickie" documentation and thus completes my raw Java
interface effort for now.

Cheers and congratulatory speeches will now be accepted....;-)

Happy New Year's Eve, everybody!

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] Updated status of the new Java interface

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

plParseOpts now works for all examples.  For the raw interface you must be
explicit about ORing in pls.PL_PARSE_NOPROGRAM to the parse mode parameter
(apparently that is an idiosyncrasy of Java) so that is what I have done for
each example.  Eventually, this detail should be hidden by the user-friendly
interface version.

I am still having difficulty with the three functions (plgdev, plgfnam, and
plgver) that return a string in their argument list, but that and some
quickie documentation are all there is left that I want to do for now with
the new raw java interface.

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] Updated status of the new Java interface

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

On Sat, 28 Dec 2002, Alan W. Irwin wrote:

> As a result of the recent commits, all examples work now except for the
> three examples with the full 3-D PLplot API, (x09, x15, x16).  In particular
> x08 works now without problems.

That situation has now been greatly improved.  As a result of recent commits
*all* java examples work!  That includes x16.java where it calls plshades
using the API rather than lame (I can use that adjective since I wrote those
myself) local workarounds that mimicked more-or-less the plshades
functionality.

There is still a bit more work to do before the new java interface is
release ready. Functions with string arguments don't work quite right as of
the moment, so, for example, plParseOpts has been commented out of all
examples temporarily. I hope to get that all sorted out and write a bit of
documentation in the next few days which should complete the java interface
work that is essential to the release.

For those of you anxious to try this new java interface yourselves, here is
the cookbook.

configure --enable-java --disable-python (and other options); make; make install.

cd $prefix/lib/java/plplot/examples and follow the instructions in
README.javademos.

Note that for the 'make' part of the above to work, you must have java
installed (see README.javademos for now although README.javaAPI will be
updated as well for the release, see comment above about "bit of
documentation").  Furthermore, you must have the latest version of swig
which is currently 1.3.17.  At their release rate of roughly one release per
month over the last 6 months, I fully expect 1.3.18 to be out any day now.
Hopefully, this developmental branch of swig releases is sufficiently
stabilized by now, that the java interface will just continue to work for
new versions of swig beyond 1.3.17.  Note, the python interface currently
does not work with swig-1.3.17 so that is why you must disable python above.
However, I will sort that all out so that swig 1.3.17 (and above, hopefully)
is what will be uniformly required for both the python and java interfaces
to PLplot for those who use CVS.  I emphasize, again, that swig versions
should only concern CVS users.  Ordinary PLplot users will not need swig
since both the java and python interface files will be pre-generated for the
tarball.

There is one other limitation to the new raw java interface that should be
added to the list below of non release-critical issues. Currently, the xg,
and yg arrays to plcont, plshades, and plshade must be two dimensional for
the raw interface. Single-dimensional versions of xg and yg should be
overloaded as part of the user-friendly interface.  Again, I don't think
such an interface is critical to the release, but if somebody would like to
make a start on it (which I don't know how to do), I would be willing to
finish it.

Alan

> There are some additional limitations to this interface which I don't
> believe are release critical and which, in any case, somebody else with more
> than my nominal java expertise will have to deal with.  I list those
> limitation here so that those of you with further interest may have a chance
> to tackle these issues before the release if you care to do so.
>
> (1) A user-friendly wrapper to the interface should be made in java to give
> us a variety of different simplified argument lists similarly to the way
> plplot.py wraps the plplotc extension module.  If someone will show me the
> way by writing such a java wrapper with just one argument list
> simplification I can fill out the rest following the user-friendly
> simplified argument list variations that have been implemented in plplot.py.
>
> (2) Each example has a rather ugly combination of two commands:
>
>     PLStreamc plsdummy = new PLStreamc();
>     plplotjavac pls = new plplotjavac();
>
> The first one dynamically loads the wrapper library (with the stream stuff
> commented out because the plplot API is not available to that class at the
> moment), and the second one loads the plplotjavac wrapper made by swig which
> then pulls in everything else that is required.  Obviously, this should all
> be done with one command where we refer to PLStream, the user-friendly
> wrapper which in turn wraps PLStreamc, which in turn (after loading the
> library) wraps plplotjavac and then finishes with the stream stuff that
> Geoffrey put in for the old interface.  But it is going to require somebody
> (that word again....;-)) more expert in Java than me to implement this.  As
> I said above, I can fill out all the required argument list variations once
> somebody shows me how to make just one of them.
>
> (3) Only the default java double-precision can be used from Java.  That is
> what the examples use (by default) so that is what works.  I believe the way
> to do this properly with swig is simply to make both single and double
> precision versions of the PLplot API description, and the two possible
> function calls will be overloaded.
>
> N.B. This java precision issue should not be confused with the double or
> single precision PLplot library issue.  I have been doing all my testing
> with the single-precision form of the PLplot library, and all
> double-precision java entities are transformed to single-precision without
> problems. I assume the double-precision form of the PLplot library will work
> fine as well since no transformation is required in that case, but I have
> not tested it.
>
> (4) The callback functions should be done properly so that java methods can
> be used for transformations for the full 3-D PLplot API.  This approach
> would be similar to the way the python interface fully implements the
> callback functions (see the mypltr definition and use in xw09.py).  For now,
> though, the "simplified version of the full 3-D API" referred to above means
> we will be taking the simplified tcl approach to the 3-d API for now rather
> than the preferred complete callback approach used for the python interface.
>
> 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] app-defaults files for PLplot/tk

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

My recent commits gives us the ability to set options in app-defaults files
for use with PLplot/tk.  To use, go down into bindings/tk/app-defaults and
look at the README file.  In short, to get started just copy one of those
PLplot.*.ad to "~/app-defaults/PLplot", then fire up a PLplot tk based
app.

There's a lot more that can be done along this path, such as:
 - convert all fixed fonts/colors/etc to be specified by options db vars
 - revamp all the default fonts (the old defaults can be restored by using
   PLplot.large.ad).

Feel free to have fun with it.

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

[Plplot-devel] Updated status of the new Java interface

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

As a result of the recent commits, all examples work now except for the
three examples with the full 3-D PLplot API, (x09, x15, x16).  In particular
x08 works now without problems.

The final things on my Java agenda before release are character string
arrays (which will allow command-line processing and the x01 version string
output), and making a simplified version of the full 3-D API work.  Those
two changes should allow all implemented java examples to work completely,
and should also give our users access to the complete common PLplot API from
Java.

There are some additional limitations to this interface which I don't
believe are release critical and which, in any case, somebody else with more
than my nominal java expertise will have to deal with.  I list those
limitation here so that those of you with further interest may have a chance
to tackle these issues before the release if you care to do so.

(1) A user-friendly wrapper to the interface should be made in java to give
us a variety of different simplified argument lists similarly to the way
plplot.py wraps the plplotc extension module.  If someone will show me the
way by writing such a java wrapper with just one argument list
simplification I can fill out the rest following the user-friendly
simplified argument list variations that have been implemented in plplot.py.

(2) Each example has a rather ugly combination of two commands:

    PLStreamc plsdummy = new PLStreamc();
    plplotjavac pls = new plplotjavac();

The first one dynamically loads the wrapper library (with the stream stuff
commented out because the plplot API is not available to that class at the
moment), and the second one loads the plplotjavac wrapper made by swig which
then pulls in everything else that is required.  Obviously, this should all
be done with one command where we refer to PLStream, the user-friendly
wrapper which in turn wraps PLStreamc, which in turn (after loading the
library) wraps plplotjavac and then finishes with the stream stuff that
Geoffrey put in for the old interface.  But it is going to require somebody
(that word again....;-)) more expert in Java than me to implement this.  As
I said above, I can fill out all the required argument list variations once
somebody shows me how to make just one of them.

(3) Only the default java double-precision can be used from Java.  That is
what the examples use (by default) so that is what works.  I believe the way
to do this properly with swig is simply to make both single and double
precision versions of the PLplot API description, and the two possible
function calls will be overloaded.

N.B. This java precision issue should not be confused with the double or
single precision PLplot library issue.  I have been doing all my testing
with the single-precision form of the PLplot library, and all
double-precision java entities are transformed to single-precision without
problems. I assume the double-precision form of the PLplot library will work
fine as well since no transformation is required in that case, but I have
not tested it.

(4) The callback functions should be done properly so that java methods can
be used for transformations for the full 3-D PLplot API.  This approach
would be similar to the way the python interface fully implements the
callback functions (see the mypltr definition and use in xw09.py).  For now,
though, the "simplified version of the full 3-D API" referred to above means
we will be taking the simplified tcl approach to the 3-d API for now rather
than the preferred complete callback approach used for the python interface.

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] KCC flags

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

On Fri, 27 Dec 2002, Maurice LeBrun wrote:

> [...]So I took your advice and tried using cc
> instead of gcc by inserting the following line in configure.ac:
>
> AC_PROG_CC(cc cl egcs gcc)
>
> which overrides the default search order, like AC_PROG_CXX.
> Then the build went:
>
> ...
> cc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../libltdl -g -c plcont.c  -KPIC -DPIC -o plcont.o
> mv -f plcont.o .libs/plcont.lo
> ...
>
> So you see, there is logic in there to build the object then move it, use it
> in the new location, and clean up appropriately.

And I notice the correct -KPIC flag is in there as well.

>
> The question is, how can I trigger this behavior for KCC?

That is a tough one. Sorry I cannot be any help on that.

My only real suggestion is to try an extremely simple example to see if the
correct behaviour is triggered.  If that is no go, then it is probably time
to take the results of that simple example to the libtool list to get the
definitive answers about KCC support.  But you also might find that the
simple example works fine.

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] KCC flags

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

To follow up on this discussion of yesterday:

- Tried autoscan.  Contained some interesting info, some of which might be
handy in rooting out additional non-portabilities.  But most of it had to
do with non-ANSI C constructs and are therefore false positives AFAIAC.
Didn't help out with any of my current problems, which are:

- Using autoconf's built-in support of KCC to fix the build under Solaris,
and improve it elsewhere.  So I added:

# List of C++ compilers to look for, in order.  The default (autconf 2.57) is:
# g++ c++ gpp aCC CC cxx cc++ cl FCC KCC RCC xlC_r xlC
AC_PROG_CXX(KCC g++ c++ gpp aCC CC cxx cc++ cl FCC RCC xlC_r xlC) 

to configure.ac, chopping out the previous part.  Didn't do a thing that I
could tell except automatically get the compiler right, which *is* nice.
So I'll replace the manual check by this, but still handle options as I
mentioned previously.

Back to Solaris.. the KCC shared lib build is still busted, as mentioned
because of this:

/bin/bash ../../libtool --mode=compile KCC -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include  -I../../libltdl   -g -c -o plstream.lo `test -f 'plstream.cc' || echo './'`plstream.cc
mkdir .libs
KCC -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../libltdl -g -c plstream.cc  -fPIC -DPIC -o .libs/plstream.lo
KCC: Option -fPIC not recognized.
cc: illegal suffix of output filename

(the -fPIC warning is harmless).  So I took your advice and tried using cc
instead of gcc by inserting the following line in configure.ac:

AC_PROG_CC(cc cl egcs gcc)

which overrides the default search order, like AC_PROG_CXX.
Then the build went:

...
cc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../libltdl -g -c plcont.c  -KPIC -DPIC -o plcont.o
mv -f plcont.o .libs/plcont.lo
...

So you see, there is logic in there to build the object then move it, use it
in the new location, and clean up appropriately.

The question is, how can I trigger this behavior for KCC?

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

[Plplot-devel] Status of new swig-based java interface for PLplot

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

I have made a lot of progress in the last couple of days with the new
swig-generated Java interface for PLplot.  (I should mention that it is only
because of Gary Bishop's pioneering efforts with the swig-generated python
interface to PLplot, that it is possible to build the java interface with
swig.) I have recently committed all my work on the java interface up to
now. Unlike the hand-crafted interface which was missing a lot of the PLplot
API, this swig-generated interface should be complete for whatever argument
list patterns have been covered.

The current status is that all PLplot functions in the common API with
variable arguments or single-dimension array float, double, or integer
arguments have been implemented.  Functions with character array arguments
and with two-dimensional array arguments still need to be implemented. That
means six of the examples (x08, x09, x11, x12, x15, and x16) won't compile,
but the rest of the examples do compile and run and give good results.
Furthermore, since the new java interface is complete (aside from the
exceptions noted above), x18.java works properly for the very first time.

Anyhow, this new interface looks extremely promising, and I hope to sort out
the remaining argument list patterns (and thus allow all the java examples
to compile and run) over the next several days.  Get in touch with me
privately if you want to know how to play with this new interface before it
is ready for prime time.

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] COPYING

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

Maurice LeBrun writes:
 > Alan W. Irwin writes:
 >  > I am a little surprised you don't have COPYING though.  ./bootstrap.sh
 >  > creates it on my machine if there is not a file by that name in the
 >  > top-level directory.
 > 
 > It didn't, or in the build process got blown away somehow.  I know it sounds
 > farfetched but in the clear light of day :) I'm looking at my command line
 > history and everything checks out but COPYING is missing (this is on IRIX).

Using a fresh checkout, bootstrap.sh does not create a top level COPYING in
my configuration on either of Linux, OSF1, or IRIX.

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

Re: [Plplot-devel] COPYING

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

Alan W. Irwin writes:
 > On Fri, 27 Dec 2002, Maurice LeBrun wrote:
 > 
 > > I'm getting this waaay too often:
 > >
 > > gmake[1]: *** No rule to make target `COPYING', needed by `all-am'.  Stop.
 > >
 > > I just got it again, after a clean checkout, in the shared lib build phase.
 > > Could we just take it out?  To be stopped short of a build because of this
 > > after messing with this stuff nearly all day is driving me *nuts*.
 > 
 > Sure.  I meant to do this anyhow as per discussion. Remove it from doc_DATA
 > in the top-level Makefile.am.
 > 
 > I am a little surprised you don't have COPYING though.  ./bootstrap.sh
 > creates it on my machine if there is not a file by that name in the
 > top-level directory.

It didn't, or in the build process got blown away somehow.  I know it sounds
farfetched but in the clear light of day :) I'm looking at my command line
history and everything checks out but COPYING is missing (this is on IRIX).

Matter of fact, I've been suffering through lots of niggling little problems
that I haven't been documenting just because I've already spent more time on
this than intended.  Lots of problems in the approach you mentioned of doing
./bootstrap.sh on one machine and then tar'ing up the distribution and trying
to build it on another machine.  I suspect other people will run up against
this too so we'll get more & detailed error reports.  To get rid of all those
problems I just put the latest auto{conf,make},libtools on all those
platforms.

Anyway back to it.  I will try to document detailed failure scenarios if I
have the time.

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

Re: [Plplot-devel] KCC flags

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

Hello Maurice:

In an effort to help you out, I have been poking around in info libtool this
morning.  If you search for "compiler characteristics" there, the
documentation clearly states that for the solaris2 platform, the
position-independent code switch is -KPIC rather than the -fPIC that you are
getting.

So I am wondering whether some of our instructions in configure.ac,
sysloc.in, etc. are confusing libtool in non-gcc situations.

To gain some insight into that question I suggest it is time to try a
different approach; use a simple example with unmodified/unhacked
configure.ac generated by autoscan as a test case.  Use the autobook "hello
world" example (suitably modified if necessary so it exercises what is not
working for you at the moment with plplot) to see whether everything works
well for all your compilers/platforms for that simple example.  After all,
autotools are used by thousands of projects, and if you grep for kcc and KCC
in configure, it does seem to be aware of that compiler.  Thus, my working
hypothesis is a simple example with autoscan-generated configure.ac is going
to work on all the compilers/platforms of interest to you, and that will
give you some insight in what we are doing wrong for our more complicated
project.

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] COPYING

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

On Fri, 27 Dec 2002, Maurice LeBrun wrote:

> I'm getting this waaay too often:
>
> gmake[1]: *** No rule to make target `COPYING', needed by `all-am'.  Stop.
>
> I just got it again, after a clean checkout, in the shared lib build phase.
> Could we just take it out?  To be stopped short of a build because of this
> after messing with this stuff nearly all day is driving me *nuts*.

Sure.  I meant to do this anyhow as per discussion. Remove it from doc_DATA
in the top-level Makefile.am.

I am a little surprised you don't have COPYING though.  ./bootstrap.sh
creates it on my machine if there is not a file by that name in the
top-level directory.

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] COPYING

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

I'm getting this waaay too often:

gmake[1]: *** No rule to make target `COPYING', needed by `all-am'.  Stop.

I just got it again, after a clean checkout, in the shared lib build phase.
Could we just take it out?  To be stopped short of a build because of this
after messing with this stuff nearly all day is driving me *nuts*.

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