plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] dev tk problems with SuSe 7.2

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

On Friday 12 April 2002 16:34, Olof Svensson wrote:
| Joao Cardoso wrote:
| > Perhaps the plot window is widthdrawn? Could you try (2 minutes) to
| > "./x01c -dev tk", and then, from another xterm:
| >
| > [jcard@feup] wish
| > % winfo interps    <--- lists the existing tk interpreters
|
| If I try "./x01c -dev tk" I get:
|
| % winfo interps
| tk wish

Thus the problem is the launching of the second tk interpreter, the=20
plserver

| and as usual, no window and no error messages. However, if I try
| "./x01c -dev ntk" I get the plotting window and:
|
| % winfo interps
| PLplot_ntk wish
|
| Strange, isn't it? What could I try next?

Nothing for now, thanks. I will try to see what is happening, and ask=20
for your help then.

Thanks,
Joao
|
| Olof

Re: [Plplot-devel] dev tk problems with SuSe 7.2

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

Joao Cardoso wrote:
> 
> Perhaps the plot window is widthdrawn? Could you try (2 minutes) to
> "./x01c -dev tk", and then, from another xterm:
> 
> [jcard@feup] wish
> % winfo interps    <--- lists the existing tk interpreters

If I try "./x01c -dev tk" I get:

% winfo interps
tk wish

and as usual, no window and no error messages. However, if I try "./x01c
-dev ntk" I get the plotting window and:

% winfo interps                                                    
PLplot_ntk wish

Strange, isn't it? What could I try next?

Olof

Re: [Plplot-devel] dev tk problems with SuSe 7.2

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

On Thursday 11 April 2002 16:58, Olof Svensson wrote:
| Hi Joao,
|
| I managed today to get the tk driver working, not on SuSE 7.2 but on
| a Sunblade running SunOS 5.8. I compiled tcl and tk version 8.3.4 and
| the tk plotting window showed up and worked. I also tried your wish
| example on SuSE 7.2 and it gave exactly the same result for me. So,
| it seems to me that the Linux tk device problem I have is not due to
| xauth. I tried to recompile the same tcl and tk versions for SuSE 7.2
| and to build plplot 5.1.0 with these libraries however I get exactly
| the same problem, everything compiles fine and the program starts but
| no tk plotting window appears. I have tried to run the programs on
| different X-servers (XFree 3.3.6, 4.1.0, Exceed 6.2) but I always
| have the same problem.
|
| Anyway, I don't use the tk driver on SuSE, I just wanted to see how
| it works. I can now use SunOS to do this so I don't think it worth
| the effort getting the tk driver running on my SuSE system since it
| runs fine on other SuSE 7.2 systems.

That's odd...
The "other SuSE 7.2 systems" you refer to are my home and job suse-7.2=20
instalations ;-). Actually upgrades from a previous suse-7.0 -- that=20
could be the problem!

Perhaps the plot window is widthdrawn? Could you try (2 minutes) to=20
"./x01c -dev tk", and then, from another xterm:

[jcard@feup] wish
% winfo interps    <--- lists the existing tk interpreters
wish x01c tk
% send tk "wm deiconify ."   <----- deiconify the intermediate tk=20
interpreter; a small empty window should appear
% send x01c "wm deiconify ."  <---- try to deiconify the plot window;=20
it should appear
% send x01c "winfo children ." <---- list the windows hierarchy
=2Emenu .x01c

If the above does not work, please e-mail the error messages, if any.
Are you willing to try at least the "ntk" driver? just configure plplot=20
with --enable-ntk, then "./x01c -dev ntk"

We appreciate your efforts, they can be usefull for other users.

Thanks,
Joao

|
| Regards,
|
| Olof

Re: [Plplot-devel] dev tk problems with SuSe 7.2

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

Hi Joao,

I managed today to get the tk driver working, not on SuSE 7.2 but on a
Sunblade running SunOS 5.8. I compiled tcl and tk version 8.3.4 and the
tk plotting window showed up and worked. I also tried your wish example
on SuSE 7.2 and it gave exactly the same result for me. So, it seems to
me that the Linux tk device problem I have is not due to xauth. I tried
to recompile the same tcl and tk versions for SuSE 7.2 and to build
plplot 5.1.0 with these libraries however I get exactly the same
problem, everything compiles fine and the program starts but no tk
plotting window appears. I have tried to run the programs on different
X-servers (XFree 3.3.6, 4.1.0, Exceed 6.2) but I always have the same
problem.

Anyway, I don't use the tk driver on SuSE, I just wanted to see how it
works. I can now use SunOS to do this so I don't think it worth the
effort getting the tk driver running on my SuSE system since it runs
fine on other SuSE 7.2 systems.

Regards,

Olof




Joao Cardoso wrote:
> 
> On Monday 08 April 2002 18:41, Alan W. Irwin wrote:
> | On Sun, 7 Apr 2002, Joao Cardoso wrote:
> | > [...]I now have a suse 7.2 and plplot 5.1.0 with
> | > the tk driver works OK.
> |
> | Is this with the SuSe rpm's for tcl/tk or your own tarball based
> | build/install of tcl/tk?
> 
> Standard suse rpms:
> 
> bash-2.05# rpm -qf `which wish`
> tk-8.3.3-23
> 
> |  It is important to clarify this point
> | because Geoffrey used his own tcl/tk tarball's and Olof's problems
> | may be related to some incompatibility between plplot-5.1.0 and the
> | SuSe 7.2 Tcl/Tk rpm's.
> |
> | Also it appears from separate e-mail that Olof can start a wish with
> | no problems which seems to indicate his SuSe 7.2 problem with plplot
> | 5.1.0 has nothing to do with xauth.
> 
> Actually, xserver security is only important when using tcl/tk "send"
> facility. The tk driver uses it in the inicial link setup.
> 
> Using the command "xhost" disables a secure xserver:
> 
> [jcard@feup] xhost +
> access control disabled, clients can connect from any host
> [jcard@feup] wish
> %
> 
> OK, now from another xterm:
> 
> bash-2.05# wish
> % send wish "set tk_version"
> X server insecure (must use xauth-style authorization); command ignored
> %
> 
> [jcard@feup] ./x01c -dev tk
> Plplot library version: 5.1.0
> X server insecure (must use xauth-style authorization); command ignored
>     while executing
> "send $client "set server_name [list $server_name]""
>     (procedure "plserver_link_init" line 25)
>     invoked from within
> "plserver_link_init"
>     (procedure "plserver_init" line 85)
>     invoked from within
> "plserver_init"
> 
> using "xhost -" sets the xserver secure again (if it was secure before)
> 
> [jcard@feup] xhost -
> access control enabled, only authorized clients can connect
> [jcard@feup] ./x01c -dev tk
> Plplot library version: 5.1.0
> 
> Don't know if this help.
> Olof, are you still with problems?
> 
> Joao
> 
> |
> | Alan

Re: [Plplot-devel] dev tk problems with SuSe 7.2

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

On Monday 08 April 2002 18:41, Alan W. Irwin wrote:
| On Sun, 7 Apr 2002, Joao Cardoso wrote:
| > [...]I now have a suse 7.2 and plplot 5.1.0 with
| > the tk driver works OK.
|
| Is this with the SuSe rpm's for tcl/tk or your own tarball based
| build/install of tcl/tk?

Standard suse rpms:

bash-2.05# rpm -qf `which wish`
tk-8.3.3-23

|  It is important to clarify this point
| because Geoffrey used his own tcl/tk tarball's and Olof's problems
| may be related to some incompatibility between plplot-5.1.0 and the
| SuSe 7.2 Tcl/Tk rpm's.
|
| Also it appears from separate e-mail that Olof can start a wish with
| no problems which seems to indicate his SuSe 7.2 problem with plplot
| 5.1.0 has nothing to do with xauth.

Actually, xserver security is only important when using tcl/tk "send"=20
facility. The tk driver uses it in the inicial link setup.

Using the command "xhost" disables a secure xserver:

[jcard@feup] xhost +
access control disabled, clients can connect from any host
[jcard@feup] wish
%

OK, now from another xterm:

bash-2.05# wish
% send wish "set tk_version"
X server insecure (must use xauth-style authorization); command ignored
%

[jcard@feup] ./x01c -dev tk
Plplot library version: 5.1.0
X server insecure (must use xauth-style authorization); command ignored
    while executing
"send $client "set server_name [list $server_name]""
    (procedure "plserver_link_init" line 25)
    invoked from within
"plserver_link_init"
    (procedure "plserver_init" line 85)
    invoked from within
"plserver_init"


using "xhost -" sets the xserver secure again (if it was secure before)

[jcard@feup] xhost -
access control enabled, only authorized clients can connect
[jcard@feup] ./x01c -dev tk
Plplot library version: 5.1.0

Don't know if this help.
Olof, are you still with problems?

Joao



|
| Alan

Re: [Plplot-devel] dev tk problems with SuSe 7.2

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

On Sun, 7 Apr 2002, Joao Cardoso wrote:

> [...]I now have a suse 7.2 and plplot 5.1.0 with
> the tk driver works OK.

Is this with the SuSe rpm's for tcl/tk or your own tarball based
build/install of tcl/tk?  It is important to clarify this point because
Geoffrey used his own tcl/tk tarball's and Olof's problems may be related to
some incompatibility between plplot-5.1.0 and the SuSe 7.2 Tcl/Tk rpm's.

Also it appears from separate e-mail that Olof can start a wish with
no problems which seems to indicate his SuSe 7.2 problem with plplot 5.1.0
has nothing to do with xauth.

Alan

Re: [Plplot-devel] PLplot representation fidelity

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

On Mon, 8 Apr 2002, Geoffrey Furnish wrote:

> Alan W. Irwin writes:
>  > I do have some further (perhaps naive) comments.  I wouldn't worry a bit
>  > about increasing the size of the metafile by a factor of four (assuming we
>  > use 64-bit which is what I hope we do).  Disk space and band width are
>  > incredibly cheap now, and the historical trends say they will get a lot
>  > cheaper in the future. It still blows my mind that the 2GB scsi disk I
>  > bought in 1996 cost me $1700.  Now, 2GB of ATA disk space can be had for
>  > $10.
>
> Well, we do tend to see some monstrously large metafiles even now, and as
> Maurice mentioned, long haul networking to remote computational sites can
> make this as much of an issue as the disk space requirement itself.  I wonder
> how well gzip or bzip2 would be able to compress a file made up of lots of
> binary 64 bit integers with lots of zero bits mixed in.
>
> Whatever we chose, the code API's will all have to use the same size values
> for passing things around between functions, but the plmeta driver could
> narrow it down to a chosen (run time selectable) bit width before writing it
> out to disk.  I'm okay with this, sounds like Maurice is too.

Yes, that sounds like a good solution in those situations where you are
bandwidth limited.

>
> One question I have is, is there a way to specify a 64 bit integer on a 32
> bit machine, that is legal ANSI C?  I don't think so.  If I remember
> correctly, long long might be 64 bits in GCC/Linux, but it's not in ANSI C.

I confirmed 64 bits for GCC long long before I posted, but I don't know
whether modern ANSI supports it or not. There were a number of comments in
e-mail lists found by a google search of ansi long long.  The gist was
"Unfortunately, the ANSI definition of C doesn't yet include 'long long'"
which implies they might support it in due course.  Does anybody have the
definitive ansi link that discusses long long?

In any case, a large majority of our users do have gcc so long long should be
allowed as a configurable option for at least that case or to put it in terms
of the proposal above, it should be one of the run-time selectable options
if the compiler supports it.

>  > Also, it sounds to me that your present difficulties are because integers
>  > lack dynamic range. Would it be possible to get around that limitation by
>  > switching to (64-bit) floating point instead?
>
> Well, note that scaled integers of any particular size have more dynamic
> range than a float of the same size.

Agreed.  However, right now are we using scaled integers or just integers?
You really have to be careful with scaled integers that you don't have
integer overflows.  So if we don't currently have scaled integers, we might
want to use floats (of sufficient precision) instead in the interest of
simplicity.  But if the coding for scaled integers can be straightforwardly
arranged to avoid integer overflow (or if that is what we do already), then
obviously that is the best solution.

Alan

Re: [Plplot-devel] PLplot representation fidelity

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

Alan W. Irwin writes:
 > I do have some further (perhaps naive) comments.  I wouldn't worry a bit
 > about increasing the size of the metafile by a factor of four (assuming we
 > use 64-bit which is what I hope we do).  Disk space and band width are
 > incredibly cheap now, and the historical trends say they will get a lot
 > cheaper in the future. It still blows my mind that the 2GB scsi disk I
 > bought in 1996 cost me $1700.  Now, 2GB of ATA disk space can be had for
 > $10.

Well, we do tend to see some monstrously large metafiles even now, and as
Maurice mentioned, long haul networking to remote computational sites can
make this as much of an issue as the disk space requirement itself.  I wonder
how well gzip or bzip2 would be able to compress a file made up of lots of
binary 64 bit integers with lots of zero bits mixed in.  

Whatever we chose, the code API's will all have to use the same size values
for passing things around between functions, but the plmeta driver could
narrow it down to a chosen (run time selectable) bit width before writing it
out to disk.  I'm okay with this, sounds like Maurice is too.

One question I have is, is there a way to specify a 64 bit integer on a 32
bit machine, that is legal ANSI C?  I don't think so.  If I remember
correctly, long long might be 64 bits in GCC/Linux, but it's not in ANSI C.
I'd be a little concerned about having the internal data representation of
plot coordinates in PLplot depend on a construct that can't be reproduced in
a strictly conforming ANSI C program.

 > Also, it sounds to me that your present difficulties are because integers
 > lack dynamic range. Would it be possible to get around that limitation by
 > switching to (64-bit) floating point instead?

Well, note that scaled integers of any particular size have more dynamic
range than a float of the same size.  This is true both because the float
covers the whole number line, extending upward and downward from the range
covered by the scaled int, but also because several bits go to the exponent.

For a 32 bit float, you have 23 bits of mantissa that cover all space,
whereas a 32 bit saled integer has all 32 bits of "mantissa" covering just
the scaled region.  Similarly, a 64 bit float has only 53 bits of mantissa. 

-- 
Geoffrey Furnish         Lightspeed Semiconductor Corp
voice: 408-616-3244           209 North Fair Oaks        
fax:   408-616-3201	     Sunnyvale, CA   94085	     

Re: [Plplot-devel] dev tk problems with SuSe 7.2

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

On Tuesday 02 April 2002 19:23, Alan W. Irwin wrote:
| Geoffrey, your good build report below for PLplot 5.1.0 on SuSe 7.2
| may have given us a false sense of security about how well plplot
| actually runs on SuSe 7.2.

I have also tested plplot 5.1.0 on suse 7.2 during the release test=20
phase and it worked OK. I now have a suse 7.2 and plplot 5.1.0 with=20
the tk driver works OK.

The problem must be, as Maurice says, a Xserver authorization issue.
If 'wish' is launched from the command line in an insecure xserver,=20
the user must see the message "X server insecure (must use=20
xauth-style authorization)".

Generally xdm (or kdm or gdm) starts the xserver with a correct=20
=2EXauthority file; if however the user uses the "startx" command from=20
the console command line to start the X server, setting security can=20
be cumbersome.

Joao

[Plplot-devel] [lamont@smallone.fc.hp.com: Bug#141723: plplot: FTBFS: busted configure check]

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

Hi,

A bug report has been recently filled against the PLplot Debian package, but
it regards actually the configure.in.  See message attached below.

-- 
Rafael

Re: [Plplot-devel] PLplot representation fidelity

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

Geoffrey Furnish writes:
 > My personal viewpoint is that I think 16 bits is too few, and we would be
 > better off to incur the size penalty of moving to 32 bits.  Zooming fidelity
 > will be improved enough at a cost that I think is reasonable.  
 > 
 > Maybe there could be an API to set the granularity of plmeta recording?

The latter would be my preference.  I'd probably personally stick with 16 bit
encoding for most stuff since often I have to transfer it across a very slow
Pacific link.

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

Re: [Plplot-devel] PLplot representation fidelity

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

On Fri, 5 Apr 2002, Geoffrey Furnish wrote:

> Alan W. Irwin writes:
>  > Go ahead and hit us with it....;-)
>
> It finally propagated to me.  Did you get it?
>

Yes, thanks.

I do have some further (perhaps naive) comments.  I wouldn't worry a bit
about increasing the size of the metafile by a factor of four (assuming we
use 64-bit which is what I hope we do).  Disk space and band width are
incredibly cheap now, and the historical trends say they will get a lot
cheaper in the future. It still blows my mind that the 2GB scsi disk I
bought in 1996 cost me $1700.  Now, 2GB of ATA disk space can be had for
$10.

Also, it sounds to me that your present difficulties are because integers
lack dynamic range. Would it be possible to get around that limitation by
switching to (64-bit) floating point instead?

Alan

Re: [Plplot-devel] PLplot representation fidelity

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

Alan W. Irwin writes:
 > Geoffrey said:
 > 
 > > Bottom line, imo, the 16 bit virtual coordinate thing in PLplot is
 > > probably the most serious "technical" defficiency in PLplot at this
 > > time.
 > 
 > > Building a scalable rendering engine might be one way to relieve the
 > > symptoms, but unless we convert to 32 bit virtual coords, I won't regard
 > > the true underlying issue as having really been solved.
 > 
 > I had no idea there was any 16-bit code in PLplot, but I have noticed some
 > minor character distortions for ordinary example plots that vary from
 > machine to machine which may be a symptom of the same problem.  In any case
 > if we can increase the precision of how characters are drawn by eliminating
 > the 16-bit code I am all for it.  So let's get started!
 > 
 > If there is some low-level but tedious part of the task (i.e., janitorial
 > work) that needs to be done, I would be glad to help.

Well, I'm glad for your enthusiasm, but I would encourage a cautious
appraisal.  There is a /lot/ of work involved with this PLplot Improvement
Proposal.  That's why I requoted the prior text, and I'll do it again now,
jsut for emphasis, with some interspersed comments for amplification.

 > Distortion:  
 >     highly zoomed plots (Tk driver) show obvious coordinate  
 >     distortion.  Believed traceable to 16 bit (short) ints in  
 >     core->driver interface.  Fatten virtual coord rep to 32 bits.   

PLplot seems to plot on a grid of "virtual pixels", of which there are 2^16
(or is it 2^15?) across the viewport (or is it the physical page?).  Ending
points for drawing segments are, I believe, constrained to this grid.  Some
truncation effects probably come into play here at the point of selecting
exactly which of two neighboring pixels certain an end point.  I suppose, for
educational enrichment, it would be good to understand clearly how this works
out in practice.

 >     Tasks:  
 >         core->driver dispatch funcs line, polyline, short->int  

Because the addressable graphics coordinate space is a square 2^16 (virtual)
pixel grid, there are numerous places where shorts are passed around in the
code.  Specifically and significantly, in the interface to the driver drawing
routines, called from the core.  Those should all be fattened to 32 bits, and
all the threads followed backward from that point to find the origin of all
16 bit quantities, and fatten them all to 32 bits.

I think this is a fairly major undertaking all by itself.

 >         plmeta, dump 4 bytes instead of 2  

Irradication of 16 bit virtual pixel addressing and promotion to 32 bits
means all plemta output will have to be fattened as well, thus
instantaneously doublling the size of all meta files...

 >         plrender, bump metafile version, backward handling for old  
 >                   metafiles.  

which will break old metafiles for plrender, unless we do proper version
increment and add code to read old 16 bit metafiles and promote them to 32
bits on the way into plrender.

 >         dashing: currently walks virtual pixels one-by-one, horrific  
 >             if expand coord space by 2^16.  Need to revamp dashing to  
 >             /calculate/ (in world coords) dash starts and stops,  
 >             including bracketing so polyline can turn corners  
 >             correctly.   

This is probably the harriest task.  Dashing actually walks virtual pixels.
I have not studied this code in sufficient detail to know what to do about
it, but we will effectively ruin PLplot for dashed/dotted line drawing if we
are not extremely careful.  It seems dashing specification is based in
physical coords (mm), and so the dasher somehow walks virtual pixels one by
one looking to see when it has covered a specific physical distance.
Increasing the address space will slow the current algorithm down by 2^16,
which will be horrifically slow.

I think all the dashing code needs to be gutted and converted to somehow
/calculate/ the ending coordinates of each dash, rather than sampling the
virtual pixel grid in a death march to oblivion.  Note that for this to
really be done right, dashes need to be able to "turn corners" when used in
polyline drawing and so forth.

This is a major undertaking, I am sure.

 >         Tk driver, like plmeta/plrender, bump transmission to use 4  
 >             bytes instead of 2.  

As with plmeta/plrender interface issues.

 > One point you should consider; if we are going to this effort in any case,
 > is there any reason not to go to long long integers (which would translate
 > to 64-bit integers on 32-bit machines)?  I don't want to be dealing with
 > 32-bit to 64-bit issues 10 years from now because we didn't look ahead.
 > Also, before you say there is no way we would ever require 64-bit integers
 > consider Bill Gates' infamous statement that "64k of RAM is all anyone
 > should ever need."....;-)

I think this is a very important issue.  There are important things which
depend directly on the bit width of plotting representation.  These things
are fundamentally: speed and space.  Fatter bit width in the plotting
representation implies higher fidelity plots, slower graphics performance,
and larger transmission buffers (whether metafiles or sockets to Tk, etc).

Now, there is no real way to accomodate all conceivable future plotting
fidelity requirements, even by going to 64 bits.  16 bits seems to be enough
for many types of scientific plots where you're just trying to represent a
publication quality historgram, line, or contour plot, with human legible
labelling. 

What I am doing right now, is drawing integrated circuits, which have vastly
more feature detail than the histograms and line plots and contour plots
currently exibited in our demo programs, for example.  These plots have
orders of magnitude more total detail, graphics elements, etc.  16 bits ain't
enough for this application.  I doubt this is really unqiue to my current
application.  I suspect there are lots of CAD-type potential users who are
not using PLplot because it doesn't support the level of detail they need.  

But note, right now I am drawing pictures of chips with order of a million
gates.  But silicon integration marches ever forward.  Current generation
microprocessors already have on the order of 100 million gates, and we all
know where this trend is headed.  So, I doubt moving to even 64 bits would
forever stem the tide.  

My feeling is that the only long term solution for scientific and engineering
application domains involving "telescoping" plotting capabilities, is to
implement a sophisticated multi-scale rendering engine which draws only the
features that can actually be resolved at a given "depth" (for lack of a
better word).

And if this is the eventual solution, then I suppose it calls into question
the advisability of even doing the 16->32 bit transition in the first place.
I thnk 16 bits is plenty for human resolvable detail.  The problem comes in
when you start zooming with plframe.  So, the real question here, is do we
want to change the default fidelity so that it supports a signficantly
greater level of "zoomability", fully realizing that this undetaking  has
several inherent properties:

1) It won't fully solve the problem, because there will still be a zoom depth
   beyond which more bits of fidelity would be required anyway.
2) It will make for fatter metafiles, or data representtion buffers in
   whatever form they take (like socket transmissions, whatever).
3) A truly scalable rendering engine will ultimately have to be developed
   anyway. 

I would very much like to see contributions to this thread from all
concerned.  

My personal viewpoint is that I think 16 bits is too few, and we would be
better off to incur the size penalty of moving to 32 bits.  Zooming fidelity
will be improved enough at a cost that I think is reasonable.  

Maybe there could be an API to set the granularity of plmeta recording?

-- 
Geoffrey Furnish         Lightspeed Semiconductor Corp
voice: 408-616-3244           209 North Fair Oaks        
fax:   408-616-3201	     Sunnyvale, CA   94085	     

Re: [Plplot-devel] PLplot representation fidelity

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

Geoffrey said:

> Bottom line, imo, the 16 bit virtual coordinate thing in PLplot is probably
the most serious "technical" defficiency in PLplot at this time.

> Building a scalable rendering engine might be one way to relieve the
symptoms, but unless we convert to 32 bit virtual coords, I won't regard the
true underlying issue as having really been solved.

I had no idea there was any 16-bit code in PLplot, but I have noticed some
minor character distortions for ordinary example plots that vary from
machine to machine which may be a symptom of the same problem.  In any case
if we can increase the precision of how characters are drawn by eliminating
the 16-bit code I am all for it.  So let's get started!

If there is some low-level but tedious part of the task (i.e., janitorial
work) that needs to be done, I would be glad to help.

One point you should consider; if we are going to this effort in any case,
is there any reason not to go to long long integers (which would translate
to 64-bit integers on 32-bit machines)?  I don't want to be dealing with
32-bit to 64-bit issues 10 years from now because we didn't look ahead.
Also, before you say there is no way we would ever require 64-bit integers
consider Bill Gates' infamous statement that "64k of RAM is all anyone
should ever need."....;-)

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] dev tk problems with SuSe 7.2

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

On Wed, 3 Apr 2002, Geoffrey Furnish wrote:

> [...] Anyway, the "problem", is almost surely an issue with xauth.  Our
> sysops got xauth working here, so I was never plagued by xauth-itis
> while I was running SuSE on our network.

Long ago Maurice alluded to the same xauth/Tcl problem, but I have never
encountered it with Debian.  I do have an .Xauthority file in my home
directory which was updated fairly recently so I believe xauth is running on
my system.  It looks like the Debian maintainer of that package has set it
up properly.

The rest of this is not a PLplot topic, but I think you might still be
interested since you have recently had to change distributions.

I wish Debian woody would go final so I could fully recommend it to my
friends.  But if you have similar needs to my own then it is the
distribution for you.  If you have further interest, the thing to do is to
install a minimal Debian potato system, then edit /etc/apt/sources.list to
point to woody rather than potato, then use

apt-get update; apt-get install apt-get; apt-get dist-upgrade

To turn your system into woody.

Debian woody is still quite active with about 10 packages upgraded each day
as it slowly converges to the final version. But it has been stable (in the
sense of nothing major broken) for me for many months with outstanding
quality assurance on the huge number of packages in the distribution so I am
quite happy I upgraded from potato (and from RedHat before that).

Alan

[Plplot-devel] more plotting quality issues

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

Hi all,

A little more on the same theme.  Three more attachments:

[Plplot-devel] PLplot representation fidelity

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

Greetings all,

In the state of the union address, I had mentioned:

 > Distortion: 
 >     highly zoomed plots (Tk driver) show obvious coordinate 
 >     distortion.  Believed traceable to 16 bit (short) ints in 
 >     core->driver interface.  Fatten virtual coord rep to 32 bits.  
 >  
 >     Tasks: 
 >         core->driver dispatch funcs line, polyline, short->int 
 >         plmeta, dump 4 bytes instead of 2 
 >         plrender, bump metafile version, backward handling for old 
 >                   metafiles. 
 >         dashing: currently walks virtual pixels one-by-one, horrific 
 >             if expand coord space by 2^16.  Need to revamp dashing to 
 >             /calculate/ (in world coords) dash starts and stops, 
 >             including bracketing so polyline can turn corners 
 >             correctly.  
 >         Tk driver, like plmeta/plrender, bump transmission to use 4 
 >             bytes instead of 2. 

I wanted to show an example that shows what I'm talking about here.

I'm attaching three files which show a PLplot plframe inside a Tk application
that I'm working on these days.

RE: [Plplot-devel] dev tk problems with SuSe 7.2

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

Alan W. Irwin writes:
 > Geoffrey, your good build report below for PLplot 5.1.0 on SuSe 7.2 may have
 > given us a false sense of security about how well plplot actually runs
 > on SuSe 7.2.
 > 
 > I have a report from Olof Svensson <sve...@es...> (who is part of the
 > team working on the pyqt widget and the windows port) that he cannot get the
 > tk device to work on his SuSe 7.2 system with plplot-5.1.0.  (He was trying
 > to verify what tcl/tk results would look like on Linux before trying to get
 > them to work on Windows.)
 > 
 > The configure and make seem to work fine for him, but if he runs
 > 
 > ./x01c -dev tk
 > 
 > (or any other tcl or tk example) he gets absolutely no widget results (and
 > no error messages).  Apparently, -dev xwin works fine for him.
 > 
 > I checked his
 > 
 > ./configure --with-double
 > 
 > and his make results and can find nothing obviously wrong, and in fact I
 > tried that same ./configure --with-double myself before building a fresh
 > plplot-5.1.0, and I get good-looking widget results from ./x01c -dev tk on
 > Debian woody. So it is not a general plplot problem but probably just
 > something specific to SuSe 7.2.
 > 
 > I think the next step is to try and verify the problem. Geoffrey, can you do
 > this on the SuSe 7.2 system available to you?  I assume from your message
 > below that everything built okay on that system, but you didn't actually try
 > a -dev tk test.  It would be most interesting to see if such a test works
 > for you or not with the usual tcl/tk rpm's from SuSe.

I switched my Lightspeed desktop from SuSE to Red Hat 7.1 a month or
so ago, because I just couldn't take SuSE anymore.  So now all my
personal work is done on Red Hat 7.1.  I'll probably upgrade to 7.2
one of these days...

Anyway, the "problem", is almost surely an issue with xauth.  Our
sysops got xauth working here, so I was never plagued by xauth-itis
while I was running SuSE on our network.  But if xauth isn't set up
right, you'll have to either straighten that out (a Herculean task if
you ask me), or circumvent it entirely (my standard course of action
when I have to deal with this issue) by setting TK_NO_SECURITY in your
Tk makefile and recompiling.

I also never use the system packaged Tcl/Tk stuff.  I always download
my own Tcl/Tk/Itcl tarballs, install to a private prefix, and
configure/make/install PLplot against this private prefix.  

There is no way to make PLplot automatically xauth imune.  If you're
using xauth on your system, you just have to figure it out, or
disable Tk's sensitivity to it (which can only be done by recompiling
Tk from source).

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

Re: [Plplot-devel] dev tk problems with SuSe 7.2

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

Alan W. Irwin writes:
 > Geoffrey, your good build report below for PLplot 5.1.0 on SuSe 7.2 may have
 > given us a false sense of security about how well plplot actually runs
 > on SuSe 7.2.
 > 
 > I have a report from Olof Svensson <sve...@es...> (who is part of the
 > team working on the pyqt widget and the windows port) that he cannot get the
 > tk device to work on his SuSe 7.2 system with plplot-5.1.0.  (He was trying
 > to verify what tcl/tk results would look like on Linux before trying to get
 > them to work on Windows.)
 > 
 > The configure and make seem to work fine for him, but if he runs
 > 
 > ./x01c -dev tk
 > 
 > (or any other tcl or tk example) he gets absolutely no widget results (and
 > no error messages).  Apparently, -dev xwin works fine for him.

One thing to try is the standalone Tk demos, i.e. 'make tkdemos' then test
each of those.  If they are ok, it's probably a communication problem.  Turn
off all xhost based access as Tk send is supposed to give an error in that
case.  

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

[Plplot-devel] dev tk problems with SuSe 7.2

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

Geoffrey, your good build report below for PLplot 5.1.0 on SuSe 7.2 may have
given us a false sense of security about how well plplot actually runs
on SuSe 7.2.

I have a report from Olof Svensson <sve...@es...> (who is part of the
team working on the pyqt widget and the windows port) that he cannot get the
tk device to work on his SuSe 7.2 system with plplot-5.1.0.  (He was trying
to verify what tcl/tk results would look like on Linux before trying to get
them to work on Windows.)

The configure and make seem to work fine for him, but if he runs

./x01c -dev tk

(or any other tcl or tk example) he gets absolutely no widget results (and
no error messages).  Apparently, -dev xwin works fine for him.

I checked his

./configure --with-double

and his make results and can find nothing obviously wrong, and in fact I
tried that same ./configure --with-double myself before building a fresh
plplot-5.1.0, and I get good-looking widget results from ./x01c -dev tk on
Debian woody. So it is not a general plplot problem but probably just
something specific to SuSe 7.2.

I think the next step is to try and verify the problem. Geoffrey, can you do
this on the SuSe 7.2 system available to you?  I assume from your message
below that everything built okay on that system, but you didn't actually try
a -dev tk test.  It would be most interesting to see if such a test works
for you or not with the usual tcl/tk rpm's from SuSe.

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
__________________________

On Mon, 28 Jan 2002, Geoffrey Furnish wrote:

> 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 have built a clean checkout today on both SuSE-7.2 and Solaris 5.7.
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] FW: PlPlot interface to AquaTerm (Mac OS X)

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

On Sunday 24 March 2002 05:08, mr...@co... wrote:
| I was using PlPlot (http://plplot.sourceforge.net)  to do plotting
| on the Mac before Mac OS X.  When OS X came out, I started looking
| into writing a shell to do plotting on the Mac under Quartz and
| Cocoa.  When Aquaterm cam out, I looked at using this as the front
| end.   I used the PGPlot interface and modified it for PlPlot.  I
| am including all the required files and instructions on how to
| compile PlPlot with the Aquaterm files.

Mark,

Thanks for the enclosed information and interest in PLplot under Mac=20
OS X.

I can take a look at your proposals, but as I lack a Mac I need=20
further support from you. If we, at PLplot, agree to incorporate your=20
changes into PLplot, are you willing to continue supporting the=20
changes, namely sending patches against cvs?

Thanks a lot,
Joao

=2E..

| As a result of going through this process, A couple of things would
| be nice:
|
| - Ability of Aquaterm to return cursor position in the plotting
| area - Ability to provide interactive feed back to and from the
| plotting package and Aquaterm.  Ths is nice because right now, I
| just let it run between plots.  I could set a simple "hit return"
| at the end of each plot to inform plplot to do the next set.
| - Ability to make Quicktime movies from a series of plots.
| - Ability to copy the plot without it being a postscript file -
| Under the classic version, when I copied a plot, I did it as a PICT
| so I could edit the plot.  It's tough editing a postscript file.
| - Speed up Aquaterm plotting.
|
| That's about it for now.  Hopefully, this makes sense.
|
| Mark Franz

[Plplot-devel] Please welcome David Schleef

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

Greetings to all worldwide members of the PLplot community.

It is my pleasure to announce that David Schleef (SF username
dschleef) has recently joined the PLplot core team.  David has
recently been involved with Debian packaging for PLplot, and Rafael
and David are planning continued close coordination in this area in
the near term.

Please join me in welcoming David.

Best regards to all,

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

[Plplot-devel] FW: PlPlot interface to AquaTerm (Mac OS X)

[<mr...@co...>]

I was using PlPlot (http://plplot.sourceforge.net)  to do plotting on the
Mac before Mac OS X.  When OS X came out, I started looking into writing a
shell to do plotting on the Mac under Quartz and Cocoa.  When Aquaterm cam
out, I looked at using this as the front end.   I used the PGPlot
interface and modified it for PlPlot.  I am including all the required
files and instructions on how to compile PlPlot with the Aquaterm files.

The simplest way to compile and test out PlPlot is to run it as a command
line program.  I created a Foundation tool project and place the PlPlot
source, header, examples and driver files into individual groups.  You can
remove those driver files for other systems you don't need or you can
leave them in.

- Remove mac.c and mac.h files from the drivers and header files if they
are there. You can use those for a classic version.

- Place aqt.m, aqt.h, AQTProtocol.h where ever you want.

- Make sure Foundation and Appkit Frameworks are in the project.  Add them
if they aren't there

- In the examples, I renamed "main(int argc, char *argv[])" to
"pl_main(int argc, char *argv[])" and use the included main.m file to call
the examples.  This only required one global replace per example file and
simplified the whole process.

The following are additional mods to the core Plplot files needed set up
Plplot to use Aquaterm.

- in the file plDevs.h, add the line

#define PLD_aqt    // Aquaterm Device

and undefine all the other devices.  This informs PlPlot that all plotting
will take place via Aquaterm.  I also tested the postscript driver and it
works - of course.

- In the file plcore.h,  add the lines:

#ifdef PLD_aqt
     plD_dispatch_init_aqt,
#endif

This identifies the dispatch table for Aquaterm plotting calls

-  In the file drivers.h add the line

void plD_dispatch_init_aqt    ( PLDispatchTable *pdt );

In the attached screen capture, PlPlot_PB.jpg, (See location below) I show
what files are 
modified and how I set up the project builder sructure.  I had a minor
problem with the way header files were included in the source files.  The
source files had

#include "plplot/header.h" , I put all the files into one folder and did a
global replace on "plplot/header.h" to just "header.h"

The files in the lib folder that contain the Hersey fonts and map data
need to be either in the folder with the compiled image or you can set a
series of environment variables to tell PlPlot where to look for these
files.  See plplotP.h and plLibOpen() in file plctrl.c for information on
the variables to set.  If plplot can't find these files, it complains and
stops.

These files are: usaglobe.map; usa.map; plxtnd5.fnt; plstnd5.fnt;
globe.map; cglobe.map

With the above instructions, I was able to compile all the examples and
run them.  Some required tcl and tk or other special features I haven't
gotten around to implement yet.  All the c versions compiled with no mod's
except for the "main" -> "pl_main" change except there were problems with:
     x14.c    requires tcl and tk
     x17.c    It's a stripcchart, and partly works then it crashes - I'll
              look into it
     x20.c    works with images and I need to better understand Aquaterm
              interface to make it work

also, the tutor.c program requires a data file if you want to run that.

Screenshots for some of the examples are included at the following site:
http://mywebpages.comcast.net/mrfranz/plplot/
  PlPlot1.jpg       Screen shot of plplot example
  PlPlot2.jpg       Screen shot of plplot example
  PlPlot_PB.jpg     Project Builder set-up

Couple of notes:

Other changes I made:  I changed the plotting area in Aquaterm.  You had
set the plotting window max's in the variables AQUA_XMAX and AQUA_YMAX and
also hard coded it in a couple of other places.

In GPTView.h, i changed the definitions of AQUA_XMAX and AQUA_YMAX to be

#define AQUA_XMAX (12.0*72.0)    /*  width times screen resolution.
12.0*72 = 864.0 */
#define AQUA_YMAX (12.0*72.0)    /*  height times screen resolution. 12.0*
72 = 864.0 */

Wherever you had hardwired the max sizes before, I included the header
file GPTView.h and replace them with AQUA_XMAX and AQUA_YMAX where
appropriate.

I also made the GPTView window in GPTWindow.nib a 400 x 400 viewing size
and set the max size to be 800 x 800 and min size to be 200 x 200.  Others
might want something else, but, these work for me.
Whatever one sets AQUA_XMAX and AQUA_YMAX to in AquaTerm, make sure the
variables AQT_Max_X and AQT_Max_Y in aqt.m are set to the same value.

Number of Aquaterm plotting windows:  This is controlled by the variable
currentPlot defined in aqt.m.  In the routine:  plD_bop_aqt, I set a
maximum numer of windows in the line:

     currentPlot = currentPlot>maxWindows?0:currentPlot;

Change the value of maxWindows to whatever you want.  It's set to 10 now.
When currentPlot exceed that number, it will start to reuse open windows.

As a result of going through this process, A couple of things would be nice:

- Ability of Aquaterm to return cursor position in the plotting area
- Ability to provide interactive feed back to and from the plotting
package and Aquaterm.  Ths is nice because right now, I just let it run
between plots.  I could set a simple "hit return" at the end of each plot
to inform plplot to do the next set.
- Ability to make Quicktime movies from a series of plots.
- Ability to copy the plot without it being a postscript file - Under the
classic version, when I copied a plot, I did it as a PICT so I could edit
the plot.  It's tough editing a postscript file.
- Speed up Aquaterm plotting.

That's about it for now.  Hopefully, this makes sense.

Mark Franz

RE: [Plplot-devel] gnuplot to PLplot translation

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

Maurice LeBrun writes:
 > I'm wondering if this is something that's amenable to a flex/yacc treatment.
 > If so a flex/yacc expert could probably whip something out in a few days, and
 > we'd just need to add the underlying support routines for doing the actual
 > plots.  That way we could support gnuplot "natively" through a new set of
 > bindings.  Eventually adding plplot-specific enhancements, of course.

BTW I think of this as a "binding" because it does (barely) fit into the
paradigm of a mapping from some arbitrary API onto plplot core intrinsics.
Each binding we have is a thoroughly independent beast, although we try
to make the API's similar.  In this case, we don't. :)

And as a binding, it would eventually come with a set of example programs that
reproduce the current example set.  Using the "PLplot command superset" as
necessary..

Sounds like a pretty cool project.

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

RE: [Plplot-devel] gnuplot to PLplot translation

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

Alan W. Irwin writes:
 > But regardless of what they do on the licensing or name, it is still
 > interesting to think about implementing an import filter from a gnuplot
 > script to a plplot script to ease the transition for those gnuplot users who
 > want to give plplot a try.  So I would like to hear from anybody here who
 > will admit (;-) to recent gnuplot experience whether they think such an
 > import filter is even possible.

I inherited some simple gnuplot scripts while at dejanews.  Although I did some
enhancement/tweaking, I never got around to redoing them in plplot because the
results were good enough for the job at hand.  

I just got around to downloading the most recent gnuplot -- 3.7.1, which was
released over 2 years ago!  Apparently the project has stagnated quite a bit.
They also lost their domain gnuplot.org, so are now at gnuplot.info.

The distribution does come with a set of demos:

ged$ ls demo
1.dat         bivariat.dem  gnuplot.rot   multimsh.dem  reread.bor    spline.dem    using.dat
2.dat         borders.dem   hemisphr.dat  multiplt.dem  scatter.dem   start.par     using.dem
3.dat         contours.dem  hexa.fnc      param.dem     scatter2.dat  stat.inc      vector.dem
airfoil.dem   controls.dem  hidden.dem    polar.dem     silver.dat    steps.dat     whale.dat
all.dem       density.fnc   klein.dat     poldat.dem    simple.dem    steps.dem     world.cor
animate.dem   discrete.dem  lcdemo.dat    prob.dem      singulr.dem   surface1.dem  world.dat
battery.dat   electron.dem  line.fnc      prob2.dem     sound.par     surface2.dem  world.dem
big_peak.dat  fit.dem       mgr.dem       random.dem    sound2.par    timedat.dat
binary.dem    glass.dat     moli3.dat     reflect.fnc   soundvel.dat  timedat.dem

So at least any attempt at replacement would have something to shoot for.

I'm wondering if this is something that's amenable to a flex/yacc treatment.
If so a flex/yacc expert could probably whip something out in a few days, and
we'd just need to add the underlying support routines for doing the actual
plots.  That way we could support gnuplot "natively" through a new set of
bindings.  Eventually adding plplot-specific enhancements, of course.

Any CS majors out there remember their flex/yacc? :)

I'd be tempted to look into it myself if I weren't so terribly busy -- I spent
a day studying the two a while back and was fascinated.

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