From: Geoffrey F. <fu...@ga...> - 2002-02-26 23:32:26
|
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... |
From: Alan W. I. <ir...@be...> - 2002-02-27 00:30:33
|
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 > |
From: Geoffrey F. <fu...@ga...> - 2002-02-27 00:59:40
|
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... |
From: Alan W. I. <ir...@be...> - 2002-02-27 02:53:53
|
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 |
From: Alan W. I. <ir...@be...> - 2002-02-27 04:08:12
|
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 __________________________ |
From: Joao C. <jc...@fe...> - 2002-02-27 05:23:53
|
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 |
From: Alan W. I. <ir...@be...> - 2002-02-27 17:03:48
|
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 > |
From: Joao C. <jc...@fe...> - 2002-02-27 18:18:38
|
On Wednesday 27 February 2002 5:03 pm, Alan W. Irwin wrote: > Using the return value in two different ways is a little awkward becaus= e 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 h= ow > about just changing the API? My suggestion was intended to avoid this API break. However, I don't thin= k=20 that it would confuse users. Many standard C library functions are expect= ed=20 to return e.g. a pointer on sucess or NULL to indicate failure. Currently, plGetCursor() comments say: Returns 0 if no translation to world coordinates is possible. I would propose that it says: Returns the subwindow number, starting at 1, or 0 if no translation to w= orld=20 coordinates is possible. With this approach I thing that most code would still work without=20 modifications; x01c will. If you think that this is not reasonable, them the PLGraphicsIn structure= =20 could contain one more field, the subwindow number; existing code will st= ill=20 work, but should be recompiled. > It is possible this might hurt some of our > users since it is public API, but I feel this is not too likely since i= t is > not part of the documented common API. > > If we agree that it is okay to change the API, I am thinking of returni= ng > 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 wh= ere > "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 th= e > 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 t= o > 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 i= t > 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=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 > __________________________ > > 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=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 > > > > _______________________________________________ > > 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 |
From: Alan W. I. <ir...@be...> - 2002-02-27 23:44:20
|
The new common API function c_plcalc_world (note the name change) can have any API it likes since this is a new function. So the goal there is to be the best possible API. Now my understanding is that common API functions are all void, i.e., the only way they return status information is via the argument list. For now I am going to return (via the argument list) a window value starting at zero with a window value of -1 indicating failure to find a valid window. I am no API expert so if that is the wrong way to go from the best possible API point of view let me know, and I will change it. But the API for this function is a completely separate issue from the plTranslateCursor API. For now, I will leave the plTranslateCursor API strictly as is, but I will change its internals to call c_plcalc_world. Once consensus has been reached on changing the plTranslateCursor API, then all data returned from c_plcalc_world will be available to plTranslateCursor to facilitate that changed API. 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 5:03 pm, Alan W. Irwin wrote: > > 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? > > My suggestion was intended to avoid this API break. However, I don't think > that it would confuse users. Many standard C library functions are expected > to return e.g. a pointer on sucess or NULL to indicate failure. > > Currently, plGetCursor() comments say: > Returns 0 if no translation to world coordinates is possible. > > I would propose that it says: > Returns the subwindow number, starting at 1, or 0 if no translation to world > coordinates is possible. > > With this approach I thing that most code would still work without > modifications; x01c will. > > If you think that this is not reasonable, them the PLGraphicsIn structure > could contain one more field, the subwindow number; existing code will still > work, but should be recompiled. > > > 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 > > > > _______________________________________________ > > 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 > |
From: Alan W. I. <ir...@be...> - 2002-02-27 21:46:42
|
OK, I have just created c_plcalc_world, changed plTranslateCursor to call this function, tested the result using ./x01c -locate -dev xwin, and committed it. If you have any API concerns for c_plcalc_world now is the time to express them because I am going to docbook/document it shortly. As expected (since the code is meant to do the same thing) I found identical behaviour for both the old and new plplot library. However, that behaviour wasn't very good. ./x01c -locate -dev xwin works fine so long as your cursor is inside a viewport. However, outside a viewport the cursor just freezes. This bug makes some sense since there is no world coordinate information outside viewports. But I expect the xwin driver is simply ignoring the current 0 return code when no valid world coordinates can be found, and therefore getting into trouble. Can somebody find a quick fix to this driver behaviour? (I just verified this cursor freeze also shows up for tk and ntk.) Instead of the cursor freeze, you should get a message back that there are no world coordinates at the current position, and you should be able to move the cursor to new valid viewport locations. On second thought, is this a x01c.c problem? Geoffrey, could you please verify that c_plcalc_world and its parent plTranslateCursor always return valid world coordinates so long as the cursor is inside *some* viewport within some subpage? If it passes this test, I think I am done since nobody has spoken up about how we could identify the various viewports within a particular subpage. 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, Alan W. Irwin wrote: > The new common API function c_plcalc_world (note the name change) can have > any API it likes since this is a new function. So the goal there is to be > the best possible API. Now my understanding is that common API functions > are all void, i.e., the only way they return status information is via the > argument list. For now I am going to return (via the argument list) a > window value starting at zero with a window value of -1 indicating failure > to find a valid window. I am no API expert so if that is the wrong way to > go from the best possible API point of view let me know, and I will change > it. But the API for this function is a completely separate issue from > the plTranslateCursor API. > > For now, I will leave the plTranslateCursor API strictly as is, but I > will change its internals to call c_plcalc_world. Once consensus has > been reached on changing the plTranslateCursor API, then all data > returned from c_plcalc_world will be available to plTranslateCursor > to facilitate that changed API. > > 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 > __________________________ |
From: Geoffrey F. <fu...@ga...> - 2002-02-27 18:25:50
|
Alan W. Irwin writes: > 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. wheeee! Well, I love to see prompt action, but I do have one concern about what is being discussed in this thread. I remember when Maurice and I first talked about this thing, years ago, but the language that is being used in this thread does not match up with what I remember we had talked about. So either my memory is wrong, or maybe somehow we never implemented what I wanted, or something. I dunno, it's been too long. Anyway, my concern is that the "window", as in the "sub page window", may not be the right--or maybe just not sufficient--info to return. I think we also need to return something about the viewport definition. Many "windows" have more than one active viewport. I /often/ make my plots have two viewports, the "main" one where the plot goes, and an additional one where the legend goes. For example, on shade plots, I may draw one big squarish region with the shaded data, and then a little thin/tall bar on the left which shows the color map used in the shade, with the y axis on this color bar being the function value range in the main plot. Now, if the user uses the locator and selects a coordinate, they might be asking the interactive tool to tell them the world coordinates at some point in the main picture area, but they might also be trying to determine the value of some particular part of the legend box. So, it seems to me that to really do this right, you need to convert the screen (pixel) coords to world coordinates, and return both the window (sub page) and the viewport for which the match was found. I think, reaching way back into the cobwebs, that the fly in the ointment here is that we don't number the viewports. |
From: Alan W. I. <ir...@be...> - 2002-02-27 21:45:59
|
Some of the confusion here is that the documentation talks about sub-pages, sub-windows (which I think are the same thing) and lots of different kinds of coordinates (some of which are the same). And now Geoffrey has brought multiple viewports to our attention. (Thanks, I think....;-)) From the documentation: Viewports are created within the current subpage. If the division of the output device into equally sized subpages is inappropriate, it is best to specify only a single subpage which occupies the entire output device (by setting nx = 1 and ny = 1 in plstart or plstar), and use one of the viewport specification subroutines below to place the plot in the desired position on the page. So my mental model of what is usually done is the arrangement of sub-pages is set up by plssub (or equivalent plstart, etc.), and the actual sub-page you are currently plotting to is specified by pladv. Only after that sub-page is specified would you set up possibly multiple (as Geoffrey has indicated) viewports. For now, I am going to go ahead with c_plcalc_world as is which will produce the same functionality as before. (I am assuming here that the sub-pages discussed above are identical with the "windows" specified in the code.) But from Geoffrey's argument below that functionality is broken for multiple viewports on the same sub-page (or page if there is only one of them). The reason I say this is that different viewports will have different world coordinates, and there doesn't seem to be any provision for that case in the current code. Geoffrey, could you please test the current functionality of plGetCursor (as in example 1, but with your multiple viewports per page) to see what world coordinates (if any) it returns for your multiple viewports? Ultimately, I think we will have to change c_plcalc_world to deal with world coordinates of multiple viewports, but I want to concentrate for now on getting the current functionality replicated in the common API. 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, Geoffrey Furnish wrote: > Alan W. Irwin writes: > > 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. > > wheeee! Well, I love to see prompt action, but I do have one concern > about what is being discussed in this thread. > > I remember when Maurice and I first talked about this thing, years > ago, but the language that is being used in this thread does not match > up with what I remember we had talked about. So either my memory is > wrong, or maybe somehow we never implemented what I wanted, or > something. I dunno, it's been too long. > > Anyway, my concern is that the "window", as in the "sub page window", > may not be the right--or maybe just not sufficient--info to return. I > think we also need to return something about the viewport definition. > Many "windows" have more than one active viewport. I /often/ make my > plots have two viewports, the "main" one where the plot goes, and an > additional one where the legend goes. For example, on shade plots, I > may draw one big squarish region with the shaded data, and then a > little thin/tall bar on the left which shows the color map used in the > shade, with the y axis on this color bar being the function value > range in the main plot. > > Now, if the user uses the locator and selects a coordinate, they might > be asking the interactive tool to tell them the world coordinates at > some point in the main picture area, but they might also be trying to > determine the value of some particular part of the legend box. So, it > seems to me that to really do this right, you need to convert the > screen (pixel) coords to world coordinates, and return both the window > (sub page) and the viewport for which the match was found. > > I think, reaching way back into the cobwebs, that the fly in the > ointment here is that we don't number the viewports. > |
From: Joao C. <jc...@fe...> - 2002-02-28 00:04:14
|
On Wednesday 27 February 2002 6:25 pm, Geoffrey Furnish wrote: > Alan W. Irwin writes: > > Using the return value in two different ways is a little awkward bec= ause > > I believe the first sub-page is numbered zero rather than one. We c= ould > > return i+1 but that could lead to all sorts of misunderstandings. S= o > > how about just changing the API? It is possible this might hurt som= e 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 succe= ss > > or failure as before. But I am no API expert so any other suggestio= ns > > 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 nu= mber > > 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 fro= m a > > PLGraphicsIn struct to the simple input variables of c_plgwc on inpu= t > > and the reverse on the returned variables. > > > > I intend to implement these ideas right away, and after checking tha= t it > > works I will commit it subject to change if anybody has some API ide= as > > in the meanwhile. > > wheeee! Well, I love to see prompt action, but I do have one concern > about what is being discussed in this thread. > > I remember when Maurice and I first talked about this thing, years > ago, but the language that is being used in this thread does not match > up with what I remember we had talked about. So either my memory is > wrong, or maybe somehow we never implemented what I wanted, or > something. I dunno, it's been too long. > > Anyway, my concern is that the "window", as in the "sub page window", > may not be the right--or maybe just not sufficient--info to return. I > think we also need to return something about the viewport definition. > Many "windows" have more than one active viewport. I /often/ make my > plots have two viewports, the "main" one where the plot goes, and an > additional one where the legend goes. For example, on shade plots, I > may draw one big squarish region with the shaded data, and then a > little thin/tall bar on the left which shows the color map used in the > shade, with the y axis on this color bar being the function value > range in the main plot. > > Now, if the user uses the locator and selects a coordinate, they might > be asking the interactive tool to tell them the world coordinates at > some point in the main picture area, but they might also be trying to > determine the value of some particular part of the legend box. I don't think this to be very likely... but one can never guess what user= s=20 will do (need). That's why I think that returning the subwindow will be=20 enough for most applications; users with special needs will learn that=20 clicking in the legend is a "feature" not yet supported, and will avoid u= sing=20 it. This is perhaps too pragmatic, but as you say bellow, we don't store=20 viewport info. In my personal case, I plot the legend bar for shade and contour plots in= side=20 the main plot, which make things worse than for you (but I have an iterat= ive=20 legend placement utility, to manually move the legend position away of=20 interesting regions). But this issue raises some future (possible) development compatibility=20 problems, and as such I think that is better to just add a field to the=20 PLGraphicsIn structure to indicate the subwindow number (instead of using= the=20 function return value for this--see my other post); latter, another field= =20 could be added to also indicate the viewport. Joao > So, it > seems to me that to really do this right, you need to convert the > screen (pixel) coords to world coordinates, and return both the window > (sub page) and the viewport for which the match was found. > > I think, reaching way back into the cobwebs, that the fly in the > ointment here is that we don't number the viewports. > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Maurice L. <mj...@ga...> - 2002-02-28 00:35:23
|
I don't really think the return code should be overloaded with window number. To me it's better/clearer to put it in a separate PLGraphicsIn struct entry. As for Geoff's comment, plots that go beyond the simple single-plot / subwindow model are indeed a problem. Although right now we do not number the windows created, we do "register" them with the plP_swin call at the end of plwind(). I added this ages ago with the hopes of supporting per-window operations from plrender for apps that handle their own windowing. Anyway, we could add the window defn at that point to a per-page list of windows, which is searched through for input events. Then return a window index in the PLGraphicsIn struct. Would need an API call to return the current window list too. Maybe best to just punt on it for now, but keep it in mind for a future project. Return a window number parameter in the PLGraphicsIn that for now is just a subpage number, but in the future may be a more generalized window number (making sure the two are compatible). Geoffrey Furnish writes: > Alan W. Irwin writes: > > 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. > > wheeee! Well, I love to see prompt action, but I do have one concern > about what is being discussed in this thread. > > I remember when Maurice and I first talked about this thing, years > ago, but the language that is being used in this thread does not match > up with what I remember we had talked about. So either my memory is > wrong, or maybe somehow we never implemented what I wanted, or > something. I dunno, it's been too long. > > Anyway, my concern is that the "window", as in the "sub page window", > may not be the right--or maybe just not sufficient--info to return. I > think we also need to return something about the viewport definition. > Many "windows" have more than one active viewport. I /often/ make my > plots have two viewports, the "main" one where the plot goes, and an > additional one where the legend goes. For example, on shade plots, I > may draw one big squarish region with the shaded data, and then a > little thin/tall bar on the left which shows the color map used in the > shade, with the y axis on this color bar being the function value > range in the main plot. > > Now, if the user uses the locator and selects a coordinate, they might > be asking the interactive tool to tell them the world coordinates at > some point in the main picture area, but they might also be trying to > determine the value of some particular part of the legend box. So, it > seems to me that to really do this right, you need to convert the > screen (pixel) coords to world coordinates, and return both the window > (sub page) and the viewport for which the match was found. > > I think, reaching way back into the cobwebs, that the fly in the > ointment here is that we don't number the viewports. > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Maurice LeBrun mj...@ga... |
From: Alan W. I. <ir...@be...> - 2002-02-28 03:58:07
|
On Wed, 27 Feb 2002, Maurice LeBrun wrote: > I don't really think the return code should be overloaded with window number. > To me it's better/clearer to put it in a separate PLGraphicsIn struct entry. That's okay if you are talking about plTranslateCursor, but I hope you ignore that completely for now since it is a separate issue. c_plcalc_world does not use PLGraphicsIn data since it is common API where the various front ends typically demand simple variable or array argument lists. Its purpose is to convert relative device coordinates to world coordinates with no assumptions about what the front ends will use that data for. Is there any reason in the c_plcalc_world case not to return -1 for the subpage number when there is no valid subpage? BTW, I have just rebuilt the documentation so you can see the description of the c_plcalc_world API at http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3/plcalc_world.html. > > As for Geoff's comment, plots that go beyond the simple single-plot / > subwindow model are indeed a problem. Although right now we do not number the > windows created, we do "register" them with the plP_swin call at the end of > plwind(). I added this ages ago with the hopes of supporting per-window > operations from plrender for apps that handle their own windowing. Anyway, > we could add the window defn at that point to a per-page list of windows, > which is searched through for input events. Then return a window index in the > PLGraphicsIn struct. Would need an API call to return the current window > list too. I understand the first part, but I don't see the problem since each subpage (or window or subwindow, grrr) is registered as you say. But I am not sure what you mean by "per-page list of windows". Is that a list of sub-pages for the current page? If so, isn't that exactly what your registering already does so that to get data for each subpage you simply walk through the list? For example, c_plcalc_windows does this by the following fragment of code: for (i = lastwin; i >= firstwin; i--) { w = &plsc->plwin[i % PL_MAXWINDOWS]; One concern I still have with c_plcalc_world is whether it gives good results for multiple viewports per (sub-)page. Geoffrey, I hope you will test that directly since you brought up this case originally (;-)) and you apparently had several examples of this you were concerned about. Also, to move to a related topic, can anybody explain the cursor freeze I encountered when outside a viewport? I assume it is an x01c.c problem or else a problem in the xwin, tk, and ntk drivers. This thread has been confused today because the e-mail delivery for plplot_devel has been extraordinarily erratic (one of my key messages about the cursor freeze, etc. got held up for many hours while later messages sailed through). Thus, I am going to send extra copies of this directly to the principal contributors (Maurice, Geoffrey, and Joao) to make sure they get it in a timely manner. Alan |
From: Maurice L. <mj...@ga...> - 2002-02-28 05:40:26
|
Alan W. Irwin writes: > On Wed, 27 Feb 2002, Maurice LeBrun wrote: > > > I don't really think the return code should be overloaded with window number. > > To me it's better/clearer to put it in a separate PLGraphicsIn struct entry. > > That's okay if you are talking about plTranslateCursor, but I hope you > ignore that completely for now since it is a separate issue. c_plcalc_world Right, I was talking about plTranslateCursor. My message was more relevant when I wrote it, quite a few hours before it actually appeared. > does not use PLGraphicsIn data since it is common API where the various > front ends typically demand simple variable or array argument lists. Its > purpose is to convert relative device coordinates to world coordinates with > no assumptions about what the front ends will use that data for. Is there > any reason in the c_plcalc_world case not to return -1 for the subpage > number when there is no valid subpage? Sounds fine. > I understand the first part, but I don't see the problem since each subpage > (or window or subwindow, grrr) is registered as you say. But I am not sure > what you mean by "per-page list of windows". Is that a list of sub-pages > for the current page? If so, isn't that exactly what your registering > already does so that to get data for each subpage you simply walk through > the list? For example, c_plcalc_windows does this by the following > fragment of code: > > for (i = lastwin; i >= firstwin; i--) { > w = &plsc->plwin[i % PL_MAXWINDOWS]; Whoops, I forgot that was in there.. cool. OK, so forget about that part of my message as it's already done. Then if you are returning the window number as found above, I'm happy. > One concern I still have with c_plcalc_world is whether it gives good > results for multiple viewports per (sub-)page. Geoffrey, I hope you will > test that directly since you brought up this case originally (;-)) and you > apparently had several examples of this you were concerned about. It should. The plsc->plwin struct only cares about windows "registered" through the plwind call, so it's nicely general. Doesn't care if it's in a subwindow or not. > Also, to move to a related topic, can anybody explain the cursor freeze > I encountered when outside a viewport? I assume it is an x01c.c problem or > else a problem in the xwin, tk, and ntk drivers. Hmm.. never noticed it before. Crappy error handling probably. :) If you invoke locate with the "L" key binding there's no problem. I'll look into it when I get a chance. > This thread has been confused today because the e-mail delivery for > plplot_devel has been extraordinarily erratic (one of my key messages about > the cursor freeze, etc. got held up for many hours while later messages > sailed through). Thus, I am going to send extra copies of this directly to > the principal contributors (Maurice, Geoffrey, and Joao) to make sure > they get it in a timely manner. > > Alan -- Maurice LeBrun mj...@ga... |
From: Maurice L. <mj...@ga...> - 2002-02-28 06:28:51
|
I looked at the dox & code, and all looks cool. My only nit is that the references to "subpage" should be replaced by "window". I like the more general term better since the code should work fine even if not using the usual PLplot subpage model. In fact I originally wrote the window registration code with a completely different windowing front-end in mind. -- Maurice LeBrun mj...@ga... |
From: Alan W. I. <ir...@be...> - 2002-02-28 19:31:54
|
Thanks, Maurice, for your comment below which inspired me to look further at the code and documentation. As my previous posts have shown, I was confused about the differences between (sub-)pages, viewports, and windows. But now I have looked again at the advanced section of the documentation, and it is all clearly layed out there. Each (sub-)page can have more than one (possibly overlapping) viewport, and each viewport can have various windows superimposed by repeated calls to plwind (with data registered for each plwind call with plP_swin). The windows for a given viewport only differ in the world coordinates of their minimum and maximum x and y values so multiple windows allow you the option of making single viewport plots with multiple sets of world coordinates. If you do have multiple sets of world coordinates for a single viewport, the data for each plwind call are registered with plP_swin with an ascending windows index. Note that in normal use there is only one window per viewport and the viewports don't physically overlap. But in the most general case we have overlapping viewports with multiple windows each. Note in c_plcalc_world I continue to use Paul Casteel's trick of searching backwards through the windows indices. Thus, the code finds the last possibly overlapping defined viewport and last window defined for that viewport that contains the relative device coordinates. This completely answers my concern (Maurice answered it as well) over what happens with multiple viewports per sub-page. However, the windows (incorrectly named subpage) index currently returned is something with a very special internal meaning. Now that I understand this index, I don't see much public use for it. Does Joao need this index just for extra information for human consumption? It won't make much sense unless you repeat all the ifs, ands, and buts from above in the documentation. Alternatively, if it is meant to be used to index some information from plplot, I am not aware of any public (much less common) API that uses this index. I am now leaning toward changing c_plcalc_world to just return a status in the argument list and drop the idea of returning the windows index altogether. That's what I will probably do unless I hear some good arguments to keep it (especially from Joao since he probably had some specific use in mind when he originally brought up the possibility of returning this index). 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 Thu, 28 Feb 2002, Maurice LeBrun wrote: > I looked at the dox & code, and all looks cool. > > My only nit is that the references to "subpage" should be replaced by > "window". I like the more general term better since the code should work fine > even if not using the usual PLplot subpage model. In fact I originally wrote > the window registration code with a completely different windowing front-end > in mind. > > -- > Maurice LeBrun mj...@ga... > > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Maurice L. <mj...@ga...> - 2002-02-28 19:51:03
|
Alan W. Irwin writes: > I am now leaning toward changing c_plcalc_world to just return a status in > the argument list and drop the idea of returning the windows index > altogether. That's what I will probably do unless I hear some good arguments > to keep it (especially from Joao since he probably had some specific use in > mind when he originally brought up the possibility of returning this index). Even with all the caveats, I think the window index can still be useful. The simplest case being that the user keeps track of the window number / page and already knows what to do with it. In a general implementation you could keep a window counter that gets reset every new-page, perhaps with a function pointer for each value of the window counter to go do stuff upon an event in that window. At its simplest, a fixed association could be used, e.g. each page represents a point in time with multiple plots/page of various physical quantities, always in a fixed location. So then an event in window #2 means the user is messing with the temperature plot, in window #3 the electric field intensity, and so on. -- Maurice LeBrun mj...@ga... |
From: Joao C. <jc...@fe...> - 2002-02-28 20:01:14
|
On Thursday 28 February 2002 7:31 pm, Alan W. Irwin wrote: =2E.. > I am now leaning toward changing c_plcalc_world to just return a status= in > the argument list and drop the idea of returning the windows index > altogether. That's what I will probably do unless I hear some good > arguments to keep it (especially from Joao since he probably had some > specific use in mind when he originally brought up the possibility of > returning this index). Good arguments? No. Only that most of my plots and most published plot ha= ve a=20 simple "layout", and given that simplicity returning the subplot number c= an=20 be helpfull to identify the plot that the user is interested in. Suppose that in x01c you want to give the user the choice of selecting on= e of=20 the subplots, clicking on it, and then plotting only it. I can think in l= ots=20 of other applications where it is desirable to identify a subplot by clic= king=20 on it (printing or saving only one subplot, have a plot browser that plot= s=20 tiny plots of your plmeta-saved plot, ...). Joao PS-subpages, viewports, and windows, and now subplots! > > 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 > __________________________ > > On Thu, 28 Feb 2002, Maurice LeBrun wrote: > > I looked at the dox & code, and all looks cool. > > > > My only nit is that the references to "subpage" should be replaced by > > "window". I like the more general term better since the code should = work > > fine even if not using the usual PLplot subpage model. In fact I > > originally wrote the window registration code with a completely diffe= rent > > windowing front-end in mind. > > > > -- > > Maurice LeBrun mj...@ga... > > > > _______________________________________________ > > Plplot-devel mailing list > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2002-02-28 20:41:50
|
On Thu, 28 Feb 2002, Joao Cardoso wrote: > PS-subpages, viewports, and windows, and now subplots! My paranoid view is all these hierarchies are a plot (heh) against the poor documenter....;-) To be serious, taking consideration of the further input from you and Maurice, I will leave c_plcalc_world as is except for a change of the index name from subpage to window and with some additional documentation of what exactly that index is. Thanks very much to all of you for your most helpful input. I will leave it to somebody else to include a place for this index in the PLGraphicsIn struct, and modify plTranslateCursor to load the index into the revised PLGraphicsIn *plg. Also, I will leave it to somebody else (smile) to fix the cursor freeze bug I found. Alan |
From: Joao C. <jc...@fe...> - 2002-02-28 13:33:59
|
On Thursday 28 February 2002 5:39 am, Maurice LeBrun wrote: > Alan W. Irwin writes: > > On Wed, 27 Feb 2002, Maurice LeBrun wrote: =2E.. > > Also, to move to a related topic, can anybody explain the cursor fre= eze > > I encountered when outside a viewport? I assume it is an x01c.c pro= blem > > or else a problem in the xwin, tk, and ntk drivers. > > Hmm.. never noticed it before. Crappy error handling probably. :) > If you invoke locate with the "L" key binding there's no problem. > I'll look into it when I get a chance. In xwin.c:GetCursorCmd() I added DestroyXhairs() at the function end,=20 otherwise the xhairs would stay "alive" to the next plot. This can't be s= ee=20 in x01c, as it only has one plot, but is obvious in x20c. It looks like i= t=20 has negative side effects... any clue? Joao |
From: Maurice L. <mj...@ga...> - 2002-02-27 23:51:51
|
Alan W. Irwin writes: > 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. I could've sworn I went through and documented these some time ago in response to a similar request. Can't find any trace of it now though, sigh. Since I get confused too I had to go through the code to refresh my memory, and this is what I came up with: physical coordinates and device coordinates are the same thing. The "pixel" addresses in device space, typically 0 up to some large value in each coordinate. absolute coordinates are page coordinates in mm. Only strictly accurate for fixed-page-size output devices. relative device coordinates and normalized device coordinates are the same same thing -- position in a [0.,1.] by [0.,1.] representation of the page. -- Maurice LeBrun mj...@ga... |
From: Alan W. I. <ir...@be...> - 2002-02-27 22:54:53
|
Thanks, Maurice, for that information. It is a big help! Where multiple terms are used in the documentation for the same thing, I will try and replace all variations by one term. However, it will be a long process.... 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 __________________________ |
From: Geoffrey F. <fu...@ga...> - 2002-02-27 16:14:37
|
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. |