plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] automatic dependencies

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

On Wed, 27 Feb 2002, Geoffrey Furnish wrote:

>  > I have no idea why gcc_v3 is being set to 1 rather than the expected zero.
>
> Turned out to be a quoting issue.

OK.  I checked out a clean copy and everything builds nicely now with
generation of .d.* files to hold the dependency information.

Thanks, Geoffrey, for this quick fix.

Alan

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

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

Using the return value in two different ways is a little awkward because I
believe the first sub-page is numbered zero rather than one.  We could
return i+1 but that could lead to all sorts of misunderstandings.  So how
about just changing the API?  It is possible this might hurt some of our
users since it is public API, but I feel this is not too likely since it is
not part of the documented common API.

If we agree that it is okay to change the API, I am thinking of returning
the window number in the argument list and returning success or failure as
before.  But I am no API expert so any other suggestions are welcome
especially if there is some obvious data structure where the returned
window number could be stored.

As far as the common API version is concerned (let's call it c_plgwc where
"gwc" stands for get world coordinates), I also intend to have a return of 1
for success and 0 for failure. Essentially it will be identical to the
current plTranslateCursor except it will have x and y "absolute" coordinates
as input, and world coordinates and window number as output rather than
assuming those data are accessible to/from a PLGraphicsIn struct.  The new
plTranslateCursor would then consist essentially of a call to c_plgwc with
an argument transformation from a PLGraphicsIn struct to the simple input
variables of c_plgwc on input and the reverse on the returned variables.

I intend to implement these ideas right away, and after checking that it
works I will commit it subject to change if anybody has some API ideas
in the meanwhile.

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 Wed, 27 Feb 2002, Joao Cardoso wrote:

> On Wednesday 27 February 2002 04:07, Alan W. Irwin wrote:
> | I would appreciate further discussion of one aspect of the
> | plTranslateCursor code.
> |
> | It goes through a reversed list of windows (I assume these are
> | sub-windows?) and for the first one where the cursor is inside the
> | sub-window it does the transformation and returns.
> |
> | If I have this interpretation right, then it looks like the pyqt
> | group's plgetpos using data in the PLStream struct won't really
> | work since on a page with subwindowing, the world coordinates can
> | vary wildly form sub-window to sub-window (e.g., example 1), and
> | their code doesn't take account of this.  So my guess is they are
> | going to be forced (by example 1) to go to the plTranslateCursor
> | type of transformation.
>
> One problem with plGetCursor() is that it doesn't give information on
> which sub-page the mouse event occurred. I always found this a
> serious limitation.
>
> Perhaps using the "i" variable as the return value from
> plGetCursor()? of course existing code that relies on a "1" to be
> returned would fail, but I guess that most code is just checking for
> a zero/non-zero return value. An advantage of this approach is that
> it wouldn't break API compatibility.
>
> Joao
>
> |
> | Do you agree?
> |
> | 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 mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] valgrind [purify killer]

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

Joao Cardoso writes:
 > While reading the valgrind docs, it looks like that it's output is 
 > very verbose. In your experience can this be a problem? 500 errors to 
 > parse :-x

valgrind gives you one block of errors for each "context", and
multiple occurrences of an error in a context result in no additional
printings of that context block during the program run.  Then at the
end, it summarizes activity in each context.  So no, 500 errors is not
that bad, because its only a few contexts, with a few lines each.
Again, if you've used purify, this will look very familiar.

For example, here's the error output for x08c:

[furnish@xiphi tmp2]$ valgrind x08c -dev xwin
==7932== valgrind-20020224, a memory error detector for x86 GNU/Linux.
==7932== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==7932== For more details, rerun with: -v
==7932== 
==7932== Use of uninitialised value of size 4
==7932==    at 0x402C3582: plnxtvhi_draw (plot3d.c:826)
==7932==    by 0x402C34E8: plnxtvhi (plot3d.c:793)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932==    by 0x402C1EE3: plt3zz (plot3d.c:499)
==7932== 
==7932== Use of uninitialised CPU condition code
==7932==    at 0x402C35B2: plnxtvhi_draw (plot3d.c:837)
==7932==    by 0x402C34E8: plnxtvhi (plot3d.c:793)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932==    by 0x402C1EE3: plt3zz (plot3d.c:499)
==7932== 
==7932== Use of uninitialised value of size 4
==7932==    at 0x402C4AD6: pl3cut (plot3d.c:1563)
==7932==    by 0x402C3A96: plnxtvhi_draw (plot3d.c:949)
==7932==    by 0x402C34E8: plnxtvhi (plot3d.c:793)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932== 
==7932== Use of uninitialised value of size 4
==7932==    at 0x402C4B2F: pl3cut (plot3d.c:1574)
==7932==    by 0x402C3A96: plnxtvhi_draw (plot3d.c:949)
==7932==    by 0x402C34E8: plnxtvhi (plot3d.c:793)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932== 
==7932== Use of uninitialised CPU condition code
==7932==    at 0x402C4B35: pl3cut (plot3d.c:1575)
==7932==    by 0x402C3A96: plnxtvhi_draw (plot3d.c:949)
==7932==    by 0x402C34E8: plnxtvhi (plot3d.c:793)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932== 
==7932== Use of uninitialised value of size 4
==7932==    at 0x402C4B87: pl3cut (plot3d.c:1588)
==7932==    by 0x402C3A96: plnxtvhi_draw (plot3d.c:949)
==7932==    by 0x402C34E8: plnxtvhi (plot3d.c:793)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932== 
==7932== Use of uninitialised value of size 4
==7932==    at 0x402C3582: plnxtvhi_draw (plot3d.c:826)
==7932==    by 0x402C34E8: plnxtvhi (plot3d.c:793)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932==    by 0x402C2C41: plgrid3 (plot3d.c:640)
==7932== 
==7932== Use of uninitialised CPU condition code
==7932==    at 0x402C35B2: plnxtvhi_draw (plot3d.c:837)
==7932==    by 0x402C34E8: plnxtvhi (plot3d.c:793)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932==    by 0x402C2C41: plgrid3 (plot3d.c:640)
==7932== 
==7932== Use of uninitialised value of size 4
==7932==    at 0x402C1C8C: plt3zz (plot3d.c:463)
==7932==    by 0x402C0BF8: c_plotsh3d (plot3d.c:159)
==7932==    by 0x8048F28: main (x08c.c:113)
==7932==    by 0x406D5627: __libc_start_main
(../sysdeps/generic/libc-start.c:129)
==7932== 
==7932== Invalid read of size 4
==7932==    at 0x402C35AC: plnxtvhi_draw (plot3d.c:837)
==7932==    by 0x402C34E8: plnxtvhi (plot3d.c:793)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932==    by 0x402C1EE3: plt3zz (plot3d.c:499)
==7932==    Address 0x4164BE20 is 0 bytes after a block of size 24
alloc'd
==7932==    at 0x4005745E: malloc (vg_clientmalloc.c:590)
==7932==    by 0x402C335B: plnxtvhi (plot3d.c:746)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932==    by 0x402C1EE3: plt3zz (plot3d.c:499)
==7932== 
==7932== Invalid read of size 4
==7932==    at 0x402C35AC: plnxtvhi_draw (plot3d.c:837)
==7932==    by 0x402C34E8: plnxtvhi (plot3d.c:793)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932==    by 0x402C1EE3: plt3zz (plot3d.c:499)
==7932==    Address 0x41664284 is 0 bytes after a block of size 376
alloc'd
==7932==    at 0x4005745E: malloc (vg_clientmalloc.c:590)
==7932==    by 0x402C335B: plnxtvhi (plot3d.c:746)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932==    by 0x402C1EE3: plt3zz (plot3d.c:499)
==7932== 
==7932== Use of uninitialised value of size 4
==7932==    at 0x402C3582: plnxtvhi_draw (plot3d.c:826)
==7932==    by 0x402C34E8: plnxtvhi (plot3d.c:793)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932==    by 0x402C2E61: plgrid3 (plot3d.c:658)
==7932== 
==7932== Use of uninitialised CPU condition code
==7932==    at 0x402C35B2: plnxtvhi_draw (plot3d.c:837)
==7932==    by 0x402C34E8: plnxtvhi (plot3d.c:793)
==7932==    by 0x402C32F9: plnxtv (plot3d.c:725)
==7932==    by 0x402C2E61: plgrid3 (plot3d.c:658)
==7932== 
==7932== Use of uninitialised value of size 4
==7932==    at 0x402C1C8C: plt3zz (plot3d.c:463)
==7932==    by 0x402C0CE9: c_plotsh3d (plot3d.c:164)
==7932==    by 0x8048F28: main (x08c.c:113)
==7932==    by 0x406D5627: __libc_start_main
(../sysdeps/generic/libc-start.c:129)
==7932== 
==7932== ERROR SUMMARY: 5079 errors from 14 contexts (suppressed: 16
from 1)
==7932== malloc/free: in use at exit: 9184 bytes in 69 blocks.
==7932== malloc/free: 765 allocs, 696 frees, 878849 bytes allocated.
==7932== For a detailed leak analysis,  rerun with: --leak-check=yes
==7932== For counts of detected errors, rerun with: -v
[furnish@xiphi tmp2]$ 

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

Re: [Plplot-devel] automatic dependencies

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

Alan W. Irwin writes:
 > On Tue, 26 Feb 2002, Geoffrey Furnish wrote:
 > >  > On my system the gcc version is as follows:
 > >  > gcc -dumpversion
 > >  > 2.95.4
 > >
 > > ?!?!  What the heck is 2.95.4?  Never heard of it.  And the release
 > > page at gcc.gnu.org makes no mention of it.  Must be another Linux
 > > dist vendor inventing gcc releases again like Red Hat did when they
 > > christened a daily gcc snapshot "2.96" and started the whole debacle.
 > 
 > I believe the .4 is just part of the Debian numbering scheme.
 > >From their changelog, they are just following gcc CVS for 2.9.5 for
 > various snapshots.

Well, there is no official gcc 2.95.4, just as there is no official
gcc 2.96.  Red Hat really opened a can of worms when they decided to
declare their own "gcc release" from a daily snapshot.  If more Linux
dists are following this trend, I think its going to lead to (more)
trouble. 

 > > Could you do me a favor and paste that line into your system, and try
 > > editing it to find out what makes the error message go away?  Is the
 > > problem the -M* options, or is it the multiple -c options, or is it
 > > just the use of the -o (which would totally floor me).
 > 
 > If the "-MF .d.pdfutils -MP" part of the option string is dropped all is
 > well. Another way of saying this is you can add -MD and (the redundant) -c
 > to the normal compile command from yesterday, and it compiles without
 > complaint, but -MF and -MP options cause problems.

Thanks.

 > I then echoed gcc_major right from the Makefile and it
 > was 2 as expected.  I then tried the same thing with gcc_v3 and
 > it was 1 which *was not expected* and which causes the problem.
 > 
 > I have no idea why gcc_v3 is being set to 1 rather than the expected zero.

Turned out to be a quoting issue.

Re: [Plplot-devel] valgrind [purify killer]

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

Maurice LeBrun writes:
 > Geoffrey Furnish writes:
 >  > For those whoe know Rational's purify product, this is the GPL app
 >  > that's gonna crush purify, at least on the Linux platform.  Rational
 > 
 > I'm glad to see it.  I left a message on Rational's web site about
 > Linux support, and although they did eventually get back to me, their
 > response was ludicrous -- yes they were going to support Linux but only
 > for IA-64. <snort>  Unbelievable.  Let's see, just how many installed
 > platforms IS that? :)

purify licenses are /really/ expensive.  When I talked to their
director of Unix tools some years ago while I was at LANL, he
basically said they didn't believe Linux users would be willing to pay
their Solaris/HPUX fees.  I had to agree.

They're probably figuring people with IA-64's will be willing to pay
more, since IA-64 is aimed higher, at corporate enterprise level
computing.  They're probably right.

Whether they're right or not, one thing is for sure.  valgrind makes
purify irrelevant for Linux on IA32.  And since valgrind has a virtual
(he calls it "synthetic") IA32 cpu buried inside it, it won't port
trivially to other architectures.

OTOH, the patheway having been demosntrated once, personally I am
/sure/ valgrind-like tools will show up on more architectures.  It's
just too good not to grow.

Re: [Plplot-devel] valgrind [purify killer]

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

Alan W. Irwin writes:
 > Does the problem with x08c go away if you comment out the plotsh3d call near
 > the end of the file?  It would be most interesting if our problems with 3D
 > shading were due to bugs in memory management.

I just ran "valgrind x08c -dev xwin", and saw errors being reported
during each of the various types of plots.  So I think it is not
solely a plotsh3d thing.  

Yesterday I tried to debug it, but quickly got lost.  I've never
really climbed around in that particular jungle gym before, and it's a
real work out.

 > I will give valgrind a try once CVS HEAD is working again....;-)

I think it's working now.

[Plplot-devel] automatic dependencies

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

I've fixed the auto deps support for Linux + old GCC strains.  Sorry
about the flase start.

At this point, it is my belief that:

1) Platforms other than Linux should see no change to prior behavior.
   ie, stale deps stored in objs.in are used, provide the appearance
   of dependency support, but mask out of date dependencies, resulting
   in trouble for developers on those platforms.

2) Linux with old GCC should see substantially improved behavior.
   Dependencies are now maintained along with the .o's, so are always
   up to date.

3) Linux with GCC 3+ sees best in class automatic dependency support,
   with a single GCC invocation producing both the .o and the .d
   files. 

All core and driver C files are covered.  x??c.c demos are covered.
tutor.c is not covered, and all f77 and C++ files are not covered.  

demos.in should be reformulated to use GNU pattern rules more
aggressively, and search for a way to fold tutor into the mix.

Shouldn't be too hard to support C++ source files for gcc 2/3, but I
won't be satisfied unless the soln handles KCC too.

Need to decide how to deal with non-Linux systems.  The old objs.in
thing is so much inferior to automorphing deps that I'd be personally
tempted to just toss objs.in, but I don't know how to implement
autodeps for every platform supported by PLplot at this time.  What do
other developers think about dropping objs.in, and just taking the
position that if someone wants deps for <their favorite platform>
then they should contribute code to define the dependency generation
step in the new compilation paradigm for their os/compiler choice, and
we'll integrate it.   ???

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

Re: [Plplot-devel] plGetCursor() return value (was Should plgetpos ...)

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

On Wednesday 27 February 2002 04:07, Alan W. Irwin wrote:
| I would appreciate further discussion of one aspect of the
| plTranslateCursor code.
|
| It goes through a reversed list of windows (I assume these are
| sub-windows?) and for the first one where the cursor is inside the
| sub-window it does the transformation and returns.
|
| If I have this interpretation right, then it looks like the pyqt
| group's plgetpos using data in the PLStream struct won't really
| work since on a page with subwindowing, the world coordinates can
| vary wildly form sub-window to sub-window (e.g., example 1), and
| their code doesn't take account of this.  So my guess is they are
| going to be forced (by example 1) to go to the plTranslateCursor
| type of transformation.

One problem with plGetCursor() is that it doesn't give information on=20
which sub-page the mouse event occurred. I always found this a=20
serious limitation.

Perhaps using the "i" variable as the return value from=20
plGetCursor()? of course existing code that relies on a "1" to be=20
returned would fail, but I guess that most code is just checking for=20
a zero/non-zero return value. An advantage of this approach is that=20
it wouldn't break API compatibility.

Joao

|
| Do you agree?
|
| Alan
|
| email: ir...@be...
| phone: 250-727-2902=09FAX: 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

Re: [Plplot-devel] valgrind [purify killer]

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

On Tuesday 26 February 2002 23:32, Geoffrey Furnish wrote:
| Hi All,
|
| I wanted to take a moment to call everyone's attention to an
| incredibly amazing Linux utility I discovered yesterday, valgrind.
|
| http://devel-home.kde.org/~sewardj/
|
| This tool is simply amazing.  I discovered it yesterday, and was
| able to use it to immediately find several bugs in my own code.=20
| I've also spent a little time using it on PLplot, and the short
| statement is that it definitely has some things to say about
| PLplot.
|
| I think that some of its output is spurious/erroneous.  It seems to
| finger some code that I don't believe is actually wrong, and some
| of these "bug" reports migrate around as I recompile PLplot with
| different versons of GCC.  I don't know if this reflects a bug in
| valgrind, or in GCC.
|
| But anyway, there are plenty of things it finds that I don't doubt
| to be real.  I fixed one problem yesterday in cmap0 initialization,
| that was rooted out using valgrind.
|
| Today I ran all the C examples through valgrind.  Omitting the ones
| that produced diagnostics I suspect to be spurious, the ones of
| interest are x08c, x11c, and x20c.  The first two of these seem to
| utilize unitialized memory thousands of times each.  The error
| count on x20c is smaller, around 500 I think, but that's still
| pretty serious.

I will certainly try it -- I have downloaded it, but I'm still using=20
linux-2.2.18 at home, and valgrind requires 2.4.x.

As for the x20c and image related core functions, they are still=20
under development, and I'm sure bug-full, e.g., x20c segfaults on an=20
alpha OSF. I know development on this has been slow, but I'm on a bad=20
mood.

While reading the valgrind docs, it looks like that it's output is=20
very verbose. In your experience can this be a problem? 500 errors to=20
parse :-x

Joao

|
| I tried to prosecute the bugs in plot3d.c (from x08c.c), but
| eventually gave up.  The bugs in there are buried too deep for me
| to spot easily.  Seems to have something to do with the u and v
| arrays in plot3d.c not having been initialized all the way to the
| last elements.
|
| Anyway, I just wanted to commend this tool to everyone.  If you're
| working on compiled code, you've gotta try valgrind, whether its
| PLplot related or not.  This tool is just amazing.
|
| For those whoe know Rational's purify product, this is the GPL app
| that's gonna crush purify, at least on the Linux platform.=20
| Rational doesn't currently ship purify on Linux, and at this point,
| I'm sure they never will, 'cause there's no longer a need.=20
| valgrind does what purify does, only perhaps arguably even better.=20
| You'll have to read the valgrind docs to understand why I say that,
| but basically it takes the notion of code instrumentation that
| purify applies to individual objects, and in valgrind this notion
| is translated straight to the cpu.  The "cpu" in valgrind is a sort
| of Intel Architecture simulator, which does for /any/ x86 object
| code, the same kind of thing that purify does on object code it
| gets to massage.  Stated another way, it's a lot like Purify, only
| more general.  And it's GPL'd.
|
| Anyway, if you work with C or C++ code on Linux, you've gotta try
| valgrind.

[Plplot-devel] Re: plgetpos transformation (was valgrind)

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

I would appreciate further discussion of one aspect of the plTranslateCursor
code.

It goes through a reversed list of windows (I assume these are sub-windows?)
and for the first one where the cursor is inside the sub-window it does the
transformation and returns.

If I have this interpretation right, then it looks like the pyqt group's
plgetpos using data in the PLStream struct won't really work since on a
page with subwindowing, the world coordinates can vary wildly form sub-window
to sub-window (e.g., example 1), and their code doesn't take account of
this.  So my guess is they are going to be forced (by example 1) to go
to the plTranslateCursor type of transformation.

Do you agree?

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] plgetpos transformation (was valgrind)

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

On Tue, 26 Feb 2002, Geoffrey Furnish wrote:

> Alan W. Irwin writes:
>  > Also, Geoffrey, despite the current flurry of PLplot activity, I especially
>  > hope you will contribute to the discussion of the python/plgetpos choice I
>  > face.  I don't want to implement one way, only to find out you prefer the
>  > other choice.
>
> Sorry, I realize I'm slipping into the half comatose, half wildly
> active external appearance thing again.  It just comes down to job
> pressure.
>
> I did read your note fully once, but would have to do so at least once
> or twice more to formulate an opinion worth articulating.  Do I
> correctly surmise that the central issue is the codification of an API
> for inverse coordinate mapping, from pixel coords on a display to
> world coords associated with a defined viewport?
>
> If so, you should also check to see how this is currently done in
> other places.  I think there's an example of this in x01c, associated
> with the locator demo, and there's also a demo of this somewhere in
> the Tk stuff, I think.  I know Maurice and I have a Tk app which does
> this reverse coordinate translation stuff, triggered by Tk mouse
> motion and button click event bindings, but I think one of us also
> shoe-horned that into one of the Tk demos, N years ago.
>
> So, if this is correct, then we should look for a way to make all the
> bindings compatible, and at least consider any current usage as a
> model for such implementation.
>
> Alternatively, if I've missed the point of your missive, please spell
> it out for me again.  I'll reread again for the details, but could you
> just state the purpose clearly in one or two sentences?

It is definitely a coordinate transformation, but it is not my code, and the
various coordinate systems in PLplot are poorly documented so that is why I
quoted the code the pyqt guys think they need rather than making a poor
attempt to explain it.

I will have to dig somewhat deeper to understand what is going on with the
coordinate system transformations. Maurice's further message was most
encouraging, but I don't know whether that cursor transformation does quite
the same thing at this stage.

One complication is the cursor transformation uses different data for the
transformation, i.e., "relative" (dxmi, etc.) and world (wxmi, etc.) window
coordinates from a PLWindow struct.  plgetpos uses "normalized" (vpwxmi) and
world (vpwxmi, etc.) viewport coordinates from a PLStream struct.  Right now
I don't know whether "relative" and "normalized" mean the same thing or
how/when the PLWindow struct coordinate data is generated.

Another complication is the pyqt code multiplies the "normalized" viewport
coordinates by the current width and height of the window as available from
pyqt.  Now that multiplied coordinate may be equivalent to the "absolute"
device coordinates within the PLWindow struct, but I just don't know at this
stage.

It would be a big help if one of you could give me a definition of absolute,
relative, and normalized coordinates.  Perhaps for completeness you should
also include world coordinates, but I think I understand what those are.

TIA,

Alan

Re: [Plplot-devel] automatic dependencies

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

On Tue, 26 Feb 2002, Geoffrey Furnish wrote:

> Hi Alan,
>
> Thanks for the prompt usage report.
>
> Alan W. Irwin writes:
>  > gcc -c          -O    -I. -I/home/software/java/jdk1.2.2//include -I/home/software/java/jdk1.2.2//include/linux -I/usr/include/tcl8.3 -I/usr/include/tcl8.3/itcl-private/generic -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/gnome-1.0 -I/usr/lib/gnome-libs/include -I/usr/include/orbit-1.0 -MD -MF .d.pdfutils -MP -c pdfutils.c -o pdfutils.o
>  > gcc: cannot specify -o with -c or -S and multiple compilations
>  > make[1]: *** [pdfutils.o] Error 1
>  > make[1]: Leaving directory `/home/software/plplot_cvs/HEAD/plplot/tmp'
>  > make: *** [all] Error 2
>  >
>  > For your convenience here is a wrapped version of that gcc line
>  >
>  > gcc -c          -O
>  > -I. -I/home/software/java/jdk1.2.2//include
>  > -I/home/software/java/jdk1.2.2//include/linux
>  > -I/usr/include/tcl8.3
>  > -I/usr/include/tcl8.3/itcl-private/generic
>  > -I/usr/include/gtk-1.2
>  > -I/usr/include/glib-1.2
>  > -I/usr/lib/glib/include
>  > -I/usr/X11R6/include
>  > -I/usr/include/gnome-1.0
>  > -I/usr/lib/gnome-libs/include
>  > -I/usr/include/orbit-1.0
>  > -MD -MF .d.pdfutils -MP -c pdfutils.c -o pdfutils.o
>  >
>  > On my system the gcc version is as follows:
>  > gcc -dumpversion
>  > 2.95.4
>
> ?!?!  What the heck is 2.95.4?  Never heard of it.  And the release
> page at gcc.gnu.org makes no mention of it.  Must be another Linux
> dist vendor inventing gcc releases again like Red Hat did when they
> christened a daily gcc snapshot "2.96" and started the whole debacle.

I believe the .4 is just part of the Debian numbering scheme.
From their changelog, they are just following gcc CVS for 2.9.5 for
various snapshots.

>
> Could you do me a favor and paste that line into your system, and try
> editing it to find out what makes the error message go away?  Is the
> problem the -M* options, or is it the multiple -c options, or is it
> just the use of the -o (which would totally floor me).

If the "-MF .d.pdfutils -MP" part of the option string is dropped all is
well. Another way of saying this is you can add -MD and (the redundant) -c
to the normal compile command from yesterday, and it compiles without
complaint, but -MF and -MP options cause problems.


>
>  > The working compile I did yesterday with the old plplot didn't have the
>  > "-MD -MF .d.pdfutils -MP -c" part of the command so I assume it is
>  > some aspect of that string of parameters that is causing the
>  > problem for my gcc version 2.95.4.
>  >
>  > As you alluded to in your message the configuration seems to be adding these
>  > gcc-3.0 parameters to the gcc command line when my system only has 2.95.4.
>
> Mmm.  Sorry.  Could you look in lib_sh_linux.in near the top, where
> the with_gcc3 business is, and telll me if you see how the shell code
> is coming up with the wrong answer there?  When I try to duplicate the
> stuff that's in $(shell ...) on my own xterm, it comes up with the
> right answer, so I can't see how it would be getting it wrong inside make.

The lines in question from the Makefile are the following:

************
with_gcc := yes

ifeq ($(with_gcc),yes)
# Need to figure out if this is GCC version 3 or not.
gcc_major := $(shell gcc -v 2>&1 | grep version | \
			cut '-d ' -f 3 | cut -d. -f 1 )
gcc_v3 := $(shell expr $gcc_major \>= 3)

ifeq ($(gcc_v3),1)
define compile-c-and-emit-deps
$(CC) $(1) -MD -MF $(3:$(2).o=.d.$(2)) -MP -c $(2).c -o $(3)
endef
automatic_deps := yes
else
define compile-c-and-emit-deps
$(CC) $(1) -c $(2).c -o $(3)
endef
automatic_deps := not_yet
endif

else
# Define the simple forms.
endif

************

Under bash on my system:
gcc -v 2>&1 | grep version | cut '-d ' -f 3 | cut -d. -f 1
2

So that works okay.  Furthermore,

export gcc_major=2
echo $gcc_major
2
expr $gcc_major \>= 3
0

So that works as well.

I then echoed gcc_major right from the Makefile and it
was 2 as expected.  I then tried the same thing with gcc_v3 and
it was 1 which *was not expected* and which causes the problem.

I have no idea why gcc_v3 is being set to 1 rather than the expected zero.

>
> Shell drives me bonkers.

The shell command within Makefiles drives me crazy....;-)

To verify my problem set gcc_major to 2, and go from there. Good luck in
finding why gcc_v3 is being set to 1 rather than the expected 0 under these
circumstances (gcc_major == 2). I wondered if the backwards slash in expr
$gcc_major \>= 3 had to be escaped when it is in a Makefile but replacing by
\\ just caused a syntax error.

Alan

Re: [Plplot-devel] valgrind [purify killer]

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

Geoffrey Furnish writes:
 > For those whoe know Rational's purify product, this is the GPL app
 > that's gonna crush purify, at least on the Linux platform.  Rational

I'm glad to see it.  I left a message on Rational's web site about
Linux support, and although they did eventually get back to me, their
response was ludicrous -- yes they were going to support Linux but only
for IA-64. <snort>  Unbelievable.  Let's see, just how many installed
platforms IS that? :)

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

Re: [Plplot-devel] Should plgetpos be part of the common API or plP_gvpd and plP_gvpw?

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

As Geoff mentioned, something very similar to this is already being done at
some places in the code.  E.g.

x01c calls plGetCursor (plpage.c), to get world coordinates of mouse click

plGetCursor calls plTranslateCursor (plpage.c)

plTranslateCursor employs basically the same logic as pl_getpos, except in
a loop over windows.

So I suggest ripping out the core logic from plTranslateCursor and putting it
into a common API function, say c_plgetpos, that returns x & y world
coordinate values given device values, and a status code.  Then you could
call that from both pl_getpos and plTranslateCursor.

Alan W. Irwin writes:
 > Alexandre Gobbo and friends have suggested some python API as follows:
 > 
 > static char doc_getpos[]="transforms window coordinates into graphic coordinates";
 > 
 > static PyObject * pl_getpos(PyObject *self, PyObject *args)
 > {
 > 	PLINT x,y;
 > 	PLINT inside=1;
 > 	PLFLT xmin,xmax,ymin,ymax;
 > 	PLINT w,h;
 > 	PLFLT posX, posY;
 > 	PLStream *pls;
 > 
 > 	PyObject *result;
 > 	TRY (PyArg_ParseTuple(args, "iiii", &x,&y, &w,&h));
 > 	plgpls(&pls);   // pls points directly to a structure PLStream
 > 
 > 	xmin=pls->vpdxmi*(PLFLT)w;
 > 	xmax=pls->vpdxma*(PLFLT)w;
 > 	ymin=pls->vpdymi*(PLFLT)h;
 > 	ymax=pls->vpdyma*(PLFLT)h;
 > 
 > 	if      ((x < xmin)||(x > xmax)||(y < ymin)||(y > ymax)) inside=0;
 > 
 > 	if      (x < xmin)	x=(PLINT)xmin;
 > 	else if (x > xmax)	x=(PLINT)xmax;
 > 	if      (y < ymin)	y=(PLINT)ymin;
 > 	else if (y > ymax)	y=(PLINT)ymax;
 > 
 > 	posX=  pls->vpwxmi + (((PLFLT)x-xmin)*(pls->vpwxma-pls->vpwxmi)/(xmax-xmin));
 > 	posY=  pls->vpwyma - (((PLFLT)y-ymin)*(pls->vpwyma-pls->vpwymi)/(ymax-ymin));
 > 
 > 
 > 	result = Py_BuildValue(PL_ARGS("(idd)", "(iff)"),inside, posX, posY);
 > 	return result;
 > }
 > 
 > w, and h (width and height from the pyqt GUI environment) and x and y are
 > supplied, and the flag "inside" and  posX and posY are returned.
 > 
 > I want to discuss some alternatives to this approach here because I am
 > allergic to special PLplot API for each individual front end.
 > 
 > So here is one question I would like you to consider.  Would this general
 > functionality be useful for the common API for other GUI's?  If so, I would
 > strip all the python stuff out and make it generally available as common API
 > and then add a python wrapper to this new common API so Gobbo et al.
 > would have access to it from python.
 > 
 > If not generally useful, then I will suggest they do this logic in python
 > using the values of pls->vpdxmi, etc., and pls->vpwxmi, etc. returned from
 > the PLplot environment.
 > 
 > Before looking at how to retrieve the values, I have looked carefully at how
 > these values are set for the PLplot environment.  pls->vpdxmi, etc. are
 > generated in either c_plsvpa (called from c_plenv) and c_plvpor, and
 > pls->vpwxmi, etc. are generated by c_plwind (called on its own or from
 > c_plenv).
 > 
 > These values are retrieved from the PLplot environment using the plP_gvpd
 > and plP_gvpw functions.  Currently these functions are part of the public C
 > API, but are meant for internal PLplot use and are not currently part of the
 > common API.
 > 
 > So if some overall functionality like the C part of the code above does not
 > become part of the common API with a python wrapper, then instead I would
 > convert plP_gvpd and plP_gvpw to common API, and provide python wrappers.
 > 
 > Which choice is better?
 > 
 > 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

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

Re: [Plplot-devel] valgrind [purify killer]

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

Alan W. Irwin writes:
 > Also, Geoffrey, despite the current flurry of PLplot activity, I especially
 > hope you will contribute to the discussion of the python/plgetpos choice I
 > face.  I don't want to implement one way, only to find out you prefer the
 > other choice.

Sorry, I realize I'm slipping into the half comatose, half wildly
active external appearance thing again.  It just comes down to job
pressure.  

I did read your note fully once, but would have to do so at least once
or twice more to formulate an opinion worth articulating.  Do I
correctly surmise that the central issue is the codification of an API
for inverse coordinate mapping, from pixel coords on a display to
world coords associated with a defined viewport?

If so, you should also check to see how this is currently done in
other places.  I think there's an example of this in x01c, associated
with the locator demo, and there's also a demo of this somewhere in
the Tk stuff, I think.  I know Maurice and I have a Tk app which does
this reverse coordinate translation stuff, triggered by Tk mouse
motion and button click event bindings, but I think one of us also
shoe-horned that into one of the Tk demos, N years ago.

So, if this is correct, then we should look for a way to make all the
bindings compatible, and at least consider any current usage as a
model for such implementation.

Alternatively, if I've missed the point of your missive, please spell
it out for me again.  I'll reread again for the details, but could you
just state the purpose clearly in one or two sentences?

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

Re: [Plplot-devel] valgrind [purify killer]

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

That does look like a killer app for C/C++ development which I could have
used when tracking down driver segfaults. Thanks for drawing valgrind to
my/our attention.

Does the problem with x08c go away if you comment out the plotsh3d call near
the end of the file?  It would be most interesting if our problems with 3D
shading were due to bugs in memory management.

I will give valgrind a try once CVS HEAD is working again....;-)

Also, Geoffrey, despite the current flurry of PLplot activity, I especially
hope you will contribute to the discussion of the python/plgetpos choice I
face.  I don't want to implement one way, only to find out you prefer the
other choice.

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 Tue, 26 Feb 2002, Geoffrey Furnish wrote:

> Hi All,
>
> I wanted to take a moment to call everyone's attention to an
> incredibly amazing Linux utility I discovered yesterday, valgrind.
>
> http://devel-home.kde.org/~sewardj/
>
> This tool is simply amazing.  I discovered it yesterday, and was able
> to use it to immediately find several bugs in my own code.  I've also
> spent a little time using it on PLplot, and the short statement is
> that it definitely has some things to say about PLplot.
>
> I think that some of its output is spurious/erroneous.  It seems to
> finger some code that I don't believe is actually wrong, and some of
> these "bug" reports migrate around as I recompile PLplot with
> different versons of GCC.  I don't know if this reflects a bug in
> valgrind, or in GCC.
>
> But anyway, there are plenty of things it finds that I don't doubt to
> be real.  I fixed one problem yesterday in cmap0 initialization, that
> was rooted out using valgrind.
>
> Today I ran all the C examples through valgrind.  Omitting the ones
> that produced diagnostics I suspect to be spurious, the ones of
> interest are x08c, x11c, and x20c.  The first two of these seem to
> utilize unitialized memory thousands of times each.  The error count
> on x20c is smaller, around 500 I think, but that's still pretty
> serious.
>
> I tried to prosecute the bugs in plot3d.c (from x08c.c), but
> eventually gave up.  The bugs in there are buried too deep for me to
> spot easily.  Seems to have something to do with the u and v arrays in
> plot3d.c not having been initialized all the way to the last
> elements.
>
> Anyway, I just wanted to commend this tool to everyone.  If you're
> working on compiled code, you've gotta try valgrind, whether its
> PLplot related or not.  This tool is just amazing.
>
> For those whoe know Rational's purify product, this is the GPL app
> that's gonna crush purify, at least on the Linux platform.  Rational
> doesn't currently ship purify on Linux, and at this point, I'm sure
> they never will, 'cause there's no longer a need.  valgrind does what
> purify does, only perhaps arguably even better.  You'll have to read
> the valgrind docs to understand why I say that, but basically it takes
> the notion of code instrumentation that purify applies to individual
> objects, and in valgrind this notion is translated straight to the
> cpu.  The "cpu" in valgrind is a sort of Intel Architecture simulator,
> which does for /any/ x86 object code, the same kind of thing that
> purify does on object code it gets to massage.  Stated another way,
> it's a lot like Purify, only more general.  And it's GPL'd.
>
> Anyway, if you work with C or C++ code on Linux, you've gotta try
> valgrind.
>
> --
> Geoffrey Furnish         fu...@ga...
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] automatic dependencies

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

Hi Alan,

Thanks for the prompt usage report.

Alan W. Irwin writes:
 > gcc -c          -O    -I. -I/home/software/java/jdk1.2.2//include -I/home/software/java/jdk1.2.2//include/linux -I/usr/include/tcl8.3 -I/usr/include/tcl8.3/itcl-private/generic -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/gnome-1.0 -I/usr/lib/gnome-libs/include -I/usr/include/orbit-1.0 -MD -MF .d.pdfutils -MP -c pdfutils.c -o pdfutils.o
 > gcc: cannot specify -o with -c or -S and multiple compilations
 > make[1]: *** [pdfutils.o] Error 1
 > make[1]: Leaving directory `/home/software/plplot_cvs/HEAD/plplot/tmp'
 > make: *** [all] Error 2
 > 
 > For your convenience here is a wrapped version of that gcc line
 > 
 > gcc -c          -O
 > -I. -I/home/software/java/jdk1.2.2//include
 > -I/home/software/java/jdk1.2.2//include/linux
 > -I/usr/include/tcl8.3
 > -I/usr/include/tcl8.3/itcl-private/generic
 > -I/usr/include/gtk-1.2
 > -I/usr/include/glib-1.2
 > -I/usr/lib/glib/include
 > -I/usr/X11R6/include
 > -I/usr/include/gnome-1.0
 > -I/usr/lib/gnome-libs/include
 > -I/usr/include/orbit-1.0
 > -MD -MF .d.pdfutils -MP -c pdfutils.c -o pdfutils.o
 > 
 > On my system the gcc version is as follows:
 > gcc -dumpversion
 > 2.95.4

?!?!  What the heck is 2.95.4?  Never heard of it.  And the release
page at gcc.gnu.org makes no mention of it.  Must be another Linux
dist vendor inventing gcc releases again like Red Hat did when they
christened a daily gcc snapshot "2.96" and started the whole debacle. 

Could you do me a favor and paste that line into your system, and try
editing it to find out what makes the error message go away?  Is the
problem the -M* options, or is it the multiple -c options, or is it
just the use of the -o (which would totally floor me).

 > The working compile I did yesterday with the old plplot didn't have the
 > "-MD -MF .d.pdfutils -MP -c" part of the command so I assume it is
 > some aspect of that string of parameters that is causing the
 > problem for my gcc version 2.95.4.
 > 
 > As you alluded to in your message the configuration seems to be adding these
 > gcc-3.0 parameters to the gcc command line when my system only has 2.95.4.

Mmm.  Sorry.  Could you look in lib_sh_linux.in near the top, where
the with_gcc3 business is, and telll me if you see how the shell code
is coming up with the wrong answer there?  When I try to duplicate the
stuff that's in $(shell ...) on my own xterm, it comes up with the
right answer, so I can't see how it would be getting it wrong inside make.  

Shell drives me bonkers.

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

Re: [Plplot-devel] automatic dependencies

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

On Tue, 26 Feb 2002, Geoffrey Furnish wrote:

> Hello all,
>
> Driven by desperation, I've begun to implement automatic dependency
> generation for PLplot.  I've just committed some files, and I figure I
> should give people a heads up.
>
> I hope my changes today don't mess anyone up.  If anyone sees builds
> failing as a result of these changes, please let me know ASAP so I can
> work on repairing things.
>

Will do....;-)

I made a clean checkout, then my usual

./configure --prefix=/usr/local/plplot --with-double --enable-dyndrivers
--enable-java --enable-gnome --enable-ntk > & ! configure.out

Could see no problems in configure.out so I then tried make

make >&! make.out.

Here is that file with the error.

cd tmp; make default
make[1]: Entering directory `/home/software/plplot_cvs/HEAD/plplot/tmp'
gcc -c          -O    -I. -I/home/software/java/jdk1.2.2//include -I/home/software/java/jdk1.2.2//include/linux -I/usr/include/tcl8.3 -I/usr/include/tcl8.3/itcl-private/generic -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/gnome-1.0 -I/usr/lib/gnome-libs/include -I/usr/include/orbit-1.0 -MD -MF .d.pdfutils -MP -c pdfutils.c -o pdfutils.o
gcc: cannot specify -o with -c or -S and multiple compilations
make[1]: *** [pdfutils.o] Error 1
make[1]: Leaving directory `/home/software/plplot_cvs/HEAD/plplot/tmp'
make: *** [all] Error 2

For your convenience here is a wrapped version of that gcc line

gcc -c          -O
-I. -I/home/software/java/jdk1.2.2//include
-I/home/software/java/jdk1.2.2//include/linux
-I/usr/include/tcl8.3
-I/usr/include/tcl8.3/itcl-private/generic
-I/usr/include/gtk-1.2
-I/usr/include/glib-1.2
-I/usr/lib/glib/include
-I/usr/X11R6/include
-I/usr/include/gnome-1.0
-I/usr/lib/gnome-libs/include
-I/usr/include/orbit-1.0
-MD -MF .d.pdfutils -MP -c pdfutils.c -o pdfutils.o

On my system the gcc version is as follows:
gcc -dumpversion
2.95.4

The working compile I did yesterday with the old plplot didn't have the
"-MD -MF .d.pdfutils -MP -c" part of the command so I assume it is
some aspect of that string of parameters that is causing the
problem for my gcc version 2.95.4.

As you alluded to in your message the configuration seems to be adding these
gcc-3.0 parameters to the gcc command line when my system only has 2.95.4.

Good luck in getting this problem straightened out.

Alan

[Plplot-devel] valgrind [purify killer]

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

Hi All,

I wanted to take a moment to call everyone's attention to an
incredibly amazing Linux utility I discovered yesterday, valgrind.

http://devel-home.kde.org/~sewardj/

This tool is simply amazing.  I discovered it yesterday, and was able
to use it to immediately find several bugs in my own code.  I've also
spent a little time using it on PLplot, and the short statement is
that it definitely has some things to say about PLplot.

I think that some of its output is spurious/erroneous.  It seems to
finger some code that I don't believe is actually wrong, and some of
these "bug" reports migrate around as I recompile PLplot with
different versons of GCC.  I don't know if this reflects a bug in
valgrind, or in GCC.  

But anyway, there are plenty of things it finds that I don't doubt to
be real.  I fixed one problem yesterday in cmap0 initialization, that
was rooted out using valgrind.

Today I ran all the C examples through valgrind.  Omitting the ones
that produced diagnostics I suspect to be spurious, the ones of
interest are x08c, x11c, and x20c.  The first two of these seem to
utilize unitialized memory thousands of times each.  The error count
on x20c is smaller, around 500 I think, but that's still pretty
serious. 

I tried to prosecute the bugs in plot3d.c (from x08c.c), but
eventually gave up.  The bugs in there are buried too deep for me to
spot easily.  Seems to have something to do with the u and v arrays in
plot3d.c not having been initialized all the way to the last
elements.  

Anyway, I just wanted to commend this tool to everyone.  If you're
working on compiled code, you've gotta try valgrind, whether its
PLplot related or not.  This tool is just amazing.

For those whoe know Rational's purify product, this is the GPL app
that's gonna crush purify, at least on the Linux platform.  Rational
doesn't currently ship purify on Linux, and at this point, I'm sure
they never will, 'cause there's no longer a need.  valgrind does what
purify does, only perhaps arguably even better.  You'll have to read
the valgrind docs to understand why I say that, but basically it takes
the notion of code instrumentation that purify applies to individual
objects, and in valgrind this notion is translated straight to the
cpu.  The "cpu" in valgrind is a sort of Intel Architecture simulator,
which does for /any/ x86 object code, the same kind of thing that
purify does on object code it gets to massage.  Stated another way,
it's a lot like Purify, only more general.  And it's GPL'd.  

Anyway, if you work with C or C++ code on Linux, you've gotta try
valgrind.  

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

[Plplot-devel] Should plgetpos be part of the common API or plP_gvpd and plP_gvpw?

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

Alexandre Gobbo and friends have suggested some python API as follows:

static char doc_getpos[]="transforms window coordinates into graphic coordinates";

static PyObject * pl_getpos(PyObject *self, PyObject *args)
{
	PLINT x,y;
	PLINT inside=1;
	PLFLT xmin,xmax,ymin,ymax;
	PLINT w,h;
	PLFLT posX, posY;
	PLStream *pls;

	PyObject *result;
	TRY (PyArg_ParseTuple(args, "iiii", &x,&y, &w,&h));
	plgpls(&pls);   // pls points directly to a structure PLStream

	xmin=pls->vpdxmi*(PLFLT)w;
	xmax=pls->vpdxma*(PLFLT)w;
	ymin=pls->vpdymi*(PLFLT)h;
	ymax=pls->vpdyma*(PLFLT)h;

	if      ((x < xmin)||(x > xmax)||(y < ymin)||(y > ymax)) inside=0;

	if      (x < xmin)	x=(PLINT)xmin;
	else if (x > xmax)	x=(PLINT)xmax;
	if      (y < ymin)	y=(PLINT)ymin;
	else if (y > ymax)	y=(PLINT)ymax;

	posX=  pls->vpwxmi + (((PLFLT)x-xmin)*(pls->vpwxma-pls->vpwxmi)/(xmax-xmin));
	posY=  pls->vpwyma - (((PLFLT)y-ymin)*(pls->vpwyma-pls->vpwymi)/(ymax-ymin));


	result = Py_BuildValue(PL_ARGS("(idd)", "(iff)"),inside, posX, posY);
	return result;
}

w, and h (width and height from the pyqt GUI environment) and x and y are
supplied, and the flag "inside" and  posX and posY are returned.

I want to discuss some alternatives to this approach here because I am
allergic to special PLplot API for each individual front end.

So here is one question I would like you to consider.  Would this general
functionality be useful for the common API for other GUI's?  If so, I would
strip all the python stuff out and make it generally available as common API
and then add a python wrapper to this new common API so Gobbo et al.
would have access to it from python.

If not generally useful, then I will suggest they do this logic in python
using the values of pls->vpdxmi, etc., and pls->vpwxmi, etc. returned from
the PLplot environment.

Before looking at how to retrieve the values, I have looked carefully at how
these values are set for the PLplot environment.  pls->vpdxmi, etc. are
generated in either c_plsvpa (called from c_plenv) and c_plvpor, and
pls->vpwxmi, etc. are generated by c_plwind (called on its own or from
c_plenv).

These values are retrieved from the PLplot environment using the plP_gvpd
and plP_gvpw functions.  Currently these functions are part of the public C
API, but are meant for internal PLplot use and are not currently part of the
common API.

So if some overall functionality like the C part of the code above does not
become part of the common API with a python wrapper, then instead I would
convert plP_gvpd and plP_gvpw to common API, and provide python wrappers.

Which choice is better?

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] automatic dependencies

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

Hello all,

Driven by desperation, I've begun to implement automatic dependency
generation for PLplot.  I've just committed some files, and I figure I
should give people a heads up.

I hope my changes today don't mess anyone up.  If anyone sees builds
failing as a result of these changes, please let me know ASAP so I can
work on repairing things.

The way it works is that I've redefined the implicit rules for
building .o's from .c's.  It used to just directly invoke the CC
macro, with flags.  Now it "calls" a macro named
compile-c-and-emit-deps.  This is only on Linux however.  All other
platforms, should, I believe, be completely unchanged by todays
commits. 

The purpose of this macro is to do just what it's name says.  It is to
compile a C file, and emit dependency info for it.  

Then comes the tricky part.  I've implemented an attempt to autodetect
gcc version 3.  That's because with GCC version 3, they introduced
some very  nice flags for dependency genration, which are very
convenient, way nicer than what you had to do before.  So, /if/ you
have gcc version 3, then we use the new flags, otherwise we just do
what we did before (which was just to compile the file, wtihout
actually emitting dependencies), in which case we also don't claim to
have automatic dependencies implemented yet.  I'll go back and fix the
gcc 2 vintage code to do dependencies later.  But for now, it is
supposed to just work.  Please let me know if you see otherwise.

That is to say, those of you using gcc 2.x.y, are supposed to see no
change, either good or bad, from today's commits. And anyone using gcc
3, on Linux, is supposed to be seeing new super cool, auto morphing
dependencies. 

There is one bizardom.  Somehow, when I I try to test this with "gcc
2.96", it seems to somehow think it has a gcc 3 even though it
doesn't, so it uses the new flags, but also, somehow mysteriously,
this "gcc 2.96" seems to implement the new flags in gcc 3.  I dunno,
its too strange, maybe I need a break to clear the cobwebs.

So, this is like a 50% confidence commit.  Works for me, hope it
doesn't screw anybody else up, let me know if it does.  I figure
that's okay in the post release era, and I'll try to manage quick
fixes for ahyone who complains.  Let me know.

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

Re: [Plplot-devel] [BUG] problem with dynamic drivers and multiple precision libs

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

Alan W. Irwin writes:
 > On Sun, 24 Feb 2002, Maurice LeBrun wrote:
 > > Yup, works great now, thanks!
 > 
 > Glad to hear that good report.
 > 
 > >
 > > Only problem I see is that the:
 > >      pstex.drv -> ps.drv
 > >
 > > link is only made for single precision.
 > 
 > Do you have a freshly checked out version with all of Joao's recent changes?
 > 
 > I cannot find such a ln command involving pstex in the cf/*.in files now,
 > and there is no reference to pstexd.drv within driversd.db (the pstex entry
 > points to psd.drv instead).  With the present arrangement (no symlink), the
 > pstex device seems to work without any obvious error on my system.

oops.. that was from an old install, sorry.  So no problems then.

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

Re: [Plplot-devel] [BUG] problem with dynamic drivers and multiple precision libs

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

On Sun, 24 Feb 2002, Maurice LeBrun wrote:
> Yup, works great now, thanks!

Glad to hear that good report.

>
> Only problem I see is that the:
>      pstex.drv -> ps.drv
>
> link is only made for single precision.

Do you have a freshly checked out version with all of Joao's recent changes?

I cannot find such a ln command involving pstex in the cf/*.in files now,
and there is no reference to pstexd.drv within driversd.db (the pstex entry
points to psd.drv instead).  With the present arrangement (no symlink), the
pstex device seems to work without any obvious error on my system.

Alan

Re: [Plplot-devel] [BUG] problem with dynamic drivers and multiple precision libs

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

Alan W. Irwin writes:
 > On Sat, 23 Feb 2002, Maurice LeBrun wrote:
 > 
 > > Alan W. Irwin writes:
 > >  > Maurice, although I don't have a deep understanding of the way dynamic
 > >  > drivers are done, I think I could probably handle most of this fix myself if
 > >  > you don't have time to deal with it at the moment.  Let me know what you
 > >  > decide.
 > >
 > > I would be thrilled if you could work on it. :)
 > 
 > OK, it is done and committed.  This solution is pretty quick and dirty since
 > I did most of it by analogy with other configuration code without looking
 > deeper. So someone else may find a more elegant way to do the same thing.
 > Also, my own testing has been extremely minimal.  I only made sure that I
 > could build with double and dyndrivers enabled, and I ran a few examples
 > with xwin, psc, and png devices.  Combinations of single and/or static
 > drivers should work, but I haven't tested them.
 > 
 > Maurice, please let me know if this solves the difficulties you were having.

Yup, works great now, thanks!

Only problem I see is that the:
     pstex.drv -> ps.drv

link is only made for single precision.

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

Re: [Plplot-devel] [BUG] problem with dynamic drivers and multiple precision libs

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

On Sat, 23 Feb 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > Maurice, although I don't have a deep understanding of the way dynamic
>  > drivers are done, I think I could probably handle most of this fix myself if
>  > you don't have time to deal with it at the moment.  Let me know what you
>  > decide.
>
> I would be thrilled if you could work on it. :)

OK, it is done and committed.  This solution is pretty quick and dirty since
I did most of it by analogy with other configuration code without looking
deeper. So someone else may find a more elegant way to do the same thing.
Also, my own testing has been extremely minimal.  I only made sure that I
could build with double and dyndrivers enabled, and I ran a few examples
with xwin, psc, and png devices.  Combinations of single and/or static
drivers should work, but I haven't tested them.

Maurice, please let me know if this solves the difficulties you were having.

Alan

>
> --
> Maurice LeBrun    mj...@ga...
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>