plplot-devel — Technical discussion about PLplot development

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

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

Joao, you have brought up a number of interesting points which I will
attempt to answer in context below.

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 Thu, 17 Jan 2002, Joao Cardoso wrote:

>
> Hi,
>
> I think that the main directory README, INSTALL, CHANGES and NEWS files
> should be updated, as they are the first think that I read on (and I assume
> others also do it :).
> The ToDo and PROBLEMS file also needs an update, as some users can have the
> expertise and mood to do/solve it. WE *should* use it, also!

I agree with both your points here.  I don't have time to start any of this
myself so I would encourage you (after the release, please!) to change these
files any way you like. Once you start to use them, I (and perhaps the other
developers) will most likely follow.  Note, if there are any English
problems with your changes, I would be willing to make corrections after you
make your main changes.

>
> The examples/java/README file should be in bindings/java, or its name changed
> to README.java, to follow what is done in the other examples directory.

Done.

> I thinks that each bindings and examples subdirs should have a README file,
> and the main README file should point to them.

We are gradually getting there on the first point, and on the second point
I say please go ahead.  I would be happy to see changes in the overall README
before the release.

>
> What is the purpose of the "new" directory and its "bogus" file? And the
> bindings/python/1.4b3 subdir?

Haven't got a clue.

>
> When will be 5.1 released?

24 January.

What do we intend to have on it?

Current CVS HEAD plus any changes we do from now until then.  See my wishlist.

> Can we add more
> and more stuff to HEAD

Yes, so long as it is useful.  plimage is an excellent example of such
an add-on.

and always have an unstable CVS?

No.  For example, we are in a stabilizing phase right now in preparation for
the release.

We have discussed release philosophy many times before so I will try to keep
this short.  As far as I am concerned, I never plan to make an experimental
or unstable release.  Instead, periodically we work hard to stabilize cvs
HEAD and release that.

My own view is we are too small a project to support a lot of different
branches.  For example, I never want to see a special stable branch (except
periodically for CVS HEAD).  Branches are useful for the really big changes
such as dynamic drivers, but I personally lost weeks of work on the tea
branch because there wasn't a critical mass of interested developers at the
time.  Thus, you have to be really careful about splitting development up
too much.  Taking the plimage example, again, I wouldn't have gotten
interested in it if you hadn't put it on the HEAD.  So for relatively small
changes like this that don't impact a lot of other stuff, put them right on
HEAD, then work to stabilize them in time for a release. Obviously, you are
not quite satisfied with plimage yet ("work in progress"), but I am not
personally going to worry if you change the API one more time after this
release.  Users of new features have to expect API changes.  However, I do
hope that the x20c example at least works for this release, and that you
have plimage completely stabilized (including API decisions) in time for the
release after this one.

>
> I would like to add some things to the documentation, after english-proofing
> by an English native speaker, but I found the DocBook too complex! I was
> still not able to create the development environment (and I tried, and I
> tried, and I tried , but I couldn't get it :-)).

I will be happy to help you get this sorted out, Joao.  But I need specifics
from you off list.  (In the next few days I will be going through this for
my own woody system and perhaps a RedHat 7.2 system as well so now is an
excellent time to get the DocBook development environment working on your
system as well.)

> Is there a xml2sgml utility?
> ( My system has a sgml2xml utility). Than I could convert to latex and add
> the docs.
>

I have not heard of an xml2sgml facility.  sgml is being phased out in favor
of xml so I think the sgml/xml language types would view xml2sgml as a
retrograde step they were unwilling to support. I think a much better
solution is simply to get the DocBook-xml environment working on your
system.  I will help, but as I said above, I need specifics about what
doesn't work.  For example, how far did you get in README.developers?

Alan

Re: [Plplot-devel] java install changes

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

On Thu, 17 Jan 2002, Joao Cardoso wrote:

> On Wednesday 16 January 2002 10:10 pm, Alan W. Irwin wrote:
> >
> > Joao, I wrote those instructions at your suggestion.  By all means please
> > give the instructions a try, and let me know if they need any additions.
> >
> > Alan
> >
> >
>
> (1) Install a jdk (Java Development Kit).  I used the Blackdown jdk-1.2.2
> for Linux, but for that platform there is also an IBM jdk if you prefer.
>
> I would say that it was also tested with sun-1.1.8 and IBM-1.3.0.

Please expand a bit. I am not sure what you mean by sun-1.1.8.  Is this the
Blackdown jdk 1.1.8 port for Linux?  By IBM-1.3.0 are you referring to their
Linux port? Finally, are you saying you tested with both of these Linux
jdk ports, and it worked fine for you?  If so, that is excellent news.

Alan

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

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

Hi,

I think that the main directory README, INSTALL, CHANGES and NEWS files=20
should be updated, as they are the first think that I read on (and I assu=
me=20
others also do it :).
The ToDo and PROBLEMS file also needs an update, as some users can have t=
he=20
expertise and mood to do/solve it. WE *should* use it, also!

The examples/java/README file should be in bindings/java, or its name cha=
nged=20
to README.java, to follow what is done in the other examples directory.
I thinks that each bindings and examples subdirs should have a README fil=
e,=20
and the main README file should point to them.

What is the purpose of the "new" directory and its "bogus" file? And the=20
bindings/python/1.4b3 subdir?

When will be 5.1 released? What do we intend to have on it? Can we add mo=
re=20
and more stuff to HEAD and always have an unstable CVS?

I would like to add some things to the documentation, after english-proof=
ing=20
by an English native speaker, but I found the DocBook too complex! I was=20
still not able to create the development environment (and I tried, and I=20
tried, and I tried , but I couldn't get it :-)). Is there a xml2sgml util=
ity?=20
( My system has a sgml2xml utility). Than I could convert to latex and ad=
d=20
the docs.

Oh well, questions, questions,

Joao

Re: [Plplot-devel] java install changes

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

On Wednesday 16 January 2002 10:10 pm, Alan W. Irwin wrote:
>
> Joao, I wrote those instructions at your suggestion.  By all means plea=
se
> give the instructions a try, and let me know if they need any additions=
=2E
>
> Alan
>
>

(1) Install a jdk (Java Development Kit).  I used the Blackdown jdk-1.2.2
for Linux, but for that platform there is also an IBM jdk if you prefer.

I would say that it was also tested with sun-1.1.8 and IBM-1.3.0.
That's OK, thanks

Joao

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

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

Alan W. Irwin writes:
 > (10) Maurice's changes that he has discussed previously on list.  Reviewing
 > his e-mail about this, they include the solution for the "plgdevlst: too
 > many devices" bug, 

I will get to this.

 > a fix for some "configuration problems involving excluded
 > devices", 

I plan to get to this also.

 > and a Tk widgets resources project Maurice hoped to complete
 > before release.

No way I can get it finished and not suck within a week.  So, next time
I guess.

 > Is there anything else?

I'll have the palette tools working again, based on Vince's TEA work.
Will require Itcl.  

Also, have had the rude awakening that on my default TrueColor visuals for 16
or 24 bit depths, I can't allocate r/w color cells, so these tools aren't
nearly as cool as-is.  When I switch to 8 bit display I can get back a
PseudoColor display with r/w color cells and they work just as I remember
them.

So now I'm thinking for TrueColor displays I'll include a switch to redraw the
whole plot each time a color is changed.  Can be slow at times (so it will be
configurable) but it's the same expense as with zoom/pan which isn't that bad
on a fast system even for 256x256 resolution grids and color shading if the
number of distinct colors isn't large (say 10).

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

[Plplot-devel] java install changes

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

I received no response on the java source install question so I made some
executive decisions: the class files will be retained for
...lib/java/plplot/core. My understanding is these binary files are analogous
to a library in the sense they are required to run any application that uses
the java front end to plplot.  Thus, like a library I install only the
binary *.class files and not the source *.java files.

The situation is different for all the other examples where we install the
source but no binaries.  To follow this idea for the java examples, the
*.java files (but not the *.class files) are now installed in
.../lib/java/plplot/examples.  Furthermore, the new README I created (see
plplot/examples/java/README) that explains how to build the java examples
either from the tmp location or the install location is also installed in
.../lib/java/plplot/examples.

Joao, I wrote those instructions at your suggestion.  By all means please
give the instructions a try, and let me know if they need any additions.

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] Re: Embedded single precision in the matrix library

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

Alan W. Irwin writes:
 > Point well taken, but I have investigated further, and there is more to this
 > story that I didn't understand before.  From the above example $ y -
 > 3.123456 has access to the full ~17 digit precision of y before subtracting the
 > constant from it so there are actually still 10 significant digits left in
 > the result (note the last two "81" digits are incorrect because the internal
 > precision of y is roughly 17 digits.)
 > 
 > But look how the corresponding matrix result does not act this way.
 > 
 > pltcl> set tcl_precision 12
 > 12
 > pltcl> matrix a f 1 = {3.1234567890123456789}
 > a
 > pltcl> puts [expr [a 0] - 3.123456]
 > 7.89010000002e-07
 > 
 > There are 5 fewer significant digits in this result than for the y - const
 > result.
 > 
 > My mental model of what is going on here is as follows: unlike $y - const,
 > [a 0] - const only has access to tcl_precision digits of precision for
 > matrix values. In other words set tcl_precision effectively sets the
 > internal precision of matrix calculations rather than simply limiting the
 > number of digits emitted for results.

The story becomes more interesting.  I believe the two representations
(variable or tclMatrix) would've given the same result in pre-Tcl8.0.  The
reason being that in the old Tcl, "everything's a string".  But no longer --
the variable that you create with "set" is "dual-ported", meaning it has both
a binary and string representation.  The binary one is used in expression
evaluations and so is more accurate.

I've been poring over the documentation, and I think it's feasible to change
tclMatrix to emit objects instead of strings, which seems to be the right way
to really fix this.  Also will help a lot with performance.  The object is
equipped with procedure calls to convert it to strings when necessary.
Unfortunately this is a pretty major undertaking, and not one I care to get
into right now.

So as for a stopgap measure, I'll change it to carry 12 digits of precision,
both internally and externally.  I tried 17 but didn't like the result.  E.g.

pltcl> matrix c f 3 = {3.2 4.5 5.7}
c
pltcl> puts [c *]
3.2000000000000002 4.5 5.7000000000000002

which the tclvars man page warns about.

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

Re: [Plplot-devel] Re: Embedded single precision in the matrix library

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

Alan W. Irwin writes:
 > Point well taken, but I have investigated further, and there is more to this
 > story that I didn't understand before.  From the above example $ y -
 > 3.123456 has access to the full ~17 digit precision of y before subtracting the
 > constant from it so there are actually still 10 significant digits left in
 > the result (note the last two "81" digits are incorrect because the internal
 > precision of y is roughly 17 digits.)
 > 
 > But look how the corresponding matrix result does not act this way.
 > 
 > pltcl> set tcl_precision 12
 > 12
 > pltcl> matrix a f 1 = {3.1234567890123456789}
 > a
 > pltcl> puts [expr [a 0] - 3.123456]
 > 7.89010000002e-07
 > 
 > There are 5 fewer significant digits in this result than for the y - const
 > result.
 > 
 > My mental model of what is going on here is as follows: unlike $y - const,
 > [a 0] - const only has access to tcl_precision digits of precision for
 > matrix values. In other words set tcl_precision effectively sets the
 > internal precision of matrix calculations rather than simply limiting the
 > number of digits emitted for results.

You're right, it's still not really right.  Will look into it some more.

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

Re: [Plplot-devel] Re: Embedded single precision in the matrix library

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

On Tue, 15 Jan 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > Thanks for your fix.  At first I thought there was a 12-digit limit to the
>  > matrix precision, but that is just the default value of tcl_precision.  If I
>  > set it to 17 I get full double-precision results.
>  >
>  > BTW, tcl_precision doesn't seem to have universal application.  My tests
>  > indicated the internal precision of ordinary variables in pltcl was 17
>  > digits regardless of what tcl_precision value was set.  For example with
>  > the default (12) value of tcl_precision I get the following results:
>  >
>  > pltcl> set y 3.12345678901234567890
>  > 3.12345678901234567890
>  > pltcl> puts [expr $y - 3.123456]
>  > 7.89012345681e-07
>    1 234567890ab
>
> ..i.e. 12 digits of precision.

Point well taken, but I have investigated further, and there is more to this
story that I didn't understand before.  From the above example $ y -
3.123456 has access to the full ~17 digit precision of y before subtracting the
constant from it so there are actually still 10 significant digits left in
the result (note the last two "81" digits are incorrect because the internal
precision of y is roughly 17 digits.)

But look how the corresponding matrix result does not act this way.

pltcl> set tcl_precision 12
12
pltcl> matrix a f 1 = {3.1234567890123456789}
a
pltcl> puts [expr [a 0] - 3.123456]
7.89010000002e-07

There are 5 fewer significant digits in this result than for the y - const
result.

My mental model of what is going on here is as follows: unlike $y - const,
[a 0] - const only has access to tcl_precision digits of precision for
matrix values. In other words set tcl_precision effectively sets the
internal precision of matrix calculations rather than simply limiting the
number of digits emitted for results.

>  > I would prefer matrix to act the same way regardless ot tcl_precision.
>  > Therefore, could you just set the matrix precision to 17 digits when PLFLT
>  > is double and 7 digits otherwise?  The other alternative I am considering is
>  > to set tcl_precision to 17 in each of the examples, but I prefer not to do
>  > that if there is an automatic PLFLT-style solution you can use for
>  > libmatrix.
>
> I really think tying it to tcl_precision is the right thing to do.
> It doesn't have any effect on internal representation, just the number
> of digits emitted when converting the PLFLT to a string.

That would be okay with me, but as you can see from the above example it
is affecting the (effective) internal precision, and not just the digits
being emitted.

Hope you can get this matrix problem sorted out.

Alan

RE: [Plplot-devel] Java install questions

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

On Tue, 15 Jan 2002, Geoffrey Furnish wrote:

> [...] However, your
> proposal doesn't seem right to me either, since it seems kludgy to have
> to have two additions to classpath to use the java stuff.  Maybe you
> could take the position that you only need the first one for normal
> client codes, and the second one is just to reach the PLplot Java
> demos,

yes.  Also, I was quite happy to see that your java package structure still
worked fine if you assembled the bits and pieces from separate directory
trees with the appropriate colon-separated list of directories in CLASSPATH.
Of course, just because something is possible doesn't mean you have to do it
so see below.

> but to me it makes more sense to have one classpath component
> which reaches all things plplot/java.

OK.  I will go along with this decision.

> Personally, I'd just leave it alone for now, figuring that it wil
> lhave to change later once we learn the ways of upscale Java packagers
> well enough to follow suit fashionably.

OK, to be revisited later when one of us knows more about jar files, etc.

You didn't answer my question about the sources.  Currently there are no
java sources anywhere in the install directory tree.  I believe at least the
java example sources should be there (by analogy with the source code that
is installed for the other examples). Assuming you agree on the examples, do
you also want the core sources installed?

Alan

RE: [Plplot-devel] Java install questions

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

Alan W. Irwin writes:
 > Geoffrey, I cannot find any installed source for the java files.  Shall I
 > just change the configuration so the sources will be installed into the
 > appropriate subdirectory of $prefix/plplot/lib/java/plplot along with
 > their corresponding *.class files?
 > 
 > Finally, I would like to install
 > java/plplot/examples into the examples install area
 > ($prefix/lib/plplot5.1.0/examples/). This requires two directories in
 > CLASSPATH, e.g.,
 > 
 > setenv CLASSPATH \
 > /usr/local/plplot/lib/java:/usr/local/plplot/lib/plplot5.1.0/examples/java
 > 
 > but so long as that change is made, e.g.,
 > 
 > java plplot.examples.x01
 > 
 > works fine. The reason I would like this change is it just seems more
 > logical to me to have the java examples installed with the remainder of the
 > plplot examples, and the java core stuff installed in $prefix/lib/java right
 > where it is now. This is just a suggestion, and if you feel the best
 > solution is the current one with the java examples split off from the rest
 > of the examples, then I will go along.

Mmm.  Well, I just think of it that all the PLplot java stuff lives
under the plplot.* package hierarchy.  Some of it is under
plplot.core.*, some of it is under plplot.examples.*.  

I said way back in the beginning, that I am a novice in java
packaging, so what is done now is surely simplistic.  However, your
proposal doesn't seem right to me either, since it seems kludgy to have
to have two additions to classpath to use the java stuff.  Maybe you
could take the position that you only need the first one for normal
client codes, and the second one is just to reach the PLplot Java
demos, but to me it makes more sense to have one classpath component
which reaches all things plplot/java.

What is probably really in order, is to build a jar file.  Then to
enhance plplot-config to have a --classpath arg to spit out the right
classpath for use as we do plplot-config --libs now in C/C++
contexts.  But I haven't gotten to that yet.

I am quite sure that upscale java dists use .jar files.  But I don't
really know how to create them fashionably, so have just put up the
current hacky thing to get us through until either I learn what to
really do, or until some Java guru developer graces us with some guru
class configuration advice.

Personally, I'd just leave it alone for now, figuring that it wil
lhave to change later once we learn the ways of upscale Java packagers
well enough to follow suit fashionably.

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

[Plplot-devel] Java install questions

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

On Mon, 14 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
> (AWI wrote) Is there anything else?
>
> Have you recently tested an installed plplot? I think to remember
> that there was some problems left from java?

Of course before installation, all java examples work fine if you are in tm=
p
and you set
setenv CLASSPATH java
setenv LD_LIBRARY_PATH .

No problems here with java after installation as well.  I do the
following (your install location will probably differ):

setenv CLASSPATH /usr/local/plplot/lib/java
setenv LD_LIBRARY_PATH /usr/local/plplot/lib/
cd /tmp  #to prove that your current directory doesn't matter.
java plplot.examples.x01
java plplot.examples.x08

Those examples worked fine so I am sure the rest are fine as well.

This brings up some other java install questions.

Geoffrey, I cannot find any installed source for the java files.  Shall I
just change the configuration so the sources will be installed into the
appropriate subdirectory of $prefix/plplot/lib/java/plplot along with
their corresponding *.class files?

Finally, I would like to install
java/plplot/examples into the examples install area
($prefix/lib/plplot5.1.0/examples/). This requires two directories in
CLASSPATH, e.g.,

setenv CLASSPATH \
/usr/local/plplot/lib/java:/usr/local/plplot/lib/plplot5.1.0/examples/java

but so long as that change is made, e.g.,

java plplot.examples.x01

works fine. The reason I would like this change is it just seems more
logical to me to have the java examples installed with the remainder of the
plplot examples, and the java core stuff installed in $prefix/lib/java righ=
t
where it is now. This is just a suggestion, and if you feel the best
solution is the current one with the java examples split off from the rest
of the examples, then I will go along.

Alan

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

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] Re: Embedded single precision in the matrix library

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

Alan W. Irwin writes:
 > Thanks for your fix.  At first I thought there was a 12-digit limit to the
 > matrix precision, but that is just the default value of tcl_precision.  If I
 > set it to 17 I get full double-precision results.
 > 
 > BTW, tcl_precision doesn't seem to have universal application.  My tests
 > indicated the internal precision of ordinary variables in pltcl was 17
 > digits regardless of what tcl_precision value was set.  For example with
 > the default (12) value of tcl_precision I get the following results:
 > 
 > pltcl> set y 3.12345678901234567890
 > 3.12345678901234567890
 > pltcl> puts [expr $y - 3.123456]
 > 7.89012345681e-07
   1 234567890ab

..i.e. 12 digits of precision.  Further examples:

pltcl> set tcl_precision 6
6
pltcl> puts [expr $y - 3.123456] 
7.89012e-07
pltcl> set tcl_precision 4
4
pltcl> puts [expr $y - 3.123456] 
7.89e-07

 > I would prefer matrix to act the same way regardless ot tcl_precision.
 > Therefore, could you just set the matrix precision to 17 digits when PLFLT
 > is double and 7 digits otherwise?  The other alternative I am considering is
 > to set tcl_precision to 17 in each of the examples, but I prefer not to do
 > that if there is an automatic PLFLT-style solution you can use for
 > libmatrix.

I really think tying it to tcl_precision is the right thing to do.
It doesn't have any effect on internal representation, just the number
of digits emitted when converting the PLFLT to a string.

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

[Plplot-devel] Re: Embedded single precision in the matrix library

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

P.S.

Maurice, an even simpler alternative is to always use 17 figures internally
rather than 17 or 7 depending on PLFLT.  The choice is up to you.

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] Re: Embedded single precision in the matrix library

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

Thanks for your fix.  At first I thought there was a 12-digit limit to the
matrix precision, but that is just the default value of tcl_precision.  If I
set it to 17 I get full double-precision results.

BTW, tcl_precision doesn't seem to have universal application.  My tests
indicated the internal precision of ordinary variables in pltcl was 17
digits regardless of what tcl_precision value was set.  For example with
the default (12) value of tcl_precision I get the following results:

pltcl> set y 3.12345678901234567890
3.12345678901234567890
pltcl> puts [expr $y - 3.123456]
7.89012345681e-07

I would prefer matrix to act the same way regardless ot tcl_precision.
Therefore, could you just set the matrix precision to 17 digits when PLFLT
is double and 7 digits otherwise?  The other alternative I am considering is
to set tcl_precision to 17 in each of the examples, but I prefer not to do
that if there is an automatic PLFLT-style solution you can use for
libmatrix.

Alan

>  > Why aren't there more significant digits in the matrix results?
>
> It's because standard sprintf was being used.  But have no fear, I've
> converted over to using the internal Tcl print (double) function, which uses
> the tcl_precision variable to decide how long to make it.
>
> --
> Maurice LeBrun    mj...@ga...
>

RE: [Plplot-devel] Re: [Plplot-cvs] CVS update notice (plplot/bindings/tcl)

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

On Mon, 14 Jan 2002, Maurice LeBrun wrote:

> E.g. on a fresh build:
>
> ...
> gcc -c  -g        -O    -I. -I/home/mjl/gts/include plimage.c
> cd /home/mjl/dev/plplot/latest/bindings/tcl; \
> perl pltclgen
> cd /home/mjl/dev/plplot/latest/bindings/tcl; \
> perl pltclgen
> cd /home/mjl/dev/plplot/latest/bindings/tcl; \
> perl pltclgen
> gcc -c  -g        -O    -I. -I/home/mjl/gts/include tclAPI.c
> tclAPI.c:35:27: plplot/tclgen.h: No such file or directory
> tclAPI.c:70:29: plplot/tclgen_s.h: No such file or directory
> tclAPI.c:478:20: tclgen.c: No such file or directory
> make: *** [tclAPI.o] Error 1
>
> Running configure again "solves" this problem, but a nicer solution should be
> found.

I put in some specific symlinks into configure.in, and that seems to solve
the problem according to my one superficial test.  Please test it for
yourself, and let me know what you think.

Alan

RE: [Plplot-devel] Re: [Plplot-cvs] CVS update notice (plplot/bindings/tcl)

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

Maurice LeBrun writes:
 > Alan W. Irwin writes:
 >  > If changing my mind is no problem to cvs (meaning I can always go back if
 >  > there is a storm of protest), then I think the right thing to do is to treat
 >  > these generated files the same way we do the configure script; exclude them
 >  > from cvs control but generate them for the tarball release.  This only puts
 >  > the onus on those of us here on the developer's list (and perhaps a few
 >  > more) that are building from CVS to be sure that they have perl.
 > 
 > I don't see any problem with this.  Previously, it was leaving the generated
 > files out of the public distribution that caused all the trouble.  

Well right off I hit a problem (first plplot build I've tried in a while).
There is a catch-22 with the build process: the necessary header files get
built *after* the symlinks into tmp/plplot are created, so they are not
found.  E.g. on a fresh build:

...
gcc -c  -g        -O    -I. -I/home/mjl/gts/include plimage.c
cd /home/mjl/dev/plplot/latest/bindings/tcl; \
perl pltclgen
cd /home/mjl/dev/plplot/latest/bindings/tcl; \
perl pltclgen
cd /home/mjl/dev/plplot/latest/bindings/tcl; \
perl pltclgen
gcc -c  -g        -O    -I. -I/home/mjl/gts/include tclAPI.c
tclAPI.c:35:27: plplot/tclgen.h: No such file or directory
tclAPI.c:70:29: plplot/tclgen_s.h: No such file or directory
tclAPI.c:478:20: tclgen.c: No such file or directory
make: *** [tclAPI.o] Error 1

Running configure again "solves" this problem, but a nicer solution should be
found.

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

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

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

On Sunday 13 January 2002 01:55, Alan W. Irwin wrote:
=2E..

| The release date is only 12 days away so I thought I should review
| where we stand.
=2E..

| (1) Make consistent examples for all the various front ends.  I
=2E..

| Joao, if you feel like bringing
| the "x" octave examples in line with the new extended examples (in
| those cases where they are different), try following what was done
| for x01c.c through x13c.c for now (since those are finished), and
| by the end of this week the extended x15c, x16c, and x18c should be
| ready as well.  The goal is for your postscript output to be
| equivalent to the others for each example as a test that your front
| end is doing exactly what it is supposed to.

Hi,

In the next five weeks I don't have the time for sistematic plplot=20
development; however I will be able to make small corrections and bug=20
fixes.

| (5) On Monday, 21 January, I plan to start the full test process
| (essentially complete runs of plplot-test.sh for psc, png, jpeg,
| and possibly cgm drivers) for Debian woody, limited compile farm
| Debian potato and Solaris, and possibly RedHat 7.2 (if I can get
| access at UVic).  Joao hopefully will be testing for the additional
| environments available to him at the same time.

That's fine for me.
=2E..

| (8) I will try to get an RH 7.2 rpm available at SF within a day of
| the release.  Joao had some trouble making RPM's for the
| distributions that were available to him last time, but I hope he
| tries again this time;

OK, I will try it again, but I will need independent testing=20
(suse-7.2), as my system is heavely hand-tuned.

| (9) Some (possible?) additional changes associated with plimage
| from Joao, and Olof.

Yes, but it still work in progress.

| Is there anything else?

Have you recently tested an installed plplot? I think to remember=20
that there was some problems left from java?

Joao

[Plplot-devel] Example 9 Java template finished

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

To get this actually to produce the 10 pages of the other example 9 front
ends the following still has to be done.

(1) In x09.java uncomment f2mnmx and modify this C code for java.  I didn't
know how to pass arrays and return values from a java function.  Also, in
the appropriate parts of x09.java, get rid of temporary assignments for
minimum and maximum values and uncomment f2mnmx instead (to get exact
agreement with other front ends).

(2) Add plvpas, pl_setcontlabelparam, and plcont to the Java API, and
uncomment the corresponding calls in x09.java.

Geoffrey, I am sorry there has been such a delay in getting this template
ready.  Once you complete this work, that will finish the first 13 examples
for Java which is quite an achievement.

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] Correction to commit message

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

Geoffrey, in case you were worried by my commit message (see below), I have
investigated further, and the problem with the perl script is not that bad.

There are some problems with the wrapper.  For example, I find that e.g.,

plgcol0 1

incorrectly gives wrong number of arguments message rather than simply
printing out the r, g, and b numbers the way that

plgcolbg

does.  Furthermore,

plgcol0

segfaults rather than giving you the wrong number of arguments message.

But if you give every argument, e.g.,

plgcol0 2 r g b

no segfault occurs, and r, g, and b are filled with the correct values.
Thus, I could have used plgcol0 0 r g b to get the background colours, but I
added plgcolbg to the tcl API, instead, and it works fine for my needs.

Alan


---------- Forwarded message ----------
Date: Sun, 13 Jan 2002 14:19:16 -0800
From: Alan W. Irwin <ai...@us...>
To: plp...@li...
Subject: [Plplot-cvs] CVS update notice (plplot/bindings/tcl)

Update of /cvsroot/plplot/plplot/bindings/tcl
In directory usw-pr-cvs1:/tmp/cvs-serv4152

Modified Files:
	plapi.tpl
Log Message:
Implemented plgcolbg, and it works well.

Changed plgcol0 to try and get it to work, but it segfaults regardless.
This must be a limitation of the current perl script for generating the
tcl wrapper code from this file.  plgcol0 has one input parameter and
3 returned values, and that must be confusing the perl script.



_______________________________________________
Plplot-cvs mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-cvs

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

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

The release date is only 12 days away so I thought I should review where we
stand.  I have dropped the extended gdimage colour image example for
now---there is just too much else to do.  Also for similar reasons,
Alessandro has dropped any additional pyqt GUI development until a later
time. Also, I have made a lot of progress on the examples, and the xw09.py
segfault has not come back to haunt me.

Here is what I am aware is left.  Above the line is my responsibility (unless
I make remarks about where others can help).

(1) Make consistent examples for all the various front ends.  I have made a
lot of progress on this, and I hope to find a good stopping point late this
week.  At that time I hope to have python, tcl, C, and yorick finished
(aside from example 20 which I won't do this time and examples 14, 17, and
19 which I will probably never do for various reasons.) I also hope to still
make a lot of progress on the Java examples.  Fortran, C++, and perl will
have to wait unless somebody volunteers. Joao, if you feel like bringing the
"x" octave examples in line with the new extended examples (in those cases
where they are different), try following what was done for x01c.c through
x13c.c for now (since those are finished), and by the end of this week the
extended x15c, x16c, and x18c should be ready as well.  The goal is for your
postscript output to be equivalent to the others for each example as a test
that your front end is doing exactly what it is supposed to.

(2) Get documentation to build on Debian woody.

(3) README-style documentation about what I did recently for the cgm driver
configuration. Hopefully, this will be the start of a new cookbook for the
dynamic (and static) driver configuration.

(4) README-style documentation on setting up java, python, pyqt.

(5) On Monday, 21 January, I plan to start the full test process
(essentially complete runs of plplot-test.sh for psc, png, jpeg, and
possibly cgm drivers) for Debian woody, limited compile farm Debian potato
and Solaris, and possibly RedHat 7.2 (if I can get access at UVic).  Joao
hopefully will be testing for the additional environments available to him
at the same time. If any changes are made to CVS after the tests are
completed, but before the CVS freeze time the file results from the earlier
tests will be available for quick comparisons to be sure nothing essential
was clobbered by the extra changes.

(6) Starting at the CVS freeze time of 8:00 PST (= 16:00 UT) on 24 January,
I will finish any last minute testing of changes, and all the other
mechanical stuff I do for a release to make it available at our SF release
area.  Typically, the whole process takes several hours (although no
guarantees--it could be as much as a day or so if there is a nasty bug we
are chasing down) until I give the word that you can use CVS again.

(7) After the file release is available at sourceforge (and downloaded again
to make sure it is identical with the original), I will circulate an
announcement on the plplot-general list, sourceforge, freshmeat, SAL, and
Linuxburg.

(8) I will try to get an RH 7.2 rpm available at SF within a day of the
release.  Joao had some trouble making RPM's for the distributions that were
available to him last time, but I hope he tries again this time; it greatly
expands our userbase if we can make rpm's for some of the major
distributions.  I also hope Rafael can quickly (say within a week after
release) make a Debian version of the new release for exactly the same
promotional reasons.

Everything below this line is someone else's responsibility, but I am
willing to help with testing.
****************************************

(7) Finish W98 and W2000 changes.  Olof is apparently satisfied with what
has been checked in, but he still needs to finish some README-style
documention about how to build the windows port of PLplot.

(8) Java API (Geoffrey, especially the plcont, plshade, and plshades API
that is necessary for examples 9, 15, and 16).

(9) Some (possible?) additional changes associated with plimage from Joao,
and Olof.  Just be sure to leave it in a reasonably well-working state
for the release.

(10) Maurice's changes that he has discussed previously on list.  Reviewing
his e-mail about this, they include the solution for the "plgdevlst: too
many devices" bug, a fix for some "configuration problems involving excluded
devices", and a Tk widgets resources project Maurice hoped to complete
before release.

Is there anything else?

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] Please try out xw09.py as a prototype for the rest of the front ends

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

On Fri, 11 Jan 2002, Joao Cardoso wrote:

> > I am not going to worry about this one since such comparisons work great
> > for my version of numpy (20.1, brought out in September).  This version is
> > part of Debian woody because woody hadn't gone into freeze at that point.
> > I think other distributions will also soon adopt numpy 20.1 (or even 20.2
> > which was brought out in December).
>
> Don't forget to say this in the releases notes!

Thanks for this suggestion.

> > Could you check these scripts again, please, (by running plplot-test.tcl)
> > for my newly committed changes?  Thanks in advance....
>
> They now run OK (except x09). In the "bogun density" example, no contour
> lines appear; also, it uses a gray colormap, instead of the default one.

The lack of contour lines is because xw16 is an old non-compliant example
using plshade with plcont commented out.  I plan to make xw16 compliant with
the other examples (e.g., using plshades which is a better API for continous
colours and which calls plcont internally) before the release.

I confirm the colour map problem for xw16 when running pythondemos.py. It is
due to xw08 not setting the default cmap1 colours after it does the 3d shade
plots.  It turns out that tcldemos.tcl has exactly the same cross-talk
problem (not seen before because cmap1 was not used in example 8 for python
and tcl before I recently brought those examples into compliance with the
rest).  Thanks for drawing my attention to this, and I hope to get out
"return cmap1 to default" fixes to xw08.py and x08.tcl (and similarly for
example 16) before the release.  Such fixes are not required for the other
front ends since they are only designed to be run one-at-a-time.

Alan

Re: [Plplot-devel] Please try out xw09.py as a prototype for the rest of the front ends

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

On Fri, 11 Jan 2002, Joao Cardoso wrote:

> On Friday 11 January 2002 5:17 am, Alan W. Irwin wrote:
> >  If you have further interest you could
> > download the latest versions of numpy from
> > http://sourceforge.net/projects/numpy.  Otherwise, just set clevpos =
> > clevel on your local machine
>
> Exactly where?

Click on "files" or "View all project files" in the above page.  This is the
same procedure you would use to get to our own file release area from
http://sourceforge.net/projects/plplot....;-)

Alan

Re: [Plplot-devel] Please try out xw09.py as a prototype for the rest of the front ends

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

On Friday 11 January 2002 5:17 am, Alan W. Irwin wrote:
> On Thu, 10 Jan 2002, Joao Cardoso wrote:
> > Hi,
> >
> > On Suse-7.2, with python-2.0, ./pythondemos.py, demo 9, with device x=
win
> > gives the following error after the "polar contour plot" (plot #7).
> >
> > Traceback (most recent call last):
> >   File "./pythondemos.py", line 31, in ?
> >     import xw09
> >   File "/home/jcard/plplot-devel/tmp/xw09.py", line 277, in ?
> >     main()
> >   File "/home/jcard/plplot-devel/tmp/xw09.py", line 269, in main
> >     potential()
> >   File "/home/jcard/plplot-devel/tmp/xw09.py", line 117, in potential
> >     clevelpos =3D compress(clevel > 0., clevel)
> > TypeError: Comparison of multiarray objects other than rank-0 arrays =
is
> > not implemented.
>
> I am not going to worry about this one since such comparisons work grea=
t
> for my version of numpy (20.1, brought out in September).  This version=
 is
> part of Debian woody because woody hadn't gone into freeze at that poin=
t.=20
> I think other distributions will also soon adopt numpy 20.1 (or even 20=
=2E2
> which was brought out in December).

Don't forget to say this in the releases notes!

>  If you have further interest you could
> download the latest versions of numpy from
> http://sourceforge.net/projects/numpy.  Otherwise, just set clevpos =3D
> clevel on your local machine

Exactly where?

> to get around this non-implementation in your
> version of numpy.
>
> > Also, on xw05, it fails with error
> >
> > *** PLPLOT ERROR ***
> > plcol0: Please call plinit first, aborting operation
> >
> > and lots of errors after that, ending with a seg. fault.
> >
> > xw01, xw02, xw03 and xw04 runs OK.
> > I have not tried the other examples.
>
> Thanks very much for spotting this one!  (I missed it because I did all=
 my
> recent tests with single examples.) It turned out that xw04.py (and als=
o
> x04.tcl) were terminated with plend.  As you discovered, this is not
> appropriate for multiplot examples such as pythondemos.py (and
> tcldemos.tcl).  I also had to get rid of a nameclash that I had introdu=
ced
> recently between x04.tcl and x01.tcl proc names.  All changes have now =
been
> committed, and I now get good results for pythondemos.py and tcldemos.t=
cl.
> Could you check these scripts again, please, (by running plplot-test.tc=
l)
> for my newly committed changes?  Thanks in advance....

They now run OK (except x09). In the "bogun density" example, no contour=20
lines appear; also, it uses a gray colormap, instead of the default one.

Joao

Re: [Plplot-devel] plimage

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

On Friday 11 January 2002 4:42 pm, Olof Svensson wrote:
> Joao Cardoso wrote:
> > What about "plimage" for the new function and "plimagefe" (front end)=
 for
> > the current one? Or, if compatibility with PGPLOT is not mandatory,
> > "plimages" (straight) for the new function? hum, this could be
> > misleading, Pick your own names, I'm not concerned with that.
>
> How about calling the existing function "plgridimage" and the new
> function "plimage"? You could even think of make it possible to pass
> the list of co-ordinates for the pixels (however I have no idea
> if this would be useful or not...):

Neither me.

I would be nice if all 2D plplot functions have the same interface, but o=
nly=20
   c_plmesh(PLFLT *x, PLFLT *y, PLFLT **z, PLINT nx, PLINT ny, PLINT opt)
takes this approach. Neither plcont() nor plshade() , nor PGPLOT cpgima()
   (void cpgimag(const float *a, int idim, int jdim, int i1, int i2, int =
j1,
 int j2, float a1, float a2, const float *tr)),
does, so lets keep the current definition.

> plimage(PLFLT *idata, PLINT nx, PLINT ny,
>         PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax,
>         PLFLT Dxmin, PLFLT Dxmax, PLFLT Dymin, PLFLT Dymax)
>
> plgridimage(PLFLT **idata, PLFLT *x, PLFLT *y, PLINT nx, PLINT ny,
>             PLFLT xmin, PLFLT xmax, PLFLT ymin, PLFLT ymax,
>             PLFLT Dxmin, PLFLT Dxmax, PLFLT Dymin, PLFLT Dymax)

OK, as you at sfr.fr start it, you have the right to choose :). You use=20
plimage(PLFLT *data, ...) and I will use plimage1(PLFLT **z, ...).

> > Yesterday I though that plimage() structure was steady, but today I'm=
 not
> > certain of that. It looks like that it is not possible to save a
> > displayed image in another format, opening another device and replayi=
ng
> > the plot buffer. (Using the standard plmkstrm/plcpstrm/plreplot/plend=
1
> > way of saving plots).
>
> I noticed a problem when resizing a plot with several subplots
> containing images

I have just now tried it  using the current CVS version, and detected no=20
problem...

> - Alessandro and I solved this problem by saving
> and restoring the Dxmin etc parameters in plbuf_image and rdbuf_image.

I can't see how this patch could correct it, as Dxmin etc are not anymore=
 in=20
the pls structure... you have been mixing versions.
=2E..

> Maybe the problem you site above can be solved by the same patch.

No, the solution to "my" problem is to change the block=20
   if( plsc->dev_fastimg =3D=3D 0) {
from plimage() to plP_image(), so that when replaying the plot buffer it =
will=20
be replayed to the other device, even if it is a "slow" one.
=2E..

> > But the modifications should be minor, so you can start to code your
> > modifications and send a patch.
>
> Ok, if you agree on the naming and argument scheme above I'll start mak=
ing
> a patch.

Lets wait till I move the "if( plsc->dev_fastimg =3D=3D 0) {"  block  fro=
m=20
limage() to plP_image(), OK?
I must admit that I'm not in the mood for this, but I will make a try=20
tomorrow.

Thanks,
Joao