plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Prescriptions for running tkdemos.tcl under wish and tcldemos.tcl under tclsh

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

On Sat, 12 Oct 2002, Joao Cardoso wrote:

> The tk driver does not work if PL_LIBRARY is not set to "." in the tmp build
> directory:
>
> ~/plplot/tmp> ./plserver
> (*AppInit) failed: can't read "pllibrary": no such variable
> ~/plplot/tmp> export PL_LIBRARY=.
> ~/plplot/tmp> ./plserver
> OK

I confirm this, but only in the case when plplot is not installed.  Thus, I
guess plserver is always attempting to access the installed version of the
library rather than the plplot/tmp one.

Perhaps this is the right way to do things?  I am beginning to think that
all these plplot/tmp issues are nothing but a maintenance headache, and we
would be better off just supporting the installed version alone.  (Of
course, if anybody likes they can execute the plplot/tmp version if they set
the appropriate environment variables as Joao just demonstrated.)

Long ago when Rafael was working with his branch for automake/libtool PLplot
configuration he came to a similar conclusion that it wasn't worth
supporting special executables for plplot/tmp.  I certainly objected then,
but I am older and wiser, now....;-)

Alan

P.S. as part of my tests for this I tried out Joao's new ./x08c -rosen.
Definitely cool!

Alan

Re: [Plplot-devel] Prescriptions for running tkdemos.tcl under wish and tcldemos.tcl under tclsh

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

On Thursday 26 September 2002 15:50, Alan W. Irwin wrote:
> On Wed, 25 Sep 2002, Maurice LeBrun wrote:
=2E..
> (2) As reported yesterday, I could not get tcldemos.tcl to work under t=
clsh
> without setting PL_LIBRARY to /usr/local/plplot/lib/plplot5.1.0/tcl.  I
> presume this is also a requirement for running tkdemos.tcl under wish
> and runAllDemos.tcl under wish.  But should it be?  Under tclsh and
> wish I already execute
>
> lappend auto_path /usr/local/plplot/lib/plplot5.1.0
>
> Thus, shouldn't we be able to find the location of everything internall=
y by
> scanning through the directories in auto_path?  We have been through so
> many variations of the tcl/tk install that I cannot remember clearly an=
y
> more, but I believe there were some variations on the theme that did no=
t
> require setting PL_LIBRARY, and I hope we can get back to that.

The tk driver does not work if PL_LIBRARY is not set to "." in the tmp bu=
ild=20
directory:

~/plplot/tmp> ./plserver=20
(*AppInit) failed: can't read "pllibrary": no such variable
~/plplot/tmp> export PL_LIBRARY=3D.
~/plplot/tmp> ./plserver=20
OK

Joao

Re: [Plplot-devel] 3D plots enhancements commited to HEAD.

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

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

> Finally I would like to merge two API entries, but have not done it
> until we discuss the matter.
> The API in question are plotfc3d() and plotsh3d(). As they are almost
> identical, only the way of coloring the surface is different, I think
> that is makes sense to merge both.
> plotfc3d() is so recent that nobody else other than us has ever seen it,
> so any change will make no harm to users. plotsh3d() is older, but as
> it was buggy I don't think that changing it will make any difference to
> users.
> So, what I propose is just to remove both API entries and create a new
> one, plsurf3d() that will have the capabilities of the old functions
> managed with the "opt" argument: if LIGHT_SHADE, than plotsh3d() will
> be handled, else if MAG_SHADE (or LIGHT_SHADE not defined) plotfc3d()
> will be handled.
> What do you think of this?

I agree with Joao's argument about not affecting our users that much so I
think he should go ahead.  However, it is going to be a while before I can
adjust the tcl, python, and java interfaces (and examples 8) to the new API
and also document the new API in doc/docbook/src so I hope Joao will do as
much of that work as possible.  I assume Joao will be handling the octave
interface and example 8 changes as well.

That leads me to a different but related topic.

Do we have a volunteer for supporting the fortran interface?  We have just
received the news that our fortran interface is getting special promotion b=
y
a fortran compiler company.  Fundamentally, I think that is great, but
unfortunatly our fortran interface is falling behind our other interfaces i=
n
terms of support of the common API, and the fortran examples need a lot of
work to bring them into consistency with the other examples (which is an
excellent test that the interface is actually working correctly and has at
least an important subset of the common API implemented.)

Now that I have reminded myself of the fortran interface problems, I will
put its maintenance in the minor, "would be nice" category in PROBLEMS.  I
classify it "minor" because although the whole project is a fair amount of
work it is actually the sum of a lot of little projects (one API or one
example at a time) that can be handled independently of each other by
multiple volunteers (hint, hint).

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
__________________________

[Plplot-devel] 3D plots enhancements commited to HEAD.

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

Hi,

I have just now committed some enhancements to 3d plots, including=20
changes to x08c.c to show the new features.

In plot3d() the "opt" argument now accepts another option, MAG_COLOR,=20
that colors the grid with a color dependent of the function magnitude.

In plotfc3d() the "side" argument is now called "opt", that accepts
 *  SURF_CONT -- draw contour at surface
 *  SURF_BASE -- draw contour at bottom xy plane
 *  DRAW_SIDE -- draw sides (this one is currently disabled, as is ugly)
 there are also two new arguments, clevel and nlevel, to specify the=20
levels of the contours.
The surface contour lines are not very good, as they are merely straight=20
lines drawn on the intersection of the contour plane with each triangle=20
that makes up the surface. The contour lines drawn at the xy plane are=20
derived from the ones drawn from plcont(), and are quite good.

x08c, besides showing the new features, has also a new function, the log=20
of the Rosenbrock function (know by optimization people). It can be=20
invoked with the command line option "-rosen". It is nicer than the=20
sombrero like default function plotted by x08c, and has the nice=20
feature of not being symmetric.

I have also changed plconf() and associated functions, and added a new=20
function cont_store(),  in order to enable  plconf()  to plot the=20
contour lines to memory. You can see an example of its usage in=20
plotfc3d().

Finally I would like to merge two API entries, but have not done it=20
until we discuss the matter.
The API in question are plotfc3d() and plotsh3d(). As they are almost=20
identical, only the way of coloring the surface is different, I think=20
that is makes sense to merge both.
plotfc3d() is so recent that nobody else other than us has ever seen it,=20
so any change will make no harm to users. plotsh3d() is older, but as=20
it was buggy I don't think that changing it will make any difference to=20
users.
So, what I propose is just to remove both API entries and create a new=20
one, plsurf3d() that will have the capabilities of the old functions=20
managed with the "opt" argument: if LIGHT_SHADE, than plotsh3d() will=20
be handled, else if MAG_SHADE (or LIGHT_SHADE not defined) plotfc3d()=20
will be handled.
What do you think of this?

Joao

Re: [Plplot-devel] cvs tag enhance_3d

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

On Friday 04 October 2002 20:20, Jo=E3o Cardoso wrote:
| On Friday 04 October 2002 19:40, Jo=E3o Cardoso wrote:

Please forget all this subject. I have the final version ready and I=20
will commit it to HEAD after some discussion I want to have in the=20
mailling list.

Sorry for all this,
Joao

| | Hi,
| |
| | I have just now created a cvs tag "enhance_3d" for some files I'm
| | working on (for weekend work...). But it looks like that something
| | went wrong, as I also intended to create a branch, and it did not
| | get created...?
| |
| | I used
| |
| | cvs tag -b enhance_3dplots 'src/plcont.c' 'src/plot3d.c'
| | 'include/plplot.h' 'examples/c/x08c.c' 'bindings/tcl/tclAPI.c'
| |
| | and after that
| |
| | cvs commit -l -m 'Add "kind of" contouring to plot3d.c:plotfc3d().
| | Add magnitude coloring to plot3d.c:plot3d().
| | Retrieve contours from plcont.c:pldrawcn().
| | Add "rosenbrock" alternative function to x08c.c; use "x08c -rosen"
| | to experiment.
| | Comment plotfc3d() support in tclAPI.c for now.' 'src/plcont.c'
| | 'src/plot3d.c' 'include/plplot.h' 'examples/c/x08c.c'
| | 'bindings/tcl/tclAPI.c'
|
| I now understand that I made two errors:
|
| 1-I have only tagged a few files, instead of the whole tree.
| 2-I have not update to the branch (cvs update -r enhance_3dplots)
| before committing.
|
| I thing that there is no cure for this. At least the "cvs book" does
| not address this issue. Unless one can remove my last commit from the
| repository, and after that I would commit it again in the right
| branch. But as I said, this is a temporary situation, until I polish
| the modifications. But I will not commit anything else until I get
| some feedback.
|
| Joao
|
| | Well, no real harm happened, but if someone can fix it :-)
| |
| | Nevertheless, the modifications are working, you can try them --
| | they look beautiful. Try the x08c demo with the new -rosen option.
| |
| | Joao
| |
| |
| | -------------------------------------------------------
| | This sf.net email is sponsored by:ThinkGeek
| | Welcome to geek heaven.
| | http://thinkgeek.com/sf
| | _______________________________________________
| | Plplot-devel mailing list
| | Plp...@li...
| | https://lists.sourceforge.net/lists/listinfo/plplot-devel
|
| -------------------------------------------------------
| This sf.net email is sponsored by:ThinkGeek
| Welcome to geek heaven.
| http://thinkgeek.com/sf
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] cvs tag enhance_3d

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

On Friday 04 October 2002 19:40, Jo=E3o Cardoso wrote:
| Hi,
|
| I have just now created a cvs tag "enhance_3d" for some files I'm
| working on (for weekend work...). But it looks like that something
| went wrong, as I also intended to create a branch, and it did not get
| created...?
|
| I used
|
| cvs tag -b enhance_3dplots 'src/plcont.c' 'src/plot3d.c'
| 'include/plplot.h' 'examples/c/x08c.c' 'bindings/tcl/tclAPI.c'
|
| and after that
|
| cvs commit -l -m 'Add "kind of" contouring to plot3d.c:plotfc3d().
| Add magnitude coloring to plot3d.c:plot3d().
| Retrieve contours from plcont.c:pldrawcn().
| Add "rosenbrock" alternative function to x08c.c; use "x08c -rosen" to
| experiment.
| Comment plotfc3d() support in tclAPI.c for now.' 'src/plcont.c'
| 'src/plot3d.c' 'include/plplot.h' 'examples/c/x08c.c'
| 'bindings/tcl/tclAPI.c'

I now understand that I made two errors:

1-I have only tagged a few files, instead of the whole tree.
2-I have not update to the branch (cvs update -r enhance_3dplots) before=20
committing.

I thing that there is no cure for this. At least the "cvs book" does not=20
address this issue. Unless one can remove my last commit from the=20
repository, and after that I would commit it again in the right branch.
But as I said, this is a temporary situation, until I polish the=20
modifications. But I will not commit anything else until I get some=20
feedback.

Joao

| Well, no real harm happened, but if someone can fix it :-)
|
| Nevertheless, the modifications are working, you can try them -- they
| look beautiful. Try the x08c demo with the new -rosen option.
|
| Joao
|
|
| -------------------------------------------------------
| This sf.net email is sponsored by:ThinkGeek
| Welcome to geek heaven.
| http://thinkgeek.com/sf
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] cvs tag enhance_3d

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

Hi,

I have just now created a cvs tag "enhance_3d" for some files I'm=20
working on (for weekend work...). But it looks like that something went=20
wrong, as I also intended to create a branch, and it did not get=20
created...?

I used=20

cvs tag -b enhance_3dplots 'src/plcont.c' 'src/plot3d.c'=20
'include/plplot.h' 'examples/c/x08c.c' 'bindings/tcl/tclAPI.c'

and after that

cvs commit -l -m 'Add "kind of" contouring to plot3d.c:plotfc3d().
Add magnitude coloring to plot3d.c:plot3d().
Retrieve contours from plcont.c:pldrawcn().
Add "rosenbrock" alternative function to x08c.c; use "x08c -rosen" to=20
experiment.
Comment plotfc3d() support in tclAPI.c for now.' 'src/plcont.c'=20
'src/plot3d.c' 'include/plplot.h' 'examples/c/x08c.c'=20
'bindings/tcl/tclAPI.c'=20

Well, no real harm happened, but if someone can fix it :-)

Nevertheless, the modifications are working, you can try them -- they=20
look beautiful. Try the x08c demo with the new -rosen option.

Joao

Re: [Plplot-devel] CVS problems

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

On Fri, 4 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> I often get the following error message when I make a recursive cvs
> update:
> [...]
> What is wrong? Me? The cvs repository?
>
> I would appreciate any hints.

I have never encountered those problems so I think the repository is fine.

One possibility is your local directories have some sticky information in
them (tags, dates) that are screwing you up.  The way to get rid of that is

cvs update -A

Another thing I can suggest is to start clean again.  One brute-force way t=
o
do this is

cvs checkout -d plplot_new plplot

where plplot_new is the *new* directory where you want to store your
clean start.

Hope one of these two suggestions will permanently solve your problem.

Alan

[Plplot-devel] CVS problems

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

Hi,

I often get the following error message when I make a recursive cvs=20
update:

[jcard@feup] pwd
/home/jcard/plplot-devel

[jcard@feup] cvs update -R -d -P '.'
=2E..
cvs update: in directory tmp:
cvs update: cannot open CVS/Entries for reading: No such file or=20
directory
cvs server: Updating tmp
cvs update: move away tmp/.cvsignore; it is in the way
C tmp/.cvsignore
cvs update: move away tmp/.dummy; it is in the way
C tmp/.dummy
cvs server: Updating utils
=2E..

[jcard@feup] pwd
/home/jcard/plplot-devel/tmp

[jcard@feup] ls -l CVS/
total 12
-rw-r--r--    1 jcard    users          84 Oct  4 15:19 Entries
-rw-r--r--    1 jcard    users          11 Mar 15  2001 Repository
-rw-r--r--    1 jcard    users          54 Mar 15  2001 Root

[jcard@feup] cvs status .dummy=20
=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=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=3D=3D=3D=3D=3D

File: .dummy            Status: Needs Checkout

   Working revision:    No entry for .dummy
   Repository revision: 1.1     /cvsroot/plplot/plplot/tmp/.dummy,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

[jcard@feup] cvs status .cvsignore=20
=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=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=3D=3D=3D=3D=3D
File: .cvsignore        Status: Needs Checkout

   Working revision:    No entry for .cvsignore
   Repository revision: 1.1     /cvsroot/plplot/plplot/tmp/.cvsignore,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

What is wrong? Me? The cvs repository?

I would appreciate any hints,
Joao

Re: [Plplot-devel] Prescriptions for running tkdemos.tcl under wish and tcldemos.tcl under tclsh

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

On Fri, 4 Oct 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > it would be nice to remove this limitation of requiring the PATH to be set
>  > for -dev tk.
>
> I got time to look into this, and I positively do not see the problem.
>
> In the tk driver, the plserver is exec'ed as follows:
>         plserver_exec = plFindCommand(pls->plserver);
>
> while plFindCommand() (in plctrl.c) searches for plserver under many different
> locations.  Including the install dir (BIN_DIR) and ".".  I put in some
> printf's to see which version it was getting, and then commented out various
> parts, and it always got the right one.  So I'm stumped.. AFAICT it's working
> fine.

It's fine now here too.  I think there has been a communications glitch so
let me clarify.

I have forgotten the exact data I mentioned this issue, but it was a while
ago, and as best I recall you came back with a change almost immediately
which solved this and all other problems I mentioned in that post.  I said
something like "everything now works" to the list at that point, but I should
have been a lot more specific or highlighted it more.

From your description now, I think searching just was not working properly
at the time for my situation (plplot and tcl installed in different prefixes)
so once you fixed searching every issue on my list (including the -dev tk
thing) was solved.

I hope from now on we can deal with such issues by putting them into (and
taking them out of when solved) the plplot/PROBLEMS file. Because the -dev
tk issue was solved before I created PROBLEMS, it was not put in there.
However, in preparation for the current post I have double-checked
everything in PROBLEMS relating to Tcl/tk, and I discovered that the
problems I was having with the cmap1 manipulation GUI under plframe have
mysteriously disappeared. I say mysteriously because I was quite careful to
test that just before I posted PROBLEMS the first time.  I may be wrong, but
I don't think anything has been changed since. Anyhow, it is well worth
keeping an eye on the colour manipulation GUI's for a while for all
situations.  However, I can no longer replicate it so I removed it from
PROBLEMS. I also just double-checked the other tcl/tk problems mentioned in
that file, and I still confirm the first page-skipping problem for x08.tcl
(if "8" [or any other multipage example] is executed first right after
source tkdemos.tcl) and the documented problems with tk02 and tk04. If you
have trouble confirming those problems, I can put a lot more detail about
them in the PROBLEMS file.

Alan

Re: [Plplot-devel] Prescriptions for running tkdemos.tcl under wish and tcldemos.tcl under tclsh

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

Alan W. Irwin writes:
 > Here are some current limitations of the tcl/tk PLplot install I would like
 > to see removed in the long term.
 > 
 > (1) Must have /usr/local/plplot/bin in PATH in order for -dev tk to work. tk
 > is the only device with this requirement.  As I understand it, this
 > requirement is needed because the tk device starts its own instance of
 > plserver, and it needs to be able to find it.  Doesn't the PLplot library
 > already know where everything is (for both the plplot/tmp location and
 > installed location) so it could find plserver without having to rely on the
 > PATH?  Obviously you need the PATH set if you are doing lots of plrendering
 > or plserving.  But there are many cases of using PLplot where you just
 > simply want to use -dev tk with, e.g, the python examples or C examples so
 > it would be nice to remove this limitation of requiring the PATH to be set
 > for -dev tk.

I got time to look into this, and I positively do not see the problem.

In the tk driver, the plserver is exec'ed as follows:
        plserver_exec = plFindCommand(pls->plserver); 

while plFindCommand() (in plctrl.c) searches for plserver under many different
locations.  Including the install dir (BIN_DIR) and ".".  I put in some
printf's to see which version it was getting, and then commented out various
parts, and it always got the right one.  So I'm stumped.. AFAICT it's working
fine.

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

Re: [Plplot-devel] Thoughts from the release guy

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

Maurice LeBrun writes:
 > Alan W. Irwin writes:
 >  > (5) There is still one issue holding back Olof et al from moving to our
 >  > supported python interface for their pyqt GUI work. They require two output
 >  > devices (one for the GUI and one to store results more permanently).  I just
 >  > checked that this was possible with -dev tk.  I haven't looked at the
 >  > plframe code that implements this functionality, but I speculate separate
 >  > devices are opened for two different streams. I have classified this one as
 >  > "Major, would be nice", but in fact a simple solution following what is done
 >  > for -dev tk might be possible in which case this should be reclassified as
 >  > minor, "would be nice"
 > 
 > I assume you're referring to "the normal plmkstrm/plcpstrm/plreplot/plend1 way
 > of saving plots".  Is this kind of stream duplication via API sufficient for
 > their needs?  
 > 
 > Because otherwise one could clone a stream at the driver interface layer,
 > directing it somewhere else (e.g. a file).  I thought about putting in
 > something like this years ago but didn't have a real need for it so it never
 > materialized.  

After rereading this, I thought this might have been a bit too obscure.

The way of saving the current plot mentioned in my first paragraph is atomic,
one that you use at the end of a page i.e. "save this page".  So it arose in
association with the extended plframe for its "save" or "print" commands.
It has several problems:
 - only done at end of page
 - API or GUI driven -- not automatic
 - how to deal with end of page -- new file or same file?

The cloned stream approach would associate one stream with another, such that
every driver interface call to the original stream would go to the cloned
stream as well.  The appeal of this approach is that it would be virtually
continuous, automatic, and you'd have all the standard plplot calls on the
cloned stream.  It'd also be easy (and fun) to test with the interactive
drivers -- you'd just get multiple windows up on the screen, all displaying
(theoretically) the same thing.

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

Re: [Plplot-devel] Thoughts from the release guy

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

Alan W. Irwin writes:
 > (1) The major release issue is to get the library linking in good shape
 > cross-platform.  ...

Agreed, 100%.  I don't think the release is going anywhere without the linkage
problems resolved.  Jan for the release is doable, I think we may really need
all that time tho.  I for one have yet to get my main production code even
working with the new plplot under Linux, not to mention the other systems I
need to support.  I'll put in work on it when I can, although there's features
work I'd rather be doing.. :/

 > (5) There is still one issue holding back Olof et al from moving to our
 > supported python interface for their pyqt GUI work. They require two output
 > devices (one for the GUI and one to store results more permanently).  I just
 > checked that this was possible with -dev tk.  I haven't looked at the
 > plframe code that implements this functionality, but I speculate separate
 > devices are opened for two different streams. I have classified this one as
 > "Major, would be nice", but in fact a simple solution following what is done
 > for -dev tk might be possible in which case this should be reclassified as
 > minor, "would be nice"

I assume you're referring to "the normal plmkstrm/plcpstrm/plreplot/plend1 way
of saving plots".  Is this kind of stream duplication via API sufficient for
their needs?  

Because otherwise one could clone a stream at the driver interface layer,
directing it somewhere else (e.g. a file).  I thought about putting in
something like this years ago but didn't have a real need for it so it never
materialized.  

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

[Plplot-devel] forwarded message from Dave Nystrom

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

Hmmm.  Looks like /somebody/ is taking the Fortran binding seriously... 

Re: [Plplot-devel] Thoughts from the release guy

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

On Wednesday 02 October 2002 15:35, Alan W. Irwin wrote:
| On Wed, 2 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
| > shouldnt "introduce or complete new features" go to NEWS instead of
| > PROBLEMS?
|
| Probably a better name for the file is CVS-STATUS.  Feel free to
| change the name to that if you like, but I thought PROBLEMS was a
| good enough fit because the items concern bugs or missing features.
|
| Also my phrasing that you quoted above was unclear.  Sorry, let me
| try again with how I think PROBLEMS and NEWS should be used.
|
| Bugs go in PROBLEMS, and if you are actively working on a missing
| feature you should mention it in PROBLEMS as well. If you fix the bug
| or implement the feature then remove the item from PROBLEMS. If that
| success is newsworthy enough report your success in NEWS.
|
| Alan

OK.

For me, that as an user often compile from sources, having a NEWS file=20
is helpfull, to see if it is worth to compile/install a new release;=20
also the BUGS is helpfull, to see if a known bug has been solved. From=20
this perspective, the entries in BUGS that are solved should be marked=20
as solved, and not deleted. But I now understand that your intention=20
was only to maintain PROBLEMS as a CVS-STATUS.

Joao

Re: [Plplot-devel] Thoughts from the release guy

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

On Wed, 2 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
> shouldnt "introduce or complete new features" go to NEWS instead of
> PROBLEMS?

Probably a better name for the file is CVS-STATUS.  Feel free to change the
name to that if you like, but I thought PROBLEMS was a good enough fit
because the items concern bugs or missing features.

Also my phrasing that you quoted above was unclear.  Sorry, let me try agai=
n
with how I think PROBLEMS and NEWS should be used.

Bugs go in PROBLEMS, and if you are actively working on a missing feature
you should mention it in PROBLEMS as well. If you fix the bug or implement
the feature then remove the item from PROBLEMS. If that success is
newsworthy enough report your success in NEWS.

Alan

Re: [Plplot-devel] Thoughts from the release guy

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

On Wednesday 02 October 2002 02:37, Alan W. Irwin wrote:
| On Tue, 1 Oct 2002, Maurice LeBrun wrote:
| > Alan W. Irwin writes:
| >  > Here is a question for all development team members: Should I
| >  > put my 4 lists in the plplot/PROBLEMS file under CVS control?=20
| >  > The current PROBLEMS file refers to problems that existed in the
| >  > 1995 (!) version. AFAIK, none of the mentioned problems exist
| >  > any more.
| >
| > Please do.
|
| Since Joao and Maurice have been so supportive of this, I did it.
|
| Please update PROBLEMS often as you find new bugs, solve old bugs, or
| introduce or complete new features.

shouldnt "introduce or complete new features" go to NEWS instead of=20
PROBLEMS?

Joao

Re: [Plplot-devel] Thoughts from the release guy

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

On Tue, 1 Oct 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > Here is a question for all development team members: Should I put my 4 lists
>  > in the plplot/PROBLEMS file under CVS control?  The current PROBLEMS file
>  > refers to problems that existed in the 1995 (!) version. AFAIK, none of the
>  > mentioned problems exist any more.
>
> Please do.

Since Joao and Maurice have been so supportive of this, I did it.

Please update PROBLEMS often as you find new bugs, solve old bugs, or
introduce or complete new features.

Alan

Re: [Plplot-devel] Thoughts from the release guy

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

Alan W. Irwin writes:
 > Here is a question for all development team members: Should I put my 4 lists
 > in the plplot/PROBLEMS file under CVS control?  The current PROBLEMS file
 > refers to problems that existed in the 1995 (!) version. AFAIK, none of the
 > mentioned problems exist any more.

Please do.

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

Re: [Plplot-devel] Have Geoffrey's fidelity concerns been addressed?

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

Alan W. Irwin writes:
 > Geoffrey, I haven't yet had a chance to test Maurice's recent character
 > precision improvements to see whether they improve the cross-platform
 > reproducibility of the PLplot examples.  However, I am hoping for a
 > substantial improvement.  Also, I am wondering if his changes have had an
 > impact on the fidelity problems you were having before with illegible
 > characters (IIRC) in a zoomed environment?

I don't think it has an impact.  But other changes I have in the works should
help.

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

Re: [Plplot-devel] Thoughts from the release guy

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

On Tuesday 01 October 2002 18:33, Alan W. Irwin wrote:
=2E..
| Here is a question for all development team members: Should I put my
| 4 lists in the plplot/PROBLEMS file under CVS control?  The current
| PROBLEMS file refers to problems that existed in the 1995 (!)
| version. AFAIK, none of the mentioned problems exist any more.
|
| Alan

YES! All reported and confirmed bugs and problems. Then, at release=20
time, its easy to check for them, clearing the solved ones, adding new=20
ones, etc.

Joao

Re: [Plplot-devel] Thoughts from the release guy

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

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

> [...] current plans of adding
> contour lines to plotfc3d() [...]

I hope that effort is successful since I could certainly use that capabilit=
y
in my own research plots.  I will put this as a "would be nice" on the list=
=2E

> ...
>
> | (5) Joao had trouble with cursors in example 1 for SuSe, Maurice does
> | not with RH 7.3.  I think I may have the problem (blue cross-hairs
> | appear, but no numbers seem to be typed when you click).  How do you
> | generate the error, and what are the exact symptoms, again, Joao, and
> | have you found a fix?
>
> I guess the problem was some incomplete rpm updates in my system. The
> reported problem has gone without code changes.

That's great.  I will change the list accordingly.

Here is a question for all development team members: Should I put my 4 list=
s
in the plplot/PROBLEMS file under CVS control?  The current PROBLEMS file
refers to problems that existed in the 1995 (!) version. AFAIK, none of the
mentioned problems exist any more.

Alan

Re: [Plplot-devel] Thoughts from the release guy

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

On Monday 30 September 2002 22:03, Alan W. Irwin wrote:
| Whenever we make enough significant changes in PLplot (and the
| current CVS HEAD definitely qualifies on that score in my opinion),
| then I start thinking about the timing for the next release date.
=2E..
| Major, essential
|
| (1) The major release issue is to get the library linking in good
| shape cross-platform.  So if anybody wants to tackle any of the
| remaining problems (rationalizing the libraries some more, static
| drivers on Linux, static libraries on Linux, plus generalization of
| the Linux solution to cross-platform) that would be great.=20
| Unfortunately, just in the wrong time frame from the PLplot
| perspective my research collaborations have gotten much more intense
| over the last month or so with other people waiting for me to finish
| joint papers so it will be at least November before I can take on a
| large project like the remaining library linking stuff.  But I am
| determined to finish it eventually if nobody else gets it done first.

I start playing with this, but stopped. If my current plans of adding=20
contour lines to plotfc3d() fails, I might restart the attempt.=20
=2E..

| (5) Joao had trouble with cursors in example 1 for SuSe, Maurice does
| not with RH 7.3.  I think I may have the problem (blue cross-hairs
| appear, but no numbers seem to be typed when you click).  How do you
| generate the error, and what are the exact symptoms, again, Joao, and
| have you found a fix?

I guess the problem was some incomplete rpm updates in my system. The=20
reported problem has gone without code changes.

Joao

[Plplot-devel] Thoughts from the release guy

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

Whenever we make enough significant changes in PLplot (and the current CVS
HEAD definitely qualifies on that score in my opinion), then I start
thinking about the timing for the next release date.

After reviewing what still needs to be done to stabilize/generalize the
current changes, I think we are looking at a release date in January at the
earliest.  I hasten to add that date is not chiseled in stone, and our group
is small enough so we have always had a flexible and informal release system
(a good thing IMHO). Nevertheless, I hope you keep that tentative date in
mind as a motivator to get your changes and bug fixes into PLplot in the
next few months.

I now give you four lists of the combinations of major, minor, essential,
and "would be nice" issues that I feel should be addressed.  Feel free to
add your favorite issues or your suggestions for changing categories.  Also
feel free to take on the ones I haven't put my name on (in fact take on the
ones I have put my name on as well....;-))

The essential two reasons for bringing these lists of issues to your
attention is (1) to help set priorities and (2) to ask for your help in
solving the issues. In particular, help with the major, essential release
issue of generalizing the Linux library linking scheme would be great, but
if you only have a few hours to spare at a time, working on one of the
several minor issues would be good as well.

Major, essential

(1) The major release issue is to get the library linking in good shape
cross-platform.  So if anybody wants to tackle any of the remaining problems
(rationalizing the libraries some more, static drivers on Linux, static
libraries on Linux, plus generalization of the Linux solution to
cross-platform) that would be great.  Unfortunately, just in the wrong time
frame from the PLplot perspective my research collaborations have gotten
much more intense over the last month or so with other people waiting for me
to finish joint papers so it will be at least November before I can take on
a large project like the remaining library linking stuff.  But I am
determined to finish it eventually if nobody else gets it done first.

Major, "would be nice"

(1) I understand Maurice plans to finish his changes to implement
handling strings as strings in the metafile format.

(2) Geoffrey plans to at least evaluate remaining fidelity problems.

(3) I also hope Geoffrey gets a chance in the next few months (once he gets
a break from his current work pressure) to at least look at plframe and the
python/Tkinter front end.

(4) Parallelogram problem for rotation which is not multiple of 90 deg. This
is on the major list because Maurice doesn't think it will be simple to sort
this out. Once this problem is sorted out, it should be possible to deal
with the remaining rotation problems for the font handling, but I don't
think it will be worth tackling those issues before the parallelogram core
problem is straightened out.

(5) There is still one issue holding back Olof et al from moving to our
supported python interface for their pyqt GUI work. They require two output
devices (one for the GUI and one to store results more permanently).  I just
checked that this was possible with -dev tk.  I haven't looked at the
plframe code that implements this functionality, but I speculate separate
devices are opened for two different streams. I have classified this one as
"Major, would be nice", but in fact a simple solution following what is done
for -dev tk might be possible in which case this should be reclassified as
minor, "would be nice"

Minor, essential.

(1) Some documentation backlog has built up which I would like to deal with
before release.

(2) If x08.tcl (or any other multi-page example) is executed first, then the
first page is skipped.

(3) tk cmap1 palette maniupulations no longer work.

(4) ./xtk02 -f tk02
invalid command name "Pltkwin"
    while executing
"Pltkwin .plw"
    (file "tk02" line 48)
    invoked from within
"source tk02"

and similarly for tk04.

(5) Joao had trouble with cursors in example 1 for SuSe, Maurice does not
with RH 7.3.  I think I may have the problem (blue cross-hairs appear, but
no numbers seem to be typed when you click).  How do you generate the error,
and what are the exact symptoms, again, Joao, and have you found a fix?

(6) Permissions problem with generated plplot-config and plplot-test.sh in
plplot/tmp.  I don't know the proper autoconf method of fixing this.

(7) bindings/tk/plcolor.tcl has execute permissions that should be removed.
examples/tcl/stats.log should be made world-readable.  Both these permission
problems need access to the CVS repository to fix.

Minor, "would be nice"

(1) I plan to try to adjust our python interface from swig-1.3.1[1-3] to
swig-2.0 if that is released before the PLplot release.

(2) I have documented on this list many minor memory leaks found by valgrind
throughout the dynloader area which should be cleaned up.

(3) Finish Java API or else completely reimplement it with swig (which might
be a much faster way of solving the problem).

(4) debian subdirectory made part of HEAD so can build debs directly
from HEAD.

(5) fortran, C++, and octave "x" examples made consistent with the C, tcl,
Java, and python examples as a test that the various front ends produce the
same results.

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: Have Geoffrey's fidelity concerns been addressed?

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

Alan W. Irwin writes:
 > Geoffrey, I haven't yet had a chance to test Maurice's recent character
 > precision improvements to see whether they improve the cross-platform
 > reproducibility of the PLplot examples.  However, I am hoping for a
 > substantial improvement.  Also, I am wondering if his changes have had an
 > impact on the fidelity problems you were having before with illegible
 > characters (IIRC) in a zoomed environment?

Sorry, I've been tuned out a little lately, due to "work/life continuation
syndrome"  In other words, if I was either unemployed, or dead, I'd probably
be a lot more involved in PLplot right now..

I have some extant changes that I was hoping to whip into suitable shape and
check in, but got distracted from finishing that.

My last major PLplot activity was to "discover"  that PLplot head was giving
me total fits with plframe.  At first I assumed it was some breakage on
PLPLot's cvs head, but I wasn't caught up on my email reading to know whether
I shoould report it, or just update.  However, in subsequent ruminations,
I've realized that the dev tree which saw the problem, happened also to be
one in which I was trying out all the newest tcl/tk/itcl releases,
significantly including some new iwidgets code, and now I'm wondering if
there were changes in the bindings in late model Tk or Itk, which perchance,
have screwed up PLXWin or plframe, or something.

Anyway, I'll try to take a gander at the new character stuff soon.  For sure,
my current plots (with an old PLplot checkout) show some bad distortion at
high magnification.

-- 
Geoffrey Furnish         Lightspeed Semiconductor Corp
voice: 512-328-7362           4611 Bee Cave Road
fax:   no fax here           Austin, Texas   78733