Thread: [Plplot-devel] State of the Union

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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

[truncated message content]

Thread: [Plplot-devel] State of the Union

Cross-platform, scientific graphics plotting library

plplot-devel