plplot-general — PLplot user discussion group

Re: [Plplot-general] plplot TEA/tcl patch

[Vince D. <vi...@sa...>]

With some help from some scriptics folk, I have a Plplot-tk more or less
working.  You can grab all of this stuff from:

ftp://ftp.ucsd.edu/pub/alpha/tcl/extensions/plplot/

pltcl.patch -- minor patch to bindings/tcl
pltk.patch -- minor patch to bindings/tk

tcltk.tar.gz -- config/make files for 'Matrix' shared lib
pltcltk.tar.gz -- config/make files for Pltcl shared lib
pltk.tar.gz -- config/make files for Pltk shared lib.

Readme.txt -- brief description.

Untar any one of the .tar.gz archives into 'bindings', cd into there and
type:

autoconf
./configure (possibly with some flags)
make
make install

and they should work.  Once this stuff seems to work I can integrate my
source code changes with a fair confidence that they won't break things.

-- Vince

<http://www.santafe.edu/~vince>

Re: [Plplot-general] plplot TEA/tcl patch

[Vince D. <vi...@sa...>]

For the more ambitious, I've now added 'pltcltk.tar.gz' to that same ftp
directory (and a slightly updated pltcl.patch).  'pltcltk.tar.gz' is
another TEA directory which can compile all of plplot's 'tcl' 'src' and
'drivers' directories (well, not all the drivers), and link everything
into a 'Pltcl' shared library which you can load into Tcl.

Again, 'autoconf, configure, make, make install' should allow you to do
'package require Pltcl' from inside a tcl shell.  This code uses the
headers in 'tmp' generates by the standard Plplot configuration.

I don't yet know how to compile TEA compliant Tk extensions (my real
goal),...

cheers,

-- Vince

<http://www.santafe.edu/~vince>

[Plplot-general] plplot TEA/tcl patch

[Vince D. <vi...@sa...>]

Making progress on breaking out my changes.  The first step seems to be to
get something with Tcl/plplot to build properly using the TEA framework
for Tcl extensions.  On that front I've prepared the necessary
configure.in/makefile.in which allow the 'Matrix' piece of Plplot to be
compiled as a standalone Tcl extension (shared library which can be loaded
into Tcl, via 'load' or 'package require Matrix').

The necessary changes are tiny (but more will be required when I begin to
tackle the real pl-tcl and pl-tk parts of plplot).  However it would be
useful if someone could verify that this actually works on some unix
platform (it works fine on Windows under cygwin).

All that should be required is:

autoconf
./configure
make
make install

And then in a tcl or tk shell, try

package require Matrix

which should return '0.1' and make the 'matrix' command available.

The only complication to the above is that you might need to specify some
directories to './configure'.  This is documented in a readme in my
changes.

If you'd like to try, please grab 'pltcl.patch' and 'tcltk.tar.gz' from

ftp://ftp.ucsd.edu/pub/alpha/tcl/extensions/

(please ignore the other plplot related stuff in there!)

'pltcl.patch' is a cvs-extracted diff to be applied to the files in
bindings/tcl (very minor changes to plplot 5.1 from cvs)

'tcltk.tar.gz' is a NEW directory, to be placed alongside bindings/tcl and
bindings/tk.  The idea is that it will contain the TEA compliant
configure/makefile stuff to build Tcl/Tk extensions using the source code
in the rest of plplot.  There is a readme in that directory.

I stress: this works 'out of the box' in cygwin, and ought to (if the TEA
designers got it right) work similarly on unix.  You will need a
reasonably modern version of Tcl/Tk installed (e.g. 8.1-8.3).  The
resulting shared library should be loadable into _any_ Tcl release 8.1 or
newer.

cheers,

-- Vince

<http://www.santafe.edu/~vince>

RE: [Plplot-general] RE: patches,..(long)

[Phil A. <ph...@ge...>]

Geoffrey Furnish writes:

 > My suggestions:
 > 
 > Get a cvs client for NT.  I have one on my little-used NT box here.  I 
 > forget where I got it.  I either compiled it myself, or perhaps I got
 > it from one of the various NT unix-goods stockpile sites.  There is
 > somebody who has XEmacs, X11, etc, maybe I got it from there.
 > 

For pointers on the compilation, check out two links at:

http://www.hirmke.de/software/develop/gnuwin32/cygwin/
              porters/Hirmke_Michael/GNUWin32-links.html :

http://www.hirmke.de/software/develop/gnuwin32/cygwin/
             porters/Wilson_Charles_S/V1.1/cvs-1.10/cvs-1.10-1-cygwin1.1.README
              


 http://www.hirmke.de/software/develop/gnuwin32/cygwin/
             porters/van_Woerkom_Marc_E_E/cvs-1.10-cygwin.README

Phil

RE: [Plplot-general] RE: patches,..(long)

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

Vince Darley writes:
 > >  > My changes are quite varied, so hopefully I'll be able to
 > >  > split them into a number of separate, independent patches.
 > >  > However, before I start that, I have a couple of questions:
 > >  > 
 > >  > (i) Does plplot support building any form of loadable
 > >  > extension for Tcl/Tk?  (i.e. a shared library Plxxx50.so which
 > >  > can be loaded into Tcl/Tk via 'load Plxxx50').
 > > 
 > > No, not at this time.  This is an obviously desirable improvment.
 > 
 > I'll probably try to create patches first which simply add
 > cross-platform Tk support to Plplot, and later work on adding
 > things like this (since I haven't compiled this code on unix for at
 > least 3 years, my makefiles are probably rather grotty).

By this to you mean owrk on your "tkwin" driver?

 > >  > (ii) Does plplot support cross-compilation (particularly for a cygwin
 > >  > hosted system to build linux executables)?
 > > 
 > > I don't know how to answer that question.  I've used cross tools
 > > before (for other things).  Ordinarily I am accustomed to just using a 
 > > particular gcc at a cerain path location, or mabye a stock gcc with a
 > > special -B or -V option to pick out the cross tool components.  To
 > > this extent--that is, just asuming your cross tool gcc/binutils are in 
 > > your path--it should "just work".  If you need some more specific kind 
 > > of support, please elaborate.
 > 
 > I mean so I can carry out a complete ./configure ; make on my windoze box,
 > yet have the executables generated work on whatever target I specify (e.g.
 > linux, solaris etc).  My simple tests didn't make it clear whether this
 > would really work or not (supposedly Tcl 8.x has a nice cross-compilation
 > ability, but I haven't really used that either).

Unless you have evidence to the contrary, it is my belief that this is 
simply a matter of chosing the gcc/binutils (putting them in your
path) which generate buidl products for the target environment.  The
only nit I can think of--is this what you're asking about?--is the
issue where configure runs little test compiles to try to
psychoanalyze the system.  In some cases it only tries to /compile/
things, but perhaps there are cases where it also tries to run the
resulting executable.  That would be a problem.  I don't know if there 
are cases where PLplot's configure script does or not.  If you find
that there are, I would be willing to try to help you develop ways to
circumvent this.

 > >  > (iii) Is there any configure/makefile support for non-unix based
 > >  > platforms?
 > > 
 > > Historically, Mac, OS/2, DOS/DJGPP and Amiga ports have all been done
 > > through a seperate makefile, independent of the unixoid configure at
 > > the top of the tree.  I've never gotten around to building on NT yet,
 > > but if I did, I would start by seeing if the existing configure script 
 > > would work okay on a cygwin platform.
 > 
 > I tried, and it doesn't look too good (not too bad either, though!).
 > Various problems arose (such as 'gcc not present', even though it is the
 > only compiler which is present).  I'll have to see what I can do. 

Well, the overall autoconf mechanism is certainly known to work on
cygwin.  All the GNU file and text utils that come with cygwin are
done that way for one thing.  Also, XEmacs works the same way (using
an autoconf-generated configure script).  So it definitely can be
done.  If there are shortcomings in PLplot's configure script, they
probably arise from the non-existence of NT cases in the various
switch blocks in plplot/cf/sysloc.cf and sysconf.cf.  I think it
shouldn't really be too hard to just visually scan that file and see
what is missing/wrong for NT.

I have an NT box here at Actel, I just never use it...  :-).

 > I'm not really sure of the best step forward from here!  I have a bunch of
 > code which has worked at varying times over the last 5 years on
 > Solaris/MacOS/Windows with various versions of Tk, and is currently in
 > constant use with Tk 8.3.1 on WinNT.  However I don't have access to a
 > linux machine I can actually do development on, so I don't really see a
 > sensible path to preparing useful patches without at least some help from
 > someone else: anyone willing to offer their services as a guinea pig?

My suggestions:

Get a cvs client for NT.  I have one on my little-used NT box here.  I 
forget where I got it.  I either compiled it myself, or perhaps I got
it from one of the various NT unix-goods stockpile sites.  There is
somebody who has XEmacs, X11, etc, maybe I got it from there.

Anyway, once you have your NT cvs client, you can do an anonymous
checkout of the plplot sources from cvs.plplot.org, straight to your
NT box.  Hack that code to your liking, then run cvs diff, and send in 
the patches.

In this mechanical respect, I don't think working on NT is much
different from unix.  I have certainly been able to successfully make
similar fixes to Actel code from my NT box here.

 > One approach I'm considering is that the core pl code should be compiled
 > into a shared library with the existing makefiles, and that the tcl/tk
 > dependent stuff should use it's own makefiles using the 'TEA' (Tcl
 > Extension Architecture) framework developed by the Tcl community which
 > should make it easy to turn 'C-code + pllibs + Tcl installation' into
 > something which will compile under any platform where Tcl/Tk works.
 > Perhaps this should be step 5, not step 1 however.  Advice appreciated!

I am definitely in favor of a TEA-based approach.  As it happens, I
downloaded the TEA docs that I could find just last week, and was
starting to look into that myself before I became distracted.  Not
sure when I could return to it myself at this point, but I definitely
agree that this is the desired plan of attack.

-- 
Geoffrey Furnish            Actel Corporation        fu...@ac...
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-522-8041

"... because only those who write the code truly control the project."
						      -- Jamie Zawinski

[Plplot-general] RE: patches,..(long)

[Vince D. <vi...@sa...>]

On Wed, 17 May 2000, Geoffrey Furnish wrote:
> Vince Darley writes:
>  > Some time soon I'm going to try to tackle the task of integrating my
>  > changes into 5.0.  
> 
> Please remember, new feature development goes on 5.1 (the cvs head).
> 5.0 is supposed to be a stabilization release, for minor bug fixes.

Sure!  I just mean the task of producing sensible patches which you and
the rest of the plplot dev. team can decide whether to include or not, at
whatever version number is appropriate.

>  > My changes are quite varied, so hopefully I'll be able
>  > to split them into a number of separate, independent patches.  However,
>  > before I start that, I have a couple of questions:
>  > 
>  > (i) Does plplot support building any form of loadable extension for
>  > Tcl/Tk?  (i.e. a shared library Plxxx50.so which can be loaded into Tcl/Tk
>  > via 'load Plxxx50').
> 
> No, not at this time.  This is an obviously desirable improvment.

I'll probably try to create patches first which simply add cross-platform
Tk support to Plplot, and later work on adding things like this (since I
haven't compiled this code on unix for at least 3 years, my makefiles are
probably rather grotty).

>  > (ii) Does plplot support cross-compilation (particularly for a cygwin
>  > hosted system to build linux executables)?
> 
> I don't know how to answer that question.  I've used cross tools
> before (for other things).  Ordinarily I am accustomed to just using a 
> particular gcc at a cerain path location, or mabye a stock gcc with a
> special -B or -V option to pick out the cross tool components.  To
> this extent--that is, just asuming your cross tool gcc/binutils are in 
> your path--it should "just work".  If you need some more specific kind 
> of support, please elaborate.

I mean so I can carry out a complete ./configure ; make on my windoze box,
yet have the executables generated work on whatever target I specify (e.g.
linux, solaris etc).  My simple tests didn't make it clear whether this
would really work or not (supposedly Tcl 8.x has a nice cross-compilation
ability, but I haven't really used that either).

>  > (iii) Is there any configure/makefile support for non-unix based
>  > platforms?
> 
> Historically, Mac, OS/2, DOS/DJGPP and Amiga ports have all been done
> through a seperate makefile, independent of the unixoid configure at
> the top of the tree.  I've never gotten around to building on NT yet,
> but if I did, I would start by seeing if the existing configure script 
> would work okay on a cygwin platform.

I tried, and it doesn't look too good (not too bad either, though!).
Various problems arose (such as 'gcc not present', even though it is the
only compiler which is present).  I'll have to see what I can do. 

I'm not really sure of the best step forward from here!  I have a bunch of
code which has worked at varying times over the last 5 years on
Solaris/MacOS/Windows with various versions of Tk, and is currently in
constant use with Tk 8.3.1 on WinNT.  However I don't have access to a
linux machine I can actually do development on, so I don't really see a
sensible path to preparing useful patches without at least some help from
someone else: anyone willing to offer their services as a guinea pig?

One approach I'm considering is that the core pl code should be compiled
into a shared library with the existing makefiles, and that the tcl/tk
dependent stuff should use it's own makefiles using the 'TEA' (Tcl
Extension Architecture) framework developed by the Tcl community which
should make it easy to turn 'C-code + pllibs + Tcl installation' into
something which will compile under any platform where Tcl/Tk works.
Perhaps this should be step 5, not step 1 however.  Advice appreciated!

cheers,

Vince

>  > p.s. Does plplot 5 fix the 'M = J' bug evident in the standard font
>  > library (but not the extended font lib)?
> 
> I haven't looked into the matter.

When I run the plplot demos (admittedly on windoze, with my shared lib
version of plplot loaded into tcl), I find that in demo 6, looking at the
uppercase letters, from 70-80, the sequence is J K L J N, i.e. M has been
substituted by J.  I actually put together a nice little script one case
use to run all the demos from a Tk interface.  You'll need to modify the
'package require Plplot' line, but beyond that it should work wherever you
can get 'plframe':

# RunDemos.tcl
#---------------------------------------------------------------------
# Source this file into a working Tk interpreter to run all the demos
# this file should be in plplot/examples/tcl/ 
#
# Vince Darley
# vi...@sa...
# 
#---------------------------------------------------------------------

lappend auto_path [pwd]
package require Plplot
plframe .p
grid .p -columnspan 5 -sticky news
grid rowconfigure . 0 -weight 1
for {set i 0} {$i < 5} {incr i} {
    grid columnconfigure . $i -weight 1
}

# turn on pauses
.p cmd plspause 1

button .bexit -text "Quit" -command exit
button .bshell -text "Shell" -command "console show"

set buttons [list .bexit .bshell]

for {set i 1} {$i <= [llength [glob x*.tcl]]} {incr i} {
    set demo x[format "%02d" $i]
    button .b$i -text "Demo $i" -command "$demo .p"
    lappend buttons .b$i
    if {[llength $buttons] == 5} {
	eval grid $buttons -sticky ew
	set buttons {}
    }
}

if {[llength $buttons]} {
    eval grid $buttons -sticky ew
}

RE: patches,..Re: [Plplot-general] PLplot 5.0.0 is released

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

Vince Darley writes:
 > Some time soon I'm going to try to tackle the task of integrating my
 > changes into 5.0.  

Please remember, new feature development goes on 5.1 (the cvs head).
5.0 is supposed to be a stabilization release, for minor bug fixes.

 > My changes are quite varied, so hopefully I'll be able
 > to split them into a number of separate, independent patches.  However,
 > before I start that, I have a couple of questions:
 > 
 > (i) Does plplot support building any form of loadable extension for
 > Tcl/Tk?  (i.e. a shared library Plxxx50.so which can be loaded into Tcl/Tk
 > via 'load Plxxx50').

No, not at this time.  This is an obviously desirable improvment.

 > (ii) Does plplot support cross-compilation (particularly for a cygwin
 > hosted system to build linux executables)?

I don't know how to answer that question.  I've used cross tools
before (for other things).  Ordinarily I am accustomed to just using a 
particular gcc at a cerain path location, or mabye a stock gcc with a
special -B or -V option to pick out the cross tool components.  To
this extent--that is, just asuming your cross tool gcc/binutils are in 
your path--it should "just work".  If you need some more specific kind 
of support, please elaborate.

 > (iii) Is there any configure/makefile support for non-unix based
 > platforms?

Historically, Mac, OS/2, DOS/DJGPP and Amiga ports have all been done
through a seperate makefile, independent of the unixoid configure at
the top of the tree.  I've never gotten around to building on NT yet,
but if I did, I would start by seeing if the existing configure script 
would work okay on a cygwin platform.

 > p.s. Does plplot 5 fix the 'M = J' bug evident in the standard font
 > library (but not the extended font lib)?

I haven't looked into the matter.

-- 
Geoffrey Furnish            Actel Corporation        fu...@ac...
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-522-8041

"... because only those who write the code truly control the project."
						      -- Jamie Zawinski

patches,..Re: [Plplot-general] PLplot 5.0.0 is released

[Vince D. <vi...@sa...>]

Some time soon I'm going to try to tackle the task of integrating my
changes into 5.0.  My changes are quite varied, so hopefully I'll be able
to split them into a number of separate, independent patches.  However,
before I start that, I have a couple of questions:

(i) Does plplot support building any form of loadable extension for
Tcl/Tk?  (i.e. a shared library Plxxx50.so which can be loaded into Tcl/Tk
via 'load Plxxx50').

(ii) Does plplot support cross-compilation (particularly for a cygwin
hosted system to build linux executables)?

(iii) Is there any configure/makefile support for non-unix based
platforms?

cheers,

-- Vince

p.s. Does plplot 5 fix the 'M = J' bug evident in the standard font
library (but not the extended font lib)?

[Plplot-general] PLplot 5.0.0 is released

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

Greetings to all,

And you thought it would /NEVER/ happen.  :-).

I am pleased to announce that PLplot version 5.0.0 has been released.
The rest of this email will attempt to explain exactly what this means 
in more detail.

First off, thanks to all the core team members who have helped with
various tasks that I could not attend to.  Not the least of which, is
the simple issue of deciding to do it, right now.

Now for a little background.  We are done with the 4.99 x, x=abc... 
business, as well as the dated snapshots.  Dated snapshots are being
replaced by providing anonymous cvs access through plplot.org.  So
anyone who wants to track day-to-day development, or follow progress
on their patch submissions, etc, will be able to do that by using cvs.

In addition to that, we will provide real releases which are supposed
to be stable, or at least to get stable over a short time.  The
releasing naming conventions will follow the Linux tradition.  Even
releases are supposed to be stable, and only bug fixes and
stabilization patches will be applied to these.  Thus, 5.0.0 is the
first in this strain.  If people find minor little nits that need
fixing, this will result in 5.0.1, 5.0.2, etc.  We hope it doesn't get 
too far...  Ongoing feature development will proceed in the 5.1
strain.

The release and versioning business is coordinated with cvs in the
following manner.  Stable releases go on a branch.  Ongoing
development continues on the cvs head.  To be really cvs technical, we 
provide a branch point tag, a branch tag, and release tags.  So, to be 
totally explicit, I did the following operations today when preparing
the 5.0.0 release:

1) cvs tag bp_v5_0
2) cvs rtag -b -r bp_v5_0 v5_0 plplot
3) cvs tag v5_0_0
4) cvs export -r v5_0_0 plplot
5) mv plplot/ plplot-5.0.0
6) tar cvzf plplot-5.0.0.tar.gz plplot-5.0.0/

Step 1 labels the state of the repository at the point in time when we 
fork the 5.0 release branch.  The name of the branch point for the 5.0 
release, is bp_v5_0.  Step 2 creates a cvs "branch tag" for referring
to the head of this branch.  The name of this tag is v5_0.  Step 3
creates a tag for the specific release 5.0.0, with tag name v5_0_0.
In the current case, there were no changes made between any of these
steps, so steps 1, 2, and 3 all refer to the same versions of the
files.  But as we move on from here, people who wish to participate in 
stabilizing the 5.0 branch will need to check out the head of this
branch via:

    cvs co -r v5_0 plplot

Then they can do stabilization oriented development, submit context
diffs, and the core team will apply these patches, and eventually at
various points along the way, we will tag v5_0_1, v5_0_2, etc.  So,
the thing to understand here is that "v5_0" is the branch tag.  It is
a floating reference, which alwasy points to the head of this branch.
Non branch tags just refer to static file versions, labelling a single
specific collection of file versions for all of time.

Henceforth, the main line of deveopment, which we will call 5.1,
proceeds on the cvs head.  There is no branch tag for this.  To see
the ongoing develoment work on the 5.1 branch, just do:

    cvs co plplot

Use update to track ongoing work, etc.  We may possibly tag a few
interesting points along the way as v5_1_0, v5_1_1, etc, but there
will not be a branch tag for this.  Eventually, when 5.1 development
seems to have run its course, we will fork another branch for 5.2,
making a new branch point tag bp_v5_2, a branch tag v5_2 to refer to
the head of the branch holding the 5.2 release strain, and occasional
tags for specific 5.2.x releases.

Hopefully that is comprehensible to people with a cvs background.  See 
the CVS faq for more background.  We'll try to put this kind of info
on the web site somewhere as we get better organized.

Anyway, in addition to the cvs access mechanisms described above, we
also are providing the 5.0.0 release as a .tar.gz file.  Steps 4, 5,
and 6 show exactly how this was created, guaranteeing that the
plplot-5.0.0.tar.gz file contains exactly the file versions that were
tagged as v5_0_0 in step 3, but omitting the CVS control information.
This tarball release is appropriate for people who just want the code
in a packaged form, and aren't interested in tracking the cvs
development specifically, or even in using cvs to fetch identified
versions.  This file has been uploaded to the plplot.org ftp site.
You can get it via:

    /ano...@ft...:/pub/plplot/plplot-5.0.0.tar.gz

Eventually we will get the www.plplot.org web site updated to reflect
this, and also figure out how to identify this file release on the
sourceforge.net project page for plplot.  Someone will post messages
about that as we progress in these other areas.  

Anyway, the bottom line is, right now you can get PLplot 5.0.0, either
by anonymous ftp, or by anonymous cvs.

Now for a word about the contents of 5.0.0.

The main thing that has happened over the past three years since I
escaped graduate school, is that we've been trying to fix bugs in the
autoconf support, and in the Tcl/Tk driver, and in color handling of
the X driver.  There have been a great many bugs rooted out of the
system over this period of time, and I would encourage all PLplot
users worldwide, to upgrade to 5.0.0 at this time.  This release is
known to work with 8.x strain Tcl/Tk releases, Itcl 3 releases, Python 
1.5, etc.  The problems with X color management are believed to be
resolved in a manner that is generally satisfactory (there's always
room for improvement in this area, but the current state is a big leg
up over where it was before in the 4.99j or in the early snapshots).
And numerous patch submissions from users worldwide have been
integrated (although admittedly there are more outstanding, pending
core team review).  There is also a new Mac driver by Rob Managan.
Currently just the necessary source and doc files, but we will get his 
Mac CW project support goods uploaded to ftp.plplot.org at some point
too.  So, there's been lots of improvement since the last release, and 
I hope people will endeavor to upgrade to this new version.  If things 
go wrong, please submit patches to sourceforge.net, and we'll work on
getting it stabilized.  

In the midst of such endeavors, please note the distinction between
bug fixes to 5.0.x, and feature development for ongoing 5.1.  The new
stuff is going to go into 5.1.  5.0.x is really there just to have an
up to date stable and official release for those who don't want to
track ongoing development.  As such, don't expect major new features
to appear in 5.0.x releases, just fixes that relate to platform
support, minor bugs, etc.

So, what lays ahead for 5.1?  Well, like I said before, that depends a 
lot on what people contribute.  My personal actions will focus in the
short term on better Tcl package participation and improved Python
module interaction.  But there are more drivers in the works, web
integration opportunities, more plot types, variations, and viewing
overhauls, etc, that various people have expressed interest in.  More
news as it happens.

Remember that you can track it all by subscribing to
plp...@pl..., or by reviewing the lists chronology in
geocrawler.  Or, you can use the cvs history command (also easily
accessible in Emacs fromt he version control pane), to see what people 
are doing, track your patch submissions to see when they get in, etc. 

Cheers to all,

-- 
Geoffrey Furnish            Actel Corporation        fu...@ac...
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-522-8041

"... because only those who write the code truly control the project."
						      -- Jamie Zawinski

[Plplot-general] mac support for plplot

[Rob M. <ma...@ll...>]

I have integrated my Macintosh port for plplot into the CVS archive 
files as of 05/09/2000.

Until I can get an anonymous ftp site set up please email me if you 
want to play with this. The archive contains a few files in the main 
distribution that were changed as well as a sys/mac directory.

It does need some work but wanted to get this old work available to 
those who will use it more than I do.

I have given the patches to the maintainers and we can hope to see it 
integrated into the CVS repository in the future.

-- 
*-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*-
Rob Managan       <mailto://ma...@ll...>
LLNL                      ph:  925-423-0903
P.O. Box 808, L-095       FAX: 925-422-3389
Livermore, CA  94551-0808

Re: [Plplot-general] old software for the Mac

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

Hello Rob,

There seems to be some interest in a Mac port on the list so I (speaking as
a member of the new plplot core team) would encourage you to bring your port
up to speed with the latest official release.  We have just started the
process of bringing that release out.  We will be calling it plplot-4.99k
(which will differ from 4.99j mostly in bug fixes that are in the cvs right
now).  We want to get this release done quickly so that people like you can
have something official and recent to test and evaluate against.

Alan W. Irwin

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

Linux-powered astrophysics
__________________________

On Mon, 8 May 2000, Rob Managan wrote:

> I used to have a sys/mac archive available at 
> ftp://ftp-lc.llnl.gov/pub/users/managan . This site is moving and 
> since the files are out of date I have removed them.
> 
> If there is a need for this software please email me directly.
> 
> -- 
> *-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*-
> Rob Managan       <mailto://ma...@ll...>
> LLNL                      ph:  925-423-0903
> P.O. Box 808, L-095       FAX: 925-422-3389
> Livermore, CA  94551-0808
> 
> 
> _______________________________________________
> Plplot-general mailing list
> Plp...@pl...
> http://lists.sourceforge.net/mailman/listinfo/plplot-general
> 
> 

[Plplot-general] old software for the Mac

[Rob M. <ma...@ll...>]

I used to have a sys/mac archive available at 
ftp://ftp-lc.llnl.gov/pub/users/managan . This site is moving and 
since the files are out of date I have removed them.

If there is a need for this software please email me directly.

-- 
*-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*-
Rob Managan       <mailto://ma...@ll...>
LLNL                      ph:  925-423-0903
P.O. Box 808, L-095       FAX: 925-422-3389
Livermore, CA  94551-0808

Re: [Plplot-general] Macintosh Port of PLplot

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

Tom,

I don't have a Mac or Codewarrior so cannot help you very much, but one
comment on your request is you should always include the exact
version of plplot in your report.  You refer to the Mac port, but what
version of the software does this correspond to?

Personally, I have found the developers snapshot for Jan 22 1999 to be quite
stable for Linux, and I suggest if you are using anything earlier than that
you should try an upgrade to see if that solves your problem.  I notice
on http://www.plplot.org/ there is mention of a Mac port right next to
mention of the developer's snapshot, but I am not clear whether those
correspond to essentially the same code base.

I was going to refer you to a link for the Jan 22 1999 version of plplot,
but it turns out that link is currently broken on our web site.  Bear with
us, we are still getting these "teething troubles" straightened out for
our new location at sourceforge.

Alan W. Irwin

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

Linux-powered astrophysics
__________________________

On Thu, 4 May 2000, Thomas O. Minahan wrote:

> To Whom It May Concern -
> 
> I am having problems getting the Mac port of PLplot (originally done with
> Think C) to compile using Metrowerk's Codewarrior.
> 
> For example, the struct _FILE defined in the Codewarrior file "cstdio"
> (included from "stdio.h") does not have a field for a window pointer, which
> is used by PLplot, e.g.
> 
> macx.c:     PLwindow = (WindowPtr) dev->graph_fp->window;
> 
> where graph_fp is a pointer to a file structure.
> 
> Does anybody have a Mac port of PLplot that compiles and works using
> Codewarrior?
> 
> Tom Minahan, PhD.
> mi...@dc...
> 
> 

[Plplot-general] Macintosh Port of PLplot

[Thomas O. M. <mi...@dc...>]

To Whom It May Concern -

I am having problems getting the Mac port of PLplot (originally done with
Think C) to compile using Metrowerk's Codewarrior.

For example, the struct _FILE defined in the Codewarrior file "cstdio"
(included from "stdio.h") does not have a field for a window pointer, which
is used by PLplot, e.g.

macx.c:     PLwindow = (WindowPtr) dev->graph_fp->window;

where graph_fp is a pointer to a file structure.

Does anybody have a Mac port of PLplot that compiles and works using
Codewarrior?

Tom Minahan, PhD.
mi...@dc...

Re: [Plplot-general] Welcome to the new era of PLplot!

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

Burkhard Neinhues writes:
 > With the CVS open for the public development should be much easier.
 > However I cecked out the latest CVS sources and I missed some files
 > which are neccessary to generate the configure file.  Is it
 > possible for you to include them ?

Those are under plplot/cf.  Cd there, and issue "autoconf".  You will
need autoconf 2.12 I think.  Then mv configure ..

 > BTW, is there any reason to link nearly all files in a tmp directory
 > before actually compiling them?

This is an involved topic.  I am well aware of the way that
autoconf-based projects ordinarily use the "compile in place" mode of
operation.  I have a number of beefs with that development model.  I
guess it works okay if all you have to do is download some pacakge and 
run configure; make; make install.  That's all most people do with the 
average autoconf based package they pull of prep.ai.mit.edu.

My feeling is that this is woefully inadequate for software
/development/, as opposed to merely "software building" described
above.

For one thing, PLplot supports a bazillion different configurations,
OS's, etc.  I find it very handy to be able to mkdir tmp1 tmp2 tmp3
tmp-u-name-it, and run a different variation of configure in each, so
that all can be regression tested simultaneously against the same
identical sources.

Yes, I know, --srcdir could be applied here.  Another beef I have with 
that model, is the difficulty of combining many build products whose
sources live in many different directories, into a single library if
using that model.

 > Another option would be the use of libtool to generate the
 > library. I may be able to incoporate this, but it would be nice to
 > have the files to regenerate the configure script as a start.

All in all, I much prefer to stick with the softlinking to tmp motif,
but if someone wants to overhaul the build rules themselves to use
libtool for building archive/shared libs uniformly on all known-by-GNU
platforms, that sounds like welcome improvement to me.

Anyway, see plplot/cf.

-- 
Geoffrey Furnish            Actel Corporation        fu...@ac...
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-522-8041

"... because only those who write the code truly control the project."
						      -- Jamie Zawinski

[Plplot-general] Welcome to the new era of PLplot!

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

Hello Everyone,

Welcome to the new era of PLplot!

With many apologies to all for the extreme delays that have been
incurred over the past months, it gives me great pleasure to be able
at this time, to finally provide details of the reorganization of the
PLplot project.

As most of you know, PLplot was hosted at dino.ph.utexas.edu during
the time that Maurice and I were employed at the Institute for Fusion
Studies, at the University of Texas at Austin.  dino continued as the
host for PLplot after we each moved on, but we were searching for a
suitable place to relocate the project.  As I am sure you all know,
the open source software movement has gained a lot of steam in recent
times, and there were a number of organizations willing to host
PLplot.  Of course we deeply appreciate the offers of sponsorship
tendered by all of these organizations.  However, it turned out that
the technical challenges of hosting a project like this, were not fully
appreciated by all such sponsoring agencies.  Curiously, we were a
little hobbled in a sense, by being just a hair ahead of the curve,
and wound up sinking significant amounts of effort into rehosting
PLplot at two sites that ultimately simply didn't have the
sophistication to quite bring the task to closure.

The final resting place, is sourceforge.net, operated by VA Linux.
PLplot now has its own domain, plplot.org, and a variety of services
accessible through this domain.  The domain is hosted by
sourceforge.net.  I will explain the current services available
through this domain below.  If anyone in the user base wants to thank
VA Linux for their sponsorship of the PLplot project, you could send
email to Chris DiBona <ch...@va...> to express your
appreciation.  Our web site will also contain attribution to this
effect, once we get it put together.

Now, on to the list of services provided through plplot.org.

First, the new official web site for PLplot is www.plplot.org.  Randy
is the web master, and will be bringing this up as time permits.  For
starters, he has imported the prior PLplot web site by Noel Gorelick,
and will be expanding from here.

Second, we now export the PLplot CVS repository via anonymous CVS at
cvs.plplot.org.  From now on, anyone will be able to obtain the latest 
version of PLplot using anonymous CVS.  CVS  has become the darling
source control system of the open source movement, and deservedly so.
I won't take the time in this message to attempt to explain this in
detail.  There are other resources on the net, and at sourceforge.net
in particular, which do this job.  The very short story is that you
can do this:
    setenv CVSROOT :pserver:ano...@cv...:/cvsroot/plplot
    cvs login
    <no password required, just hit return>
    cvs co plplot
Once you have done this, you will be able to track ongoing development 
(if you wish) by doing a "cvs update" from time to time.

Third, there will be anonymous ftp as well.  We don't have anything up 
there yet, so information will be forthcoming on this once we finally
put some files up there.  Probably we will put up the same files that
were on dino, providing the historical "releases", and in the future
we may make pacakged tarballs of future releases.  Anyway, more info
on that once there is something concrete to report.

Fourth, there is a new mailing list, "plp...@pl...".  All
subscribers to the old list (pl...@di...) have been
transfered to the new list.  Also, a few people who've sent me email
over the last fewmonths have been added as well (that is, the requests
I could still locate in my inbox :-).  You should've just received a
message from the list manager explaining to you how you can interact
with it.  Sourceforge.net uses "mailman", which is a bit different
from what we used before (majordomo), but there is plenty to like
about mailman if you haven't encountered it before.  Primarily it
interacts with subscribers through a web interface, so you have much
greater personal control over how it interacts with you.  In
particular, I hope that this will finally put an end to the
desperation "get me off this list" problem we were having before.
Please, if you want off, just go the mailman management page, and do
the job!  But you can also use it to control numerous delivery options
including digesting, etc.

One thing that we were not able to do, is to get the old majordomo
mailing list archives, directly imported into the new list manager.
We'll probably put those historic list archives up on the anon ftp
site somewhere so you can still get them if you want.  Anyway, mailing 
list traffic from this point forward /is/ being archived, just not
combined with the old stuff.  Oh well.

Anyway, "plp...@pl..." supercedes the old list.  The old
one is down anyway as everyone probably knows.  The story on that is
that dino actually suffered a cataclysmic hardware failure last fall,
just as we were about to move off to sourceforge.  This resulted in
lost time as we scurried to restore the filesystems, recover the
PLplot cvs repository, etc.  If anybody wants to thank the IFS staffer 
who exerted heroic effort to help us recover from this disaster, you
could send email to Jim Dibble <di...@pe...>, to
express your gratitude.  He worked really hard to help dig us out of
that ditch.

Besides "plp...@pl...", there is also
"plp...@pl...", to which cvs commit messages will be sent
when developers with write access to the repository commit changes.
If you haven't used cvs before, let me just say that these commit
messages are an extremely valuable way to keep abreast of what is
going on in a software development project.  It results in a certain
amount of email, so if that bothers you, you won't want to be on that
list (or you should make sure you have a filtering agent so you can
control the inbound flux to your liking).  But if you just want to
have a very low-overhead way to keep tabs on what is going on, who's
done what when, who's patches have been applied to the repository,
etc, subscribing to plp...@pl... is an excellent idea.  If
you are one of the people who makes occasional patch submissions, you
might want to subscribe at least long enough to watch for when your
changes go in, for example.

Fifth, there is a "project page" at sourceforge.net:
       http://sourceforge.net/project/?group_id=2915
We will probably have a link to this somewhere on the www.plplot.org
home page.  Anyway, people who are tapped into how sourceforge works,
may find this useful.  Frankly, none of the current developers have a
clue what to do with all this stuff, so we're all learning here, and
will all have to collectively help educate ourselves about how to get
the most value out of this.  Anyway, one thing that is fairly easy to
access from here, is a browsable portal onto the CVS repository,
orchestrated through "CVS Web", modified by sourceforge.net.  There is
lots to explore at sourceforge.net, far more than I am even remotely
aware of or could convey in this message.  We will all have to learn
together how to best exploit this resource for the open source
community.  

Finally, a word about people.  As long time participants on this
mailing list will remember, there has long been a lot of frustration
over the difficulty of getting patches into PLplot.  This has
primarily been a function of the fact that Maurice and I are both out
of the university scene now, holding down real day jobs with real
professional commitments, and simply haven't been able to provide the
bandwidth to support the pace of development of an open source project
like PLplot.  We (and here "we" means the entire PLplot community)
certainly appreciate and have benefited from the valuable
contributions offered by many over the years, but my personal failure
to rapidly incorporate everyone's work, has been a key liability for
the project.  Correcting this critical problem, was one of the primary
goals in seeking a rehosting arrangement for PLplot.

This vision has now FINALLY! been realized.  At this time, there are a 
total of five people with write access to the repository:

myself
Maurice
Alan W. Irwin
James Phillips (randy)
Rafael Laboissiere

Alan and Rafael have been overhauling the documentation of late, and
that will be showing up for public consumption before long.  And Randy 
is picking up the webmaster role.

Exactly how we will deal with inbound patch submissions has not been
fully worked out, but my point here is, at least /I/ am no longer the
bottleneck.  We have a publicly accessible host, we are exporting the
CVS repo through anoncvs, and we have multiple people who can act to
get patches applied.  These are the reasons for regarding this as the
dawn of the new era of PLplot.  I would like to take this chance to
publicly thank Alan, Randy and Rafael for joining Maurice and I in
this capacity, and for both the work they have already done, and will
be doing as we move forward.

it has been a long time in coming (too long), but I hope that all
PLplot users everywhere will share my enthusiasm as we enter the new
millenium with a revitalized PLplot project.

I suppose in closing, it would be good to say some words about what is 
really going on with the software itself.  Curiously, this is the part 
I am least able to address.  And in a strange but real sense, that is
the best part of this message.  I have no idea what is ahead of us.
It really just depends on what the world wide open source developer
community pulls out of their hats (keyboards).

Onward Ho!

-- 
Geoffrey Furnish            Actel Corporation        fu...@ac...
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-522-8041

"... because only those who write the code truly control the project."
						      -- Jamie Zawinski

[Plplot-general] test

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

#2