plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] State of the Union

[Rafael L. <lab...@mp...>]

Geoffrey,

Thanks a lot for this impressive proposal.  It is gigantic and I confess
that I just skimmed through it (BTW, are you just a single person, or a
collection of individuals responding to the name of "Geoff Furnish"? :-)

I share your opinion about the lack of documents summarizing our discussions
and ideas and find the PIP idea very appealing.  I took a look at the Python
PEP system (http://python.sourceforge.net/peps) and vote for adopting it for
the PIPs.  The PEP format is quite simple and well documented, and the
scripts for htmlizing the source files are available. Let us avoid
reinventing the wheel.  Let us suck it from elsewhere.

As regards location for PIPs in the CVS tree, a better place would be under
$CVSROOT/pip/ and not $CVSROOT/plplot/pip, as you suggested.  This would
have the benefit of avoiding the branch & tag problems in the source tree.

I find this PIP idea particularly interesting because I was envisaging to do
something similar for the AM/LT project.  The work on that branch has been
stalled for a while and I simply forgot its present state (BTW, the same
must be said about the gnome driver, the Debian packages and the Perl
bindings...)

So here is the immediate roadmap: convert your previous post into the PEP
format and give it the title "Index of PLplot Improvement Proposals (PIPs)";
call it PIP #0 and cvs commit to $CVSROOT/pip/pip-0000.txt; rip out the
scraps of text for each proposed project and put them in separate files
pip-xxxx.txt; set up a rudimentary home page under
http://plplot.sf.net/devel to host the PIPs; setup the automatic htmlization
(seems to be as simple as "$ python pep2html.py -i NUM").  [An aside note:
in the PLplot-Docbook project, we use scripts for updating the web site,
although they are not generated automatically (by cron jobs, say).]

These hacks should last a couple of hours.  Having this proof of concept
working would be great.

-- 
Rafael

Re: [Plplot-devel] PLplot statistics

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

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

> On Thursday 07 February 2002 22:30, Alan W. Irwin wrote:
> [...] Those who use
> | a prefix of /usr for tarball installs or a /usr/local prefix for
> | rpm or deb installs get what they deserve....;-)
>
> Like me, when I made an automatic upgrade in my linux box, just to
> find that (of course) the upgrade had upgraded just the distro
> packages, not the manually installed rpm ones? And then searching for
> all them... it would be much easier if they were in /usr/local -- or
> if I had a separate rpm database just for them.

The way I used to organize this when I used rpm extensively was I would cop=
y
all the downloaded package files (e.g., plplot....rpm) to certain
directories. The contents of those directories would remind me what had to
be updated in the future.  Also, when actually building binary rpm's from
src rpm's the resulting binary rpm's are naturally placed in the RPMS/i?86
directory and the src rpm into SRPMS.

Under Debian I also do something similar to keep track of what has been
downloaded or built outside the official distribution.

>
> But I don't see the point in installing rpms under /usr -- there must
> exist some reasoning behind that?

It's traditional. Maybe its even in the LSB by now, but violate that
tradition at your peril.

>
> I have yet another rpm question. With dyndrivers, we can make rpm
> with all available drivers, without having to worry if the user
> system has the necessary libs or not! Of course the user will not be
> able to use those drivers, but it will not hurt, and if the user
> latter install the extra packages the drivers will be there. Correct?

Didn't we just go through this exercise to prove the libraries had to be
there (i.e., mentioned specifically for the link command) for the dynamic
driver builds?

Anyhow, when building from a src rpm we use the ordinary configure script
just like when building from a tarball or cvs. (And I am sure Rafael would
answer the same for the deb package build.) Our current configuration check=
s
for certain libraries and headers on the build machine.  If libcd is not
there it doesn't build the cgm driver.  If libgd isn't there, it doesn't
build the gd driver with png and jpeg devices.  This is uniform across src
rpm, (presumably) src deb, tarball, and cvs builds. Once the binary rpm's
and binary debs are available, and assuming, for example, that libgd was
found and linked with on the build machine, the packages will automatically
have dependencies on libgd, etc.  This forces the *binary* rpm user to
install the libgd package before the plplot package is installed (or in
Debian's case forcing apt-get to automatically install libgd before plplot.=
)
This is yet another reason why the tarball approach and the package approac=
h
(be it rpm or deb) should not be mixed for installation.  Time and again I
have heard users complain they cannot build packages on their Linux machine=
s
and often it is due to a dependency problem caused by using this mixed
approach.  If you understand enough to build a package from tarball it is n=
o
great leap to doing it from a src rpm.  I have done this many times (even
once with the whole tcl/tk src rpm package from RH 6.2, that I required on
my RH 5.2 machine at that time so I could play pysol (!)), and rarely run
into any insoluble problems. It is so straightforward, I would encourage yo=
u
to use src rpm builds rather than tarball builds just so you won't mess up
the package dependencies of your rpm-based Linux machine.

If you run into any specific problems with a src rpm build of say PLplot,
don't hesitate to ask me for help.  But my help will only be effective
if the system has been cleanly installed strictly from rpm's without
any forcing.

Alan

Re: [Plplot-devel] PLplot statistics

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

On Thursday 07 February 2002 22:30, Alan W. Irwin wrote:
| > On Thursday 07 February 2002 8:43 pm, Alan W. Irwin wrote:
| > > So far, no bugs have been reported for 5.1.0.
| >
| > I'm not sure if this is a bug, I configured --prefix=3D/usr/local,
| > then "make -n install" gives:
| >
| > ...
| > cp -p -a plmodule.so /usr/local//usr/lib/python2.0//site-packages
| > cp -p -a pyqt_plmodule.so
| > /usr/local//usr/lib/python2.0//site-packages
|
| Looks like YACP, yet another configuration problem.  That extra
| /usr in the middle of the path shouldn't be there.  If I specify
| either /usr/local/plplot or /usr for the prefix everything works
| fine.
|
| > I have been looking at the distributed rpm specs files, and I
| > found that they specify /usr as the install point.
|
| That's standard for all rpms and also debs.  In Linux distributions
| /usr/local is reserved for tarball installs *not* under rpm (or
| deb) control and /usr is reserved for debs and rpms.  Those who use
| a prefix of /usr for tarball installs or a /usr/local prefix for
| rpm or deb installs get what they deserve....;-)

Like me, when I made an automatic upgrade in my linux box, just to=20
find that (of course) the upgrade had upgraded just the distro=20
packages, not the manually installed rpm ones? And then searching for=20
all them... it would be much easier if they were in /usr/local -- or=20
if I had a separate rpm database just for them.

But I don't see the point in installing rpms under /usr -- there must=20
exist some reasoning behind that?

I have yet another rpm question. With dyndrivers, we can make rpm=20
with all available drivers, without having to worry if the user=20
system has the necessary libs or not! Of course the user will not be=20
able to use those drivers, but it will not hurt, and if the user=20
latter install the extra packages the drivers will be there. Correct?

Joao

Re: [Plplot-devel] State of the Union

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

On Thursday 07 February 2002 21:24, Alan W. Irwin wrote:
| Thanks very much, Geoffrey, for this extensive statement of the
| future possibilities for PLplot.

Me too, although I didn't mention it in my previous mail!

| I am concerned about the change to a C++ core from the point of
| view of the various front ends.  How would that work?  If no direct
| extension of a front-end was available for C++ (e.g., the yplot
| yorick front end) would you provide C wrappers for your C++ core?=20
| I did notice that my favorite front end, python, discusses C and
| C++ extensions simultaneously so I don't think there would be a
| problem for that front end.

And what about other OS support? One of the reasons (the smaller!)=20
why I choose PLplot was the possibility of using my code under native=20
M$. And (native) development tools are not that cheaper in other OSs

Joao

Re: [Plplot-devel] State of the Union

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

Alan W. Irwin writes:
 > I have a question about one area that caught my eye.  I would like to know
 > the effort required to convert the core of PLplot to C++.  How much
 > full-time would it take for *you* to sit down and re-write the whole core of
 > PLplot (excluding drivers) in C++?  Is this a project that would take say a
 > week of your vacation time or would this require several months full time
 > before you got something that was beginning to be useful.

Mmm, well, to "re-write PLplot in C++" sounds like a big job.  The way
I would advocate starting, is to simply "compile PLplot with C++".  If
we were to approach this by say, renaming all (or most, see below) C
files from xxx.c to xxx.cc, and then twiggling whatever makefile stuff
was needed to compile with C++, and fixiing whatever minor syntax
issues there might be, I would expect we could be "compiling with C++"
with a time investment of a few hours or so.  Once the C is actually
being regarded as C++ by the compiler, the human programmers can start
writing new code in C++ at will, on timescales that relate to their
personal inclinations and time budgets.

 > My C++ skills are non-existent, but if you say there are lots of
 > benefits to moving to a C++ core, I believe you and would be
 > willing to learn it.

I don't do my main coding activities in anything else.  

 > Certainly, the KDE team absolutely swear by C++ as a way to get newbie
 > programmers quickly writing code.  Although the KDE experience with a
 > massive C++ project has exposed some Linux C++ weaknesses, my impression is
 > those are rapidly becoming solved. For example, apparently some of the long
 > start up times for KDE apps are due to a Linux binutils problem with C++
 > that is about to be fixed.

Well, not really "Linux C++ weaknesses", I suppose, but more like "GCC
C++ weaknesses".  All GCC versions prior to 3.0 are essentially
unusable from a C++ perspective, as far as I'm concerned.  Sure, lots
of stuff works in 2.95.3, but too many things don't work, too many
things that are perfectly legal C++ won't compile with gcc 2.95.3,
that I simply haven't been able to use it.  That's why PLplot's C++
autoconf autodetects KCC, for example.

With GCC 3.0, I think GCC's C++ support is finally good enough to take
seriously.  I think if we coded in C++ in PLplot now, people would be
able to still use the result, provided they compile with GCC 3.0.
BTW, this doesn't mean I don't know of serious bugs in 3.0--I do--but
the number of them is at least low enough that it isn't such a painful
experience like it used to be.

I don't know when major Linux distros will convert to 3.0.x strain
versions of GCC.  Hopefully soon.  But there were many ABI changes
going from 2.95.x to 3.0.x, so we're talking about a total recompile
here.  Probably will take the distros awhile to brace themselves for
the effort.

 > I am concerned about the change to a C++ core from the point of
 > view of the various front ends.  How would that work?  If no direct
 > extension of a front-end was available for C++ (e.g., the yplot
 > yorick front end) would you provide C wrappers for your C++ core?

I would view it that retaining a C callable interface was a mandate.
Fortunately this is trivially easy to achieve.  C++ allows you to
declare functions with C linkage (no mangling would be introduced,
etc), so you can retain C API entry points, which then call C++ code
inside. 

I could imagine that the C PLStream becomes an opaque handle.  mksstrm
just chooses which active stream to use--ie, sets the active (global)
stream pointer for the C api--then all PLplot C api functions become

extern "C" 
void plXYZ(args) { return pls->XYZ(args); }

Then the whole core would just work directly on a real C++ stream
/class/ object (instead of on plsc, the global single active PLplot
current stream pointer).

In other words, in summary, no externally visible change to the API.
No impact on front ends.

But the coding beneath the C-callable layer could be done in C++, make
use of the better features C++ provides for programming in the large,
etc.  We could finally have a precision-neutral C++ PLplot library
because the C++ interface could be templated, etc.

That's just a very rough outline, it would have to be sketeched out in
a lot more detail before I would think there would be a real chance of
turning this sales pitch into a closed deal.

 > I did notice that my favorite front end, python, discusses C and
 > C++ extensions simultaneously so I don't think there would be a
 > problem for that front end.

I dunno if you know, but I am/was the Python C++ Sig chair.  The
python C++ sig never really delivered, and I think Guido has "reaped"
it by now.  But I "happen to know" that it is possible to make Python
extension programming a /lot/ easier by using C++.  It's one of the
reaons I haven't worked on plmodule.c actually, because knowing how
much nicer it is possible to make Python extension programming in C++
than in C, has totally disenthused me about working on a major C
extension module.

It's a big topic, too much to get into here probably.  The Python C++
sig failed to deliver for a variety of reasons.  But if PLplot were in
C++, then plmodule.cc could at least use good C++ techniques for
interacting with Python, independent of whether Python ever grows a
quality C++ interface.

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

Re: [Plplot-devel] PLplot statistics

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

> On Thursday 07 February 2002 8:43 pm, Alan W. Irwin wrote:
> > So far, no bugs have been reported for 5.1.0.
>
> I'm not sure if this is a bug, I configured --prefix=/usr/local, then "make
> -n install" gives:
>
> ...
> cp -p -a plmodule.so /usr/local//usr/lib/python2.0//site-packages
> cp -p -a pyqt_plmodule.so /usr/local//usr/lib/python2.0//site-packages

Looks like YACP, yet another configuration problem.  That extra /usr
in the middle of the path shouldn't be there.  If I specify either
/usr/local/plplot or /usr for the prefix everything works fine.


>
> I have been looking at the distributed rpm specs files, and I found that they
> specify /usr as the install point.

That's standard for all rpms and also debs.  In Linux distributions
/usr/local is reserved for tarball installs *not* under rpm (or deb) control
and /usr is reserved for debs and rpms.  Those who use a prefix of /usr for
tarball installs or a /usr/local prefix for rpm or deb installs get what
they deserve....;-)

>
> I think to remember that you said the the java examples would stay under
> lib/java/examples, to avoid setting CLASSPATH to two different directories.
> Is this correct? and really necessary?

I would prefer them installed with the other examples (which would require
two separate directories in the colon-separated list of directories in
CLASSPATH), but Geoffrey felt they should stay where they are currently
installed so CLASSPATH would only need one directory. I went along at the
time, but when users make their own java plplot examples they'll need two
directories in the CLASSPATH in any case. So I hope Geoffrey changes his
mind about where the Java examples should be installed, but if not, that is
fine as well.

Alan

Re: [Plplot-devel] Where do we go from here?

[Rafael L. <lab...@mp...>]

* Geoffrey Furnish <fu...@ga...> [2002-02-07 10:27]:

> Hey buddy, you can run but you can't hide.  Once a member always a member.
> :-).  Seriously, we all face differing time demands, diverging personal sw
> and research interests, etc.  If you need to spend N months doing something
> else, even an indeterminately long dive, that's no reason to feel you need
> to "resign".  Maurice and I have both had long fallow periods on PLplot,
> whilst pushing other agendas. Don't sweat it.  We're happy to have your
> constructive contributions whenever you have the time.  And we'll push on
> as best we can the rest of the time.  Really, its that way for all of us.
> My personal ambitions for what I wish I could accomplish on PLplot /far/
> exceed what I can actually deliver, measured over any human timescale of
> interest.  Such is life.

* Alan W. Irwin <ir...@be...> [2002-02-07 08:36]:

> On Thu, 7 Feb 2002, Rafael Laboissiere wrote:
> 
> > [...] Unfortunately, I
> > have this time budget problem right now.  At any rate, I did not resign from
> > the project yet, but if I see that I cannot do anything to improve the
> > situation, I will have to make a decision.  I will tell you when/if this
> > arrive (I hope not).
> 
> I presume you are talking about just the AM/LT project, Rafael. Your total
> contributions to PLplot have been most valuable, and I hope they long 
> continue on whatever sub-project you decide to work on.  Also, note there
> is no hurry on the AM/LT decision. 

First of all, thanks for your kind words.  I have to apologize for the
extremely bad wording in the paragraph above.  When I wrote "I will have to
make a decision" I was not meaning resignation from the PLplot project, but
as Alan correctly inferred, I was referring to the AM/LT front.  I am still
willing to lead the work on this front, but if I cannot resume it in the
foreseeable future, it is better that someone else take it over from me.

-- 
Rafael

Re: [Plplot-devel] State of the Union

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

Thanks very much, Geoffrey, for this extensive statement of the future
possibilities for PLplot.

I have a question about one area that caught my eye.  I would like to know
the effort required to convert the core of PLplot to C++.  How much
full-time would it take for *you* to sit down and re-write the whole core of
PLplot (excluding drivers) in C++?  Is this a project that would take say a
week of your vacation time or would this require several months full time
before you got something that was beginning to be useful.

My C++ skills are non-existent, but if you say there are lots of benefits to
moving to a C++ core, I believe you and would be willing to learn it.
Certainly, the KDE team absolutely swear by C++ as a way to get newbie
programmers quickly writing code.  Although the KDE experience with a
massive C++ project has exposed some Linux C++ weaknesses, my impression is
those are rapidly becoming solved. For example, apparently some of the long
start up times for KDE apps are due to a Linux binutils problem with C++
that is about to be fixed.

I am concerned about the change to a C++ core from the point of view of the
various front ends.  How would that work?  If no direct extension of a
front-end was available for C++ (e.g., the yplot yorick front end) would you
provide C wrappers for your C++ core?  I did notice that my favorite
front end, python, discusses C and C++ extensions simultaneously so I
don't think there would be a problem for that front end.

Alan

Re: [Plplot-devel] PLplot statistics

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

On Thursday 07 February 2002 8:43 pm, Alan W. Irwin wrote:
> Have a look at
> http://sourceforge.net/project/stats/index.php?report=3Dlast_30&group_i=
d=3D2915
> to see the big effect of the recent release on our web view and downloa=
d
> statistics.  From past experience this effect is mostly due to freshmea=
t
> users taking a look.
>
> To put this fast-attack, slow-decay spike into perspective, the statist=
ics
> for the first 7 days of February are roughly comparable to the entire m=
onth
> of January.  From past experience the higher-than-normal web view and
> download rates will continue for some time after the release so it is
> likely this month will be the best month ever.  In the first 7 days we =
are
> already 67 per cent of the way there in web views and 74 per cent of th=
e
> way there in downloads (if you exclude a suspiciously large result for =
one
> day in October 2001 which completely distorts that month's statistics).
>
> So far, no bugs have been reported for 5.1.0.

I'm not sure if this is a bug, I configured --prefix=3D/usr/local, then "=
make=20
-n install" gives:

=2E..
cp -p -a plmodule.so /usr/local//usr/lib/python2.0//site-packages
cp -p -a pyqt_plmodule.so /usr/local//usr/lib/python2.0//site-packages

I have been looking at the distributed rpm specs files, and I found that =
they=20
specify /usr as the install point. Is this the default? Shouldn't users=20
install non-distro packages in /usr/local, if possible? It is the default=
 in=20
"configure".

I think to remember that you said the the java examples would stay under=20
lib/java/examples, to avoid setting CLASSPATH to two different directorie=
s.=20
Is this correct? and really necessary?

Joao

[Plplot-devel] PLplot statistics

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

Have a look at
http://sourceforge.net/project/stats/index.php?report=last_30&group_id=2915
to see the big effect of the recent release on our web view and download
statistics.  From past experience this effect is mostly due to freshmeat
users taking a look.

To put this fast-attack, slow-decay spike into perspective, the statistics
for the first 7 days of February are roughly comparable to the entire month
of January.  From past experience the higher-than-normal web view and
download rates will continue for some time after the release so it is likely
this month will be the best month ever.  In the first 7 days we are already
67 per cent of the way there in web views and 74 per cent of the way there
in downloads (if you exclude a suspiciously large result for one day in
October 2001 which completely distorts that month's statistics).

So far, no bugs have been reported for 5.1.0.

Congratulations to everybody who participated in this release.

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] State of the Union

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

On Thursday 07 February 2002 6:48 pm, Geoffrey Furnish wrote:
>

What a speach!

You spoke in threading the redisplay process, but not in threading the=20
interative drivers, which is a must giving the interpreted languages we=20
support.

For the rest... in the 5 to 10 years you admit that it would take us to h=
ave=20
the job done, things will be much different then. What atracts me in plpl=
ot=20
is that it a simple, manageable, and yet capable scientific plotting libr=
ary=20
that supports several languages, output devices and OSs.

Some of the things you spoke can motivate me, but resources are scarce. P=
IPs=20
must have a priority associated. The non-existing "Bugs" item should have=
 the=20
higher priority, followed nearly by "Core", "Ports" and "Documentation", =
but=20
"PLplot Applications" should have the lower one. That's my view. Of cours=
e a=20
sub-priority should be assigned to each sub-task of each major task.

Joao

[Plplot-devel] State of the Union

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

Greetings to all members of the world-wide PLplot development community,

Now that we have successfully navigated the 5.1.0 release rapids, I
thought it would be an appropriate time to take a step back for a
moment, and just do a little group thinking about the future
directions for PLplot.  We have been with sourceforge for just about
two years now.  (SF.net shows we registered on 2/23/00, although we were
actually with SF.org for about 6 months prior to that), and during
this time the project has matured greatly.  Breaking the one-person
patch incorporation bottleneck was a major enabling factor, and that
was followed quickly with the release of PLplot 5.0, which the PLplot
user community had been anticipating for probably over 5-7 years.  After
that we have been doing lots in the areas of bug stomping,
configuration, language bindings, driver expansion, and many other
things, too many for me to even remember it all.  And the project
shows every indication of continuing to gather steam as the user base
and the developer base grows.

Consequently, I have been thinking that it might make sense to put a
little more effort into the planning area of the PLplot project, in
order to facilitate an orderly and  sensibly architected approach to
world domination of the explosively growing "scientific plotting
software" market segment.  :-).

To this end, I have been doing a little poking around lately, looking
at how other successful and respectable OSS projects are managing
their growth and development.  The thing I've noticed which has most
impressed me, is the use of highly focused topical documents for the
purpose of consensus building, software design, and ultimately status
reporting.  In the Tcl world these are called "TIPs", Tcl Improvement
Proposals.  In Python they're called "PEPs", Python Enhancement
Proposals.  In keeping with this, I'd like to propose that we
introduce a system of PLplot development centered around "PIPs",
PLplot Improvement Proposals.

Let me just stop right now, to assure everyone that I have not had
some sort of an out-of-body after life experience as a result of a
bike wreck or anything like that.  I'm not trying to propose in any
way that we bog down PLplot development with large bureaucratic
systems that stifle developer enthusiasm, or anything like that.  We
are still small, not anywhere near the size of efforts like the Tcl or
Python projects, so I am not imagining some grand massive heavyweight
software process here.

But, like most OSS projects I am sure, we do have the property that
our developers are geographically decentralized.  Most of us have
never actually exchanged verbal communication with each other or even
met in person, and may never (no tears please) so we just need to do
what we can in this net-centric environment, to promote orderly
development.  (Any volunteers to organize (and finance :-) the first
world congress of the extended PLplot community? :-)

Below, I am presenting a rough draft of a sort of overview of PLplot
development activities that I can think of that need to be undertaken.
Even while I was composing this over the last week, there have been
additional things under discussion on pLplot-devel, and we should
probably add to this, things like the palette tool overhaul that Alan
is requesting, and probably lots more.  I'm sure my compilation, long
as it is, under represents the union of the views/ambitions of all
developers, so I am by no means trying to squelch anyone.  Quite the
opposite, I'm  trying to catalyze the fleshing out of a real PLplot
development agenda.

If anyone is not familiar with TIPs or PEPs, I'd encourage taking a
little sojourn over to the Tcl and Python projects, and fishing
around until you find their TIP and PEP registries, and then just
perusing a bit to see how they're organized, what they contain, etc.

In very short summary, a PIP should have a clearly identified, highly
focused purpose, covering a specific area of (desired) PLplot
improvement.  And we should realize that PIP's will undergo a sort of
life cycle.  To begin with, the purpose is stated.  Perhaps it will
take work on the part of multiple people even to refine that,
crystallize it, etc.  Ultimately it should document enough background
about the current situation in PLplot for someone to really understand
what specifically needs to be fixed, improved, or originally
developed.  Then enough in the way of a design prescription so that a
developer can execute it.  And finally it should result in a clearly
stated result status so that people can know what the end result in
the code actually is.  This would serve as at least one permanent
record of the work, written by the developer, which would provide at
least some documentation of what is really going on.

I would just like to emphasize again, even though I said above, that I
really do not mean to imply that /every/ PLplot development task needs
a PIP.  People with write access to the cvs are entitled to just keep
working their magic, and I hope that continues. 

But some things are big enough of an undertaking, to warrant some real
planning, and review at the planning stage, before proceeding to
development, and then of course review of the development before
integration.  Even in such matters, some tasks are of a character that
they can be pursued on cvs head, while others are invasive enough that
they really need to be done on a branch, at least at the beginning.
The Java binding work is an example which imo, is not really very
dangerous, and can proceed on head without much worry about messing
anything up.  But the dyndriver work was done on a branch until it
reached a point that was suitable for integration.  So I see that
model continuing, where each significant PLplot undertaking utilizes
software development strategies and tactics appropriate to its
"weight".

I guess my main point here is really just that up until now, we have
treated almost everything as if it were light weight, with only three
things I can think of so far winding up on branches: dydrivers, AM/LT,
and TEA (in reverse order).  My feeling is that many of the tasks
outlined below should wind up on a branch as well.  Anything heavy
enough to merit a branch, for sure merits a formal PIP.  And many
things not heavy enough for a branch, still merit a PIP.

Finally, one might say that plplot-devel covers the discussion phase
adequately.  I guess my feeling is that a very large amount of very
useful dialog does occur on plplot-devel, but at least for myself, I
often feel a few months down the road that I cannot recall some of the
important final conclusions on some topic, or even remember the
arguments that led to the conclusion in sufficient detail to re-derive
the conclusion.  Maybe I could be better about archive searching, but
I just feel a simpler approach would be to introduce a PIP, where
someone (or a multi-person party of responsible someones) usher an
actual PIP document through stages of refinement and maturation, so
that the current state of the thinking is always available for review
in a specific easy to find location.  Discussion still would occur on
plplot-devel, but the consensus would be actually recorded in the PIP.

So, these PIPs, and the PIP registry (PIP #0) would be stored in cvs,
say in plplot/pip/pip<#>.txt, or some such.  If someone could acquire
the TIP management scripts that the Tcl group uses to web-alate their
TIPS, that would be great, but even if we just check them into CVS,
and /use/ them, personally I would view that as a huge step up from
what we do now.  Maybe we should store the PIPs in a separate cvs
module from the plplot code itself, so that we don't have to worry
about PIP's on branches.  I dunno, somebody comment on this please.

And finally, I'd just like to emphasize that another key point of the
PIP notion, is that some of us with extremely limited PLplot hacking
time budgets, if we just documented clearly what we think needs to be
done, then perhaps we will be better able to recruit additional
developers.  If newer people can see clearly defined tasks, in
writing, they may be able to undertake those development tasks and
post patch sets which implement them.  In other words, smaller PIPs
may serve as a draw for new talent and talent development activities.

So, anyway, without further adieu, below follows my first draft of an
overview for what I think needs to happen in PLplot.  I hope other
will comment, both on the whole notion of PIPs described above, and on
the specific tasks outlined below.  I hope that what comes out of this
is an actual consensus on whether people do or don't like the PIP
notion (don't be afraid to say nay, if you really don't like it, as
discussion forums only work if people really believe they can speak
their true mind), and then additional refinement (and expansion?) of
the task list.

Voila!


Complete language bindings:
===========================

Java:
    complete API
    complete examples

Perl:
    ??? current status ???
    What about PDL?

C++:
    Like Java, implement float/double wrappers.  Can probably achieve
    it via member templates, allowing a single method specification
    for each method.  Have to check into that.  KCC, use --one_per.
    What about Intel C++, etc.

Python:
    Revamp plmodule.c, robustify and generalize.

E-lisp:
    Exploit dynamic loadable modules in XEmacs 2X, provide lisp
    bindings for PLplot API, allowing rendering to embedded buffer
    widget.  Elisp funcs for plotting data in email, or buffers read
    in from disk, etc.

Ruby: ???  Did I miss anything else?

Ports:
======

Windows/DOS:
    Upgrade documentation to clearly describe current options for
    compiling PLplot on MS-ware.  What vendor compilers are currently
    supported, with what graphics libs?  Borland, MS VC?

    What about djgpp, gcc/cygwin, mingw32?

OS/2:
    emx?  gcc?

Mac:
    ? What do we say here ?

Other:
    Anything else?  Beos, palm, windows CE?  Scientific graphics in the
    palm of your hand?  Does that light anyone's fire?  Displace those
    multi-player palm games for some "real work"?

Core work:
==========

TEA:
    Make Tcl and Tk PLplot extensions dynamically loadable via TEA.
    Make sure that Python/Tk can import plframe dynamically.

Driver separation:
    Introduce "struct PLEnv *", ala JNI, to separate drivers from
    PLplot core once and for all.  Result, all drivers can be linked
    without reference to libplplot, simplifies dyndriver building,
    use. 

Shared libs:
    Upgrade shared lib support in configure, support Solaris, other
    notable platforms.  Make --enable-dyndrivers default to yes for
    only those platforms for which we know how to build loadable
    modules.  Note, loadable modules is not the same as shared libs.
    Could have dyndrivers on a platform without having shared libs,
    although presumably the additional work to complete shared libs
    would  just be a small additional dribble of effort.

X-win/Tk driver dynamification:
    Don't understand the issues in detail, but something has to be
    done.  Figure it out once and for all, and do it.

Plframe Bugs:
    Of course more is needed than just fixing bugs (see scalable
    rendering engine below), but still, there are some annoying
    behaviors of plframe that should be corrected.

    1) Plots with large numbers of graphical elements (IC chip layout
       plots, for example) drop some of the drawings at default/min
       zoom.  They are visible if you zoom in, but then C-r brings you
       back to the default display, and some lines/polygons are
       missing. 

    2) First zoom in seems to often be a double display.  Very
       noticeable for big plots where it takes several seconds in dead
       time to display.  After the first zoom, the screen goes blank,
       then the plot flashes up, then immediately disappears, then
       more dead time, followed finally by a redisplay of the image.
       The second one "sticks".  Next zoom is okay.  (Still slow, but
       at least it only redisplays once).  But the first zoom down
       from the top, is a double hitter.

    3) C-r does a double redisplay too.  Once to go back to the size
       of the plot when there were scroll bars.  But then it notices
       the scroll bars are gone, so it resizes again and redisplays
       given the full screen real estate of the fully reseted
       plframe. 

    Probably we need a way for a Tcl script to set a "don't update"
    flag in plframe, then it can do the stuff with the Tk geometry
    manager to resize the plframe sans the scroll bars, then it should
    reenable event handling and tell plframe to redraw (just once).

P-Threaded plframe:
    Something really needs to be done about plframe's long redisplay
    times.  For plots with lots of graphical elements, the current
    redisplay code is very painful.  Commercial CAD tools, for
    example, do waaaaay better with zoom/redisplay.  The ultimate
    solution to this problem is almost assuredly some sort of a
    scalable rendering framework project, such as that outlined
    below.  But it seems that some worthwhile relief could still be
    obtained in the context of a less ambitious plframe project.

    Specifically, the redisplay code should be taken out of the parent
    process thread, and redraw should happen in a separate thread.
    This display thread should then periodically check for
    obsolescence of the current tasking orders.  So if a 500k vector
    redisplay is under way (takes many seconds even on fast modern
    iron), instead of the whole Tk driver being frozen, instead the
    user would still be able to advance the plot, and the redisplay
    thread would be notified (via mutex) that the current plot buffer
    display list was being obsoleted, and it would immediately abandon
    that and sync up with the new inbound display commands.
    Similarly, X events that resize the window, unmap it, etc, would
    all interrupt the display processing thread, so that it could
    short circuit work that no longer needs to be done.

    This alone won't solve the issues with the nonscalability of the
    existing rendering framework, but it would at least provide some
    relief from the current extreme delays in the current
    single-thread-with-no-status-polling modus operandi of the
    redisplay code.

Distortion:
    highly zoomed plots (Tk driver) show obvious coordinate
    distortion.  Believed traceable to 16 bit (short) ints in
    core->driver interface.  Fatten virtual coord rep to 32 bits. 

    Tasks:
        core->driver dispatch funcs line, polyline, short->int
	plmeta, dump 4 bytes instead of 2
	plrender, bump metafile version, backward handling for old
		  metafiles.
        dashing: currently walks virtual pixels one-by-one, horrific
	    if expand coord space by 2^16.  Need to revamp dashing to
	    /calculate/ (in world coords) dash starts and stops,
	    including bracketing so polyline can turn corners
	    correctly. 
	Tk driver, like plmeta/plrender, bump transmission to use 4
	    bytes instead of 2.

plmeta/plrender:
    Add page directory.  Plrender (w/ mandatory Tk interface? or maybe
    we call this a new app, named plrendertk?) reads
    page directory when it inputs metafile, allows page/chapter
    selection widget for skipping to section introducers, plus
    telescoping directory expander for page access.  Allows random
    access to plots.

Fonts/Stroking:
    PLplot currently has severely limited textual capabilities.
    pl[mp]tex allow annotation of the viewport, in viewport-centric
    terms (character scaling, etc).  Consider alternatives:

    Tasks:
        Native text:  Allow capable devices to draw text with native
	    fonts.  This should be supportable for X and PS for sure,
	    maybe more.  Learn about native font
	    specification/selection techniques, exploit.  Tcl(/Tk)
	    could be a useful guide here (in the done-it-before dept).
	Text scaling in world coords:  There seems to be no way to do
	    this at present, but there should be a way.  Note, aspect
	    ratio makes it tricky.  There should be a way to perform
	    annotations with text scaled to world coords, and somehow
	    maintain a proper font aspect ratio even if the viewport
	    has extreme aspect ratio.  In other words, find a way to
	    specify font scaling in world coords, but make font
	    drawing be font a/r preserving.  Tricky, but important.
	Stroke fonts: Obviously these exist in the code somewhere.
	    Should provide an API for fetching font stroking arrays
	    from the character generator.  Then make global PLplot API
	    function for plotting stroke sets.  NOTE: a stroke API
	    would be like plline(), but would add an additional
	    indexable field for specifying whether the given coord was
	    a move-to or a draw-to.  Other plotting API's I have seen,
	    have had this.


Axes (tick label occlusion):
    I'm sure its much better than it used to be, since we've gotten
    lots of patch work in the area of plbox and related functions.
    But still serious deficiencies remain in the area of axis
    generation and labeling.

    Issues:
        Naive use of xtick, nxsub can produce absurdly bogus
	    labeling.  I recently produce plots with axis labels evenly
	    spaced:, 1, 2, 4.  Also 1, 3, 4, etc.  Fractional xtick
	    appears to be ruinous.
        No easy (and simultaneously reliable) way to control # of axis
	    labels on a side.
        Extreme aspect ratio plots are a disaster.  Axis labels on
	    short axis are all over each other, looks ridiculous.  A
	    scientific graphics package should be able to do
	    floor-planning for tick labels!  Should calculate
	    non-overlapping windows (in world coords) in which tick
	    labels should reside, then get the labels drawn within
	    these boxes.  Requires world-coords lettering capability,
	    mentioned above.
        Orientation, should be able to write twisted (flowing down)
	    axis labels on X axes.  Will be needed when extreme aspect
	    ratio plots are drawn with short axes in X coordinate.


zooming (handler, widget)
    Zooming support in PLplot right now, is present, which is
    significant by itself. But it could be improved in several ways. 

    Tasks:
        zoom handler: Currently there is no zoom handler (that I know
	    of), so the zoom support is limited to the widget.
	    Currently the Tk (plframe) widget has zoom support (does
	    the Gnome widget have this too?  What about ntk?), but
	    this works by zooming the whole plot, whacking the
	    viewport.  An alternative would be to allow installation
	    of a zoom handler.  A user-supplied zoom handler could
	    preserve the viewport, but relabel with zoomed box coords,
	    allowing the plot to be accurately redrawn with (side)
	    annotations, but a limited coord range.  This capability
	    would be especially useful in situations where there is a
	    plot legend that is obliterated by the current zoom
	    mechanism. 

	    Such a mechanism might partially or completely alleviate
	    the damage done by the distortion problem noted above,
	    serving as a poor man's alternative, to a true high
	    quality scalable zooming engine (see below).

        Geometry aware zoom scalability:  

	    The current zoom engine works by replaying the display list
	    with a new window mapping.  (Somebody authenticate the
	    accuracy of this statement).  But due to the distortion
	    bug (design ramification) mentioned above, the zoomed
	    plots can show serious deformation.  Moreover, deep zooms
	    are wasting effort replaying a plot buffer (that was
	    already truncated to 16 bits of usable "mantissa", with
	    the old window mapping) filled with elements that won't be
	    in the viewport.

            For many types of scientific graphics showing data
	    variation of this versus that, the problem may not be too
	    severe, and modern CPU throughput may handle the situation
	    acceptably.  But it is clear that certain application
	    domains have oodles of geometric features in a plot.
	    Think of CAD (circuit layout for the P4, for example), or
	    maybe molecular biophysics and biochemistry (drug design,
	    macro molecules, etc), or even some CFD applications,
	    where there might be 10^9+ graphical elements in a
	    displayed plot.  Zooming such a plot will be unbearable
	    with the current zooming framework.  (Plus the plot buffer
	    probably doesn't even scale that way, somebody confirm).

	    Need to have a telescoping geometry information database in
	    the display list, so that an intelligent zooming engine
	    can redisplay only those graphics elements with footprint
	    in the new viewport.  Quad tree, R-Tree probably others.

        Widget independence:  The above described scalable
	    zooming/rendering engine should be built, but not built
	    directly into plframe.  Instead, build this scalable
	    zooming engine in such a way that it can be reused by
	    multiple intelligent widgets.  (Tk, Gnome, etc).


Annotations, Smart-Visibility, etc.:
    Related to the scalable zooming engine project proposal above,
    there is also the issue of feature visibility as a function of
    zooming factor.  Consider the example of CAD, say in particular,
    the circuit layout for the P4.  At the top maybe you see blocks
    for the ALU, register file, icache, etc.  Zoom in by 10^4 and you
    should be able to see Verilog element names.  But the display
    engine shouldn't waste pixels drawing labels at low magnification,
    since they'll eat pixels without conveying information.  Instead,
    need an intelligent rendering engine that draws features based on
    resolvability at the current zoom factor.  When the lettering
    (scaled to world coordinates of small-feature-size graphical
    elements) becomes large enough to resolve (at extremely high
    magnification), the lettering is rendered, but not otherwise.
    Similarly for other feature details.

Segments:
    Other scientific plotting API's (Tektronix Plot 10) have allowed
    identification of "graphical segments", collections of drawing
    primitives that together form a single identifiable element.
    These can then be assigned attributes (brighter, blinking, hidden,
    etc).  Useful in interactive graphics applications.  Do we want this?

Overlays:
    At various times over the years, I've wished for an X windows
    widget that I could pack directly over the top of our current xwin
    driver.  This widget would be transparent in areas not drawn to.
    This would provide a way to draw atop an image while retaining
    separation between the image and the annotation.  Think of using
    double buffering where you have an animation (or continuous time
    computation/display) displaying beneath a fixed
    labeling/viewport. 

Consider C++ for PLplot Implementation Language:
    This has been discussed before, but not seriously for about 3
    years.  C is painful, just no other way to say it.  The above
    development agenda items (scalable/intelligent rendering
    framework, multi-stroke "segments", segment attribution) for
    graphics API core work, will represent significant code authorship
    activities.  Would be /very/ nice to have access to C++ for all
    that effort.  

    One could advance a powerful (to me) argument for converting the
    whole PLplot core over to C++.  Make drivers derive from an
    abstract base with pure virtual methods for the driver entry
    points.  Make the PLStream an actual class.  Convert the geometric
    transformation kernels into OO service layers, etc.  I could see
    lots of prospective benefit from this.  At the cost of a lot of
    work that ultimately wouldn't /by itself/ change the core feature
    set of PLplot.  It would be valuable from the standpoint of
    improving the code structure (to my way of thinking), but wouldn't
    by itself result in better actual PLplot functionality until
    subsequent development activity was leveraged on top of it.

    Consequently, this proposal might be to just start with doing some
    of these core graphics primitive/API additions, in C++, leaving
    the existing "plplot core" in C pretty much as it sits right now.
    Segments could be added in C++, but still ultimately rendered
    using the existing underlying drawing framework.  etc.  Have to
    think a little harder about widget framework extension work
    though.  If we supported a scalable rendering framework effort by
    authoring code in C++, would we consider revamping plframe into
    C++ in order to exploit it?  Or should we keep widget facilitation
    infrastructure in C to ease use from existing C widgets?  But
    writing lots of code in C is soooo painful...

    Something to think hard about.

    This PIP would have to hit topics like separation of
    implementation work into subsets for C and C++, composition of the
    resulting libraries, thinking about linking support with C and
    FORTRAN codes, impact on dynamic drivers, etc.  For example, would
    wholesale adoption of shared libs allow wholesale migration to C++
    without negatively impacting use from C/F77 (including imposing no
    onerous rules about linking techniques)?  Would that alleviate
    anti-C++ fears?

Polygon Intersection:
    Drawing lines without worrying about occlusion is probably okay.
    But using plfill to draw polygons can result in situations where
    one polygon intersects with another.  The current code does
    nothing to handle this.  On a pen plotter (HPGL) you can probably
    see the intersection in the final physical medium, but with raster
    display devices like X-windows, this info is probably completely
    lost.  Overlays with some sort of translucency might be one way to
    deal with this.  Another way would be to use the geometry feature
    size aware scalable zooming engine, and endow it with the ability
    to perform polygon intersection for polygonal elements selected
    for rendering.  Then you'd want some way to chose a color
    interpolant for the intersection polygon.

auto-dependencies:
    Auto detect GCC 3.0, add makefile magic exploiting -TP and all
    that.  Similar support for other C/C++ compilers, such as KCC,
    pgiC++, Intel C++, SGI, etc.

Identify C++ Compilation Environment:
    C++ compilers are generally not ABI compatible.  This is due to
    many factors, and has bean purposely promoted by C++ compiler
    vendors and standards participants over the years.  Intel may
    broker a standardized ABI for C++ on IA-64, but even if
    successful, it will remain the case that C++ ABI's are
    incompatible between compiler vendors on other hardware
    platforms. 

    PLplot should allow compiling libplcxx with multiple compilers,
    installing to same $prefix, similar to current float/double
    disambiguation (which is itself extremely valuable in certain
    circumstances).   To do this, append (optional) "environment tag"
    to name of C++ lib targets, libplcxx_$(env).[a|so].

Improve plplot-config Flexibility:
    Clients don't always want the same things.  plplot-config should
    recognize some of the same options as provided to configure.
    Things like --disable-f77, --with-double, etc.  So when a client
    makefile calls $s(shell plplot-config --disable-f77 --libs), what
    should come back is the current plplot-config --libs output, sans
    the FORTRAN stubs library, correct precision tag, correct C++
    compilation environment tag (see above), etc.  plplot-config
    should support pulling different configurations out of the same
    prefix, so that sophisticated PLplot client programs can get "just
    what they want" out of PLplot.

    Also fix the spurious -Llib eye sore.

Contouring:
    PLplot has long been needing investment in the contouring area.
    See documented bug relating to Y invariance (or was it X
    invariance?).  Need a robust contouring algorithm.

N active view ports:
    UGS (SLAC), I think also Plot 10 (Tektronix), had multiple active
    view ports, with independent window mappings.  Allowed plots to
    world coords to appear simultaneously in two view ports, with
    different coordinate xforms.  One really cool application:
    stereo graphic 3-d molecular structure graphics.  Two view ports,
    with 3 degrees divergence in eye vector, one pass drawing of
    molecular structure, simultaneous rendering to two side-by-side
    view ports, and presto, 3-d proteins in your face.  

    Is this something we want in PLplot?  Other scientific graphics
    API's have it.  Note, you can do display list replication to
    multiple view ports the hard way, so it is just a convenience.  And
    there is probably some run time cost associated with supporting N
    active view ports.  But it /is/ convenient for certain
    situations. 

Better Data Visualization:
    surface slices, wall projections, etc.

Presentation Graphics:
    For the executive board room presentation.  Bitmaps in the
    background, all that Power Point glitz stuff.


PLplot Applications:
====================

TD/Gnuplot Killer:
    Its a dirty job, but somebody's gotta do it.  We've had this
    rudimentary plot.tcl thing for several years, but it isn't really
    up to the task of unseating Gnuplot.  (TD was an early interactive
    data plotting program by Bill Grupp, while he was at Yale/CS.
    Gnuplot looks to me a lot like the early TD program).

    This PIP is to build a data plotting /application program/.
    Probably in Python/Tk, or maybe with one of the other tool kits
    (gnome/gtk?), that uses PLplot for interactive display and
    ultimate rendering to printable files.  I'm imagining a set of
    widgets that control data import and field interpretation,
    resulting in definition of "data sets".  Then plotting
    megawidgets, maybe one for 1-d plots and another for 2-d plots,
    which control the selection of line styles, markers, colors, etc.

    This should also be scriptable, so that people can automate
    production of .epsf files for inclusion in LaTeX docs, etc.
    Bottom line, some people don't have codes, they have data.  And
    PLplot should serve them too.

Browser Plugins:
    There's a Tcl/Tk Netscape plugin, also a Python Netscape plugin.
    Can we get a plframe in a Netscape buffer?  Can TEA enable plframe
    to be dynloaded into a page with the Tcl/Tk plugin already
    activated? 

Flash Driver:
    I don't remember the punch line to the former Flash discussions.
    If this is viable, maybe we need to build a flash driver.  Kinda
    like the plframe loadable into the Tcl/Tk plugin idea above,
    except that probably more people already have flash.  A flash
    driver might make PLplot a lot more accessible than anything else
    we have. 

    But this idea needs to be developed more.  Explain how we render
    to it, get it into web pages, etc.

Server Loadable Modules (Apache Extension):
    This is the other end of the browser plugin pipe.  Get PLplot into
    Apache so that plots can be generated without subshells and all
    that.  This idea would have to be fleshed out a lot.

Cgi-bin:
    This is a lot less sophisticated than the server extension PIP,
    but could still fill a valuable role in promoting PLplot.  I wanna
    go to cnn.com, and find them rendering financials with PLplot.  Or
    big charts.com.  Whatever.  Anyway, in order to achieve our
    rightful role as the de facto, world-wide plot rendering engine, we
    need web serviceability.  Learning how to do cgi-bin could be a
    single, valuable step along this journey.

Webserver Plotting Engine:
    www.sci-plots.org.  People point their browser there, post data
    sets with a web form, get back bitmaps or .epsf they can use.
    Maybe this would be partially obviated if the Gnuplot Killer App
    were produced, but my feeling is there will always be people who
    for one reason or anther, can't run it on their system.  They won't
    have Python installed, can't install, work in an irrepressible
    Dilbert-phb-dominated company, whatever.   Anyway, what these
    people need is a web site where they can go and get their data
    plotted, then they take the rendered plot file, and import it into
    their paper.


Documentation, Informative Stuff:
=================================

Formalize PIP's (PLplot Improvement Proposals), modeled after TIP's
(Tcl IP's).

Convert above wish list into families of PIP's.

Solicit additional community involvement.  The outlined PIPs above
constitute 5x to 10x what the current core team can do in 5 years
given existing professional obligations.  PIP-alizing the PLplot
project could encourage SF devfolk to get involved, or might allow
corporate sponsorship (or even grants) of PLplot development for
existing core team members.

Need informative pips, or documentation dev work, to cover many areas
of PLplot internals.  Current API ref docs and usage chapters are
adequate for beginner to intermediate level PLplot app developers.
But PLplot hacking itself, needs to be facilitated through substantial
documentation effort on PLplot internals.  Seeking detailed
informative pips on internal coord systems and xformations, clipping
behavior, font representation, pattern fill, etc.

FAQ:
    Need to have an online FAQ, with questions that scientists ask.
    How do I plot a square/circle on the screen?
    How do I relate world coordinate aspect ratios to the physical medium?
    How do I implement interactive data querying functions (locator mode)?
    How to annotate a plot with strings with sizes in word coords?

Update website, credits section, acknowledge more people's individual
contributions.  

Testing and Automation:
=======================

Current examples are useful as API tutorials.  But need more robust
API regression test coverage.

Framework for automated purify-cation.

Continued investment in automated testing framework to reduce human
testing load during release process.

All these things need to be fleshed out.

Re: [Plplot-devel] Where do we go from here?

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

On Thu, 7 Feb 2002, Rafael Laboissiere wrote:

> [...] Unfortunately, I
> have this time budget problem right now.  At any rate, I did not resign from
> the project yet, but if I see that I cannot do anything to improve the
> situation, I will have to make a decision.  I will tell you when/if this
> arrive (I hope not).

I presume you are talking about just the AM/LT project, Rafael. Your total
contributions to PLplot have been most valuable, and I hope they long
continue on whatever sub-project you decide to work on.  Also, note there is
no hurry on the AM/LT decision.  Did you notice all the rush of volunteers
that I got?  ...;-)

The only reason I am agitating about AM/LT now is I feel it is important
infrastructure we should at least test preferably at the start of *a*
release cycle.  If it turns out we don't get it into the release in this
cycle, I will definitely be asking about AM/LT again near the start of the
next release cycle since I do not want to lose all the valuable work you put
into the AM/LT branch.

Alan

Re: [Plplot-devel] Where do we go from here?

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

Rafael Laboissiere writes:
Quoted out of order:
 > > Yeah, I'd feel the most comfortable if the effort were led by Rafael.
 > > Hopefully no time real soon so I can get some other work done. :)
 > 
 > No doubt, I am the most entitled person to do the job.  Unfortunately, I
 > have this time budget problem right now.  At any rate, I did not resign from
 > the project yet, but if I see that I cannot do anything to improve the
 > situation, I will have to make a decision.  I will tell you when/if this
 > arrive (I hope not).

Hey buddy, you can run but you can't hide.  Once a member always a
member.  :-).  Seriously, we all face differing time demands,
diverging personal sw and research interests, etc.  If you need to
spend N months doing something else, even an indeterminately long
dive, that's no reason to feel you need to "resign".  Maurice and I
have both had long fallow periods on PLplot, whilst pushing other
agendas. Don't sweat it.  We're happy to have your constructive
contributions whenever you have the time.  And we'll push on as best
we can the rest of the time.  Really, its that way for all of us.  My
personal ambitions for what I wish I could accomplish on PLplot /far/
exceed what I can actually deliver, measured over any human
timescale of interest.  Such is life.

 > * Maurice LeBrun <mj...@ga...> [2002-02-06 21:56]:
 > 
 > > I'm a bit skeptical it would have made a big difference.  It seems to me
 > > that with the addition of dyndrivers, there were going to be a lot of
 > > configuration changes regardless of which configuration model we were
 > > using.
 > 
 > I do not remember if I told you guys about this, but in my private AM/LT
 > branch (not in CVS) I started porting the dyndrv code to libltdl, a portable
 > library for manipulating dynamically loaded objects (see
 > http://www.gnu.org/manual/libtool-1.4.2/html_node/libtool_45.html).  The
 > goal is to make the dyndrv code largely portable across platforms. By no
 > means, using libltdl means using libtool, but the two things work nice
 > together.
 > 
 > > Certainly the commits I made personally left me with that impression.  I
 > > don't mean to be throwing water on your enthusiasm, I just think it will
 > > take a while for the payoff from AM/LT (or dyndrivers for that matter) to
 > > be really evident.  The payoff from cool new features, however, can be
 > > immediate.
 > 
 > I also think that AM/LT will not bring anything visible for the end-user. My
 > interest in AM/LT is from the packager point of view.  Believe me, the
 > current configuration can be a nightmare for people packaging PLplot
 > (witness rpath problems, non-relocatability, etc).  Besides that,
 > integrating the TEA stuff may be an easier task in the framework of AM/LT.
 > I also think that making the configuration scheme more "modern" (yeah, in
 > the GNU sense...) will make it much more attractive for the potential future
 > developers joining our team.

I'll say again that I share Maurice's (healthy) skepticism, but both
of Rafael's pp's above have interesting, even tantalizing aspects, so
we should by all means endeavor to carry this through to the point
where it can be seriously evaluated.

My only real beef wit the "modern GNU (autoconf) way", is that it is
so woefully inadequate for the overwhelming majority of the software
development I do.  Which is to say, day-in-and-day-out development of
highly levelized C++ software.  Okay, those words don't describe
PLplot much, so maybe a more "modern" autoconf scheme would be okay
for PLplot.  I'm willing to be shown.  But I've just never really felt
that the GNU autoconf system really brings much to the table in the
area of software organization, layout, and general developer-centric
sw issues.  What it does wonderfully, par-excellance, is system
suckiness deobfuscation and workaround demystification.  And that's
pretty much what we use it for, to my mind, with substantial benefit.
And if I could read Maurice's mind from here, I'm guessing he's
feeling about the same, that we are deriving the main benefit of
autoconf right now.  In fact, we are actually deriving more than the
usual benefit, because Maurice has spent so much time (way back at the
beginning) desuckifying some of the autoconf macros.  Maybe they're
catching up by now, but at least for several years, our autoconf stuff
worked a lot better than the average.  I cannot count the number of
times I was able to configure PLplot, but not other GNU software, on
various unix systems where the swadmins had done various cockamaymee
nonsense.  This was especially bad in the labs, where "national
security" was such an oft-abused rubric for excusing any imaginable
sort of sysadmin-lunacy.  X headers under /dont/look/here, X libs
under /you/wont/believe/its/over/here, etc.  

I dunno, we need to see it working.  It may well be worth the switch.
I think the summary for Maurice and me, is just "let's not decide
before we see the proof".  But by all means, if the evidence can be
seen, we'll look.

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

Re: [Plplot-devel] Where do we go from here?

[Rafael L. <lab...@mp...>]

* Maurice LeBrun <mj...@ga...> [2002-02-06 21:56]:

> I'm a bit skeptical it would have made a big difference.  It seems to me
> that with the addition of dyndrivers, there were going to be a lot of
> configuration changes regardless of which configuration model we were
> using.

I do not remember if I told you guys about this, but in my private AM/LT
branch (not in CVS) I started porting the dyndrv code to libltdl, a portable
library for manipulating dynamically loaded objects (see
http://www.gnu.org/manual/libtool-1.4.2/html_node/libtool_45.html).  The
goal is to make the dyndrv code largely portable across platforms. By no
means, using libltdl means using libtool, but the two things work nice
together.

> Certainly the commits I made personally left me with that impression.  I
> don't mean to be throwing water on your enthusiasm, I just think it will
> take a while for the payoff from AM/LT (or dyndrivers for that matter) to
> be really evident.  The payoff from cool new features, however, can be
> immediate.

I also think that AM/LT will not bring anything visible for the end-user. My
interest in AM/LT is from the packager point of view.  Believe me, the
current configuration can be a nightmare for people packaging PLplot
(witness rpath problems, non-relocatability, etc).  Besides that,
integrating the TEA stuff may be an easier task in the framework of AM/LT.
I also think that making the configuration scheme more "modern" (yeah, in
the GNU sense...) will make it much more attractive for the potential future
developers joining our team.

> Yeah, I'd feel the most comfortable if the effort were led by Rafael.
> Hopefully no time real soon so I can get some other work done. :)

No doubt, I am the most entitled person to do the job.  Unfortunately, I
have this time budget problem right now.  At any rate, I did not resign from
the project yet, but if I see that I cannot do anything to improve the
situation, I will have to make a decision.  I will tell you when/if this
arrive (I hope not).

-- 
Rafael

Re: [Plplot-devel] Where do we go from here?

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

> Alan W. Irwin writes:
>  > Furthermore, I believe that major
>  > improvement should be an AM/LT configuration scheme.  It did not escape my
>  > notice that a substantial fraction of our commits since 5.0.4 had to do with
>  > configuration changes, and I think that ratio would be greatly reduced with
>  > AM/LT once we had overcome the learning curve.
>
> I'm a bit skeptical it would have made a big difference.  It seems to me that
> with the addition of dyndrivers, there were going to be a lot of configuration
> changes regardless of which configuration model we were using.  Certainly the
> commits I made personally left me with that impression.  I don't mean to be
> throwing water on your enthusiasm, I just think it will take a while for the
> payoff from AM/LT (or dyndrivers for that matter) to be really evident.  The
> payoff from cool new features, however, can be immediate.

IMHO, if we improve the configuration organization and overall
infrastructure, then it will make the interesting "cool new features"
substantially easier to do (e.g., fewer and easier configuration commits
then what occurred with the dyndriver changes.) I am glad we continue to
desuckify the current configuration scheme (witness Geoffrey's comments on
the dependency problems that just bit me), but at some point you have to
evaluate how much time that is taking versus the advantages of a new
approach.

From the encouraging things I have read, I am willing to gamble with my time
doing testing on the AM/LT branch that automake and libtool will make our
life considerably easier.  But I don't want to finish Rafael's experiment
alone.

Alan

RE: [Plplot-devel] Where do we go from here?

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

Alan W. Irwin writes:
 > I understand that Geoffrey is still preparing his state of the union message

Sorry, I know I said I'd already have transmitted it by now, but the
last few days hae gone wacky on me.  

Will try to push it out "real soon now".

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

Re: [Plplot-devel] wish list for the colour palettes

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

Alan W. Irwin writes:
 > Thanks for that suggestion which was bang on.
 > 
 > make clean
 > ./configure ....
 > make
 > cd tmp; make x08c
 > 
 > fixed the problem.  I usually do go through a clean rebuild (sometimes even

make clean is supposed to be never necessary.  Desuckifying the
dependencies once and for all, is on the short list.

I've been bitten by such things toooooo many times in PLplot.

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

Re: [Plplot-devel] Where do we go from here?

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

Alan W. Irwin writes:
 > Furthermore, I believe that major
 > improvement should be an AM/LT configuration scheme.  It did not escape my
 > notice that a substantial fraction of our commits since 5.0.4 had to do with
 > configuration changes, and I think that ratio would be greatly reduced with
 > AM/LT once we had overcome the learning curve.

I'm a bit skeptical it would have made a big difference.  It seems to me that
with the addition of dyndrivers, there were going to be a lot of configuration
changes regardless of which configuration model we were using.  Certainly the
commits I made personally left me with that impression.  I don't mean to be
throwing water on your enthusiasm, I just think it will take a while for the
payoff from AM/LT (or dyndrivers for that matter) to be really evident.  The
payoff from cool new features, however, can be immediate.

 > So I am looking for an AM/LT leader I could follow.  Rafael would be ideal
 > for this role (and we have worked well together before), but he may not be
 > able to make a time commitment in the near future so we may have to rely on
 > somebody else.

Yeah, I'd feel the most comfortable if the effort were led by Rafael.
Hopefully no time real soon so I can get some other work done. :)

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

[Plplot-devel] Where do we go from here?

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

I understand that Geoffrey is still preparing his state of the union message
(or speech from the throne here in Canada.)  But in light of my semi-humorous
remark about the next release in my last post, I decided to jump start that
discussion.

My preference for the next release is I would like to see a continued effort
at the small bug fixes, documentation, example consistency, Java API, etc.,
mixed with at least one major improvement. Furthermore, I believe that major
improvement should be an AM/LT configuration scheme.  It did not escape my
notice that a substantial fraction of our commits since 5.0.4 had to do with
configuration changes, and I think that ratio would be greatly reduced with
AM/LT once we had overcome the learning curve.  I wouldn't feel comfortable
leading the AM/LT project, but once Rafael (or some other knowledgeable
volunteer) had time to lead that effort, then I would be willing to spend
some time on a CVS branch helping him with testing the new scheme. Once my
AM/LT leader and I were satisfied, I would hope the rest of the developers
would give the AM/LT configuration a try so that we were all comfortable
bringing it to CVS head for final refinement.

So I am looking for an AM/LT leader I could follow.  Rafael would be ideal
for this role (and we have worked well together before), but he may not be
able to make a time commitment in the near future so we may have to rely on
somebody 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] wish list for the colour palettes

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

On Wed, 6 Feb 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > ./x08c -dev tk
>  >
>  > *** PLPLOT WARNING ***
>  > Driver does not support hardware solid fills, switching to software fill.
>  >
>  > That software fill is really slow and ugly (;-) compared to the hardware
>  > fill we had before.
>
> That's really strange.  Could you try a complete rebuild to see if it's a
> dependency problem?

Thanks for that suggestion which was bang on.

make clean
./configure ....
make
cd tmp; make x08c

fixed the problem.  I usually do go through a clean rebuild (sometimes even
clean from a cvs checkout), but this one time I didn't do that, it bit me.
Live and learn....

BTW, I played with the 2-point palette here, and you get an awesome looking
silvery gray colour if you play with the black.  I will probably put that
in.

Your other fix for ./plserver -f tk03 works fine here as well.  Time for a
new release?....;-)

Alan

Re: [Plplot-devel] cvs HEAD version multipage looks better, but there is now a tk03 problem

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

Alan W. Irwin writes:
 > However, I also noticed there was a problem with the following command:
 > 
 > ./plserver -f tk03
 > 
 > If you hit the new button it generates the following error box:
 > 
 > Error: can't read "plmenu_lstat_depth(.1.plw)": no such variable

Fixed now, thanks for bringing it to my attention.

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

Re: [Plplot-devel] wish list for the colour palettes

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

Alan W. Irwin writes:
 > > Whoops, dunno what I was looking at, now it looks fine. :)  So AFAIK am all
 > > done on this point for now.
 > 
 > Thanks very much for these changes.  The non-default colour palette works
 > for me as well.
 > 
 > However, another problem seems to have been introduced on my system.
 > 
 > ./x08c -dev tk
 > 
 > *** PLPLOT WARNING ***
 > Driver does not support hardware solid fills, switching to software fill.
 > 
 > That software fill is really slow and ugly (;-) compared to the hardware
 > fill we had before.

That's really strange.  Could you try a complete rebuild to see if it's a
dependency problem?

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

Re: [Plplot-devel] wish list for the colour palettes

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

> Whoops, dunno what I was looking at, now it looks fine. :)  So AFAIK am all
> done on this point for now.

Thanks very much for these changes.  The non-default colour palette works
for me as well.

However, another problem seems to have been introduced on my system.

./x08c -dev tk

*** PLPLOT WARNING ***
Driver does not support hardware solid fills, switching to software fill.

That software fill is really slow and ugly (;-) compared to the hardware
fill we had before.

Alan

Re: [Plplot-devel] wish list for the colour palettes

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

Maurice LeBrun writes:
 > Maurice LeBrun writes:
 >  > Maurice LeBrun writes:
 >  >  > Alan W. Irwin writes:
 >  >  >  > Finally, I noticed when checking example 8 that no attempt (as far as I
 >  >  >  > could tell) was made to display the working palette.  Instead when the cmap1
 >  >  >  > palette was pressed, immediately the gray scale was turned into the default
 >  >  >  > colour scheme.
 >  >  > 
 >  >  > Right, this is a side effect of the brute force initialization of the color
 >  >  > map.  It will go away after I change x08c to use plscmap1l() instead.
 >  > 
 >  > I was wrong about this, even with my change the default map is still installed
 >  > when bringing up the palette tool.  I'll look into it.. probably a quick fix.
 > 
 > OK, it works now, at least my test using x08c.  I did notice that the plframe
 > widget wasn't propagating the 'rev' flag correctly, not used in this test.
 > Will get to that tomorrow.

Whoops, dunno what I was looking at, now it looks fine. :)  So AFAIK am all
done on this point for now.

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