plplot-devel — Technical discussion about PLplot development

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

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

Maurice LeBrun writes:
 > Maurice LeBrun writes:
 >  > Alan W. Irwin writes:
 >  >  > Finally, I noticed when checking example 8 that no attempt (as far as I
 >  >  > could tell) was made to display the working palette.  Instead when the cmap1
 >  >  > palette was pressed, immediately the gray scale was turned into the default
 >  >  > colour scheme.
 >  > 
 >  > Right, this is a side effect of the brute force initialization of the color
 >  > map.  It will go away after I change x08c to use plscmap1l() instead.
 > 
 > I was wrong about this, even with my change the default map is still installed
 > when bringing up the palette tool.  I'll look into it.. probably a quick fix.

OK, it works now, at least my test using x08c.  I did notice that the plframe
widget wasn't propagating the 'rev' flag correctly, not used in this test.
Will get to that tomorrow.

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

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

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

Maurice LeBrun writes:
 > Alan W. Irwin writes:
 >  > Finally, I noticed when checking example 8 that no attempt (as far as I
 >  > could tell) was made to display the working palette.  Instead when the cmap1
 >  > palette was pressed, immediately the gray scale was turned into the default
 >  > colour scheme.
 > 
 > Right, this is a side effect of the brute force initialization of the color
 > map.  It will go away after I change x08c to use plscmap1l() instead.

I was wrong about this, even with my change the default map is still installed
when bringing up the palette tool.  I'll look into it.. probably a quick fix.

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

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

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

On Tue, 5 Feb 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > Maurice, could you please find a way to display the entire cmap0 colour
>  > palette GUI? Right now, the 16 default colour buttons overlap at the end,
>  > and I believe one of them is entirely covered up.
>
> They all appear just fine on my display. :) But I have a feeling I'll see what
> you mean when I try it on my notebook at 800x600 resolution.  What resolution
> are you using?

1024x768.

> I don't really like the plscmap1() way of initializing the palette.

Understood for ordinary use, but plscmap1() is invaluable for dealing with
colour paletted images so this functionality should be retained.  However, I
agree we shouldn't demo plscmap1() in example 8, and generating gray scale
with two control points is a more beneficial example for the newbie user.

>> Finally, I noticed when checking example 8 that no attempt (as far as I
>> could tell) was made to display the working palette.  Instead when the cmap1
>> palette was pressed, immediately the gray scale was turned into the default
>> colour scheme.
> Right, this is a side effect of the brute force initialization of the color
> map.  It will go away after I change x08c to use plscmap1l() instead.

Good.

Thanks also for the additional information you gave re cmap0 and cmap1
palette files.

Alan

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

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

Alan W. Irwin writes:
 > I woke up this morning realizing my message below had blurred some important
 > distinctions between the control point method of setting the cmap1 palette
 > and the direct method of doing the same thing.  So here are some clarifying
 > points and additional wish list items.
 > 
 > Our current API does not save anything to do with control points.  Instead,
 > it just uses them without storing them to create the cmap1 palette.  So add
 > to my wish list some core API to set the control points (consisting of
 > number of control points, and the i, h, l, s, and rev arrays) 

Already exists -- plscmap1l().

 > and to get
 > them again with provision made for the case where no control points are used
 > at all to generate cmap1.

Yeah there should probably be a corresponding plgcmap1l(), if you want to add
it feel free.  As for the undefined control points case, that's not something
I care to support as I find the control point model to do everything I need.
Again, if someone else wants to do any work in this area, that's fine.

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

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

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

Alan W. Irwin writes:
 > Maurice, could you please find a way to display the entire cmap0 colour
 > palette GUI? Right now, the 16 default colour buttons overlap at the end,
 > and I believe one of them is entirely covered up.  

They all appear just fine on my display. :) But I have a feeling I'll see what
you mean when I try it on my notebook at 800x600 resolution.  What resolution
are you using?

In any case, these kinds of sizing considerations will all be addressed in the
revamp of the resources handling that I have brewing.  I don't know if it will
be coming any time real soon b/c I need to concentrate on other things for the
next few weeks, but I'll try to fit it in as best I can.

 > Also, sure as anything
 > you will have some user wanting to use more or less than 16 cmap0 colours so
 > would you be willing to put in a user-selectable number of colours?  Perhaps
 > the solution is a slider which lets you look at various parts of cmap0 if
 > there are more than say 12 colours.
 > 
 > Similarly, I think the number of cmap1 control points should be user
 > selectable with a slider for display so the number of control points could
 > be much greater than 16 if the user desired. 

GUI control of these would be nice but I doubt I'll ever bother because
there's a simple alternative method that works just fine -- edit the palette
file.  I recommend taking a look at each of the *.pal files.  In fact, you
should load each in and play with them.  On x16c, edit the cmap0 palette
to see that user settings are taken into account.

The cmap0 palette file is of the form:

<n>
<color1>
...
<colorn>

where <n> is the number of colors, while cmap1 palettes are of the form:

<n>
<color1> <pos1> [<reverse>]
...
<colorn> <posn> [<reverse>]

where <n> is the number of control points. The positions here are given
as integers from 0-100.. divide by 100 to get the ordinary position in
cmap1 space.

 > For example, the gray scale in
 > example 8 is done with 256 cmap1 control points.  It would be nice to be
 > able to display and manipulate that palette or any colour image palette
 > (with typically 256 colours) that you might run into when working with
 > images.

Ugh.. I didn't realize that's what x08c was doing.  I don't really like the
plscmap1() way of initializing the palette.  It was my first implementation
and I didn't see the harm in keeping it in for odd situations.  Definitely
plscmap1l() with a small number of control points is to be preferred.  In
this case, the explicit initialization using 256 colors can be replaced with
a cmap1 initialization that uses only 2 control points, which on my display
looks the same.  I'll probably go ahead and make the change to x08c to do it
this way.

 > Finally, I noticed when checking example 8 that no attempt (as far as I
 > could tell) was made to display the working palette.  Instead when the cmap1
 > palette was pressed, immediately the gray scale was turned into the default
 > colour scheme.

Right, this is a side effect of the brute force initialization of the color
map.  It will go away after I change x08c to use plscmap1l() instead.

 > ...
 > So here is the wishlist summary:
 > 
 > (1) User selectable number of colours for cmap0
 > 
 > (2) User selectable number of control points for cmap1
 > 
 > (3) If GUI would be too large use a slider to display parts of it
 > 
 > (4) cmap1 colour palette displays the actual colour map when it starts
 > and not the default colour map.
 > 
 > (5) Make sure actual colour map is also used for cmap0 palette when it starts
 > (I haven't played with it so I don't know the score there.)
 > 
 > I will settle for (4) with number of control points fixed at 6, but I
 > hope you do the rest as well.

As per the above notes, these are all handled by existing functionality except
for sizing concerns, which I'll address over the coming weeks/months.

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

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

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

I woke up this morning realizing my message below had blurred some important
distinctions between the control point method of setting the cmap1 palette
and the direct method of doing the same thing.  So here are some clarifying
points and additional wish list items.

Our current API does not save anything to do with control points.  Instead,
it just uses them without storing them to create the cmap1 palette.  So add
to my wish list some core API to set the control points (consisting of
number of control points, and the i, h, l, s, and rev arrays) and to get
them again with provision made for the case where no control points are used
at all to generate cmap1.

As an example of that latter case, the gray scale cmap1 palette in example 8
is currently established without recourse to control points. Of course, this
is a bit of a bad example because gray scale is so easy to represent with
control points.  But we do need direct access (i.e., access by integer index
without the use of control points) to deal with, for example, the colour
palette of colour images.  So also add to my wishlist a core routine to get
cmap1 palette values by *integer* index much like we can set them by integer
index now.

Alan

On Mon, 4 Feb 2002, Alan W. Irwin wrote:

> Maurice, could you please find a way to display the entire cmap0 colour
> palette GUI? Right now, the 16 default colour buttons overlap at the end,
> and I believe one of them is entirely covered up.  Also, sure as anything
> you will have some user wanting to use more or less than 16 cmap0 colours so
> would you be willing to put in a user-selectable number of colours?  Perhaps
> the solution is a slider which lets you look at various parts of cmap0 if
> there are more than say 12 colours.
>
> Similarly, I think the number of cmap1 control points should be user
> selectable with a slider for display so the number of control points could
> be much greater than 16 if the user desired. For example, the gray scale in
> example 8 is done with 256 cmap1 control points.  It would be nice to be
> able to display and manipulate that palette or any colour image palette
> (with typically 256 colours) that you might run into when working with
> images.
>
> Finally, I noticed when checking example 8 that no attempt (as far as I
> could tell) was made to display the working palette.  Instead when the cmap1
> palette was pressed, immediately the gray scale was turned into the default
> colour scheme.
>
> For now, even if your GUI won't support anything other than cmap1's with 6
> control points, it would still be worthwhile to be able to display and edit
> the current working palette (assuming it has the same number of control
> points as your default one).  I could use that capability immediately to
> diagnose troubles with 6-control point palettes that are set up under
> programme control like restore_cmap1 in x08.tcl.  In that case, my eyes tell
> me it is not quite restoring the default colours (I am trying to match your
> 6 points with my local copy of x08.tcl before I check in the results). It
> would be great to actually see the cmap1 numbers produced by restore_cmap1
> using your palette GUI, but right now it always just gives me the default
> regardless of what I do under programme control.
>
> So here is the wishlist summary:
>
> (1) User selectable number of colours for cmap0
>
> (2) User selectable number of control points for cmap1
>
> (3) If GUI would be too large use a slider to display parts of it
>
> (4) cmap1 colour palette displays the actual colour map when it starts
> and not the default colour map.
>
> (5) Make sure actual colour map is also used for cmap0 palette when it starts
> (I haven't played with it so I don't know the score there.)
>
> I will settle for (4) with number of control points fixed at 6, but I
> hope you do the rest as well.
>
> 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 mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] wish list for the colour palettes

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

Maurice, could you please find a way to display the entire cmap0 colour
palette GUI? Right now, the 16 default colour buttons overlap at the end,
and I believe one of them is entirely covered up.  Also, sure as anything
you will have some user wanting to use more or less than 16 cmap0 colours so
would you be willing to put in a user-selectable number of colours?  Perhaps
the solution is a slider which lets you look at various parts of cmap0 if
there are more than say 12 colours.

Similarly, I think the number of cmap1 control points should be user
selectable with a slider for display so the number of control points could
be much greater than 16 if the user desired. For example, the gray scale in
example 8 is done with 256 cmap1 control points.  It would be nice to be
able to display and manipulate that palette or any colour image palette
(with typically 256 colours) that you might run into when working with
images.

Finally, I noticed when checking example 8 that no attempt (as far as I
could tell) was made to display the working palette.  Instead when the cmap1
palette was pressed, immediately the gray scale was turned into the default
colour scheme.

For now, even if your GUI won't support anything other than cmap1's with 6
control points, it would still be worthwhile to be able to display and edit
the current working palette (assuming it has the same number of control
points as your default one).  I could use that capability immediately to
diagnose troubles with 6-control point palettes that are set up under
programme control like restore_cmap1 in x08.tcl.  In that case, my eyes tell
me it is not quite restoring the default colours (I am trying to match your
6 points with my local copy of x08.tcl before I check in the results). It
would be great to actually see the cmap1 numbers produced by restore_cmap1
using your palette GUI, but right now it always just gives me the default
regardless of what I do under programme control.

So here is the wishlist summary:

(1) User selectable number of colours for cmap0

(2) User selectable number of control points for cmap1

(3) If GUI would be too large use a slider to display parts of it

(4) cmap1 colour palette displays the actual colour map when it starts
and not the default colour map.

(5) Make sure actual colour map is also used for cmap0 palette when it starts
(I haven't played with it so I don't know the score there.)

I will settle for (4) with number of control points fixed at 6, but I
hope you do the rest as well.

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] cvs HEAD version multipage looks better, but there is now a tk03 problem

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

I just have had a chance to look at the post-5.1.0 changes with a clean
checkout, and thanks, Maurice, for putting some pause control into plframe.
The tkdemos.tcl multi-page examples now act a lot better.

However, I also noticed there was a problem with the following command:

./plserver -f tk03

If you hit the new button it generates the following error box:

Error: can't read "plmenu_lstat_depth(.1.plw)": no such variable

The above was executed from the plplot/tmp location, and the error also
occurs if you execute the installed plserver, instead.

When I do the same test on installed 5.1.0, no such problem occurs so I
believe this was introduced with the recent pause control changes from
Maurice.

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] 5.1.0 followups

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

* Alan W. Irwin <ir...@be...> [2002-02-01 17:47]:

> One neat thing I discovered from the google search is that netbsd has what
> looks like a well-maintained version of PLplot-5.0.4 as part of their
> distribution.  They tracked us from 5.0.1 onwards so they should catch on
> to 5.1.0 quickly.  But to move that along I am going to try and get in
> touch with their packager.  Hopefully, he will also give me some feedback
> on how PLplot is doing in that environment.

Just an aside note: if/when the Debian GNU/Linux packages for 5.1.0 come
out, and if/when the Debian NetBSD port (http://debian-bsd.sourceforge.net/)
will be functional, chances are high that PLplot 5.0.1 will also be available
in the NetBSD environment.  [Debian NetBSD has received a lot of press
citations lately, see e.g. http://slashdot.org/bsd/02/01/19/1915256.shtml.]

-- 
Rafael

[Plplot-devel] 5.1.0 followups

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

To follow up on the release of 5.1.0, I have updated our information at
opensourcedirectory (http://www.opensourcedirectory.org/projects/plplot/)
and freshmeat (http://freshmeat.net/releases/68777/).  Everything is fine at
SAL (http://sal.kachinatech.com/D/2/PLPLOT.html) except for the version
number which I have asked them to update.

As part of this exercise I have been searching for plplot references with
google.  The Linuxburg twocows site is so far down the google list, that I
am not going to bother with them.  In any case it is like pulling teeth to
get them to change their site; I tried for two years to get them to point to
modern yplot rather than the 1995 (!) version before I was finally
successful.  On the positive side, I am two for three in getting web managers
of highly rated (by google) plplot sites to point to our latest version,
with two requests still outstanding.

One neat thing I discovered from the google search is that netbsd has what
looks like a well-maintained version of PLplot-5.0.4 as part of their
distribution.  They tracked us from 5.0.1 onwards so they should catch on to
5.1.0 quickly.  But to move that along I am going to try and get in touch
with their packager.  Hopefully, he will also give me some feedback on how
PLplot is doing in that environment.

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] RE: [Plplot-general] PLplot-5.1.0 is released!

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

On Fri, 1 Feb 2002, Geoffrey Furnish wrote:

> Alan W. Irwin writes:
>  > 7 months and 500+ CVS commits after PLplot-5.0.4 it is time for another
>  > stable release of this publication-quality scientific plotting package.
>  > [...]
>  > For details see the full release announcement at
>  > http://plplot.sourceforge.net/announce-plplot-5.1.0.html.
>
> Thanks Alan, that was splendidly prepared!

I have to give credit to the quanta web development tool
(http://quanta.sourceforge.net/) for that.  I had heard about it before, but
yesterday when I decided to go with an html announcement, I looked at quanta
seriously for the very first time.  I found I could start using it right
away because it was already part of Debian. One of the big advantages is
quanta produces human-readable html, but there are lots of labor-saving GUI
clicks to insert useful HTML patterns into the edit window where you are
forming that html. And you can immediately see the consequences of your
changes by clicking on a preview window.  Anyhow, I am completely sold; it
made it quite easy to convert an ascii form of the announcement to html with
no prior quanta experience and quite limited html experience.

Alan

[Plplot-devel] RE: [Plplot-general] PLplot-5.1.0 is released!

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

Alan W. Irwin writes:
 > 7 months and 500+ CVS commits after PLplot-5.0.4 it is time for another
 > stable release of this publication-quality scientific plotting package.
 > [...]
 > For details see the full release announcement at
 > http://plplot.sourceforge.net/announce-plplot-5.1.0.html.

Thanks Alan, that was splendidly prepared!

And thanks and congratulatons to all the members of our extended
community who did so much over the past few months to bring us to this
point. 

While Alan has been cooking the release, I've been trying to prepare
mentally for whatever comes next.  I'll have a post to make soon.  If
not tomorrow, then certainly by early next week.

Cheers to all,

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

RE: [Plplot-devel] 5.1.0 tagged final!!!!

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

On Thu, 31 Jan 2002, Geoffrey Furnish wrote:

> You've just been getting spoiled through your OSS immersion :-).

And loving every minute of it....;-)

>
> And Alan, we all deeply appreciate the great energy that you have put
> into the release management process.

And I thank all the developers for their hard work.  There have been 500+
commits since the last release.  Not bad!

>
> I'm looking forward to the final public announcement of 5.1.0, before
> initiating my next PLplot undertaking.

There is no need to wait.

I have been distracted today by file releasing the rpm's.  As part of my
RH-7.1 testing I made rpm's for that distribution so that was
straightforward.  But in addition Conrad Steenberg (my co-developer for
yplot) has just come through with rpm's for Mandrake 8.1 which I have been
checking in detail for any problems with the file list, scripts,
dependencies, etc.  Those Mandrake rpm's should appear shortly in our file
release area.  For those with Mandrake 8.1 or RedHat 7.1, I would appreciate
you giving those rpm's a spin.  Also, if somebody could come through with
SuSe rpm's those would be most appreciated as well.

Next week I hope to make RH 7.2 rpm's when our astrogroup computers are
converted from RH 7.1 to 7.2.  Also, Rafael has told me he will use his next
chance to work on free software to Debian package 5.1.0 (although no
promises yet on when this will occur).  I think that effort is really
important because Debian users are especially helpful with bug reports, and
it is great publicity for us to have PLplot-5.1.0 a standard part of a major
distribution.

I hope to get out the 5.1.0 release announcement tonight, but that won't
happen immediately because I am skimming through all those commit messages
to make sure I have not forgotten anything important.

Alan

RE: [Plplot-devel] 5.1.0 tagged final!!!!

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

Alan W. Irwin writes:
 > Before getting to the interesting subject of this e-mail, I should note BTW,
 > that I fooled around trying to get the native solaris compiler to work on
 > that compile farm machine this morning.  It was incredibly slow taking
 > minutes to compile a "hello world" programme.  Finally, after two
 > frustrating hours I got a message that the cc license-server was dead! Since
 > my working environment is Microsoft free, I never thought I would have to
 > contend with such licensing issues, but Sun proved me wrong....GRRH!

Unix commercial software is often, even usually controlled by a
license daemon.  The KCC C++ compiler I use is that way, purify is
that way, Sun, SGI, HP compilers are all that way, the CAD tools we
use at Lightspeed, etc.  In the old days there used to be a plethora
of licensing managers, but there seems to have been a consolidation so
that by now pretty much all Unix licensed software is using the
Globetrotter "FLexLM" license manager.  Oh, the PGI tools on Linux are
also controlled by FlexLM.  Mmm, and also the Intel C/C++ compiler for
Linux, which is generating rave reviews these days.

You've just been getting spoiled through your OSS immersion :-).

 > I want to thank all of you who contributed so much to this release with
 > extensive development over the last 7 months as well as extensive bug fixing
 > and cross-platform testing over the last several weeks.
 > 
 > I believe this will be a release we can all be proud of.

And Alan, we all deeply appreciate the great energy that you have put
into the release management process.

I'm looking forward to the final public announcement of 5.1.0, before
initiating my next PLplot undertaking.

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

Re: [Plplot-devel] 5.1.0 tagged final!!!!

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

Congratulations, Alan.  I hope I will be more active next time.

-- 
Rafael

[Plplot-devel] 5.1.0 tagged final!!!!

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

Before getting to the interesting subject of this e-mail, I should note BTW,
that I fooled around trying to get the native solaris compiler to work on
that compile farm machine this morning.  It was incredibly slow taking
minutes to compile a "hello world" programme.  Finally, after two
frustrating hours I got a message that the cc license-server was dead! Since
my working environment is Microsoft free, I never thought I would have to
contend with such licensing issues, but Sun proved me wrong....GRRH!

Anyhow, I will just rely on whatever solaris native compiler testing others
here have done.

For the solaris/gcc tests from yesterday, the 10 plmeta file differences for
solaris compile farm versus Debian woody were hard to see when I compared
results visually using plrender -dev xwin. And similarly for the 4
postscript file differences. Therefore, I judge this particular solaris/gcc
test as successful, and

=======>that completes the testing<=========

Now the actual release process begins.

I CVS tagged this version as v5_1_0_final. The only difference between
v5_1_0_final and v5_1_0_rc2 was the plplot-config.in bugfix.

v5_1_0_final is just being uploaded to the file release area as I write
this, and will probably appear there (taking into account server delays) in
an hour or so.  There is a lot to talk about for this release so it will
take me a while to put the announcement together which you will probably see
on plplot_general late this evening or even tomorrow.

I want to thank all of you who contributed so much to this release with
extensive development over the last 7 months as well as extensive bug fixing
and cross-platform testing over the last several weeks.

I believe this will be a release we can all be proud of.

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] release status as of v5_1_0_rc2

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

Alan W. Irwin writes:
 > The compile farm sparc
 > 
 > (uname -a
 > SunOS usf-cf-sparc-solaris-2 5.8 Generic_108528-11 sun4u sparc SUNW,Ultra-60)
 > 
 > had Tcl/Tk 8.3, but the names of the libraries were libtcl8.3.so and
 > libtk8.3.so so our configuration could not find them.  

I view this as more the fault of the Tcl/Tk install target, which does not
create generically named symlinks (i.e. tclsh -> tclsh8.3, etc).  I ended up
writing a script that generates all the required symlinks so I never have to
worry about it again.  I guess I could commit it to the plplot tree if anyone
wants it.

naka-spf$ ~/dev/gts/n64/tools/setup_tklinks -h
Usage:
        setup_tklinks [options]

Options:
    -h          Write usage message
    -n          Print action without actually doing anything
    -x          Sets xtrace option

Sets up links from specifically versioned Tcl/TK/iTcl/iTk libraries & binaries
to generically named ones.  You'd think the stock Tcl/etc install target would
do this.  On Linux, you can use 'ldconfig', but that's not intended for
user-installed libraries.

Must be run from the $prefix dir.  Clobbers any previous generic file links.

I don't want to get too fancy so just hardcode the version numbers.  Currently
set to:
    Tcl/Tk      8.3
    iTcl        3.2

naka-spf$ ~/dev/gts/n64/tools/setup_tklinks -n
linking libtcl.so to libtcl8.3.so
linking libtclstub.a to libtclstub8.3.a
linking libtk.so to libtk8.3.so
linking libtkstub.a to libtkstub8.3.a
linking libitcl.so to libitcl3.2.so
linking libitclstub.a to libitclstub3.2.a
linking libitk.so to libitk3.2.so
linking libitkstub.a to libitkstub3.2.a
linking tclsh to tclsh8.3
linking wish to wish8.3

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

Re: [Plplot-devel] release status as of v5_1_0_rc2

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

* Alan W. Irwin <ir...@be...> [2002-01-29 19:15]:

> Please try the new model on all platforms.  The critical question for this
> model is does plplot-config work correctly on all platforms?  AFAIK nobody
> has complained about plplot-config before so I assume it works on all
> platforms, but if it doesn't we will have to fix it.

When I wrote the plplot-config script I tried to write it in standard Bourne
shell.  The script works when there is the link /bin/sh -> ash (instead of
bash) in my Debian system, so I think it is portable.  People having access
to other platforms should test this, though.

-- 
Rafael

Re: [Plplot-devel] release status as of v5_1_0_rc2

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

On Tue, 29 Jan 2002, Alan W. Irwin wrote:

> On Tue, 29 Jan 2002, Alan W. Irwin wrote:
>
> So RedHat 7.1 seems good, and it is now on to solaris.

The compile farm sparc

(uname -a
SunOS usf-cf-sparc-solaris-2 5.8 Generic_108528-11 sun4u sparc SUNW,Ultra-60)

had Tcl/Tk 8.3, but the names of the libraries were libtcl8.3.so and
libtk8.3.so so our configuration could not find them.  Also, there
was python but no numpy which meant no python could be used.  No matwrap
so octave could not be used.  No gtk+ so gnome could not be used, no libgd
or libcd so the useful png, jpeg, and cgm devices cannot be used.

Aint Solaris wonderful?

Anyhow, --with-gcc was able to build just the C, C++ (see note below), and
fortran front ends. And of the usual png, jpeg, cgm, psc, and plmeta devices
I usually test, only the last two are available.

4 of the 32 psc files were different (in quite subtle ways as revealed by
diff and visual inspection).

10 of the 32 plmeta files were different.  I have not looked at those in
detail yet, but I assume the differences will be small.

C++ build problem.  For the static libraries on solaris, library order
matters.  plplot-config --libs --with-c++ currently puts the -lplcxxd
parameter in the wrong order so I had to change it by hand to get everything
to work.  Tomorrow, I will change plplot-config.in to do the linking in
the right order.

For those who are continuing cross-platform tests, if you are using static
libraries and C++ is enabled you should watch out for this problem when
running the ...lib/plplot5.1.0/examples/Makefile.

Conclusion: there are still a few tag ends to do before I can move from
the testing process to the actual release process, but it still looks like
the release will happen tomorrow.

Alan

Re: [Plplot-devel] a few glitches in the test process. Also, a lot of test progress

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

Alan W. Irwin writes:
 > On Tue, 29 Jan 2002, Maurice LeBrun wrote:
 > 
 > > Tested the tagged version on both of these again; no problems.
 > 
 > Thanks, Maurice.  Just tagged a new version v5_1_0_rc2 with enough changes
 > that it would be well worthwhile to do this again.  Sorry about that.

Redid my tests, still fine.

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

Re: [Plplot-devel] release status as of v5_1_0_rc2

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

On Tue, 29 Jan 2002, Alan W. Irwin wrote:

> Because of the good results on RH-7.1, I have tagged this version as
> v5_1_0_rc2.  This version will be final unless something shows up when
> viewing the RH-7.1-generated files or during the tests on the compile farm
> solaris computer.

So far so good.  The RH-7.1 file differences for png and jpeg turned out to
be mostly due to the width change that Andrew enabled for libgd >=2.0. (I
had forgotten about that). Since RH7.1 has a 1.8.x version it doesn't
generate thickened lines like my Debian version.  There were also some
subtle differences that could be seen by eye when comparing the small subset
of plots that were different (exactly the same subset of examples generated
differences for jpeg and png).  However, these subtle differences are again
probably due to different library versions. Anyhow, they are so subtle I am
not going to worry about them.

So RedHat 7.1 seems good, and it is now on to solaris.

Alan

Re: [Plplot-devel] a few glitches in the test process. Also, a lot of test progress

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

On Tue, 29 Jan 2002, Maurice LeBrun wrote:

> Tested the tagged version on both of these again; no problems.

Thanks, Maurice.  Just tagged a new version v5_1_0_rc2 with enough changes
that it would be well worthwhile to do this again.  Sorry about that.

Alan

[Plplot-devel] release status as of v5_1_0_rc2

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

I have just tagged v5_1_0_rc2 so you will be able to cvs checkout exactly
what I am working with if there is a major problem I need help with.
Meanwhile, feel free to CVS commit since I will be ignoring all updates.

Most of the changes are minor except for the new install location for
drivers and the new model for Makedemo, a.k.a. the Makefile in the installed
examples directory.  I have changed that file so it uses plplot-config
(which brings in -ltclmatrixd which is required on RH7.1) rather than
attempting to approximate the same thing which is what the old Makedemo was
trying to do.

Please try the new model on all platforms.  The critical question for this
model is does plplot-config work correctly on all platforms?  AFAIK nobody
has complained about plplot-config before so I assume it works on all
platforms, but if it doesn't we will have to fix it.

The RH 7.1 tests are mostly done.  I have been building it using the rpm
method so a byproduct of this work is an updated spec file which I just
committed before the rc2 tag.  After rpm installation, I tested the
installed examples.  The new examples Makefile which uses plplot-config (see
above) works like a charm on RH 7.1. The tk_test.sh script worked (albeit
rather slowly over my slow ssh link to the University).  Also x08c -dev
xwin, x08c -dev tk, and x08c -dev ntk all worked.  For the non-interactive
tests, the generated postscript (sans date) and plmeta files were identical
to the corresponding files generated on my Debian woody machine.  The png
and jpeg files were sometimes not identical.  I presume that is due to
different libraries (libgd 1.8.3 on RH 7.1 versus libgd 2.0.1 on Debian
woody.) Later tonight I will download those different jpeg and png files and
see how they display, but I presume they are fine since they built without
error messages and with no zero-length files.

Because of the good results on RH-7.1, I have tagged this version as
v5_1_0_rc2.  This version will be final unless something shows up when
viewing the RH-7.1-generated files or during the tests on the compile farm
solaris computer.

*With luck* we might have the release tomorrow.

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] a few glitches in the test process. Also, a lot of test progress

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

Maurice LeBrun writes:
 > Alan W. Irwin writes:
 >  > Geoffrey, Maurice, and Joao: you have all done some cross-platform testing
 >  > recently.  In the release notes can I describe that testing as Solaris/cc,
 >  > OSF1/Dec Alpha, and SuSe 7.1?  Please let me know if I have the qualifiers
 >  > right and/or whether I need more qualifiers to describe those platforms you
 >  > tested on.
 > 
 > I tried last week on the following systems with no problems:
 > 
 > zion$ uname -a
 > OSF1 zion.naka.jaeri.go.jp V4.0 564 alpha
 > 
 > naka-spf$ uname -a
 > IRIX64 naka-spf 6.5 04131233 IP35 mips
 > 
 > I'll give the latest another try soon to make sure nothing odd's come up.

Tested the tagged version on both of these again; no problems.

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

Re: [Plplot-devel] need help with atexit error

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

P.S.  and of course to exercise the non-interactive installed examples, use
plplot-test.sh from $prefix/lib/plplot5.1.0/examples The tk testing script I
included in my last e-mail also is executed from the same location.

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
__________________________