plplot-devel — Technical discussion about PLplot development

[Plplot-devel] Our web page

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

Hi,

Some days ago I have downloaded a new version of the examples directory=20
to sourceforge, and forgot to advertise it.

Can you please take a look? Specially people with IE-6.x? I checked it=20
with konqueror-3.0.4, galeon-1.2.6, opera-6.0.2 and mozilla-1.0.1 on=20
linux, ie-6.0 on win98 and XP -- everything OK. Netscape 4.79 on linux=20
doesn't give the same results as others.

Suggestions? Shall I cvs commit the changes and start using it as=20
default? One problem is that it is using the examples in the current=20
cvs tree, not the official release.

http://plplot.sourceforge.net/nexamples/

Joao

[Plplot-devel] Re: float or double under W2000

[Olof S. <sve...@es...>]

Joachim Wuttke wrote:
> 
> I built the plplot/tmp stuff with configuration option --with-double,
> then I went to sys/win32/msdev and built plplib/plplot.lib without any further explicit configuring.

The sys/win32/msdev port of plplot doesn't make use of configure, just
nmake as mentioned in the INSTALL.txt file. How did you manage to run
configure? Did you use cygwin? 
 
> As far as I see, the resulting object expects me to pass data as floats.
> Is that correct, and how could I possibly build a double precision plplotd.lib ?

As I didn't make use of configure I hardwired the compilation options
into the makefile in plplot/sys/win32/msdev. If you'd like to use double
instead of float make the following change and run nmake again:

Makefile with float (i.e. current one):

> #
> # Create plconfig.h file
> #
>   @echo ``
>   @echo `Creating $(PLTMP)\plplot\plconfig.h`
>   @echo <<$(PLTMP)\plplot\plconfig.h
> #ifndef __PLCONFIG_H__
> #define __PLCONFIG_H__
> #define LIB_DIR "$(PLLIB:\=\\)"
> #define BIN_DIR "$(PLBIN:\=\\)"
> #define PLPLOT_VERSION "5.1.0"
> #endif
> <<keep

Makefile with double:

> #
> # Create plconfig.h file
> #
>   @echo ``
>   @echo `Creating $(PLTMP)\plplot\plconfig.h`
>   @echo <<$(PLTMP)\plplot\plconfig.h
> #ifndef __PLCONFIG_H__
> #define __PLCONFIG_H__
> #define LIB_DIR "$(PLLIB:\=\\)"
> #define BIN_DIR "$(PLBIN:\=\\)"
> #define PLPLOT_VERSION "5.1.0"
> #define PL_DOUBLE 1
> #endif
> <<keep

I hope this helps,

Olof

[Plplot-devel] float or double under W2000

[Joachim W. <wu...@cr...>]

I built the plplot/tmp stuff with configuration option --with-double,
then I went to sys/win32/msdev and built plplib/plplot.lib without any =
further explicit configuring.

As far as I see, the resulting object expects me to pass data as floats.
Is that correct, and how could I possibly build a double precision =
plplotd.lib ?

- Joachim=20

Re: [Plplot-devel] memory leaks under Windows2000

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

On Wednesday 27 November 2002 12:16, Olof Svensson wrote:
| Hi Joachim,
|
| Joachim Wuttke wrote:
| > On running the minimal application
| >
| > main (..) {
| >     plottest();
| > }
| >
| > void plottest () {
| >     plsdev("win3");
| >     plinit();
| >     plend();
| > }
| >
| > under Visual C++ 6.0, the debugger detects memory leaks.
| > The message looks like:
| >
| > Detected memory leaks!
| > Dumping objects ->
| > {50} normal block at 0x002F2908, 48 bytes long.
| >  Data: < hC  hC     *   > B0 68 43 00 A8 68 43 00 FF FF FF FF 2A 00
| > 00 00 {49} normal block at 0x002F2890, 48 bytes long.
| >  Data: <`iC xiC         > 60 69 43 00 78 69 43 00 00 00 00 00 1E 00
| > 00 00 ......

Are these the only memory leaks? They are very modest... 48 bytes...
Some leaks are expected, as for example when one duplicates a string  or=20
open a new plot/device.

In unix if we use 'valgrind' we also find leaks, but they are static,=20
i.e., they dont increasing with program complexity or looping.
As a matter of fact 'valgrind' finds more leaks in system libraries such=20
as X11 than in plplot:


[jcard@feup] /src/valgrind-20020226/valgrind --leak-check=3Dyes ./x01c=20
-dev xwin
=3D=3D6103=3D=3D valgrind-20020226, a memory error detector for x86 GNU/L=
inux.
=3D=3D6103=3D=3D Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward=
=2E
=3D=3D6103=3D=3D For more details, rerun with: -v
=3D=3D6103=3D=3D=20
Plplot library version: 5.1.0
=3D=3D6103=3D=3D=20
=3D=3D6103=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 31 =
from 3)
=3D=3D6103=3D=3D malloc/free: in use at exit: 29255 bytes in 613 blocks.
=3D=3D6103=3D=3D malloc/free: 745 allocs, 132 frees, 115299 bytes allocat=
ed.
=3D=3D6103=3D=3D For counts of detected errors, rerun with: -v
=3D=3D6103=3D=3D searching for pointers to 613 not-freed blocks.

Look here                                         ^^^^^^^^^^^^^^^^^^

=3D=3D6103=3D=3D checked 5260452 bytes.
=3D=3D6103=3D=3D=20
=3D=3D6103=3D=3D definitely lost: 546 bytes in 5 blocks.

Look here                        ^^^^^^^^^^^^^^^^^^

=3D=3D6103=3D=3D possibly lost:   0 bytes in 0 blocks.
=3D=3D6103=3D=3D=20
=3D=3D6103=3D=3D 13 bytes in 1 blocks are definitely lost in loss record =
10 of=20
52
=3D=3D6103=3D=3D    at 0x400640BB: malloc (vg_clientmalloc.c:590)
=3D=3D6103=3D=3D    by 0x41ED903D: resolve_name (in=20
/usr/X11R6/lib/libX11.so.6.2)
=3D=3D6103=3D=3D    by 0x41ED9A89: _XlcLocaleDirName (in=20
/usr/X11R6/lib/libX11.so.6.2)
=3D=3D6103=3D=3D    by 0x41ED300E: _XlcDynamicLoad (in=20
/usr/X11R6/lib/libX11.so.6.2)
=3D=3D6103=3D=3D=20
=3D=3D6103=3D=3D 21 bytes in 2 blocks are definitely lost in loss record =
13 of=20
52
=3D=3D6103=3D=3D    at 0x400640BB: malloc (vg_clientmalloc.c:590)
=3D=3D6103=3D=3D    by 0x402BDE31: plstrdup (in=20
/home/jcard/plplot-head/tmp/libplplotd.so.5.1.0)
=3D=3D6103=3D=3D    by 0x402B96D8: plInitDispatchTable (in=20
/home/jcard/plplot-head/tmp/libplplotd.so.5.1.0)
=3D=3D6103=3D=3D    by 0x402B894B: pllib_init (in=20
/home/jcard/plplot-head/tmp/libplplotd.so.5.1.0)
=3D=3D6103=3D=3D=20
=3D=3D6103=3D=3D 112 bytes in 1 blocks are definitely lost in loss record=
 25 of=20
52
=3D=3D6103=3D=3D    at 0x400640BB: malloc (vg_clientmalloc.c:590)
=3D=3D6103=3D=3D    by 0x41E82CFA: XCreateGC (in /usr/X11R6/lib/libX11.so=
=2E6.2)
=3D=3D6103=3D=3D    by 0x41E0BC60: Init (in=20
/home/jcard/plplot-head/tmp/drivers/xwind_drv.so)
=3D=3D6103=3D=3D    by 0x41E0ABBD: plD_init_xw (in=20
/home/jcard/plplot-head/tmp/drivers/xwind_drv.so)
=3D=3D6103=3D=3D=20
=3D=3D6103=3D=3D 400 bytes in 1 blocks are definitely lost in loss record=
 40 of=20
52
=3D=3D6103=3D=3D    at 0x400640BB: malloc (vg_clientmalloc.c:590)
=3D=3D6103=3D=3D    by 0x41E9BC7B: XGetVisualInfo (in=20
/usr/X11R6/lib/libX11.so.6.2)
=3D=3D6103=3D=3D    by 0x41E0E4F4: AreWeGrayscale (in=20
/home/jcard/plplot-head/tmp/drivers/xwind_drv.so)
=3D=3D6103=3D=3D    by 0x41E0BB5B: OpenXwin (in=20
/home/jcard/plplot-head/tmp/drivers/xwind_drv.so)
[jcard@feup]=20


|
| Oh dear. Which version are you using, the latest release 5.1.0 or the
| latest CVS version? I have made some changes since the last release
| so if you're not doing so already make a try with the latest CVS
| version.
|
| I must admit that I have never tried the MSVC++ 6.0 debugger. Could
| you please send me the instructions on how to make the debugger
| detect the memory leak?
|
| Regards,
|
| Olof Svensson
| ESRF
|
|
| -------------------------------------------------------
| This SF.net email is sponsored by: Get the new Palm Tungsten T
| handheld. Power & Color in a compact size!
| http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] memory leaks under Windows2000

[Olof S. <sve...@es...>]

Hi Joachim,

Joachim Wuttke wrote:
> 
> On running the minimal application
> 
> main (..) {
>     plottest();
> }
> 
> void plottest () {
>     plsdev("win3");
>     plinit();
>     plend();
> }
> 
> under Visual C++ 6.0, the debugger detects memory leaks.
> The message looks like:
> 
> Detected memory leaks!
> Dumping objects ->
> {50} normal block at 0x002F2908, 48 bytes long.
>  Data: < hC  hC     *   > B0 68 43 00 A8 68 43 00 FF FF FF FF 2A 00 00 00
> {49} normal block at 0x002F2890, 48 bytes long.
>  Data: <`iC xiC         > 60 69 43 00 78 69 43 00 00 00 00 00 1E 00 00 00 ......

Oh dear. Which version are you using, the latest release 5.1.0 or the
latest CVS version? I have made some changes since the last release so
if you're not doing so already make a try with the latest CVS version.

I must admit that I have never tried the MSVC++ 6.0 debugger. Could you
please send me the instructions on how to make the debugger detect the
memory leak?

Regards,

Olof Svensson
ESRF

[Plplot-devel] memory leaks under Windows2000

[Joachim W. <wu...@cr...>]

On running the minimal application

main (..) {
    plottest();
}

void plottest () {
    plsdev("win3");
    plinit();
    plend();
}

under Visual C++ 6.0, the debugger detects memory leaks.
The message looks like:

Detected memory leaks!
Dumping objects ->
{50} normal block at 0x002F2908, 48 bytes long.
 Data: < hC  hC     *   > B0 68 43 00 A8 68 43 00 FF FF FF FF 2A 00 00 =
00=20
{49} normal block at 0x002F2890, 48 bytes long.
 Data: <`iC xiC         > 60 69 43 00 78 69 43 00 00 00 00 00 1E 00 00 =
00 ......

- Joachim

[Plplot-devel] examples/f77 builds now work on AT with make -f Makefile.examples

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

As Rafael mentioned last year, the fortran wrapper library, libplf77 was
easily split from libplplot in AM-LT, and I am continuing that with AT (with
a hierarchichal linking fix which I have just committed).  Furthermore, with
this scheme, the fortran apps only need to link with the fortran wrapper
library, libplf77. (See the installed examples/f77/Makefile.examples.)

The fortran examples built by

cd $prefix/lib/plplot-5.1.0/examples/f77; make -f Makefile.examples

execute without problems.

So essentially at the press of an (autotools) button we get what Maurice and
I have wanted for years.

To keep some balance here, I must emphasize that there is bound to be
glitches when you first try AT because I just cannot do as extensive testing
as the combination of the rest of the developers.  Furthermore, AT is a
paradigm shift from the old way of configuring our package so that is bound
to produce some irritation and frustration at the new way of doing things.

However, I am having a lot of trouble keeping unbiased here as everything
I tackle seems to fall into place.  I think you will like AT as well once
you try it....;-)

Alan

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

Linux-powered astrophysics
__________________________

[Plplot-devel] c++ example now builds with AT

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

The recipe is

cd to the installed examples/c++

make -f Makefile.examples

If you look inside that Makefile you will see it is really quite simple. You
only need to link to libplcxx (i.e. just the symbols directly required by
x01cc.cc are linked).  When that library is created, it is linked only to
libplplot (i.e., just the symbols directly required by libplcxx are linked).
So the heirarchichal linking model that I worked on earlier this year is
absolutely compatible with libtool.  I knew that theoretically, but this is
the first real chance I have had to see it in action with libtool.  So
I am a happy camper this evening!

Alan

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

Linux-powered astrophysics
__________________________

[Plplot-devel] C examples code is done, c++ and f77 is almost there

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

Just committed AT changes so that example code is installed in the usual
directory for the c, c++, and f77 examples.  I checked that the correct
support files for this (*.fm4, etc.) have been made part of the distribution
tarball so everything should just work in that mode for Linux and solaris
(and others?) without having to deal separately with example files
as I had to do yesterday.

After you use the usual cookbook (.bootstrap.sh; ./configure
--enable-dyndrivers; make; make install)
then simply cd to the *installed* version of examples/c and type

make -f Makefile.examples

to generate x01c --> x20c. In Makefiles.examples I have used the
plplot_libtool script (our configured version of the libtool script which is
now installed in $prefix/bin) to build the example executables.  This idea
worked yesterday (by hand) for building the examples on solaris so I think
it should just work on all Unix platforms.  Thus, I decided to use this idea
in Makefile.examples on a permanent basis, and I tested today that this
approach works on Linux.

I have also worked in parallel on Makefiles.examples(.in) in examples/c++
and examples/f77 but don't expect the above make -f command to work quite
yet in those installed directories.

Thanks, Maurice, for the encouraging words in a previous post.  The visible
progress I have been able to make with AT every day is also quite encouraging.

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] The libltdl method of dynamically loading our drivers is now working (was Quick help needed with changing a struct and a typedef in PLplot)

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

On Tue, 26 Nov 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > Any C expert on the list know why *PLDispatchInit rather than
>  > PLDispatchInit?

> [...]One confusing point is that ANSI C allows you to drop the explicit dereference
> when making the actual function call, i.e.
>
>     (*dispatch_init)(pdt);
> and
>     dispatch_init(pdt);
>
> are the same.  But since you have to keep the distinction straight in the
> declaration, the first form is probably better (IMO) as being more
> transparent.

Thanks, Maurice.  I was indeed getting confused by that.  Thanks for the
explanation!

>  > One other issue I ran into was how to initialize libltdl and release its
>  > memory when done.
>
> Could it go in pllib_init()? I added this earlier this year to help solve
> this problem

Yes, that is an excellent solution which I have just tested and committed.
Thanks!

Alan

Re: [Plplot-devel] The libltdl method of dynamically loading our drivers is now working (was Quick help needed with changing a struct and a typedef in PLplot)

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

Alan W. Irwin writes:
 > (2) should be changed to
 > typedef lt_ptr (*PLDispatchInit)( PLDispatchTable *pdt );
 > 
 > Any C expert on the list know why *PLDispatchInit rather than
 > PLDispatchInit? I naively thought you would drop the asterisk because the
 > type was going from void * to lt_ptr, but as you all know, my C programming
 > skills are not the best especially when dealing with pointers and
 > complicated typedefs. The example of typedef on p. 147 of the little white
 > K&R book is analogous to this one, but I don't understand the point of
 > (*PFI) rather than (PFI) in that case as well.

It looks to me you're going from a void (not void*) to lt_ptr, since the
original typedef was:

    typedef void (*PLDispatchInit)( PLDispatchTable *pdt );

The new typedef:

    typedef lt_ptr (*func)( PLDispatchTable *pdt );

allows you to declare a function pointer in the following way:

    func dispatch_init;

which means that:

    dispatch_init is a pointer to a function that passes a pointer to a
PLDispatchTable and returns lt_ptr.  

It doesn't matter what "func" is called, in this case PLDispatchInit.

One confusing point is that ANSI C allows you to drop the explicit dereference
when making the actual function call, i.e.

    (*dispatch_init)(pdt);
and
    dispatch_init(pdt);

are the same.  But since you have to keep the distinction straight in the
declaration, the first form is probably better (IMO) as being more
transparent.

 > One other issue I ran into was how to initialize libltdl and release its
 > memory when done.  Same old problem (mentioned in the plcore.c comments) of
 > no clear PLplot library initialization . So I chose to do the initialize
 > whenever a stream was created and release whenever it was destroyed.  This
 > is overcomplicated, and it would be better to initialize just once before
 > any streams are created and release after they are all destroyed, but there
 > is no clear way to tell when plinit is first called so I had to do it stream
 > by stream.

Could it go in pllib_init()?  I added this earlier this year to help solve
this problem -- any routine the user might call first (if I didn't miss any)
calls this first to do library initialization.

 > The AT effort is going much faster than I thought (because of the great
 > start by Rafael and because autotools is pretty easy to learn from scratch)
 > so the merge to HEAD *could* happen soon (i.e., maybe even sometime during
 > this week unless I run into unforseen problems.) So I suggest you should get
 > involved immediately if you want to evaluate the AT approach before the
 > merge!

Will try, but am very very busy.  I appreciate all your effort on this tho.

 > Alan

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

[Plplot-devel] AT branch distribution tarball now works on solaris

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

I have just committed some minor changes so that everything would build from
the distribution tarball on solaris.

Getting x08c compiled, however, was a bit of an adventure on solaris (and
the fun was greatly improved by the compile farm computers going down 4 [!]
separate times while I was working there today.) The compilation of x08c was
done in the following way:

plplot-5.1.0_solaris_sparc/libtool gcc x08c.c
-I/home/users/a/ai/airwin/plplot_install_solaris_sparc/include/plplot
-L/home/users/a/ai/airwin/plplot_install_solaris_sparc/lib -lplplotd -o x08c
-I.

i.e., I used the libtool script in the top of my plplot tree.  That resulted
in the following command (which of course could also be used directly
without the libtool script):

gcc x08c.c \
-I/home/users/a/ai/airwin/plplot_install_solaris_sparc/include/plplot -o \
x08c -I. \
/home/users/a/ai/airwin/plplot_install_solaris_sparc/lib/libplplotd.so -lm \
-ldl -R/home/users/a/ai/airwin/plplot_install_solaris_sparc/lib

Both the libtool and gcc form showed link errors with an undefined isinf. I
looked that up on google "solaris isinf", and sure enough that is an unfixed
bug in the solaris libraries (unless you pay for new ones).  See
http://www.docs.spruce.se/docs/os/solaris2/Q5.6.html where they also publish
the following workaround:

#include <ieeefp.h>
int isinf(double x) { return !finite(x) && x==x; }

With those two lines inserted in the x08c.c code, both of the two above
build commands completed without error, and for both, the "./x08c -dev psc"
command generated identical results to my prior tests today.

So this is pretty convincing evidence that the AT approach is going to work
cross-platform, and I therefore urge those with other platforms accessible
to them to give the current AT branch a try.  Geoffrey, I especially have
you in mind because you have complained before that CVS HEAD would not work
on solaris, and I think AT is the answer.  Maurice, I would also especially
appreciate you giving this a try with your access to alphas.

Meanwhile, I will work on getting at least the same drivers and front ends
working as current CVS HEAD in preparation for the forthcoming merge of AT
to HEAD.

Alan

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

Linux-powered astrophysics
__________________________

[Plplot-devel] Distributed tarball success on ix86

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

I just finished a commit on the AT branch so that if you follow the usual
recipe with "make dist", it will roll a tarball with everything required for
a cross-platform build (only xwin and ps drivers and only C front end).

I tried this tarball at the Debian ix86 computer on the compile farm and
achieved complete success.  No autotools were required there.  It was simply
configure --prefix=wherever --with-double --enable-dyndrivers; make; make install. The
file generated by x08c -dev psc there was identical to the one generated on
my home machine. (Note the current tarball does not include any examples so
you have to copy x08c and plcdemos.h to whatever machine you are testing
on.)

That test is of course necessary, but not sufficient.  We should try this on
a whole variety of machines to test whether the distribution tarball is
truly cross-platform.

I have one more platform accessible to me to try this on: the Sparc - R220
Sun Solaris (8) at the compile farm.  But after that, it is up to those of
you with more extensive platform access to try this while I concentrate for
the next couple of days on getting more drivers and front ends going.

Alan

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

Linux-powered astrophysics
__________________________

[Plplot-devel] running plplot under W2000

[Joachim W. <wu...@cr...>]

Thank you, Olof:

with your help (and Wayne=B4s), I succeeded in installing plplot.

It is also possible to run the examples from the Cygwin shell,
provided the environment variable is set by a UNIX command, but
with content in DOS style:

export PLPLOT_HOME=3DD:\\my_plplot_directory

Regards, Joachim

[Plplot-devel] The libltdl method of dynamically loading our drivers is now working (was Quick help needed with changing a struct and a typedef in PLplot)

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

OK.  I answered my own questions empirically. Turned out that lt_ptr_t was
obsolete (shows how quickly things have moved since autotools book), and
according to info pages for libtool version 1.4.2, lt_ptr should be used
instead.  After I fixed that problem, here are the answers I
discovered by seeing whether the build, install, and x08c test worked.

(1) is correct.

(2) should be changed to
typedef lt_ptr (*PLDispatchInit)( PLDispatchTable *pdt );

Any C expert on the list know why *PLDispatchInit rather than
PLDispatchInit? I naively thought you would drop the asterisk because the
type was going from void * to lt_ptr, but as you all know, my C programming
skills are not the best especially when dealing with pointers and
complicated typedefs. The example of typedef on p. 147 of the little white
K&R book is analogous to this one, but I don't understand the point of
(*PFI) rather than (PFI) in that case as well.

One other issue I ran into was how to initialize libltdl and release its
memory when done.  Same old problem (mentioned in the plcore.c comments) of
no clear PLplot library initialization . So I chose to do the initialize
whenever a stream was created and release whenever it was destroyed.  This
is overcomplicated, and it would be better to initialize just once before
any streams are created and release after they are all destroyed, but there
is no clear way to tell when plinit is first called so I had to do it stream
by stream.

A final issue was the top-level aclocal.m4 was one of those deleted files
that Rafael accidentally included during his merge from MAIN to AM-LT.  I
deleted that file from the AT branch since a new version of it (not a 7-yr
old version!) is automatically generated by one of the commands in
bootstrap.sh.

Anyhow, after those changes (just now committed) the AT cookbook just worked
again.  Also, a valgrind test of ./x08c -dev psc -o test.ps revealed no new
problems beyond what I have reported before.

Next step (tomorrow) is to try all this on a solaris platform to see if
there are any obvious cross-platform issues with dynamic drivers (or
anything else) there.  I will be following Rafael's old cookbook on making a
tarball to try out on solaris.  The neat thing about this approach is
nothing will be needed on the solaris machine other than a working compiler,
and the solaris version of scripting and make.

Once that is sorted out, the next steps are to try the tarball results of
the AT branch on as many platforms as the other developers here have access
to while I concentrate on expanding to more than the xwin and ps drivers
that are working now and more front ends than just the C front end that is
working now.

Once we have at least the current CVS HEAD functionality on the AT branch
(all dynamic drivers and all front ends working) with the addition of
cross-platform capability, I will want to merge the AT branch into CVS HEAD.

The AT effort is going much faster than I thought (because of the great
start by Rafael and because autotools is pretty easy to learn from scratch)
so the merge to HEAD *could* happen soon (i.e., maybe even sometime during
this week unless I run into unforseen problems.) So I suggest you should get
involved immediately if you want to evaluate the AT approach before the
merge!

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
__________________________

---------- Forwarded message ----------
Date: Sun, 24 Nov 2002 13:36:25 -0800 (PST)
From: Alan W. Irwin <ir...@uv...>
To: PLplot development list <Plp...@li...>
Cc: Rafael Laboissiere <lab...@ps...>
Subject: [Plplot-devel] Quick help needed with changing a struct and a
    typedef in PLplot

I start with the background information that is required on the dlopen to
libltdl API change, then get to my two "simple" numbered questions at the
end which any C expert should be able to answer for me.

For the AT branch I am in the middle of changing from the dlopen API
to the libltdl API to increase cross-platform compatibility.

The old API:

void * dlopen (const char *filename, int flag)
void * dlsym (void *handle, char *name)
int dlclose (void *handle)
const char * dlerror (void)

The new API:

lt_dlhandle lt_dlopen (const char *filename)
lt_dlhandle lt_dlopenext (const char *filename)
lt_ptr_t lt_dlsym (lt_dlhandle handle, const char *name)
int lt_dlclose (lt_dlhandle handle)
const char * lt_dlerror (void)

Note: lt_dlopenext is the same as lt_dlopen except that it tries with
alternate suffixes if there is not an exact match to the name.

In the new plcore.c there is the following line:

driver->dlhand = lt_dlopenext( drvspec);

which replaces the old

driver->dlhand = dlopen( drvspec, flag);

Subsequently driver->dlhand is used as an argument to lt_dlsym


So in plplot.h I have changed from

typedef struct {
    char *drvnam;
    void *dlhand;

} PLLoadableDriver;

to

typedef struct {
    char *drvnam;
    lt_dlhandle dlhand;

} PLLoadableDriver;

With appropriate #include of the libltdl header and protection by
#ifdef ENABLE_DYNDRIVERS.

(1) Is that change to the struct the correct thing to do for the changed API?

(2) The new plcore.c code also has the following fragment:

PLDispatchInit dispatch_init = lt_dlsym( driver->dlhand, sym );

where the old disptab.h has

typedef void (*PLDispatchInit)( PLDispatchTable *pdt );

What should I change that typedef to?

My guess is something like

typedef lt_ptr_t (PLDispatchInit)( PLDispatchTable *pdt );

but I am not completely sure so any quick help would be much appreciated.
Of course I am going to try some variations on this theme this afternoon
and hopefully get something to work, but the definitive answer would be
most useful. C typedefs and pointers just plain drive me crazy!

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
__________________________



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Plplot-devel mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Revised AT cookbook

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

On Sun, 24 Nov 2002, Rafael Laboissiere wrote:

> I did not check your changes, but it should be useful to include that call
> to libtoolize into bootstrap.sh.

Good idea which I just committed.

So the revised AT cookbook has the libtoolize line dropped since it is now
in ./bootstrap.sh.

Alan

[Plplot-devel] Quick help needed with changing a struct and a typedef in PLplot

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

I start with the background information that is required on the dlopen to
libltdl API change, then get to my two "simple" numbered questions at the
end which any C expert should be able to answer for me.

For the AT branch I am in the middle of changing from the dlopen API
to the libltdl API to increase cross-platform compatibility.

The old API:

void * dlopen (const char *filename, int flag)
void * dlsym (void *handle, char *name)
int dlclose (void *handle)
const char * dlerror (void)

The new API:

lt_dlhandle lt_dlopen (const char *filename)
lt_dlhandle lt_dlopenext (const char *filename)
lt_ptr_t lt_dlsym (lt_dlhandle handle, const char *name)
int lt_dlclose (lt_dlhandle handle)
const char * lt_dlerror (void)

Note: lt_dlopenext is the same as lt_dlopen except that it tries with
alternate suffixes if there is not an exact match to the name.

In the new plcore.c there is the following line:

driver->dlhand = lt_dlopenext( drvspec);

which replaces the old

driver->dlhand = dlopen( drvspec, flag);

Subsequently driver->dlhand is used as an argument to lt_dlsym


So in plplot.h I have changed from

typedef struct {
    char *drvnam;
    void *dlhand;

} PLLoadableDriver;

to

typedef struct {
    char *drvnam;
    lt_dlhandle dlhand;

} PLLoadableDriver;

With appropriate #include of the libltdl header and protection by
#ifdef ENABLE_DYNDRIVERS.

(1) Is that change to the struct the correct thing to do for the changed API?

(2) The new plcore.c code also has the following fragment:

PLDispatchInit dispatch_init = lt_dlsym( driver->dlhand, sym );

where the old disptab.h has

typedef void (*PLDispatchInit)( PLDispatchTable *pdt );

What should I change that typedef to?

My guess is something like

typedef lt_ptr_t (PLDispatchInit)( PLDispatchTable *pdt );

but I am not completely sure so any quick help would be much appreciated.
Of course I am going to try some variations on this theme this afternoon
and hopefully get something to work, but the definitive answer would be
most useful. C typedefs and pointers just plain drive me crazy!

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] Revised AT cookbook

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

* Alan W. Irwin <ir...@be...> [2002-11-24 09:05]:

> * Add libtoolize line to create all the required ltdl files. (The current
>   configure.in and resulting configure checks for these, but they are not
>   actually used yet since libltdl has not yet been implemented.)

I did not check your changes, but it should be useful to include that call
to libtoolize into bootstrap.sh.

-- 
Rafael

[Plplot-devel] Revised AT cookbook

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

Changes from the previous AT cookbook are the following:

* libfreetype is optional rather than mandatory since the libfreetype
  configuration is now done properly.

* The x08c build below now is able to use the correct -I option because of
  an include/Makefile.am fix just committed. Also, libtool is not required
  for the x08c build so I now give the gcc alternative.

* Add libtoolize line to create all the required ltdl files. (The current
  configure.in and resulting configure checks for these, but they are not
  actually used yet since libltdl has not yet been implemented.)

Note: I used autoconf-2.53, automake-1.5, and libtool-1.4.2.  Probably you
should stick with these versions or later.

Cookbook:

cvs checkout -r AT -d AT plplot
cd AT
# N.B. Next line only needs to be done once per fresh AT checkout
libtoolize  --copy --ltdl

# The purpose of bootstrap.sh is put the tree in shape so that you can
# can run ./configure; make; make install.  So run ./bootstrap.sh whenever
# configure.in or one of the Makefile.am files is changed.
./bootstrap.sh >& bootstrap.out
./configure --prefix=/usr/local/plplot_at --with-double \
--enable-dyndrivers > & ! configure.out
make >& make.out &
make >& make_install.out

cd examples/c

gcc x08c.c -I/usr/local/plplot_at/include/plplot \
-L/usr/local/plplot_at/lib -lplplotd \
-Wl,--rpath -Wl,/usr/local/plplot_at/lib -o x08c

After this compilation, both

./x08c -dev xwin

and

./x08c -dev psc -o temp.ps

work great for me, i.e., dynamic drivers are working properly for Linux and
the AT branch.

Alan

[Plplot-devel] freetype configuration finally working in AT

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

I have been trying some various options to get freetype configured for the
AT branch today, and I believe I have come up with a reasonable solution
that builds on what we currently do for MAIN HEAD.

Instead of using the INCS or LIBS symbols (which tends to put in lots of
stuff that is not needed for a particular compile or link step) my approach
is to generate specific symbols for each library.  In the freetype case
these symbols are FREETYPEINCCMD and FREETYPELIBCMD.

Currently I include sysloc.in (a version of cf/sysloc.in that has been
copied to the top-level directory and edited to remove all the OS-specific
stuff) into configure.in.  sysloc.in optionally defines the symbols

FREETYPEINCDIR, FREETYPELIBDIR, and FREETYPELIBSTR

in the usual way (which I believe is a big advantage since it allows our
users maximum flexibility in specifying their own locations for libfreetype
[or any other library we are using]).

I use these symbols to generate FREETYPEINCCMD and FREETYPELIBCMD with the
following configure.in fragment:

if test "$with_freetype" = yes; then
   if test "$FREETYPEINCDIR" != default; then
      FREETYPEINCCMD="-I"$FREETYPEINCDIR
      AC_SUBST(FREETYPEINCCMD)
   fi
   if test "$FREETYPELIBDIR" = default; then
      FREETYPELIBCMD=$FREETYPELIBSTR
   else
      FREETYPELIBCMD="-L "$FREETYPELIBDIR" "$FREETYPELIBSTR
   fi
   AC_SUBST(FREETYPELIBCMD)
fi

(or I could add this fragment to sysloc.in....I don't care.) I then use
@FREETYPEINCCMD@ and @FREETYPEINCCMD@ in the src/Makefile.am where they
affect how plfreetype.c is built and libplplot(d) is linked.  I have just
tested the AT changes which implement this scheme, and configuration with
and without freetype seems to be working properly.  I have also just
committed the changes to the AT branch so you can try this scheme for
yourself.

Here is your chance to comment on this design before I go ahead and
duplicate it for every other library that we need.  Note there will be a
fair number of LIBRARYINCCMD and LIBRARYLIBCMD symbols defined, but they
will only be used in a very limited manner.  For example, I intend to use
GDINCCMD and GDLIBCMD only to compile gd.c and link the associated dynamic
driver.

Alan

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

Linux-powered astrophysics
__________________________

[Plplot-devel] AT commits to make dynamic drivers work

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

I have just committed some changes to make dynamic drivers work on the
AT branch.  (Note, I have disabled static drivers for now to keep life
simple.)

I encourage you to try out this branch on Linux.

Here is the cookbook.

Please follow it as closely as possible since I don't have some corner cases
taken care of yet.

I used autoconf-2.53, automake-1.5, and libtool-1.4.2.  Probably you should
stick with these versions or later.

You will need the freetype library version 6 (development version) installed.

cvs checkout -r AT -d AT plplot
cd AT
./bootstrap.sh >& bootstrap.out
./configure --prefix=/usr/local/plplot_at --with-double \
--enable-dyndrivers > & ! configure.out
make >& make.out &
make >& make_install.out

Note I have used a special install location prefix so I don't mess up
my usual plplot install area.  Also, I used --with-double.  If you drop
this option it should work, but I haven't tested it.
--enable-dyndrivers is mandatory (for now).

cd examples/c
libtool gcc -g x08c.c -L/usr/local/plplot_at/lib -lplplotd -o x08c -rpath
/usr/local/plplot_at/lib -I../../include

Note, I don't have the installed headers done quite correctly yet so that
is the reason why I am using -I../../include

./x08c -dev xwin
./x08c -dev psc -o temp.ps

Both these commands work like a charm using the xwin and psc dynamic
devices.

It has been a lot easier than I thought to get to the stage where dynamic
devices work.  Rafael has told us all along that autotools are easy to
use, and he is absolutely correct.

There are some obvious rough spots in the above.  None of the front ends
work except for C.  static drivers have been disabled for now (just like for
CVS HEAD).  Some options have been hard coded (for example, there is an
assumption that libfreetype version 6 has been installed).  I have only
implemented the xwin and psc devices for now.  The examples are not installed,
and they have to be compiled by hand as in the above.

But I view these rough spots as second priorities for now.  My highest
priority is to get everything to work with the compile farm solaris machine

uname -a
SunOS usf-cf-sparc-solaris-1 5.8 Generic_108528-17 sun4u sparcSUNW,Ultra-60

I suspect this is going to take some additional effort since there are
usually cross-platform issues with dlopened plug-ins (our dynamic devices)
according to the AT book.  But my short-term goal this weekend is to get the
AT branch working on solaris as well or better than it does now on Linux.  I
believe that will be a major breakthrough since AFAIK, dynamic drivers have
never worked before on any platform other than Linux.

Alan

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

Linux-powered astrophysics
__________________________

[Plplot-devel] Initial commit of AT branch

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

For the historical record, this is how I resurrected Rafael's AM-LT work for
the new AT branch.

N.B. There is much more to come today because I made *a lot* of progress on
AT on my home copy of the repository.  These changes have to be
systematically transferred to the SF repository AT branch, then I will
comment on what is now possible with that revised AT branch.

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
__________________________

#Initial merge and commit:

#Do merge with HEAD on 20021122 10:28 Pacific Time (UTC-8)
cvs checkout -d HEAD plplot
cd HEAD
cvs tag bp_AT
cvs tag -b AT
cd ..
cvs checkout -r AT -d AT plplot
cd AT
# am_lt_files contains the following:
************
.cvsignore
AUTHORS
COPYING
ChangeLog
Makefile.am
TODO.AM-LT
acconfig.h
acinclude.m4
bindings/.cvsignore
bindings/Makefile.am
bindings/c++/.cvsignore
bindings/c++/Makefile.am
bindings/f77/.cvsignore
bindings/f77/Makefile.am
bootstrap.sh
configure.in
drivers/.cvsignore
drivers/Makefile.am
include/.cvsignore
include/Makefile.am
lib/.cvsignore
lib/Makefile.am
src/.cvsignore
src/Makefile.am
******************
foreach tmp (`cat ../am_lt_files` )
cvs update -kk -j AM-LT $tmp
end
# Generated file
cvs remove -f Makefile
cp cf/plDevs.h.in include
cvs add include/plDevs.h.in
# replace.pl is Rafael's infamous (;-)) script to do search and replace.
../replace.pl '#include "plplot\/' '#include "' \
src/*.c drivers/*.c include/*.h \
bindings/c++/*.cc \
bindings/c++/*.h \
bindings/f77/*.c \
bindings/f77/*.h
# The following files have PLPLOT_VERSION changed to VERSION
jed src/plargs.c src/plcore.c

#Now commit the changes for first checkin of AT.
cvs commit

[Plplot-devel] Re: unable to install plplot under W2000

[Olof S. <sve...@es...>]

Hi Joachim,

Joachim Wuttke wrote:
> 
> Hi Olof,
> 
>    I am trying to install plplot under W2000 (with Cygwin).
> In a first step, I did ./configure, make, make install in
> the plplot main directory (btw: which configure options are
> recommended if I only want to use the W2000 port ?).

I managed to compile plplot under cygwin even with the X11 device
working on Cygwin XFree86 with the following command:

> command:        /cygdrive/c/Docume~1/svensson/develop/plplot/plplot-5.1.0/configure --with-gcc
> system:         CYGWIN_NT-5.0-1.3.12(0.54/3/2)
> prefix:         /usr/local/plplot
> CC:             gcc -c          -O
> LDC:            gcc
> CXX:            g++ -c            -O
> LDCXX:          g++
> F77:            g77 -c           -O
> LDF:            g77
> INCS:            -I. -I/usr/X11R6/include
> LIBS:            -L/usr/X11R6/lib -lX11 -lm
> LIB_TAG:
> devices:         plmeta null xterm tek4010 tek4010f tek4107 tek4107f mskermit conex vlt versaterm dg300 ps psc xfig ljii hp7470 hp7580 lj_hpgl ljiip imp xwin pbm pstex
> 
> Available device drivers
> static:          plmeta null tek dg300 ps xfig ljii hpgl ljiip impress xwin pbm
> pstex
> dynamic:
> 
> with_shlib:     no              with_double:    no
> with_debug:     no              with_opt:       yes
> with_warn:      no              with_profile:   no
> with_gcc:       yes             with_rpath:     yes
> 
> enable_xwin:    yes             enable_tcl:     no
> enable_tk:      no              enable_itcl:    no
> enable_cxx:     yes             enable_python:  no
> enable_f77:     yes             enable_java:    no
> enable_octave:  no              enable_gnome:   no

I can then compile and run all the examples with the xwin device, I
haven't tested all the other devices.
 
> In a second step I went into the sys/win32/msdev directory,
> and I followed your instructions until step 5, which fails
> with the following message:
> 
> ---------------------------------------------------------------------------------
> /D/Downloads/plplot-5.1.0/sys/win32/msdev/plplib $ nmake plplib.mak
> 
> Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
> 
> No configuration specified. Defaulting to plplib - Win32 Debug.
> Warning: cannot find "plplib.dep"
>         if not exist ".\Release/" mkdir ".\Release"
>         cl.exe /nologo /ML /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_MBCS" /D "_LI
> B" /Fo".\Release\\" /Fd".\Release\\" /FD /c ..\..\..\..\tmp\plcore.cpp
> plcore.cpp
> ..\..\..\..\tmp\plplot/plplotP.h(94) : fatal error C1034: ctype.h: no include pa
> th set
> NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
> Stop.
> ----------------------------------------------------------------------------------

I got exactly the same question from another person who found the
solution himself:

> Wayne Richardson wrote:
> 
> Dear Sir,
> 
> I am able to compile and run PLPLOT !!  Thanks very much for your
> help.
> 
> You actually gave the solution to the problem in the readme.txt file.
> The relevent part reads `` make sure that you can execute the ``
> nmake'' command on a MS-DOS prompt command line.''  Running nmake from
> the command line requires the setting of many more environmental
> variables than I had set and in fact the issue was addressed in a note
> on MS Knowledge base.  More importantly, the settings to run nmake are
> contained in the file  Vcvars32.bat     which is in the VC98\bin
> directory.  Hence by either first executing Vcvars32.bat, or placing
> it in the autoexec.bat file, it is possible to make nmake work
> properly.
> 
> Again, thanks very much for you help.
> 
> Respectfully,
> W. Richardson

I hope this helps!

Regards,

Olof

[Plplot-devel] unable to install plplot under W2000

[Joachim W. <wu...@cr...>]

Hi Olof,

   I am trying to install plplot under W2000 (with Cygwin).
In a first step, I did ./configure, make, make install in
the plplot main directory (btw: which configure options are
recommended if I only want to use the W2000 port ?).

In a second step I went into the sys/win32/msdev directory,
and I followed your instructions until step 5, which fails
with the following message:

-------------------------------------------------------------------------=
--------
/D/Downloads/plplot-5.1.0/sys/win32/msdev/plplib $ nmake plplib.mak

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

No configuration specified. Defaulting to plplib - Win32 Debug.
Warning: cannot find "plplib.dep"
        if not exist ".\Release/" mkdir ".\Release"
        cl.exe /nologo /ML /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_MBCS" =
/D "_LI
B" /Fo".\Release\\" /Fd".\Release\\" /FD /c ..\..\..\..\tmp\plcore.cpp
plcore.cpp
..\..\..\..\tmp\plplot/plplotP.h(94) : fatal error C1034: ctype.h: no =
include pa
th set
NMAKE : fatal error U1077: 'cl.exe' : return code '0x2'
Stop.
-------------------------------------------------------------------------=
---------

Thank you for any help - Joachim

[Plplot-devel] AT status report

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

Just to remind you, my primary motivation for the AT (autotools) project
(revived AM-LT) is to allow us to build our libraries and dynamic drivers in
a manner that works cross-platform.  There are all sorts of other compelling
benefits that Rafael has mentioned as well, but what really makes me
confident that this is the way to go is that major projects such as KDE use
autotools, and I therefore think it should satisfy our needs as well.

I have now completed a light reading through the autotools book, a quick
(although somewhat dated) cookbook recommended by Rafael,
http://tinf2.vub.ac.be/~dvermeir/manuals/autocookbook/cookbook.html, the
info pages for libtool and automake, and Rafaels AM-LT comments to
plplot_devel and his AM-LT commit messages.  Thus, today I thought it was
time to get my hands dirty by actually trying to reproduce the situation
where he left off one and a half years ago.

I quickly found that the old AM-LT branch had been badly contaminated
(presumably during Rafael's merges from the MAIN branch to AM-LT) by files
from the CVS attic, i.e, files that had been removed from CVS.  There is
some warning about this "issue" (I would call it a bug) in info cvs if you
use static tags rather than branch tags during merges.  However, by going
over Rafael's old commit messages I was able to get a list of files that he
had actually changed or created as part of the AM-LT effort so it was
possible to make a clean start by merging those specific files with a clean
branch without the "removed" files interfering with that branch.

The new AT branch created this way (in a recent copy of the repository I
established on my home machine to avoid mucking with the SF version until I
gained a bit more experience with cvs branching and merging) works as
advertised by Rafael.  This particular clean start was based on the MAIN
branch from one and a half years ago with the specific AM-LT files merged
in.  I was able to build and install libraries and one (non-functional,
since this was for plplot before the dynamic drivers merge) driver *.so.
Obviously, there is still lots left to do.  For example, I have no idea
whether the installed libraries actually work since there are no examples,
no functioning drivers, and all the script language front ends are not built
or installed for now.  But at least I seem to have reproduced pretty much
the situation (without all the extra "removed" files) when Rafael had to
drop the AM-LT project.  For example, all the builds just worked without
error.

The next step tomorrow is to do a similar clean start of an AT branch at
SourceForge based this time on the current CVS HEAD merged with specific
AM-LT files rather than the merge with PLplot from one and a half years ago.
After I get that build to work, my next priorities are the dynamic drivers,
and the c examples to make sure those libraries and drivers work on Linux.

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
__________________________