plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

Vince Darley writes:
 > The tkwin driver works fine for me with 8.4.1.  Beyond that, "isn't
 > working" doesn't shed too much light on your problem ;-)

I cannot configure plplot cvs head against a prefix with installations
of either Tcl/Tk 8.4.1, or for that matter, Tcl/Tk 8.3.4, and have the
build complete successfully.  Looking at the link lines that fail, it
is clear that libraries are being dropped, which contain needed
symbols.  Vince, you're not building on Linux are you?

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

The tkwin driver works fine for me with 8.4.1.  Beyond that, "isn't
working" doesn't shed too much light on your problem ;-)

-- Vince

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


On Wed, 6 Nov 2002, Alan W. Irwin wrote:

> On Wed, 6 Nov 2002, Geoffrey Furnish wrote:
>
> > Hi all,
> >
> > Sorry for my extended silence.  Very busy here.
>
> Always glad to hear from you.
>
> >
> > Question: Is anyone able to use cvs head with Tcl/Tk 8.4.1?  The Tk
> > driver isn't working for me in this configuration.
>
> Last I checked it worked fine for Tcl/Tk 8.3.3.  Sorry, I don't have time
> right now to try a later version of Tcl/Tk.
>
> Does PLplot cvs HEAD work okay for you with Tcl/Tk 8.3?  A positive or
> negative result there would narrow down where the problem is.
>
> Alan
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

On Wed, 6 Nov 2002, Geoffrey Furnish wrote:

> Hi all,
>
> Sorry for my extended silence.  Very busy here.

Always glad to hear from you.

>
> Question: Is anyone able to use cvs head with Tcl/Tk 8.4.1?  The Tk
> driver isn't working for me in this configuration.

Last I checked it worked fine for Tcl/Tk 8.3.3.  Sorry, I don't have time
right now to try a later version of Tcl/Tk.

Does PLplot cvs HEAD work okay for you with Tcl/Tk 8.3?  A positive or
negative result there would narrow down where the problem is.

Alan

[Plplot-devel] cvs head versus Tcl/Tk 8.4.1

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

Hi all,

Sorry for my extended silence.  Very busy here.

Question: Is anyone able to use cvs head with Tcl/Tk 8.4.1?  The Tk
driver isn't working for me in this configuration.

[Plplot-devel] Revision needed for our API for passing 3D information to our 3D routines

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

After this next release is out the door I hope to make some substantial
changes in how we call our current 3D routines, plot3d, plmesh, plsurf3d,
plcont, plshade, and plshades.

Currently we have a nonuniform mixture of API's for the way we pass 3D
information to our 3D routines. For example, many routines don't worry about
a defined region and plcont and plshade(s) have a generalized method of
passing z, x, y which allows using arbitrary methods (e.g., pltr0, pltr1,
pltr2, etc.) of evaluating the data while the rest of the routines (plot3d,
plmesh, plsurf3d) don't use a generalized method of passing 3D information
so their capabilities are much more limited as a result.

This lack of a generalized method of passing 3D information to plot3d,
plmesh, and plsurf3d has become a real problem for my own research work.
Typically my z arrays are defined with either fixed nx and ny a function of
x index or fixed ny with nx a function of y index.  It should not be a
problem for me to define more pltr variations that will handle these cases,
but the lack of a generalized method of passing information to plot3d,
plmesh, and plsurf3d also needs to be addressed as well.

One unavoidable issue is whether we are willing to go through the necessary
API changes to get these problems fixed.  My own view is changes in API are
permissible so long as there is a compelling reason. In the present case a
common API rather than the present non-uniform API for passing 3D
information to our 3D routines is IMO already a compelling enough reason for
change. To be more specific the nx, ny issue above a compelling reason. For
years gnuplot has had the facility of allowing ny to be a function of x
index or nx be a function of y index for all 3D routines, and PLplot has
suffered in comparison.  I was willing to accept this PLplot limitation in
1995 because gnuplot axis labelling sucked in the 3D case, but that does not
have to mean we must accept this PLplot limitation indefinitely.

I should also emphasize if we do decide to change to a common 3D information
passing API, that we give a strong warning to our users.  I suggest the best
way to make such a strong warning is a special release of PLplot with just
the 3D information passing API change.  I would be happy to do that once the
present release is out the door and we have implemented the API change.

What I would like to encourage now is discussion of what the ideal 3D
information passing API should be with the discussion unconstrained by any
3D passing API decisions we have made in the past.  My C skills (such as
they are) have been solely developed by looking at code in PLplot so it is
hard for me to think outside that box in a creative way. However, I believe
the current 3D argument lists are way too cluttered with z, nx, ny, and x
and y index range limits. Surely all that stuff could be made part of the
general struct that is needed in any case to pass the 3D information to the
3D routine?  It should also be kept in mind that in general either nx is a
function of y index or ny is a function of x index.

Maurice, I know you have thought quite a bit about the problem of passing 3D
information to our 3D routines in the past and also the corresponding
problem for the 3D defined region information so I am hoping you will open
the discussion on what you think that ideal API should be.  I am also hoping
that your vision will be so compelling that your post will also effectively
close the ideal API discussion....;-)

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] plenv() issues

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

Alan W. Irwin writes:
 > On Tue, 5 Nov 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
 >=20
 > > What do you think of this problem? Is there a "cure" that does not=

 > > influence other users?
 >=20
 > How about define plenv0 which does everything but the page advance? =
 Then
 > define plenv as the combination of pladv and plenv0.
 >=20
 > I know this adds one more piece of public API that we have to propag=
ate to
 > all the language interfaces *and* document, but that is pretty
 > straightforward, and we currently have so many variations on our sta=
rtup
 > commands (think of all the plstart variations), and our advance page=

 > commands, that adding another convenient plenv variation isn't that =
big a
 > deal IMO.
 >=20
 > Geoffrey and Maurice, is such a solution OK with you?

Sure.  I've never been completely happy with the behavior of plenv in t=
his
regard either.

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

Re: [Plplot-devel] plenv() issues

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

On Tue, 5 Nov 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> What do you think of this problem? Is there a "cure" that does not
> influence other users?

How about define plenv0 which does everything but the page advance?  Then
define plenv as the combination of pladv and plenv0.

I know this adds one more piece of public API that we have to propagate to
all the language interfaces *and* document, but that is pretty
straightforward, and we currently have so many variations on our startup
commands (think of all the plstart variations), and our advance page
commands, that adding another convenient plenv variation isn't that big a
deal IMO.

Geoffrey and Maurice, is such a solution OK with you?

Alan

[Plplot-devel] plenv() issues

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

Hi,

I have a recurrent problem with plenv() that I would like to discuss.

For start, plenv() is so handy that I always use it whenever possible.

But with multiplots (sub-windows or whatever -- set with plssub()), I=20
always have a problem: plenv() always advance the page, which is not=20
desirable. For interactive languages, one might wish to keep making=20
plots in the same sub-window until satisfied, and then advance to the=20
next or any other sub-window. This is not possible to do with plenv(),=20
as it always advance the page, which in multi-plot mode means another=20
sub-window.

A possible cure would be to do a pladv(desired_page -1) followed by =20
plenv(), but this fails if one desires to plot in sub-window 1, as=20
pladv(0) has a different behavior, issuing a pleop/plbop sequence.

So I always end up having a private copy of plenv() with the following=20
modifications:

 if ( plsc->nsubx * plsc->nsuby !=3D 1) {
    /* multiplot, erase current subwindow, plclear() does not work!*/
    /* don't advance page! */
    plvpor(0,1,0,1)
    plwind(0,1,0,1)
    plcol(0);plpsty(0)
    plfill(4, x_rect, y_rect); /* fill sub-window with background color=20
*/
   }
  else
    pladv(0)
 =20
CVS committing something like this would break code compatibility, as=20
users that depend on plenv() in multiplot mode would need to issue a=20
pladv(0) before.

What do you think of this problem? Is there a "cure" that does not=20
influence other users?

Thanks,
Joao

Re: [Plplot-devel] Get mouse position without action

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

On Tuesday 05 November 2002 07:34, chenu-tournier marc wrote:
| Hello
|
| I would like to get the mouse position without wating of a action
| from the user. Is that possible?
| Thanks.
| Marc

Yes. Not easy. From xwin.c:

/*-----------------------------------------------------------------------=
---*\
 * MasterEH()
 *
 * Master X event handler routine.
 * Redirects control to routines to handle:
 *    - keyboard events
 *    - mouse events
 *    - expose events
 *    - resize events
 *
 * By supplying a master event handler, the user can take over all event
 * processing.  If events other than those trapped by PLplot need=20
handling,
 * just call XSelectInput with the appropriate flags.  The default=20
PLplot
 * event handling can be modified arbitrarily by changing the event=20
struct.
\*-----------------------------------------------------------------------=
---*/

static void
MasterEH(PLStream *pls, XEvent *event)
{
  XwDev *dev =3D (XwDev *) pls->dev;
 =20
  if (dev->MasterEH !=3D NULL)
    (*dev->MasterEH) (pls, event);  <---------- user supplied, I think.
 =20
  switch (event->type) {


Or, if the the Caps-Lock key is locked, then "x01c -dev xwin -locate"=20
works!

Joao

[Plplot-devel] Get mouse position without action

[chenu-tournier m. <ch...@ma...>]

Hello

I would like to get the mouse position without wating of a action from the user.
Is that possible?
Thanks.
Marc
-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Single & ready to mingle? lavalife.com:  Where singles click. Free to Search!
http://www.lavalife.com/mailcom.epl?a=2116

[Plplot-devel] Autotools (AT)

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

Today I started my effort on what we used to call the automake/libtools
project (AM/LT), but I will call it autotools (AT) for short since autoconf
is involved as well.  These 3 tools are collectively called autotools in an
excellent on-line book I just discovered entitled "Gnu Autoconf, Automake,
and Libtool". (I am not sure whether Rafael referred to this book before,
but I found it with a google search for libtool tutorial.) The book's
website is at http://sources.redhat.com/autobook/ where you can get access
to the on-line version (with all errata applied), a download version, or
the publisher's page where you could buy the print edition.

I have already read the first 4 introductory chapters in detail, and now
that I am beginning to get into the hard part, I think I will try to follow
along with our already existing AT approach for building the documentation
in plplot/doc/docbook.  Once I thoroughly understand what was done there,
then I may be able to understand what Rafael attempted to do on the AM-LT
branch.

So obviously I am still very much just getting started with learning about AT,
but at least that start has been made.

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] Bugs...

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

Hi,

I had to restart some work, old by almost an year, and decided to use the=
=20
current plplot cvs. I found of course some bugs.

1-if I don't specify the --prefix during configure, than INSTALL_RPATH is=
=20
NONE/lib. I have to specify --prefix=3D/usr/local or /usr/local/plplot.

2-x10c.c looks different in the tk and xwin driver. I have removed the DP=
MM=20
define, which is now in plplotP.h. Please check it is now OK. I also remo=
ved=20
the definition from tkwin.c.

3-plsurf3d() seems to fail is the z matrix is all zeros (or all values ha=
ve=20
the same amplitude?).

4-x08c.java works OK only for the first set of plots, than it fails. I al=
ready=20
knew this on, this is just a reminder (and a request for help).

5-"make install" needs a plain "make" before. Not a serious issue, but a=20
target could be added. Also, a plain "make x01c" after configure don't bu=
ild=20
the dynamic drivers, one has to do "make dynamic_drivers_target" -- what =
a=20
long name!

6-the tk drivers ignore plconfig.tcl if it is in the user directory ~/tcl=
 and=20
a tclIndex file is generated. "auto_path" is correctly initialized to ~/t=
cl,=20
`pwd`/tcl, etc, but plconfig is not executed. As a matter of fact, even i=
f I=20
put a modified pldefaults.tcl in ~/tcl or `pwd`/tcl it is ignored. This i=
s=20
serious, at least for me. I'm now using a modified pldefaults.tcl in the=20
install directory.

7-the tk driver ignores the "-plwind" command line option, as it override=
s=20
pls->plwind with pls->programs. I have corrected this one.

Well, sorry for the terse report, but I'm now busy.

Thanks,
Joao

[Plplot-devel] Re: [Plplot-core] State of our statistics

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

On Saturday 26 October 2002 03:19, Andrew Roach wrote:
> >PS-I checked the page with konqueror, galeon,  mozilla,  ie (yes!), an=
d
> >netscape (can't see the source code with it!).
>
> I just checked it (twice) with ie 6 on Win XP

I have used ie 5 on win98. It worked. Not with netscape 4.79 in linux (no=
=20
source code could be viewed).

But as I'm a novice html/php user, and this was just a prototype, for pub=
lic=20
evaluation and aproval, it is obvious that it needs more attention.

I admit that I become mad when I can't see some web pages with a browser =
other=20
than ie, but I don't want to make to others what they make to me. Help=20
required!

> and both times it opened an
> infinite number of recursive "source code" panes of with the images unt=
il
> the browser crashed. That probably sounds confusing, but I cant think o=
f
> any quicker way to explain it. Basically the entire window is redrawn
> *inside* the "source code" pane, and then another copy inside each
> subsequent "source code" pane on and on... I hope that sounds a bit bet=
ter

wonderfull, a novice html/php user using recursivity! I'm really good!=20
Amazing! :-))

joao

> ?
>
> -Andrew
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> _______________________________________________
> Plplot-core mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-core

Re: [Plplot-devel] Re: [Plplot-core] State of our statistics

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

On Friday 25 October 2002 23:42, Joao Cardoso wrote:
> On Friday 25 October 2002 22:45, Alan W. Irwin wrote:
> > On Fri, 25 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
> > > Please see it at:
> > >
> > > http://plplot.sourceforge.net/nexamples/
> > >
> > > (notice, I have not changed the originals, the name is nexamples, n=
ot
> > > examples)
> > >
> > > The procedure was somewhat automated, so some things are not yet OK=
=2E
> > > I think that it is much better now. What do you think?
> >
> > I think this organization is much better than what we currently have =
in
> > examples.  However, I have some additional comments/questions.
> >
> > (1) If we change the example source in CVS will the source you show o=
n
> > the web site also be automatically changed or will that be a maintena=
nce
> > problem?
>
> Of course the web site must be updated!
>
> > (2) Same question for the images.  I ask this because right now keepi=
ng
> > the images in sync with the CVS software is a maintenance problem, an=
d it
> > would be nice if that were more automated, i.e., a script to generate=
 say
> > all the C examples as png images on your home machine (a cut-down ver=
sion
> > of plplot-test.sh) and update the website appropriately like what we =
do
> > for the documentation, now.
>
> I created a script to automate things. After configure, make, make cdem=
os,
> in the plplot tmp directory, the script will generate the pictures and
> thumbnails and populate another tree with both the source examples, the
> thumbnails and the pictures. Thus, there is no need to keep the sources=
,
> pictures and thumbnails in CVS.
>
> The script is of course crude. I attach it at the end.
>
> If the examples change (more generated pages, e.g.), then the index.php
> must be hand-edited.
>
> > (3) The full-size images are fine, but the thumb-nail images are larg=
ely
> > just a black square on both konqueor and mozilla.
>
> It didn't look like that to me... and thumbnails of plots can't be like
> thumbnails of images.

humm, as a matter of fact in my home monitor the plots looks like fadding=
 --=20
so we have another API entry, plfade() :-)

Joao

>
> >  To get the lines to show
> > for the thumbnails perhaps you need a wider pen width?
>
> I don't think so, but you can try. Anyway, I must now "publish or die",=
 so
> I don't have the time.

However I can CVS commit the index.php files, and the script to populate =
a www=20
directory. Shall the old examples files be CVS removed?
The index.php files must still be filled with the standard left navigatio=
n=20
links and be more html-conformant; the x14 and x17 examples should be rem=
oved=20
from examples.html; etc... other comments?

Joao

>
> Joao
>
> >  The png device
> > honors pen width requests if you have libgd version 2 installed.
> >
> > Alan

[Plplot-devel] Re: [Plplot-core] State of our statistics

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

On Friday 25 October 2002 22:45, Alan W. Irwin wrote:
> On Fri, 25 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
> > Please see it at:
> >
> > http://plplot.sourceforge.net/nexamples/
> >
> > (notice, I have not changed the originals, the name is nexamples, not
> > examples)
> >
> > The procedure was somewhat automated, so some things are not yet OK.
> > I think that it is much better now. What do you think?
>
> I think this organization is much better than what we currently have in
> examples.  However, I have some additional comments/questions.
>
> (1) If we change the example source in CVS will the source you show on =
the
> web site also be automatically changed or will that be a maintenance
> problem?

Of course the web site must be updated!

>
> (2) Same question for the images.  I ask this because right now keeping=
 the
> images in sync with the CVS software is a maintenance problem, and it w=
ould
> be nice if that were more automated, i.e., a script to generate say all=
 the
> C examples as png images on your home machine (a cut-down version of
> plplot-test.sh) and update the website appropriately like what we do fo=
r
> the documentation, now.

I created a script to automate things. After configure, make, make cdemos=
, in=20
the plplot tmp directory, the script will generate the pictures and=20
thumbnails and populate another tree with both the source examples, the=20
thumbnails and the pictures. Thus, there is no need to keep the sources,=20
pictures and thumbnails in CVS.

The script is of course crude. I attach it at the end.

If the examples change (more generated pages, e.g.), then the index.php m=
ust=20
be hand-edited.


>
> (3) The full-size images are fine, but the thumb-nail images are largel=
y
> just a black square on both konqueor and mozilla.

It didn't look like that to me... and thumbnails of plots can't be like=20
thumbnails of images.

>  To get the lines to show
> for the thumbnails perhaps you need a wider pen width?

I don't think so, but you can try. Anyway, I must now "publish or die", s=
o I=20
don't have the time.

Joao

>  The png device
> honors pen width requests if you have libgd version 2 installed.
>
> Alan

Re: [Plplot-devel] Moving Octave demos directory to examples/octave

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

Sorry I am responding to this question so late, but I just ran across the
definitive information.  See
http://sourceforge.net/docman/display_doc.php?docid=768&group_id=1

So contrary to several SF news items and announcements some time ago, there
is no shell access for PLplot developers to our CVS repository.  However,
the SF staff apparently are willing to do any CVS repository adjustments
that you request, and all these requests receive their highest priority.
Look at the above URL to see how to set up repository changes with them.

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] Bug report

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

On Wed, 23 Oct 2002, Joao Cardoso wrote:

>
>
> Hi,
>
> Is anyone aware of this bug report?
> http://sourceforge.net/tracker/?group_id=2915&atid=102915

Thanks for drawing this to the plplot_devel list's attention.

David, have you had any trouble building plplot with gcc/g++ 3.x on Debian
unstable like this guy claims?  I only run Debian woody with gcc/g++ 2.9.5
so I cannot prove or disprove what he says.

Alan

[Plplot-devel] Bug report

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

Hi,

Is anyone aware of this bug report?
http://sourceforge.net/tracker/?group_id=3D2915&atid=3D102915

Joao

 622084 ] c++-bindings fail to build with g++-3.2


Email:    (?)=20


Date:
2002-10-11 14:03
Priority:
5


Submitted By:
Michael Banck (mbanck)
Assigned To:
Nobody/Anonymous (nobody)


Category:
None
Status:
Open


Summary:
c++-bindings fail to build with g++-3.2


 Hi,=20

this is the error:=20
g++ -c -O -I. plstream.cc=20
In file included from /usr/include/stdlib.h:390,=20
from plplot/plplot.h:59,=20
from plstream.cc:9:=20
/usr/include/sys/types.h:99: declaration does not declare anything=20
make[1]: *** [plstream.o] Error 1=20

I'm running debian unstable.=20

cheers,=20

Michael=20

Re: [Plplot-devel] x08c changes

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

On Monday 21 October 2002 21:51, Maurice LeBrun wrote:
> The head version of x08c.c contains the following:
>
> #define XPTS   120// 35          /* Data points in x */
> #define YPTS   160// 46          /* Datat points in y */
>
> Aside from the c++isms and typo, is this precision increase intentional=
?=20
> It does look better, and is fast enough on my machine (even x08.tcl wit=
h a
> similar change).  But all the example programs should be changed to mat=
ch.

oops, it slipped from my last commit. I will put it as was before, but on=
ly=20
tomorrow.

Joao

[Plplot-devel] x08c changes

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

The head version of x08c.c contains the following:

#define XPTS   120// 35          /* Data points in x */
#define YPTS   160// 46          /* Datat points in y */

Aside from the c++isms and typo, is this precision increase intentional?  It
does look better, and is fast enough on my machine (even x08.tcl with a
similar change).  But all the example programs should be changed to match.

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

Re: [Plplot-devel] Moving Octave demos directory to examples/octave

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

On Tuesday 15 October 2002 10:27, Maurice LeBrun wrote:
| Jo=E3o Cardoso writes:
|  > I need to move files around without losing revision history
|  > ...
|  > Can anyone with the rihgt rights please do it?
|  > I want to move
|  >
|  >     bindings/octave/misc
|  > and
|  >     bindings/octave/demos
|  >
|  > to a new directory,
|  >    examples/octave/
|  >
|  > so it will look like this:
|  >    examples/octave/demos/
|  >    examples/octave/misc/
|
| AFAIK we don't have direct access to the cvs repository.  It can be
| done nevertheless, but is a chore.  The procedure I followed before
| was: - check out the CVSROOT dir, using the standard plplot $CVSROOT
| setting. - modify the script used for sending out the log messages
| (mfpipe.pl) to do it.  Best to test it using an existing local cvs
| repository, else you could really screw things up.

I see. I will let it as is. Or I might risk loosing the revision history=20
and just remove/commit in the new directory.

Thanks,
Joao

|  - check in mfpipe.pl
|  - make a dummy commit to trigger the action
|  - see if it worked
|  - revert the changes to mfpipe.pl and commit it again
|
| Have fun. :)

[Plplot-devel] The next step toward a new release of PLplot

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

Our next release date (January 2003 or later) is still up in the air because
the new linking scheme only works on Linux, and considerable effort is going
to be required to get it to work for all Unix platforms. (There are other
issues as well; please have a look at plplot/PROBLEMS.) However, I intend to
generalize the new linking scheme across Unix platforms shortly; my recent
astrophysical research effort was quite successful, but it is now winding
down, and I expect to have a lot more time for PLplot starting about a week
from now.

Here is the current status.  The current Linux linking has been set up in a
way that is largely compatible with what libtool expects.  The "long
shopping list of linking all possible libraries" scheme is gone and instead
each application or library is only linked against the specific libraries
that it needs in a hierarchical way with object code split amongst the
libaries in such a way that no cross-linking occurs between libraries.  This
scheme includes the linking of the dynamic devices which are themselves
(mini-) dynamically loaded libraries. The result of this new linking scheme,
as Maurice has noted, is much faster linking.  Also, this scheme allows for
the first time to have the tkwin, tk, and xwin devices treated as dynamic
devices.

So far this new linking scheme has only been implemented by hand for the
combination of Linux shared libraries and dynamic devices without use of
libtool at all.  We could continue this "by hand" approach to generalize the
linking scheme for some (but not all) of the other Unix platforms.  But this
would be a lot of work, and I would much rather spend my efforts making our
configuration work with automake and libtool.

These configuration tools have been adopted by a number of large (KDE, for
example) Linux projects to greatly simplify their configuration effort.
Also, there is a derived benefit that once we get the scheme to work on
Linux, it should automatically work on all Unix platforms which neatly
solves all our Unix cross-platform issues.  Thus, PLplot would greatly
benefit from using automake/libtool.  Rafael has long since come to the same
conclusion, and in fact pioneered a branch of an old version of PLplot which
used those tools for configuration.  Unfortunately, nobody else from the
development group got involved with that effort and eventually it came to a
standstill when Rafael had a new job to deal with.

What I propose to do starting late this week is to make a concentrated
effort to understand libtool, automake, and Rafael's branch with the goal of
(a) getting AM/LT configuration of our current CVS HEAD source code to work
on Linux, and (b) immediately after that bringing the AM/LT configuration
scheme to CVS HEAD for fuller group evaluation and participation in the new
scheme.  My judgement of when to bring it to CVS HEAD will follow what
happened with Geoffrey's dynamic driver effort; he brought it to CVS HEAD
once it was basically working on Linux.  There was a lot of group effort
afterward in polishing it which went quite well, and I hope something
similar happens in the AM/LT case once I bring it to CVS HEAD.

Through a concentrated effort I plan to get AM/LT configuration of PLplot to
the Linux working stage on a time scale of several weeks to a month or so.
***If anyone else wants to participate in this effort before I bring it to
CVS HEAD please get in touch with me so we can arrange how we will share the
effort.*** In particular, this effort will obviously go faster the more
Rafael is involved (in fact I would be glad if he would lead the project),
but I understand he may still have some heavy research commitments that
preclude this. Regardless of that question, PLplot configuration needs
(IMHO) to use the AM/LT approach, and I also have the time to deal with
changing to that approach now.  Thus, I plan to just go ahead with the
effort if Rafael cannot participate much at this time, but I hope he can.

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: plsurf() bugs

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

On Thu, 17 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> As I said , I don't think they are broken.

I think you are right.

For page 6 of the normal sombrero function (which is what triggered this
report initially) some of the upper surface contours do look broken even
under tk zoom.  But I find entering coordinate ranges by hand a really bad
interface to zoom in on a trouble spot so I didn't pursue it perhaps to as
high a magnification as I should have.

I abandoned that approach and tried gv on the corresponding psc file. At
ordinary magnification the upper surface contours look broken, but if you
use either anti-aliasing or higher magnification without antialiasing they
look okay.

Since the psc device gives good results, I conclude there is nothing wrong
with the contour drawing in the plsurf3d core.

Sorry for the "wild goose chase", but apparently you found and fixed anothe=
r
bug so at least it wasn't a waste of time.

As far as I am concerned your beautiful new features are ready for release.
Thanks very much for this effort.  Will you please do the honors on the
PROBLEMS and NEWS files?

Alan

[Plplot-devel] Re: plsurf() bugs

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

On Thursday 17 October 2002 18:27, Jo=E3o Cardoso wrote:
| On Thursday 17 October 2002 05:16, Alan W. Irwin wrote:
| | On Wed, 16 Oct 2002, Alan W. Irwin wrote:
=2E..

| | Joao, I have noticed one final plsurf3d core bug that shows up for
| | all front ends and which detracts from the appearance of the
| | surface contours; those contour lines are sometimes broken (page 6
| | for example).
|
| I supose you are refering to the contour drawn at the surface, using
| the rosenbrock function?
|
| If you mean the sombrero like function, than try to magnify the
| broken contour line using the tk driver. The contour is there!
|
| If you mean the rosenbrock function, and you mean that some contour
| lines in the deep valeys are broken, remember that you are watching
| just the face of the valey that is visible... thus you can only see
| part of the contour.
|
| To make the valeys more visible, you can try to increase the number
| of points, XPTS and YPTS. I did it and got a core dump!!! One more
| bug to solve.

That was easy. But one can't see better the deep valeys from the top=20
(shouldn't we call them "holes" instead of valleys?).
Anyway they are there.

Joao

| |  You comment in the code that the surface contours are
| | simple minded.  Does that mean it will be difficult to fix the
| | broken surface contour problem?

As I said , I don't think they are broken. When I said the algorithm was=20
simple minded (and it is, but it does not mean it is not effective), I=20
meant that the contour lines could be jagged, as there is no=20
interpolation nor smoothing done...
It is possible to use the information from the countour lines drawn at=20
the base xy plane, but that would make the plot much more lengthy than=20
it already is; I think, I didn't tried it.

Joao

plsurf() bugs [Was: Re: [Plplot-devel] valgrind warning generated by this line, why?]

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

On Thursday 17 October 2002 05:16, Alan W. Irwin wrote:
| On Wed, 16 Oct 2002, Alan W. Irwin wrote:
| > The tcl example 8 result is different from the C and python result.
| > I will look further at that since it may be something simple.
|
| ifshade=3D=3D2 was creating some differences, and that was due to a bug
| in tclAPI.c (clev =3D NULL rather than *clev =3D NULL) which I have now
| fixed.
|
| The results of the diff command for various combinations of ifshade
| range indicate the only remaining differences are for ifshade=3D=3D5.
| This is the page that uses contours where Joao created the levels
| following Vince's suggestion for preserving as much precision as
| possible for the current 12-digit rounding scheme.  Probably the only
| solution here is to use tcl native double precision (or single
| precision when appropriate) rather than converting strings to double
| and back rounded to 12 digits.  I am looking forward to Maurice
| implementing this just so we don't continue to have these minor but
| still somewhat lame tcl differences compared to every other front
| end.
|
| Joao, I have noticed one final plsurf3d core bug that shows up for
| all front ends and which detracts from the appearance of the surface
| contours; those contour lines are sometimes broken (page 6 for
| example).

I supose you are refering to the contour drawn at the surface, using the=20
rosenbrock function?

If you mean the sombrero like function, than try to magnify the broken=20
contour line using the tk driver. The contour is there!

If you mean the rosenbrock function, and you mean that some contour=20
lines in the deep valeys are broken, remember that you are watching=20
just the face of the valey that is visible... thus you can only see=20
part of the contour.

To make the valeys more visible, you can try to increase the number of=20
points, XPTS and YPTS. I did it and got a core dump!!! One more bug to=20
solve.

Joao

|  You comment in the code that the surface contours are
| simple minded.  Does that mean it will be difficult to fix the broken
| surface contour problem?
|
| Alan
|
|
|
| -------------------------------------------------------
| This sf.net email is sponsored by: viaVerio will pay you up to
| $1,000 for every account that you consolidate with us.
| http://ad.doubleclick.net/clk;4749864;7604308;v?
| http://www.viaverio.com/consolidator/osdn.cfm
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel