Re: [Plplot-devel] Bug in notcrossed() function of plfill.c
On Monday, June 15, 2015 at 11:18:33 (-0700) Alan W. Irwin writes: Hi Phil: git blame is your friend for figuring out who authored what, and it turns out I am virtually (except for a change by Hez) the sole author of notcrossed, but IIRC, that built on top of what Arjen had done before with (embedded logic rather than a function) which built on top of what Maurice had done before ..and I can't take credit for that either, as the core contourer had already been written when I got hold of it. IIRC I fixed a bug or two and added the function evaluator interface so I could use it from Fortran and later our C++ matrix class. This is what I started with, summer of 1990: http://amiga-fish.erkan.se/amiga-fish-disk-340-content-Plplot/ -- Maurice LeBrun -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plot metafile questions
On Thursday, March 5, 2015 at 14:44:20 (-0500) Jim Dishaw writes: On Mar 5, 2015, at 5:45 AM, Phil Rosenberg p.d.rosenb...@gmail.com wrote: I sort of agree. Sounds like a maintenance nightmare, plus, again, I thought that was the buffer's role - sit after major processing (e.g. After contour generation) but before device dependence, collecting commands which can be transferred to any device for repotting? The buffer essentially sits right before the call to the driver. The information stored in the buffer are in the device specific coordinate system. The original purpose of the buffer was to redraw the window on a resize event. The plot buffer can be brought up the hierarchy, but the tradeoff is reduced performance on window redraws. Plus, as Maurice points out, the current code architecture is not designed for a mid-level interface. Consider the case of a dashed grid. The dash is specified as lengths in mm, thus there will be a different of number of dashes for different physical sizes. For example, in x01c I count ~2 horizontal dashes between vertical ticks on the psc device, ~3 on the xwin device, ~2 on qtwidget, and ~2 on cairo. When resizing the GUI windows, the number of dashes remains unchanged, which violates the specified dash lengths. While working on the code, my thinking has iterated over different solutions as gained a better understanding of what is happening in the guts. There are two basic directions that we can go with plbuf/plmeta. 1) Keep the current structure and live with the differences in rendering Pro: Less change to the code, better performance on redraws Con: Resized windows or rerendered plots might not be correct in appearance. 2) Move plbuf up in the architecture and make plmeta a very smart driver. Pro: Plots would be rendered correctly (e.g. dash length) on redraws or when output on different devices from a metafile. Con: Redraw performance will be a bit less (probably not noticeable on most machines), more change to the code What I mean by a very smart driver is that it would be able to do all graphic operations natively (e.g. dashed lines, pattern fills). I think the second option is the right way to go and it is closest to what was originally discussed when this effort started. [snip] I really wish I had time to be more involved, since these are issues I've dealt / struggled with myself back in ancient history. No time to follow code changes or even to build/test. :( That said, about 10yrs ago I had the following on my wish-list: 1. Enhancements to driver intelligence plot-buffer a) Expanding device space to 32b assuming brain-dead dashed line algo was fixed b) Embellishing driver smarts to such things as strings, maybe other object types. Ended up getting stuck on both accounts, sadly. 2. Design implement a mid-level device-independent interface which would be the basis for the new metafile driver renderer. The problems with the current metafile architecture (aside from bit-rot) have been known for a very long time. It was made good enough for our needs given the time constraints. I settled for a common default resolution size for the devices I could, such as plm, xwin, etc, which mitigated the problem. The comments (this is from an old checkout) in plplotP.h about the latter are actually kind of funny to read today. Starting with: /* These define the virtual coordinate system used by the metafile driver. * Others are free to use it, or some variation, or define their own. */ ... Never even came close to starting this one. But conceivable, given the fairly small number of plplot core operations e.g. draw a line. :) 3. There was no #3 but it occurs to me a mid-level interface might be fast enough to handle redraws and have significant advantages in flexibility and whatnot. No way to find out except a real world test. At a previous employer we ended up driving everything from the client side which meant redraws used the public API all the way down to device level (xwin/plframe). Basically we had no plot buffer. We let expose events do their thing but everything else we handled ourselves. Being in the client we could throw away a lot of data to begin with instead of pumping it all through poor little plframe. :) So that included anything offscreen (when zoomed) and anything too small in resolution to see (with some caveats). I think my last project involved implementing overlaid rulers. They weren't saved as part of the plot buffer but done as the last stage so that moving them around on the screen was fast (refresh == expose + line draws over top). Of course, all proprietary. :( -- Maurice LeBrun -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot
Re: [Plplot-devel] plot metafile questions
On Saturday, March 7, 2015 at 00:14:27 (-0600) Maurice LeBrun writes: I think my last project involved implementing overlaid rulers. They weren't saved as part of the plot buffer but done as the last stage so that moving ^^^ Argghh.. I meant the xwin pixmap used to handle expose events. them around on the screen was fast (refresh == expose + line draws over top). Of course, all proprietary. :( -- Maurice LeBrun -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plot metafile questions
On Wednesday, March 4, 2015 at 12:56:22 (-0500) Jim Dishaw writes: On Mar 4, 2015, at 6:04 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: If you think that escape code trick should work as a way to transport raw user input directly to plmeta to be stored in the plmeta file, can you also use a similar trick to transport and store the relevant raw user input data for the non-solid line case? That is much trickier with the current architecture. The plmeta driver is at the same level as all the other drivers, which is after all the coordinate transformations. To do what you describe will take more work (more than I am comfortable doing this close to release). There are different approaches to implementing what you describe. One thought that I had was to restructure the interface to the drivers by expanding and unifying a driver capabilities structure. We sort have that now with a dev_unicode, dev_text, dev_hrshsym, hardware fills, etc. Basically, my thought is that a driver would be able to declare that it has a native capability to all the primitives (pattern fills, dashed lines, etc) and coordinate transformations. Then all PLplot would do for that driver is layout the plot. For less capable drivers, PLplot with render the missing features. I have not figured out how to handle clipping and difilt in this architecture. Jim is right, the idea of implementing a mid-level interface that would be at just the right place of device-independence always horrified me sufficiently to stay well away from it. But it sounds like a agreat idea. :) -- Maurice LeBrun -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Fwd: metafiles
In my experience, you will definitely need file versioning. Won't be used that often but essential for backward compatibility. The original plmeta/plrender also had a nifty way to seek to a given page in the file, seek forward/backward N pages, etc. Unfortunately it meant backing up and filling in a next page offset as you were writing the metafile.. was a pain to debug but cool once it was working right. From plmeta.c: // plD_bop_plm() // // Set up for the next page. // // Page header layout as follows: // // BOP (U_CHAR) // page number (U_SHORT) // prev page offset (U_LONG) // next page offset (U_LONG) // // Each call after the first is responsible for updating the table of // contents and the next page offset from the previous page. Also you might look at options supported by plrender.c for ideas. Was handy to be able to change colors etc. Poor man's graphical editor. Just food for thought.. -- Maurice LeBrun -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Fwd: metafiles
Both the endianness and IEEE float issues are dealt with in a portable way by the functions in src/pdfutils.c. Neither integers or floating point are dependent on the native architecture, making the metafiles 100% portable. 1. Endianness is little, by fiat, implemented by shifts masks. 2. Floating point is IEEE, by fiat, implemented as per the spec. At the time some architectures didn't use IEEE floats (e.g. Cray) and there wasn't much need for f.p. output for a device driver, so speed wasn't an issue. Design issues include: - As mentioned, it fell out of active use so as device driver capability grew, plmeta became unable to fully reproduce the observed output. - The physical device coordinate space was a limiting factor, say for later zooms. - Ditto for the physical device API. A metafile/renderer built at a higher level would've had more versatility. -- Maurice LeBrun -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] An issue with the ps device driver that is extraordinarily sensitive to rounding
Hi Alan, Thanks for your analysis, it was very interesting. Perhaps if I were to take an extended look at that 20-yr-old fix I might be able to dredge up some insights. OTOH, the ps driver was not my creation and I never felt truly comfortable modifying it. I basically just hacked it as needed to get the desired printable output. In other words, you're on your own, good luck. :) Maurice On Thursday, October 23, 2014 at 22:44:52 (-0700) Alan W. Irwin writes: To Maurice and Andrew: I think you will be interested both in the history of this issue and also how I resolved it. If either of you think I screwed up this fix of Maurice's (1994) fix, please let me know! Basically Maurice's fix emitted M commands for _every_ state change other than PLSTATE_WIDTH. The complete list of those state changes (as far as I know) other than PLSTATE_WIDTH is PLSTATE_FILL, PLSTATE_COLOR[01], and PLSTATE_CMAP[01] and evidentally one or more of those which are normally no-ops for the ps device (i.e., PLSTATE_FILL and PLSTATE_CMAP[01]) have been triggered by rounding differences with the result that isolated M commands are being emitted for one type of rounding compared to another. My fix essentially returned the M command emitting code back to what it was like prior to Maurice's fix but with the undefined variable issue fixed; the M commands are now only issued after a C command, i.e., only for case PLSTATE_COLOR[01] and only if the relevant variables for the M command are defined. Andrew's psttf device driver code is partially based on the ps device driver code and evidentially Maurice's fix propagated to the psttf device driver so I had to fix that as well. I still have no idea why the C command must be followed by an M command for PostScrit. That decision was made before 1994. Hopefully, Maurice or Andrew will be able to comment on the reason for this. For further details about the current fix and Maurice's fix see http://sourceforge.net/p/plplot/plplot/ci/3028bea51568a023dcf3612a664a8a4345e91b14 and http://sourceforge.net/p/plplot/plplot/ci/07eab71b70249ac03a0f89db4061583d968f7365. Note the current fix likely does not get rid of all causes of extreme sensitivity of the psc device results to rounding issues, but I do recall a number of such issues in the past that also involved extra M PostScript commands being emitted by one language compared to another. Therefore, I believe this current fix will at least get rid of a substantial subset of such issues, and it certainly gets rid of that issue for the Python/C special test comparison of the new example 8 results. Tomorrow after removing some special testing hacks and throughly testing the final new Python example 8 against the repository version of the C code, you should see a commit from me of that new Python code, and I hope my further planned changes to example 8 for Octave and Java are a lot less interesting than they have been for the Python case! Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] test post
Test to see if I got dropped from the list. -- Maurice LeBrun -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Examples not generated during build
I saw something very similar strange happen with a software product in the not too recent past. We were seeing syntax errors from the command interpreter, from a line that looked completely fine. On a hunch, I had the person delete what appeared to be a dash, then insert a '-' from his US keyboard. It worked! Some sort of translation issue, coupled with the origination point for the script being from a Japanese locale system. Maurice On Thursday, April 3, 2014 at 05:51:41 (+) Arjen Markus writes: HI Thorsten, I am glad you have found the reason - this is on the border of bizarre and it is not something I would have been able to guess. Anyway, it shows you are never too old to be surprised by a computer system. Regards, Arjen -Original Message- From: Thorsten Behrens [mailto:thorsten.behr...@dorunth.de] Sent: Wednesday, April 02, 2014 9:01 PM To: PLplot development discussion Subject: Re: [Plplot-devel] Examples not generated during build Hi Arjen! I can not find anything suspicious - there is a variable DEVPAK that may interfere with BUILD_TEST, but that variable is not set, so it doesn't influence this. There is no indication in the cmake.out file either as to what is going on. One desperate suggestion/question: What happens if you start it in a completely clean directory? Just create a brandnew one and run CMake. This should get rid of any cached information. In the meantime I was able to solve this very strange problem! Thanks for your suggestions that brought me on the correct path and finally made me find the solution! When using the command line build I was a bit lazy. I already had PLplot installed some years ago (V5.8, IIRC). During that time I created a MS Word document containing a complete How to install PLplot manual (for my colleagues should they also want to install it). Well, now, when again installing PLplot (completely from scratch, i.e. no installed older version of PLplot on this computer) I used that document as a guide (and updating it wherever something has changed). Now, instead of typing the command line I just marked it in that Word document, copied it and pasted it into the command line. It looked completely OK to me (and still does - BTW, I also copied that line into my first email on this topic). However, using this pasted text, no examples are build! If, on the other hand, I just type the command character by character (everything else being the same, i.e. build directory completely cleaned before) everything is fine ... all examples are built. Why this happens is a complete mystery to me! If, instead of pasting the text into the command line pasting it into any text editor (emacs, notepad), there are no strange/control characters. It just looks identical to the typed-in version. But CMake generates two different build directories. I will now put a remark into my installation manual and everything should be fine. -- Best regards, Thorsten Behrens -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] git (again)
As part of the pilot effort, be sure to test interoperability with git under Cygwin. In a previous position I worked with another developer who used that configuration, and his added files had their permissions all messed up when checking out under Linux. Basically all the rwx bits were set. When I unset the ones I didn't want, he got conflicts when trying to check out. Might be an easily resolved issue, I never did figure it out. Was a few years back. -- Maurice LeBrun -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] Any way to get a list of available devices to a program?
I became curious reading this thread so I had a look -- apparently the answer
is in the code. From src/plcore.c:
...
void
plgDevs( const char ***p_menustr, const char ***p_devname, int *p_ndev )
{
plgdevlst( *p_menustr, *p_devname, p_ndev, -1 );
}
static void
plgdevlst( const char **p_menustr, const char **p_devname, int *p_ndev, int
type )
{
...
The pointers are dereferenced by the API calls to the implementing routine, so
are not needed. I probably meant to go back fix that up eventually but
ended up forgetting all about it. :)
--
Maurice LeBrun
--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] Any way to get a list of available devices to a program?
On Thursday, November 21, 2013 at 22:53:02 (-0600) Maurice LeBrun writes:
I became curious reading this thread so I had a look -- apparently the answer
is in the code. From src/plcore.c:
...
void
plgDevs( const char ***p_menustr, const char ***p_devname, int *p_ndev )
{
plgdevlst( *p_menustr, *p_devname, p_ndev, -1 );
}
static void
plgdevlst( const char **p_menustr, const char **p_devname, int *p_ndev, int
type )
{
...
The pointers are dereferenced by the API calls to the implementing routine,
so
are not needed. I probably meant to go back fix that up eventually but
ended up forgetting all about it. :)
I should add, I think I initially saw the problem as Andrew put it, that the
array of char*'s was like a 2d array so in order to return it I needed to
pass a pointer to a 2d array i.e. char***. But then realized I could skip
that and just do pointer copies instead. Bleah.. give me a nice class foo
any day..
--
Maurice LeBrun
--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Pltk segfault
That would be great Arjen, as unfortunately I'd find it difficult to commit to anything right now. Maurice On Wednesday, November 6, 2013 at 08:36:40 (+) Arjen Markus writes: Hi Alan, I can definitely have a look - it has been a rather busy period for me, but after this week it should be more relaxed. Regards, Arjen -Original Message- From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] Sent: Tuesday, November 05, 2013 9:48 PM To: Maurice LeBrun; Arjen Markus Cc: PLplot development list Subject: Re: [Plplot-devel] Pltk segfault On 2013-11-05 00:45-0800 Alan W. Irwin wrote: [...] % plstdwin . % plxframe .plw segfaults with the Debian versions of Tcl/Tk8.5 and itcl... version 3. I discovered by comparison with examples/tk/runAllDemos.tcl that the source of this issue (I am pretty sure, but I would appreciate confirmation from Maurice) is that you should use plframe rather than plxframe inside a wish environment. Accordingly I made the appropriate change in the tkdemos.tcl logic (revision 12663) and with two caveats ([1] a pretty rough logic hack that only works if you follow the examples/tk/README.tkdemos instructions religiously, and [2] a lack of access to libplplotd constants such as $::PLPLOT::PL_PI [namespace issues???]) I now have tkdemos.tcl working under wish. For example, the 10th and 12th examples work fine since they do not require libplplotd constants. These changes to tkdemos.tcl do not compromise its long-standing ability to work without issues under plserver. So we are back in business with tkdemos.tcl under wish after many years when it did not work at all. @Maurice and Arjen: as Tcl/Tk experts here would you be willing to follow up on those two caveats to extend the current proof-of-concept to a smooth and complete result? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Help needed in setting global Tcl variables for the PLplot case
On Monday, October 28, 2013 at 14:44:48 (-0700) Alan W. Irwin writes: On 2013-10-28 14:23-0700 Alan W. Irwin wrote: The goal here is to make it easy for the user to choose between using either version 3 of [incr Tcl_tk] or version 4. In fact, my testing of those two cases is being held up because I don't have an easy way to switch between them (without a lot of code editing). So some quick help on how to make this possible would be appreciated. Soon after I sent the above appeal off, I discovered how our build system set the macro TCL_DIR and how bindings/tcl/tclMain.c used that macro to help determine the Tcl global variable $dir. Therefore, I will try something similar to globally set itcl_package_name, etc., (unless you guys can think of a better method). I think in order to avoid coding in package version dependencies where none should exist, make sure your desired tcl package library directories are all properly positioned in auto_path. E.g. on my Kubuntu 12.04.3 box: $ tclsh8.4 % puts $auto_path /usr/share/tcltk/tcl8.4 /usr/lib /usr/local/lib/tcltk /usr/local/share/tcltk /usr/lib/tcltk /usr/share/tcltk $ tclsh8.5 % puts $auto_path /usr/share/tcltk/tcl8.5 /usr/lib /usr/local/lib/tcltk /usr/local/share/tcltk /usr/lib/tcltk /usr/share/tcltk That first entry enables it to find the right packages. -- Maurice LeBrun -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] map resolution
On Tuesday, October 2, 2012 at 16:41:43 (-0700) Alan W. Irwin writes: Hi Phil: On 2012-10-02 14:51-0700 phil rosenberg wrote: [snip] 3) Do either 1) or 2) but also provide an interface for loading a standard file format (presumably shapefiles via shapelib?). Also Better than now and useful for those who wish to use GIS data, but adds an extra dependancy. One possible hazard is that shapefiles can be up to 2 GB and I think the whole file must be read even if we want to plot over a limited lat/lon. Yes, please! It would probably be a good idea to include in the API the ability to limit the input map file to a user-supplied latitude and longitude range, but that is all I would do for now. So for large files there might be some noticable read time with this approach, but the result that is handled in PLplot after that will be reasonably small. In any case, I don't think you should be too concerned with large map efficiency issues. After all, presumbably there are plenty of small map files to deal with low resolution needs, and for high resolution needs the user has the choice to use some external tool to convert a large high-resolution map file into something smaller with more limited range or else use the internal PLplot range selection (see above). I agree with Alan's points. There may be other filters (I don't know) that could be used on the data as well. In addition, plan for the future -- ram is cheap. People wanting to manipulate a huge DB can have it all in ram if they really want. Earlier this year I bought 8G of DDR2 (4x2G) for only $100 from newegg. Wait a few years and 32G or even 64G will be attainable without paying enterprise prices. -- Maurice LeBrun -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Plplot-devel Digest, Vol 75, Issue 15
On Friday, August 31, 2012 at 16:07:06 (-0700) Jerry writes: I would reverse the sort of implied preference that Alan states here, if I understand correctly. I would say the primary zoom style would be to redraw the plot with new (zoomed) axes. If the zooming only enlarges everything in the window, it will normally cause the axes to disappear off-screen--not good. Yes, ideally for applications where axes are important, they would be redrawn and overlaid on the new section of space after the zoom. This critique was raised by Geoffrey from the other side of my office even before the existing zoom feature was functional back in 1993. ;) The existing zoom uses the plot buffer to redraw so acts as a simple magnifier. It works reasonably well down to scales where the 2^16 device coordinate resolution becomes an issue. Stuff that you want to be redrawn rather than simply magnified as one zooms could be done as overlays that get triggered after the initial redraw. So axes, rulers, ...? Such support does not exist in plplot today. Would be cool but a fair amount of work. Maybe good to focus on getting simple zoom working for multiple interactive drivers first. Also, an Undo stack should be kept so that one can back up one zoom operation at a time (without loosing numerical precision in the event that an extreme zoom has been reached). And a home feature to return to the originally (un)scaled view. This is probably stating the obvious but I have seen a surprising number of plotters where one is simply left to get home by manually entering the inverse of accumulated zoom factors or manually entering the axis limits. See bindings/tk/help_keys.tcl for keystroke zoom support in plframe. Note, I haven't tried any of this lately. :( ... When a plframe widget has the input focus, keyboard input is relayed to its remote TK driver. The default actions of the keyboard handler are as follows: Q | Ctrl-x Terminate program Return or Page Down Advance to the next page m Toogle top menus z enter zoom (Cliking once zooms x 2) b back zoom f forward zoom r reset zoom P print s save again 5 scroll magnification factor ?? 1 scroll speed?? leftrightupdown scroll after zoom Altkey increase scroll speed -- Maurice LeBrun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Interactive capabilities of PLplot
On Thursday, August 30, 2012 at 09:28:49 (-0700) Alan W. Irwin writes: On 2012-08-30 02:26-0700 Jerry wrote: Does the Tk interactive method allow the user to use a mouse to interactively select a rectangular portion of the plot for zooming? This would certainly be useful and then I would have an actual personal interest in this work. Do any of the interactive devices allow this? X, Aquaterm and Qt do not--those are the only ones that I have tried. Any Tcl/TK application using a plframe widget, that is, plplot-enhanced frame, can do zoom pan, palette modifications, orientation swaps, margin adjustments, save to file. All very handy stuff. This question introduces a new topic, so I am using a different subject for it. ... Note that high-level interactive use has to be programmed at the application level. [snip] Note, some higher-level interactive capability (zooming) has already been implemented for our tk device, but that would potentially interfere with implementation of higher level interactivity in applications like I have just described. So I definitely don't want to see, e.g., zooming capability implemented for all our interactive devices. On the other hand, I do want to see the fundamental interactive capability available for all our interactive devices so we do need a volunteer to add mouse button/key identification for -dev qtwidtet. As long as the default behavior can be overridden by the user, I see no issue with implementing more default interactive capabilities. For example when we were at Lightspeed, Geoffrey I implemented an interactive scalable renderer on top of plframe. We were able to override the default keystroke bindings and menu accessors in order to take full control of the zoom/pan behavior. In so doing we were able to zoom to something like 10,000x magnification without undue performance penalties, since our rendering engine would omit as many plot elements that were off-screen as possible. An additional speedup was to only include microscopic details as they became visually relevant, i.e. on the order of 1 pixel in size or more. This was done using a stock plplot build, naturally. IIRC, there were some features that I'd like to see the plplot Tcl/TK have in support of such efforts, such as being more library oriented for application writers. However no changes are absolutely necessary -- all you really need is the ability to change existing key bindings or menu entries (straightforward enough in Tcl/TK). Granted, we were a bit lucky since such extensibility was never a design requirement back when the plplot Tcl/TK support was written. For future efforts, it should be. If I ever had the free time (ha) I'd like to code a demo. Not that hard since I've already done it but would take a bit of time to do from scratch. -- Maurice LeBrun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] cmap1 colourscale direction
On Sunday, August 12, 2012 at 08:02:20 (-0700) Alan W. Irwin writes:
On 2012-08-12 00:22-0500 Maurice LeBrun wrote:
Here is the behavior I see on a plplot build (a bit old but none of this
stuff
has changed recently AFAIK). BTW H=120 is green, blue is H=240. Cf.
http://en.wikipedia.org/wiki/HLS_color_space
Using a Hue range of {0,120} gives a Red - Yellow - Green shading.
Using a Hue range of {120,0} gives a Green - Yellow - Red shading.
Selecting rev=1 causes the interpolation to go around the back side of
the
color wheel, yielding in the latter case Green - Cyan - Blue - Magenta -
Red.
So from my perspective it's working as expected, aside from the rev
misnomer
(back or wrap would've been better -- my bad).
The name of that argument can be changed without causing an API
disruption so if we can come up with a name that is a lot better, I
would encourage a patch making the change (and also the associated
change to the documentation).
But I am not sure back or wrap are a _lot_ better than rev. Just
to throw another possibility into the pot and get some discussion
going about the ideal name, how about large or larger_angle (for
the choice of range corresponding to the larger hue angles). I also
thought of cc (for counter-clockwise), but that is a similar misnomer
to rev.
large such variants don't work when the hue range exceeds 180, e.g.
{0,240}. where the shorter angle is traversed by going around the back side.
I agree back is poor also since front back are arbitrary
constructions. The most accurate mathematical description would be something
like path_includes_zero as the interpolation is defined by going through the
H=0=360 (red) point. So maybe that or something similar.
Of course, this silliness could've been avoided if I'd merely chosen a default
interpolation direction, like counterclockwise, and then used the flag to
reverse polarity. That didn't occur to me at the time. The reason for the
existing design probably reflects bias due to seeing the HLS wheel displayed
in flattened form (red on the left). In that view, a default front side
interpolation seems more intuitive. But so does driving on the RHS of the
road. ;)
--
Maurice LeBrun
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] cmap1 colourscale direction
On Sunday, August 12, 2012 at 12:59:53 (-0700) Alan W. Irwin writes: path_includes_zero usually does describe the mathematical meaning, but that term is ambiguous for the special case when the hue range ends with zero or 360 since both path alternatives in that case include zero (or 360). To avoid ambiguity, how about dropping all special meaning from the name and using alt_hue_path instead (with appropriate docbook and doxygen documentation of exactly what that means in a mathematical sense)? Sounds good. -- Maurice LeBrun -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] cmap1 colourscale direction
Here is the behavior I see on a plplot build (a bit old but none of this stuff
has changed recently AFAIK). BTW H=120 is green, blue is H=240. Cf.
http://en.wikipedia.org/wiki/HLS_color_space
Using a Hue range of {0,120} gives a Red - Yellow - Green shading.
Using a Hue range of {120,0} gives a Green - Yellow - Red shading.
Selecting rev=1 causes the interpolation to go around the back side of the
color wheel, yielding in the latter case Green - Cyan - Blue - Magenta - Red.
So from my perspective it's working as expected, aside from the rev misnomer
(back or wrap would've been better -- my bad).
Maurice
On Friday, August 10, 2012 at 03:04:22 (-0700) phil rosenberg writes:
Hi all
I've come across a feature of the cmap1 colourscale that I wanted to
check. According to the doumentation for plscmap1l the hue is interpolated
around the front of the colour wheel (red-green-blue-red) unless the rev
flag is set to true.
I've found however that this isn't always the case and that reversing the
order of points on the coord arrays also reverses the direction. For example
using HLS I set coord1 to {0,120} and rev to false which gives me a
colourscale of red-yellow-green-turquoise-blue. If I then set coord1 to
{120,0} I would expect to get a colourscheme from blue-purple-red, but
instead I get blue-turquoise-green-yellow-red.
I've called it a feature, because I'm not sure if this is a bug in the code
or if it is the correct behaviour but the documentation isn't great. Any
thoughts?
Phil
Rosenberg--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Should we drop g77 compiler support now by weeding out our *a name-mangling variants?
In the better late than never category.. On Sunday, November 6, 2011 at 18:40:01 (-0800) Alan W. Irwin writes: [snip] Which Fortran compiler (g77 or gfortran) do you use to build PLplot on CentOS 5.x? (Both the cmake output and output from make VERBOSE=1 should tell you that.) I believe if you have both the gfortran and g77 compilers available on your system, that our build system will choose gfortran by default without you having to fiddle with the FC environment variable. But it would be good to get confirmation of that (and also confirmation that gfortran produces good PLplot Fortran results) for CentOS 5.x before we make any decision about dropping support for the g77 compiler. I looked into this the other day, last chance before upgrading to CentOS 6.x. Turns out the cmake configuration selects /usr/bin/gfortran under CentOS 5.7, so it seems no need to support g77 on that platform any more. -- Maurice LeBrun -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [ plplot-Bugs-3474186 ] wxWidgets dc and gc driver on uses cmap0 for text
Not a bug at least according to original design. cmap1 is intended for representing continuous data variation through a mapping of value to color, cmap0 for more fixed elements like labels and axes. OTOH given a compelling example of why/when/how you'd want to use cmap1 instead it might be worth supporting that. -- Maurice LeBrun On Monday, January 16, 2012 at 14:47:40 (+) Andrew Ross writes: Is this actually a bug? Example 12 uses plcol1 to set the colour for the boxes in a box chart, then plots text. The text comes out in the same (cmap0) colour even though the boxes change colour. I've checked with xwin / psc / wxwidgets / qt and cairo drivers and all seem to do the same thing. Phil, if you are on the list can you provide us with a short demonstration to illustrate what you mean? Andrew On Sun, Jan 15, 2012 at 07:41:48AM -0800, SourceForge.net wrote: Bugs item #3474186, was opened at 2012-01-15 07:41 Message generated for change (Tracker Item Submitted) made by philrosenberg You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=102915aid=3474186group_id=2915 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Phil Rosenberg (philrosenberg) Assigned to: Nobody/Anonymous (nobody) Summary: wxWidgets dc and gc driver on uses cmap0 for text Initial Comment: When drawing text using the dc and gc wxWidgets driver it always uses cmap0 colours. Setting the foreground colour using cmap1 has no effect upon the text colour. I think from looking at the code (but I have not checked) that the agg wxWidgets text colour can be set by either cmap0 or cmap1. I've checked the psc driver and this allows setting the colour using cmap1. This behaviour is not documented in the manual as far as I can see. This can be fixed by editing the wxPLDevDC::ProcessString function in wxwidgets_dc.cpp and wxwidgets_gc.cpp - the appropriate lines are pretty obvious. I'm sorry I can't submit a patch but I only have access to a windows machine so don't have access to diff, which I think is needed for creating patches -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=102915aid=3474186group_id=2915 -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Should we drop g77 compiler support now by weeding out our *a name-mangling variants?
On Sunday, November 6, 2011 at 12:51:12 (-0800) Alan W. Irwin writes: Does anyone here know the g77 package availability for enterprise RedHat and SuSe? On my CentOS 5.x box, g77 is indeed part of the standard installation, with /usr/bin/f77 symlinked to /usr/bin/g77. -- Maurice LeBrun -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Planned change to the minimum CMake version.
On Friday, October 21, 2011 at 19:43:14 (-0700) Alan W. Irwin writes: Hi Maurice: On 2011-10-21 18:32-0600 Maurice LeBrun wrote: On Friday, October 21, 2011 at 10:43:56 (-0700) Alan W. Irwin writes: If I don't hear any strong objections to changing the minimum version of CMake to 2.8.6 for Windows and 2.8.2 for all other platforms, I plan to make this important change to our build system early next week (probably Monday). Ubuntu 10.04 (LTS) is using 2.8.1, is there a good reason not to make this the minimum? The usual x.x.0 and x.x.1 troubles. For example, it took a while for ... OK, good points, I'm fine with your proposal. -- Maurice LeBrun -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] PLplot contains non-commercial licence?
On Tuesday, August 2, 2011 at 09:09:40 (-0700) Alan W. Irwin writes: Hi Maurice: I have some questions for you at the end. OK, inline below. On 2011-07-29 17:13+0530 Atri Bhattacharya wrote: Hi! I package plplot rpms for openSUSE. I am a little confused about the licence header mentioned in the file plplot/plplot-5.9.7/bindings/tk/about.tcl that says The PLPLOT package is freely distributable, but NOT in the public domain. The PLPLOT source code, except header files and those files explicitly granting permission, may not be used in a commercial software package without consent of the authors. You are allowed and encouraged to include the PLPLOT object library and header files in a commercial package provided that: (1) it is explicitly and prominently stated that the PLPLOT library is freely available, and (2) the full copyrights on the PLPLOT package Is this statement not in conflict with PLplot's otherwise LGPL licence? Yes. Is this simply a remnant of an old licence, and needs to cleared out? Virtually positive. svn diff shows the last substantial change to the text was done in 1994. Maurice, do you agree this old licensing-type language needs to be cleared out and replaced with a reference to the LGPL instead? Absolutely. We were remiss in not clearing that out to begin with. Do you also agree there is lots of other extremely dated information in that file (references to old institutions, e-mail addresses, and operating systems) that should be removed? Definitely. I know there are still references to our long-dead original hosting machine (dino.ph.utexas.edu) that absurdly out of date. More than a decade. If you agree changes should be made, do you want to update the file yourself or do you want me to do it? If you could, I'd appreciate it, as I'm swamped at work as usual. -- Maurice LeBrun -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] ABOUT file
On Friday, July 29, 2011 at 13:57:36 (-0400) Hazen Babcock writes: We are only missing the answer to this question: Why and when did PLplot come to be? Which I think that Geoff or Maurice could perhaps answer (a link to a old e-mail would be fine)? Has anyone else been with the project from the beginning? -Hazen Ugh.. yeah those emails have been begging for me to comment. Some of the early history is in the (hopelessly out of date) intro in the docbook manual, i.e. http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.7/intro.html From this, the project apparently germinated in 1986. Quoting from the manual: PLplot was originally developed by Sze Tan of the University of Auckland in Fortran-77. Many of the underlying concepts used in the PLplot package are based on ideas used in Tim Pearson's PGPLOT package. Sze Tan writes: I'm rather amazed how far PLPLOT has traveled given its origins etc. I first used PGPLOT on the Starlink VAX computers while I was a graduate student at the Mullard Radio Astronomy Observatory in Cambridge from 1983-1987. At the beginning of 1986, I was to give a seminar within the department at which I wanted to have a computer graphics demonstration on an IBM PC which was connected to a completely non-standard graphics card. Having about a week to do this and not having any drivers for the card, I started from the back end and designed PLPLOT to be such that one only needed to be able to draw a line or a dot on the screen in order to do arbitrary graphics. The application programmer's interface was made as similar as possible to PGPLOT so that I could easily port my programs from the VAX to the PC. The kernel of PLPLOT was modeled on PGPLOT but the code is not derived from it. Then Tony Richardson ported it to the Commodore Amiga, rewriting in C with additional improvements. While doing a post-doc fellowship in Japan I needed a free scientific graphics library for my plasma simulation code and came across PLplot on a series of free software for the Amiga (Fish disks). I ported it back to several varieties of Unix and took over maintenance from Tony. After returning to the Institute of Fusion Studies at University of TX I continued to develop the package, with Geoff Furnish joining me as co-developer. In the early 90s's the new contributions were released under the LGPL. When I left UT in '95 Geoff became sole maintainer for some years, and was responsible for getting it up at Sourceforge in the earliest days of that site's existence. That made it easier to add collaborators such, and starting with Alan Rafael (IIRC) the core team gradually came to be. Feel free to adopt / condense / add-to any of the above. -- Maurice LeBrun -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Line style choices
On Friday, July 1, 2011 at 00:58:14 (-0700) Alan W. Irwin writes: Hi Maurice: I am addressing this specifically to you because you may have some idea of why the line style choices were made the way they were from your long history with PLplot, but I hope others here jump into this discussion as well. [snip] Sorry for the delayed response. I can't comment on the history of the line style choices except to say they have been that way since I first started working with PLplot in 1990 and I haven't touched them IIRC. I personally don't use them much -- solid dashed (I think #3) lines is about it. I was never that impressed with the appearance of some of the higher numbered ones either. Since you're contemplating a change that (a) would look better but (b) introduce backward incompatibility, one nice way to handle it would be through line style sets. The legacy set would be 0, the new set 1. Let it default to the new set but use an API call to switch back to the legacy set. That way you can also easily recover exact postscript results on test program output when you're trying to isolate an output regression. Just my two cents, I don't have a strong opinion either way. Down with the British! (happy 7/4 ;) -- Maurice LeBrun -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Different background colours for different pages of a multi-page plot
On Friday, May 6, 2011 at 21:24:03 (+0100) Andrew Ross writes: A further quirk that has come to light is that the xwin driver actually uses a single colourmap for all windows / streams, whereas plplot has individual colourmaps for each stream. This is only an issue if you have multiple windows and change the colours. I suspect this feature was initially for 8-bit displays and avoids the annoying flashing colours when you switched windows (anyone still remember that?) These days it is probably not really an issue. I'm tempted to clean this up to make a per stream colourmap. Any strong opinions? I've never actually encountered this problem, but I imagine for interactive use like octave it could potentially be an issue. It should definitely be changed to per-stream colormaps if you've got a hankerin' to do it. It's been an issue that did annoy me at times when using multiple plframe widgets in an application. -- Maurice LeBrun -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Should we unformly use the const attribute for our input arrays?
On Tuesday, March 8, 2011 at 19:58:26 (-0800) Alan W. Irwin writes: I have already had one positive response off-list from Andrew on this question so I have decided to start the process to see how far I can get. I just *have* to post the const-nazi bit here. Apologies to anyone who is offended by the portrayal (btw my mom's side of the family is German). I thought it was really funny. And, although sometimes it's a PITA, I do really like const. http://gamesfromwithin.com/the-const-nazi -- Maurice LeBrun -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] About plfill, plline, plmap and request of functionalities
On Thursday, December 23, 2010 at 09:28:20 (+0100) José Luis García Pallero writes: Attached I send a patch for svn plfill() that uses malloc/free in case of n PL_MAXPOLY-1. I've used a behavior similar to the function plP_plfclp() in plfill.c. plP_plfclp tests if the number of point is greater than PL_MAXPOLY and uses static or dynamic array in consequence. I've done the same for c_plfill() and c_plfill3(), so for polygons with small number of vertices no overload is done for the using of malloc/free. This only introduces two if's sentences: for test if malloc must be used and for tests if free must be used. And deletes a if sentence: the check if ( n PL_MAXPOLY ) in the test for determining if the last point is the same as the initial in tle polyline defining the polygon. Have you surveyed the rest of the code base for other places that need changing? I see drivers/xwin.c and src/plbuf.c for sure. Else code will go boom. -- Maurice LeBrun -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Plplot-general] About plfill, plline, plmap and request of functionalities
On Wednesday, December 22, 2010 at 23:15:12 (+) Andrew Ross writes: Thread moved to plplot-devel as this is becoming a discussion on new developments / improvements. On Wed, Dec 22, 2010 at 02:32:24PM -0800, Alan Irwin wrote: On 2010-12-22 11:00+0100 Jos? Luis Garc?a Pallero wrote: Hello, I think that PLPlot is a great tool. Thanks to the developers for their hard work. I'm using PLPlot in order to draw worldmaps with coastlines. I'm using plfill, plline and plmap functions and I find they very useful. Nevertheless I have some minor problems (I'm using PLPlot 5.9.7 compiled by me on a Debian GNU/Linux Sid). Using plfill I obtain a the message *** PLPLOT WARNING *** plfill: too many points in polygon using polygons with 1000 vertices. Can I change the maximum number of vertices at runtime or must I recompile the library? [snip] Arjen has already answered you in general terms on the PL_MAXPOLY question (currently set at a hard limit of 256 in include/plplotP.h). If you grep through our code for that symbol, you will notice a number of fixed arrays that are dimensioned with that value. I would welcome a patch to replace all of those with malloced (and freed) memory so we could do away with the PL_MAXPOLY limit completely. A cautionary note: PL_MAXPOLY impacts a fair amount of code. Also there are heap-vs-stack performance implications -- e.g. directly moving from a fixed allocation to a malloc/free each time plfill() is called could suck for the many small-n-vertices polygon case. Using per-stream polyline buffers is better but more convoluted. The short term solution is definitely just recompile with a higher limit. -- Maurice LeBrun -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Clobbered commentary in bindings/tk/tkMain.c
Thanks for the fix. As prize, I'll send you some snow. ;) (Just had 2nd snowfall here in Longmont, CO.) Maurice On Thursday, November 11, 2010 at 10:21:57 (-0800) Alan W. Irwin writes: Hi Maurice: I thought you would be amused by revision 11326. When searching all our source files for instances of \.rc last night I noticed the following clobbered commentary in bindings/tk/tkMain.c. // Commands will come from standard input, so set up an event // handler for standard input. If the input device is aEvaluate the // .rc file, if one has been specified, set up an event handler I was concerned that my comment restyling script had somehow clobbered that comment, but it turns out that aEvaluate and the inserted (or missing) words before it has been in this file since its initial commit by you back in 1994 (!). That explanation took all the urgency away from this issue, but I decided nevertheless to fix the issue by replacing the comment with its correct form (found with a google search) which is to remove If the input device is a from the comment. That fix for a 16-yr old issue (no matter how trivial) has got to set some sort of PLplot record. Do I get a prize? :-) BTW, the .rc stays in that commentary because it is referring to a different kind of file than our driver information files. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] x14 bug with -xwin and focus stealing
Hi Alan, I'm somewhat in the dark about xwin focus issues. I recall Tk goes to some trouble to do the right thing about it, and maybe that's the problem here. The demo was originally envisioned as testing ground for more arcane scenarios involving the Tk driver; I'm a little amused/surprised it sort of works for xwin as well (a bug: the plot is only supposed to advance when the master widget gets the page advance, but on my build the xwin driver advances when either window does). Anyway, regarding focus, maybe Tk solves some problem that we're not. Sorry I couldn't be of more help. Maurice On Thursday, August 5, 2010 at 17:31:11 (-0700) Alan W. Irwin writes: Hi Maurice: If I run x14c like examples/c/x14c -dev whatever on a KDE desktop that is set up with the high or extreme setting to prevent focus stealing (via System Settings == Window Behavior == Window Behavior == Focus Stealing Prevention Level), it works fine for -dev xcairo, -dev qtwidget, and even -dev tk (once I click on the window generated by x14c to give that window focus), but hangs (with top giving 100 per cent of the cpu to x14c indefinitely) for -dev xwin regardless of clicking on the window. If I use -debug, I get one expose event before attempting to click on the window, but then it hangs with two black screens (one with a vertical red line through it) until I hit ctrl-C. Demo of multiple output streams via the xwin driver. Running with the second stream as slave to the first. ExposeEH: x = 92, y = 0, width = 408, height = 410, count = 0, pending = 0 ^C If I set focus stealing prevention to none, low, or medium, all is well with -dev xwin. It appears with x14c (but no other example) that -dev xwin (but no other device including -dev tk) requires focus stealing (perhaps for the second window?) from the start or otherwise it hangs. Do you (or anybody else on this list) have some suggestions for fixing xwin.c so this issue does not happen? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] creating a graph using Tcl/tk
In order to run TK code that uses plplot extensions, you need an extended wish that knows about these extra commands. That's what plserver is for (it also has some IPC for handling requests from the plplot TK driver which is why it's not simply called plwish.. too bad, that would've been more transparent). So use plserver, or write your own extended wish; it should be straightforward enough (google it). One of the niceties of Tcl/Tk is its ease of embedding in users applications and light footprint. Maurice On Monday, August 9, 2010 at 08:09:34 (-0700) Faizullabhoy, Alefiya writes: Hello Arwen, Thank you for your reply. Do you have sample TK code that plots a graph without using plserver or an xtk02 C wrapper? I did look at the tk02.in sample program but have not been able to invoke it without using xtk02. I am running on Linux. Thanks, Alefiya -Original Message- From: Arjen Markus [mailto:arjen.mar...@deltares.nl] Sent: Monday, August 09, 2010 10:03 AM To: Faizullabhoy, Alefiya Cc: plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] creating a graph using Tcl/tk Hello Alefiya, should you have more questions about the Tcl/Tk interface, let us know. (I should be able to help out with it - especially if you use it on Window.) Regards, Arjen On 2010-08-03 23:04, Alan W. Irwin wrote: On 2010-08-03 06:50-0700 Faizullabhoy, Alefiya wrote: I'm new to plplot and I installed plplot with all the given examples on Fedora. I need an example where I can create a graph from within a TCL/TK program. I looked at the examples but they all seem to require a C program to run them ie xtk02 -f tk02.in. How do I create a graph directly from a TCL/TK program without using a C program such as xtk02? Hi Alefiya: Thanks for your interest in PLplot. To answer your specific question, in the svn version (and possibly 5.9.6 as well although there are some issues that have been fixed since 5.9.6) look at examples/tk/standard_examples.in in the source tree that is the template for the configured shell script located at examples/tk/standard_examples in the build tree. That configured shell script implements what is suggested for the plserver way of doing things in examples/tk/README.tkdemos. That latter file also suggests some additional possibilities for running our standard Tcl examples (as well a C-compiled examples) from a Tk environment. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xor mode
On Wednesday, May 12, 2010 at 20:18:40 (+0100) Andrew Ross writes: On Tue, May 11, 2010 at 11:55:29PM -0500, Maurice LeBrun wrote: I agree, xor mode sucks big time (due to the line occasionally becoming invisible). On a recent project, I implemented a plot overlay capability for drawing a ruler between two interactively selected points, with coordinates plotted in world coordinates. The basic flow was as follows: - set up all the event bindings to have the facility act as desired - every time the mouse moves: o force an expose event.. this blits the backing pixmap to the screen o turn off plot buffer backing pixmap writing o draw your desired overlay register it with your redraw facility (you must commandeer redraw for this to work) o turn back on plot buffer backing pixmap writing - restore original bindings when custom drawing mode is terminated The turning off of the plot buffer backing pixmap writing requires some rather evil direct manipulation of the contents of the PLStream and XwDev structs.. an API for this would be hugely better. As well as a demo. One can dream.. anyway maybe some food for thought. I quite like this approach as it is more general than my idea for specifically dealing with selection rectangles. Any chance you could share your code for this? I'd have to essentially reimplement it from memory.. no time. On the great pile of projects I'd like to get around to. -- Maurice LeBrun -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] xor mode
On Tuesday, May 11, 2010 at 15:34:23 (+0100) Andrew Ross writes: I've been trying to tidy up some of the inconsistencies between different interactive drivers on plplot. The xwin, tk, qtwidget and xcairo drivers now all more or less have consistent handling of plGetCursor as far as is possible. The big outstanding issue in terms of the interactive examples in plplot is the xor mode which is used by xwin and tk to draw then remove lines while interactively selecting region in example 20 (also tested in example 1). Now these days it seems that this is not the preferred way of doing such things. Qt for example dropped support for xor mode. It does provide alternative ways of doing things like selection using QRubberBand. One problem is that using xor does not guarantee you a line that is clearly visible, depending on the background image or graph. As a stop-gap measure we could just not draw the lines for devices which don't support xor mode but do support plGetCursor. I've done this for the octave examples and it works, but it isn't ideal. I wonder if it would be better to have a plplot function to select a rectangle (something like the octave plrb) which could delegate the drawing of the rectangle to the driver via an escape function? The drivers could then handle it in the most appropriate way. For the low level xwin driver this would be via xor, for higher level drivers such as qtwidget it might use library specific functions. I guess we would leave xor mode for those drivers which support it, but depreciate it over time. Of course, if anyone has any bright ideas how to implement something like xor mode for some of the other drivers that would be good. I agree, xor mode sucks big time (due to the line occasionally becoming invisible). On a recent project, I implemented a plot overlay capability for drawing a ruler between two interactively selected points, with coordinates plotted in world coordinates. The basic flow was as follows: - set up all the event bindings to have the facility act as desired - every time the mouse moves: o force an expose event.. this blits the backing pixmap to the screen o turn off plot buffer backing pixmap writing o draw your desired overlay register it with your redraw facility (you must commandeer redraw for this to work) o turn back on plot buffer backing pixmap writing - restore original bindings when custom drawing mode is terminated The turning off of the plot buffer backing pixmap writing requires some rather evil direct manipulation of the contents of the PLStream and XwDev structs.. an API for this would be hugely better. As well as a demo. One can dream.. anyway maybe some food for thought. -- Maurice LeBrun -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [ plplot-Bugs-2998260 ] -dev xwin shows fatal error when window closed
On Monday, May 10, 2010 at 09:50:28 (-0700) Alan W. Irwin writes: On 2010-05-10 13:55+0100 Andrew Ross wrote: On Fri, May 07, 2010 at 09:03:59PM -0400, chm wrote: On 5/7/2010 1:03 PM, SourceForge.net wrote: Summary: -dev xwin shows fatal error when window closed Initial Comment: For -dev xwin, when you close the window by alt+F4 or other equivalents, the following fatal error message is the result: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server This fatal error can be disruptive to certain environments (e.g., lisp) and should be replaced by a smooth exit from PLplot. as occurs under these same circumstances for -dev qtwidget and -dev wxwidgets. I took a look at xwin.c and it appears that a number of the X11 calls do not have check for error returns. Perhaps this is the origin of the problem. The underlying problem is that to detect pressing of the close button in the top right of a X window you need to explicitly ask for it to be forwarded on, and then handle the consequences yourself. I've now committed a change to do this. The event handling in the xwin driver is not simple and so I would appreciate people robustly testing these changes to make sure I've not broken anything else. Thanks very much for taking on this tricky fix. I tried a lot of variations of x01c with -xor and -locate with various ways of closing the window and all was well. I also tried multipage examples and all seemed well. Finally, I tried -dev tk (which depends on -dev xwin code) using the command examples/c/x01c -dev tk and I get a hang from alt+F4 or any other method of closing the window. (BTW, to set up all the prerequisites for that command you can use make -j4 test_c_tk or make -j4 all.) I am not sure whether this -dev tk hang is a long-standing problem or the result of your recent change because up to now I have rarely tested closing the window, but it would be great if you would be willing to take a look. I'm not sure about the tk driver status, as it's been a long time since I used it substantially. But I do use the plframe binding, a lot. And I fear the bug fix as implemented will be incompatible with that. Here's the situation: a user with a plplot-enhanced wish (the one we build in the package is named plserver) launches a bunch of windows. Then the user clicks on the go-away button. The xwin driver calls plexit() and the whole application shuts down. Not good. It should just exit that stream. I haven't verified this experimentally, but an easy way to do so is using examples/tk/tk03. It uses a stock plserver for plotting (you can change @plserver_LOCATION@ to be just . and run from the directory plserver is sitting in). Click on the Open new button to open a 2nd plframe. Then close it with the goaway button. Only that window, and not the first, should shut down. -- Maurice LeBrun -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] proposal for consideration: plcont_phase.c for contour plots of phase data
On Monday, April 19, 2010 at 22:35:33 (-0700) Alan W. Irwin writes:
On 2010-04-19 22:21-0500 Maurice LeBrun wrote:
[...]
Note, people doing polar plots (shades or contours) have to similarly
massage
their data before passing it to plplot in order to pick up the continuity
condition at angle 0 = 2pi. One could claim this is an important effect
for
the library to handle natively, but frankly I've never seen the need,
preferring a leaner and more easily maintained API. This is illustrated
(rather quietly) in the final (polar) plot of example 16, where the angle
coordinate value runs from 0 to 2pi inclusive -- providing a duplicated
data
point to enforce continuity.
Hi Ed:
Let me add a bit more to what Maurice said by talking about a specific
example. Suppose the function you are plotting is theta(x,y), where theta =
arctan2(y, x) In this (simple) case, there is obviously a 2 pi discontinuity
in theta at +/- pi. For lack of a better term, let's call that an
angle range discontinuity.
I don't have a lot of experience with the plcont API, but I know it is quite
general and the Contour and Shade PLot section of our documentation at
http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.5/contour-plots.html
says the following:
Examples of the use of these transformation routines are given in
examples/c/x09c.c, examples/c/x14c.c, and examples/c/x16c.c. These same
three examples also demonstrate a user-defined transformation function
mypltr which is capable of arbitrary translation, rotation, and/or shear. By
defining other transformation subroutines, it is possible to draw contours
wrapped around polar grids etc.
It appears to me that last sentence is stating the user-defined
transformation function is the proper way to deal with contouring of angular
data with range discontinuities like the simple example above. The same
approach may allow you to deal properly with your more general case of a
phase range discontinuity occuring at arbitrary curves in the x, y, plane.
Maurice, do you agree or was there something else you had in mind?
The general remapping of coordinates is a crucial part of it. I was also
pointing out how one can achieve a specific functional boundary condition
i.e. f(r, 0) == f(r, 2pi) on a polar grid without having to support that in
plplot per se. Typically when one discretizes space it's a one-to-one mapping
between grid indices and spatial coordinates barring degenerate points like
r=0 (which I have never liked and tend to avoid if possible). If you do a
contour or shade plot for such a regular discretization in polar
coordinates, IIRC you end up with a plot that looks like a pie with a slice
cut out of it -- because the contourer and shader know nothing about your
boundary condition. You've just taken a rectangular grid and stretched it
around until it approximates a circle. To fill in the pie slice you need to
add in an extra gridpoint at 2pi. It's redundant, so anathema to the
central loops in a simulation code, but makes the diagnostic give the result
you want. So in this case the wrapper function is called for.
In example 16 you can see the wrap-around in theta clearly:
for ( i = 0; i nx; i++ )
{
r = ( (PLFLT) i ) / ( nx - 1 );
for ( j = 0; j ny; j++ )
{
t = ( 2. * M_PI / ( ny - 1. ) ) * j;
cgrid2.xg[i][j] = r * cos( t );
cgrid2.yg[i][j] = r * sin( t );
z[i][j] = exp( -r * r ) * cos( 5. * M_PI * r ) * cos( 5. *
t );
}
}
although like I mentioned it's not well-advertised. Sorry..
--
Maurice LeBrun
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] proposal for consideration: plcont_phase.c for contour plots of phase data
On Monday, April 19, 2010 at 15:22:14 (-0700) Alan W. Irwin writes: On 2010-04-19 13:47-0700 Ed Zaron wrote: Hi All, I've been using plplot for a project where we have to plot so-called co-tidal charts which display the amplitude and phase of the tide in the ocean. The amplitude is normally shown with a color image (made with plimage), and the phase is shown with contours (using the fortran interface, plcon1). As you may know, contours of phase data have jumps where the phase wraps around, say, the 0/360 degree reference phase. This leads to situations in contour plots where the phase is contoured nicely, except where these jumps occur. Within the jump, all the contour lines are packed into the jump. This is an unavoidable consequence of trying to contour phase in 2-d, whenever the field has zero amplitude points (so-called, amphidromes, in the tidal context) where the phase is undefined. I've attached a little patch to plplot/src/plcont.c from a freshly checked out source distribution (r10926). I wonder if you might consider adding a new subroutine to the plplot library, say, plcont_phase, which would correctly represent phase contours without the jumps? Hi Ed: I haven't looked at your patch, but I assume it processes phase data to impose phase continuity so that after processing you end up (in general) with a continous phase range from -M*360 deg to N*360 deg which is easy to contour. Assuming your patch does something like that, the question which I would like you to discuss further is whether this is of sufficient usefulness to PLplot users to add this functionality to our API for all the languages we support or whether this straightforward processing to impose phase continuity should be done by individual users before they call PLplot with their (now) continuous phase data. I agree with Alan, AFAICT the phase transformation can therefore should be done in user space. I suggest a suitable wrapper function on your end, to copy and transform the data as necessary. Note, people doing polar plots (shades or contours) have to similarly massage their data before passing it to plplot in order to pick up the continuity condition at angle 0 = 2pi. One could claim this is an important effect for the library to handle natively, but frankly I've never seen the need, preferring a leaner and more easily maintained API. This is illustrated (rather quietly) in the final (polar) plot of example 16, where the angle coordinate value runs from 0 to 2pi inclusive -- providing a duplicated data point to enforce continuity. -- Maurice LeBrun -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [PATCH] Support arbitrary storage of 2D user data
On Monday, February 22, 2010 at 14:42:57 (+) Andrew Ross writes: 3) Talking of efficiency, I worry that this introduces a large additional level of complexity for a rather specialist set of cases where odd data storage methods are used. I am slightly relieved by David's comments, but I would like to have a thorough comparison of the time difference. This should include a large data case as well where timings might be more important. The lena image might be one suitable case. The test should also multi-language tests to see if not copying large amounts of data around is quicker than having lots of callbacks. I see this issue as mostly about program clarity programmer convenience. Nothing wrong with a test, but I'll restate (and elaborate upon) my previous prediction that efficiency is mostly a moot point. Of course those with scientific programming backgrounds will tend to see function calls associated with a single data point as somewhat evil, and they'd be right -- in the high performance arena of say, the central processing loops of a multidimensional simulation. But that's not the situation here. Aside from the oddball case of plotting into a memory buffer, at the end of the call chain some i/o will be performed. That should dwarf the function call overhead. -- Maurice LeBrun -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Another feature request (maybe)
On Wednesday, January 6, 2010 at 17:00:40 (-0800) David MacMahon writes: Hi, Alan, On Jan 6, 2010, at 9:03 , Alan W. Irwin wrote: If we have a mixture of C and Fortran ordering for the two-dimensional arrays in our API, we should decide which convention we should use in our API and convert to it if/when we decide to do other major API breakage we have been discussing. I guess I joined the list after that discussion, but I think it would be great if the API supported the following four ways of passing in 2D data... 1) 1D array of nx pointers to 1D arrays of ny values 2) 1D array of ny pointers to 1D arrays of nx values 3) Pointer to 1D array of nx*ny values in row major order 4) Pointer to 1D array of nx*ny values in column major order This may be somewhat of a grandiose, idealistic wish, but it would support the most common ways of specifying 2D data without requiring (potentially expensive) transposition of the data. I haven't gotten too far into the other 3D-ish functions yet, but some (e.g. plcont) accept a transformation function pointer through which lookups occur. Perhaps this mechanism (or something similar) could be used to provide the level of flexibility I'm suggesting (and beyond!). Some centuries ago I did endow the contourer with the function evaluator technique to deal with the issue of C vs Fortran vs whatever array storage. Worked out nicely IMO. Would've liked to upgrade all array-handling functions in like fashion but so far I think it's only been done for the plshadexx family. -- Maurice LeBrun -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Another feature request (maybe)
On Wednesday, January 6, 2010 at 22:43:44 (-0800) David MacMahon writes: On Jan 6, 2010, at 17:14 , Maurice LeBrun wrote: Some centuries ago I did endow the contourer with the function evaluator technique to deal with the issue of C vs Fortran vs whatever array storage. Worked out nicely IMO. Would've liked to upgrade all array- handling functions in like fashion but so far I think it's only been done for the plshadexx family. Thanks, Maurice, I see that now in plfcont and plfshade. I think that's just the kind of thing that would be great to have for every function that deals with 1-D data. I'm willing to try my hand at adapting some other functions to use this technique. As far as I can tell, the list of functions that could benefit from this are... c_plgriddata (*) c_plmesh (**) c_plmeshc (**) c_plot3d (**) c_plot3dc (**) c_plot3dcl c_plimagefr (***) c_plimage (***) c_plsurf3d () c_plsurf3dl c_plvect (*) (*) c_plgriddata might need both a getter and a setter version of this technique. (**) calls through to c_plot3dcl (***) might need a plf... version of plMinMax2dGrid () calls through to c_plsurf3dl (*) already has a plfvect in plvect.c, but not plplot.h! My plan would be to rename the existing functions from c_pl... to plf... (or c_plf...?) and create new versions of the old functions that call the plf variant with a particular choice for f2eval and f2eval_data (as the c_plcont comments say). The only downside to doing this, AFAICT, is that the current behavior of these functions will be somewhat slower since they will be getting data via the evaluator function and not directly from the z[nx][ny] array (at least for z arrays that don't need to be pre-un- transposed into that format). My only suggestion is to not worry about the performance issues in function evaluation.. after all you've got a system call somewhere down the line to actually draw something. In my experience that's usually where the worst (and most intractable) bottleneck occurs. -- Maurice LeBrun -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Setting windows title
On Wednesday, November 18, 2009 at 13:00:09 (-0800) Alan W. Irwin writes: I agree a prompt should be available for all interactive devices, but to me stderr (or stdout) output is fine (and can allow for a longer prompt). Is there some reason why you prefer the prompt in the windows title rather than stderr or stdout? Note, I am talking here about the PLplot interactive devices run from the command line, not standalone GUI's where access to stderr or stdout might be more problematic. A prompt in the window title for a standalone GUI is potentially even more problematic, because it's not a linear plotting paradigm. A GUI responds to user input to and displays plots based on that, no pressing return needed for anything. Unless I'm misunderstanding what's being proposed, I don't think anything about hitting return should be in the default window title. -- Maurice LeBrun -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plsyax bug
The reasoning behind the specific fixed choices in the library are no longer accessible to me. I do know that prior to the exponential notation mods, plplot would give really ugly plots when in the extremes of small and large number ranges. I do recall spending a lot of time futzing with various choices, finally ending with Good enough! Time to get some real work done. Extra choice to the user is always good. Better defaults are also good. Determining an indisputably better solution in either case, especially the latter, is sometimes difficult. :) Sorry I can't be of more help but I'd have to basically rediscover my previous decision making anyway, even if I had the time to look into it. So a good learning experience for any developer that decides to take this on. On Monday, November 16, 2009 at 11:43:37 (-0800) Alan W. Irwin writes: To Maurice and Geoffrey: I have questions for you below concerning a PLplot style change that would give users more freedom about deciding whether or not exponential notation is used in axis labels. On 2009-11-14 17:47-0800 Alan W. Irwin wrote: While investigating the old bug report https://sourceforge.net/tracker/?func=detailaid=844858group_id=2915atid=102915, I managed to reproduce the problem with the following python script: [...] plsyax(1, 0) [...] plwind(0.00, 1.00, 0.00, 0.08) [...] If I change the plwind call to plwind(0.00, 1.00, 0.00, 0.10) the issue goes away. I have investigated this issue further. The pldprec code predicts digmin, the largest possible label length for the given range (which in this case is slightly negative to slightly more than 0.08). Normally, 0.08 would correspond to digmin of 4 (this digits count includes the sign and decimal point), but the code calculates digmin = 5 since the range includes negative values (which handles the possibility of a label at, say, -0.01). The plsyax call above insures pldprec is called for the y axis with digmax=1. However, that digmax value is interpreted further using the following macro values #define MAX_FIXDIG_POS6 #define MAX_FIXDIG_NEG4 which are the ceiling on digfix calculated from digmax depending on whether we are dealing with positive or negative exponents. In this case, digfix is 4 since 0.08 corresponds to negative exponents. Thus, digmin digfix which is why there is no way for users to get anything other than exponential notation for plwind(0.00, 1.00, 0.00, 0.08) So fundamentally, this issue is a fixed style issue imposed by the choice of the above macro values. My own feeling on style issues is we should have good defaults. (Our code sets if ( plsc-xdigmax == 0 ) plsc-xdigmax = 4; if ( plsc-ydigmax == 0 ) plsc-ydigmax = 4; if ( plsc-zdigmax == 0 ) plsc-zdigmax = 3; when the library is initialized which I think is probably okay.) However, I also believe we should allow users freedom to impose their own style if they want. You could increase that freedom by increasing both MAX_FIXDIG_POS and MAX_FIXDIG_NEG or you could give complete user freedom by simply dropping MAX_FIXDIG_POS and MAX_FIXDIG_NEG and setting digfix = digmax. This complete freedom implies the user can avoid exponential notation if he so desires regardless of the range by using pls[xyz]ax appropriately. If the result is ugly, then he should reconsider the large first argument he is using for pls[xyz]ax or else simply use our default values. Maurice and Geoffrey, the above macros defining MAX_FIXDIG_POS and MAX_FIXDIG_NEG go back to before 1995 (!) in our code so I am wondering if you guys can remember the historical justification of this fixed style decision. In any case, would you now be willing to go along with giving users more style freedom on whether the axis labelling is done with exponential notation or not? If the answer is yes, please let me know what MAX_FIXDIG_POS and MAX_FIXDIG_NEG values you think are appropriate or whether we should ignore them and simply use digfix = digmax. Same questions for other PLplot developers here if you feel strongly about this style issue. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Maurice LeBrun -- Let
Re: [Plplot-devel] File permissions, other misc issues
On Thursday, September 24, 2009 at 14:15:27 (-0700) Alan W. Irwin writes: On 2009-09-24 21:34+0100 Andrew Ross wrote: plexit calls plend _after_ the exit handler is called, and so if the exit handler throws an exception plplot will not call plend to tidy up and free memory. Provided that you do this yourself in your handler then you _should_ be ok. Of course, we would need to check all code paths with plexit in to make sure they don't leave any locally allocated memory unfreed. I don't know whether this is the case. It has probably never been thoroughly tested since we only tend to run valgrind on the examples which are set up not to generate any errors. Sorry for entering late to this conversation. I may have missed some key piece of information earlier in the thread, but let me ask a dumb question, anyway. plexit ultimately calls exit, which AFAIK immediately exits without returning control to the routine that called the plplot library in the first place. So plexit should be reserved (and I think it normally is) for truly catastrophic errors where no means exist to recover. For that case where a castrophe is occurring anyway, why are we concerned about memory management issues? Why does plexit even bother to call plend? Shouldn't it just send a message about the castrophic error and exit? Throwing in my 2 cents, the user-specified error abort handler exist to give the calling application some flexibility in how to handle plplot errors. Since we don't know a-priori how serious those errors may be, it's basically up to the user/application to decide how to proceed. If you want to override the default plplot behavior, simply have the user-supplied handler never return control to plplot. One could throw up an error dialog describing the nature of the problem, at which the user could take appropriate action. As has been pointed out in this thread, simply exiting could result in loss of a substantial amount of state. That said, continuing happily along from that point may not be a good idea. Who knows what memory has been leaked, what internal corruption may have occurred, etc. I generally assume that if the code is too confused to continue, a segfault may be looming right around the corner, and it's best to save your data fix/avoid whatever issue (bad inputs, experimental feature, etc) caused the problem to begin with. Or, you may get away with lots of these sorts of events if they're innocuous enough. In which case you've got to ask yourself one question: Do I feel lucky? ;) -- Maurice LeBrun -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] #define PLD_* questions
Yeah, I have no recollection why either, but agree it was probably something like what you describe. On Friday, August 14, 2009 at 21:32:12 (+0100) Andrew Ross writes: Perhaps it was because config.h was only available on autoconf generated builds in the past. The plDevs.h version must have been useful for windows and other builds. There was a lot of duplication like this in config.h and plConfig.h which I pruned out recently as well. With cmake the distinction has gone. I can't think of any other likely reason. I'd go ahead and make the changes. Andrew On Fri, Aug 14, 2009 at 01:06:55PM -0700, Alan Irwin wrote: To Maurice and Andrew: Since the earth was cooling we seemed to have been maintaining a list of configurable #define PLD_* macros in both include/plDevs.h.cmake and config.h.cmake, and I have a question about those configurable macros. Could one of you (or anybody else here) remind me why we maintain two duplicate lists? Ideally, I would like to get rid of all the #cmakedefine PLD_* configurables in config.h.cmake, and use #include plDevs.h where needed (e.g., in the small fraction of files in drivers/* that do not include plDevs.h now.) Comments on that possible change would be appreciated. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Maurice LeBrun -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Default cmap1 depends on background colour
On Thursday, July 9, 2009 at 23:35:51 (-0700) Alan W. Irwin writes: For your information there is a peculiar but designed interaction between the background colour and _default_ cmap1. If you run example 16 with the background set to a light-coloured value, e.g., c/x16c -dev psc -o test.ps -bg f or c/x16c -dev psc -o test.ps -cmap0 cmap1_black_on_white.pal you get very different default cmap1 values than if you run with a black background colour. The result is independent of device driver. I originally thought this was some horrible bug, but it turns out the vertex logic used to set the _default_ cmap1 depends on the mean background colour by design. I wasted a lot of time on this today (including a binary search to discover that the effect was not there for -bg 7f7f7f but was there for -bg 808080) so I thought I should mention it here so that others don't waste their time trying to track down this bug. Sorry this was never documented except in code. The idea here is that when switching from a black background (such as I typically use for interactive plotting) to a white background good for paper, cmap1's that are meant to fade to background at some point must necessarily change. -- Maurice LeBrun -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] cmap0.pal and cmap1.pal support
On Wednesday, July 8, 2009 at 11:23:23 (+0100) Andrew Ross writes: 2) When I tried to create a .pal file I realised that the current file format assumes that the position value is an integer in the range 0-100, whereas plplot actually uses a PLFLT in the range 0-1. This might not be significant for most purposes, but for example I sometimes use continuous colour scales with a narrow band of values picked out in a different colour, either for emphasis or for ensuring that values around zero are white. The resolution offered by the .pal files might not be sufficient and I would rather not saddle us with something now that might cause problems later on. I think the original reason was that tk provided poor float support. Let's not saddle the rest of plplot with that. Indeed. At the time that was written TK scale widgets only supported integer values, so I used integers in the 0-100 range for simplicity. It should really be floating point however. And TK scale widgets apparently support that now so in principle the TK support could be made compatible with the new format file. -- Maurice LeBrun -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plConfig.h and HAVE_* macros
I agree the HAVE_* macros are a problem wrt the global namespace. Some of the example programs use them, however, which needs to be taken into account. I like the idea of just making them more plplot-specific (as has been done for PL_HAVE_USLEEP). -- Maurice LeBrun -- ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] cmake troubles, user error?
On Thursday, April 30, 2009 at 10:07:26 (+0100) Andrew Ross writes: I think I have convinced myself that XInitThreads is needed for the Tk case since we don't control all the Xlib calls. A quick web search suggests our symptoms are probably a result of Xlib calls being made before XInitThreads is called. I tried Maurice's suggestion, but this does not help. It is still not early enough. Adding a call to XInitThreads into the start of tkMain.c does solve the problem though. The additional call in xwin.c does not seem to be a problem. This leaves the basic xwin code unchanged and only affects the tk code, so I am happy to commit this ahead of the release and to re-enable HAVE_PTHREAD by default. Sounds good. -- Maurice LeBrun -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Time to bump version to 5.9.3 in svn?
On Thursday, April 30, 2009 at 19:48:40 (+0100) Andrew Ross writes: I quite like your idea of something like 5.9.2+ though as it is simple. Just wanted to point out a potential downside.. if anyone does version number parsing expects numeric fields throughout, their code will likely barf on this. What I do for a different project is call the non-released code master (or head) and then the version number parser checks for that special string first before assuming it's a released version doing the numeric parsing. -- Maurice LeBrun -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] cmake troubles, user error?
On Wednesday, April 29, 2009 at 21:58:03 (+0100) Andrew Ross writes: Further testing has shown that I can get rid of the segmentation fault by removing the call to XInitThreads in the OpenXwin function in xwin.c. According to the Xlib documentation: The XInitThreads() function initializes Xlib support for concurrent threads. This function must be the first Xlib function a multi-threaded program calls, and it must complete before any other Xlib call is made. This function returns a nonzero status if initialization was successful; otherwise, it returns zero. On systems that do not support threads, this function always returns zero. It is only necessary to call this function if multiple threads might use Xlib concurrently. If all calls to Xlib functions are protected by some other access mechanism (for example, a mutual exclusion lock in a toolkit or through explicit client programming), Xlib thread initialization is not required. It is recommended that single-threaded programs not call this function. .. In particular, with the tk support there may be other Xlib calls elsewhere which are not protected. It is also probable that XInitThreads is not actually the first Xlib call in this case. It is not. In plframe.c the window is created by: new = Tk_CreateWindowFromPath(interp, Tk_MainWindow(interp), argv[1], (char *) NULL); which ultimately terminates in a call to XCreateWindow(). From the Tk generic/tkWindow.c -- * tkWindow.c -- * * This file provides basic window-manipulation procedures, * which are equivalent to procedures in Xlib (and even * invoke them) but also maintain the local Tk_Window * structure. The partial initialization of the xwin driver the plframe widget does after that may not require the window to actually already exist -- I don't see any explicit dependence, although it's been too long for me to remember if I ever tried doing the two ops in reverse order. You might want to give this a try. I.e. move the code /* Partially initialize X driver. */ pllib_init(); plsdev(xwin); pllib_devinit(); plP_esc(PLESC_DEVINIT, NULL); above the call to Tk_CreateWindowFromPath(). -- Maurice LeBrun -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Is it time to retire the gd and gcw device drivers?
On Tuesday, April 21, 2009 at 23:05:34 (-0500) Geoffrey Furnish writes: ... My own experience might be summarized as life in a ginormous corporation. As Linux pushes into large enterprises, companies/corporations wind up spinning up ginormous (read bureacratic/slow) IT organizations which seek standardization as they roll out server farms with gobs and gobs of cpus, and even attempting to provide worldwide multi-site synchronization of the software environment (the stack) across this huge expanse of computing hardware. One hint: They don't use Debian etch, or Gentoo, etc. They use Red Hat Enterprise Linux, and I don't mean 5.3. Right now I am staring at the most computing horsepower I've seen since I left the US national labs, and it's all been recently upgraded (cough cough) to the amazingly modern Linux distro known as Red Hat Enterprise Linux (drum roll) ... 4. There are rumors of a skunk works RHEL5 eval study. I figure it will see the light of day in 3 years at the earliest. These are excellent points. I too work for a ginormous corporation for which RHEL4 represents state-of-the-art tech. And have similar doubts that will change for a couple years at least. So the legacy png driver will remain very useful to me my team for some time to come. -- Maurice LeBrun -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] text handling proposal
On Tuesday, March 24, 2009 at 22:49:08 (-0400) Hazen Babcock writes: Even though no one objected to adding 4 new functions to the dispatch table, I'm thinking that is probably not the best way after all. Instead I think the best way to do this is to add some new PLESC cases, something like: PLESC_BEGIN_TEXT PLESC_TEXT_CHAR PLESC_CONTROL_CHAR PLESC_END_TEXT Drivers can then chose whether they want to get all the text at once via PLESC_HAS_TEXT, or broken out character by character by PLplot core via the above. Thank you. I just got around to reading this thread and was about to say something about this point but you fixed it before I could. :) Having gone through the painful exercise of adding new driver calls several times in the past, I can definitively say it's best avoided through using the escape function if possible. -- Maurice LeBrun -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] using plplot for interactive financial graphs?
On Tuesday, February 3, 2009 at 17:34:02 (+0100) Vadim Zeitlin writes: Thanks for your answer and advice! I've started looking into actually doing something like this and realized that there is actually a third potential problem: is it possible to provide the plot data on demand with PLplot? E.g. with these financial plots you may have data for some market price from 1990 to 2008 with the resolution of one day. Usually the user of the application would just look at some small subrange of this interval, e.g. a couple of last months but I'd like to allow zooming and panning the graph to show more (or less) values and would like to avoid creating all the plot points unnecessarily and only do it when they're about to be shown. Would you have any idea about how could this be done? Dunno about wx, but with TK you can easily hijack the default key/mouse handlers with those of your own choosing. In addition the TK bindings have a plw::set_zoom_handler proc so that you can reuse some of the native zoom logic. By doing your own key/mouse handling, there's no limit to the kinds of special effects you can mix in, including selective plotting of data as you mention. So one can imagine a tool that models zillions of plot elements, each of which only become visible once zoomed to a sufficiently high resolution. This gets around the limitations of the 16-bit driver interface (regarding accuracy at high zoom levels) and performance implications of plotting enormous quantities of sub-pixel-resolution (therefore redundant) plot elements. -- Maurice LeBrun -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] So blindingly obvious ... (Was: Example 13)
On Wednesday, January 7, 2009 at 06:23:06 (+0100) Arjen Markus writes: On 2009-01-05 10:33+0100 Arjen Markus wrote: Now, there are still the strange deviations in example 11. I am not sure how to proceed here - probably the same stubbornness as for example 20 is required :). It turned out to be easier than that: the cause was the same as before but in a different part of the bindings. I changed the format for returning the minimum and maximum in the matrix extension to %.17g to guarantee a lossless conversion of the floating point number to a string and that did the trick. So, I reckon the Tcl examples now all give a perfect match (at least with Tcl 8.5), only example 19 is still missing. Great to hear. -- Maurice LeBrun -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Adding example 14 to standard tests
On Tuesday, January 6, 2009 at 21:02:06 (+0100) Werner Smekal writes: Hi Andrew and Alan, Would it be straightforward to implement a -stream command-line option that means all subsequent options refer to the specified stream number? That would provide an elegant solution to the example 14 issue with, e.g., c/x14c -dev psc -o x14ac.psc -stream 1 -dev psc -o x14bc.psc Or how about anything before the option could be applied to all streams, options after a -stream command only apply to that stream, unless another -stream option is encountered. Each stream can then call plparseopts and only extract the commands meant for it. Default would be the current behaviour. A stream can then decide whether or not it wants to use command line options. The only down side of this is that the (currently internal) stream numbers are exposed to the user. I think you provide a solution for only one specific example. Before we do that we should think about if this is a common case which is often used (which I don't think). Also it is very easy to do that inside the program, e.g. before we parse the command line options, make a copy of them and then parse the copy for the new stream. Personally I think 95% of the time PLplot is used only a single stream is used. I you use a second stream you most likely use it to use a different driver (e.g. to save a png), where different options apply. I actually want to say, that when I had a look at the command line options parsing code I obtained the opinion that it is a lot of work to make changes to this code (bugfree), so it is not worth it, since there are a lot of other things to do and since it works at the moment and it is transparent how it works (although maybe not well documented ;) we should just keep it as it is. I also had big troubles, since due to a bug driver specific options propagated to different streams (with different drivers) which lead to crashes which were not easy to understand. Maybe that is the reason why I'm against changes ;) Regards, Werner I've been watching this thread and mulling the issue over. Fortunately Werner jumped in with an argument very similar to one I might have made. The arg parsing part of PLplot was indeed a substantial project. It seemed a bit of overkill at the time, but at the same time I didn't see what part of it I could comfortably leave out. I've come up with a few wish-list items for it over the years but nothing major. So in my opinion, serious modification should be undertaken only with a measure of certainty that it's really needed. I did consider the issue of initialization of separate streams, but the issue is still as murky now as it was then. What does the application intend to do with those extra streams? And if this behavior is so application-dependent, shouldn't it be controlled from the application writer directly? The way options are supported now is clear unambiguous. If there were a clear demand for command line args with multiple stream support, or if it were easy to do, or preferably both :), I'd say sure. But I don't think supporting x14 in the test suite qualifies. As it is, x14 was created to be a demonstration of something cool you could do with multiple streams in an interactive environment, that's all. One can go much farther down that path as an application writer. But the farther down that path you go, the more likely you are to be handling configuration changes via GUI input, config files, or X resources, rather than supporting a massive command line syntax. -- Maurice LeBrun -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plgvpw (view port limits) initial patch
On Friday, October 10, 2008 at 09:10:59 (-0400) Hezekiah M. Carty writes: On Fri, Oct 10, 2008 at 12:09 AM, Maurice LeBrun [EMAIL PROTECTED] wrote: What do you think of this as a compromise? Nothing has to be propagated to other language bindings, and the plgvpw functionality becomes (I think) more intuitive. I have to admit to being a little bothered by this change. The plP_gvpw private function is a good way to shield internal workings from this change, but begs the larger question: what should plgvpw() actually return? I can see three classes of opinion on the topic: 1. plgvpw() MUST return exactly what I specified in plwind() 2. plgvpw() MUST return exactly what the plot library's actually using 3. either is good enough There are good arguments for both 1 2. (2) is what we're using now, moving to (1) is the proposal. The people in category (1) could reverse the delta easily enough, as long as it was documented didn't change. The people in category (2) could do the same, on old code that's long since been forgotten about. The vast majority in (3) will never notice. As a user, I'm in category (3), and don't *really* care either way. But be aware you are introducing a change that has the potential to change existing code behavior. Maurice, Thank you for your feedback on this. My extra argument for position (1) is that, for some viewport dimensions, the delta is not cleanly reversible due to floating point rounding errors. Adding the delta to get the (2) case does not have this floating point rounding problem so the values for (2) are always retrievable if the values from (1) are still available. Ah.. right. OK, seems a good enough reason to proceed with (1). The proposal is certainly a change to plgvpw's prior behavior. But being able to retrieve the case (1) information from PLplot is, I think, quite important as it relieves the user from having to track this information which leaves less for the user to keep track of on their own, and hopefully less room for user error. It will also make adding new PLplot-related functions (such as legends or interactions with external Cairo surfaces) much cleaner since these functions can retrieve the user-provided information directly from PLplot. If it is too close to the 5.9.1 release to consider a change like this, perhaps it could be reconsidered after 5.9.1 is released? Maybe better to do it now, so that the issue is still fresh in case any issues arise. -- Maurice LeBrun - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plgvpw (view port limits) initial patch
On Monday, September 29, 2008 at 16:27:56 (-0400) Hezekiah M. Carty writes: Would it be possible to add an internal function, not exposed in the official API, which applies the transform itself, while keeping the actual plsc-vpw* values unaltered from what the user provides? Looking through the src/ directory, all of the instances of vpwxmi, vpwxma, vpwymi, vpwyma are values from plgvpw with the exception of plwind.c, which is where they are set initially. I am not sure of the proper naming convention, but perhaps a function named something like plP_gvpw could be added to the internal PLplot API which adds the offsets to the viewport limits, but leaves the internal representation unchanged from what the user provides. Then this internal function could continue to provide what plgvpw currently does, and plgvpw could return the original user-provided limits. I have attached two potential patches to make such a change. They both add a plP_gvpw function, exported through plplotP.h but not plplot.h. The first (plP_gvpw-full.patch) replaces all internal (src/*) calls to plgvpw with plP_gvpw. The second (plP_gvpw-partial.patch) has the same content, except that the plgvpw - plP_gvpw replacement was only done in the label_box function in plbox.c because that seems to be the only place where it is needed. Only one of these patches should be applied if this proposal is accepted. I am fairly certain that the above patches address all of the vpw* variables in the PLplot source code. I looked at each occurrence of vpwmi and they are all results of calls to plgvpw (or, after the above patch(es), plP_gvpw). The function plgvpw is not used in any of the examples. What do you think of this as a compromise? Nothing has to be propagated to other language bindings, and the plgvpw functionality becomes (I think) more intuitive. I have to admit to being a little bothered by this change. The plP_gvpw private function is a good way to shield internal workings from this change, but begs the larger question: what should plgvpw() actually return? I can see three classes of opinion on the topic: 1. plgvpw() MUST return exactly what I specified in plwind() 2. plgvpw() MUST return exactly what the plot library's actually using 3. either is good enough There are good arguments for both 1 2. (2) is what we're using now, moving to (1) is the proposal. The people in category (1) could reverse the delta easily enough, as long as it was documented didn't change. The people in category (2) could do the same, on old code that's long since been forgotten about. The vast majority in (3) will never notice. As a user, I'm in category (3), and don't *really* care either way. But be aware you are introducing a change that has the potential to change existing code behavior. -- Maurice LeBrun - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] src/README.pages
On Thursday, October 9, 2008 at 23:42:11 (-0500) Maurice LeBrun writes: On Saturday, October 4, 2008 at 16:46:53 (-0700) Alan W. Irwin writes: On 2008-10-04 14:04-0700 Alan W. Irwin wrote: Hi Maurice: I have just committed my first attempt (see src/README.pages) to annotate all the code fragments in our source code that affect paging and familying. Could you please give this a critical read? I am especially interested in the open question of whether plsc-page_status should be set to DRAWING (or perhaps a new status?) for plP_state, and plP_esc. I guess the question turns on why DRAWING is set at all for most plotting operations. If there is some purpose to that, then my own view is the DRAWING status should also be set for at least plP_esc (which usually draws something), and perhaps plP_state as well (which AFAIK does not draw, but usually the result is status information gets written to files for file-oriented devices). To give you some background... [...]Anyhow, my plan is to deal with the repeat pladv(0) case, and once that simple test case produces valid empty page files (like it should), see whether that fix solves the example 23 issues. I made the empty-page fix, and indeed that fixed the example 23 issue for the pages which consisted just of text (see my recent post on the svg status). However, in my view those text-only pages (done with plP_esc(PLESC_HAS_TEXT...) should have set the DRAWING status if that status is to be meaningful at all. What do you think about setting the DRAWING status generally for both plP_esc and plP_state? That should be ok. The main thing to worry about are the AT_BOP and AT_EOP values, so the pagination commands don't get confused. Be aware there may be some situations where you set state to DRAWING when you are actually between pages, but that shouldn't affect anything. I may have originally had more plans for DRAWING but now I forget. I read through your doc, it looks good except the warning not to mix pladv() and plbop/pleop is perhaps a bit too strong. One of the reasons for putting these flags in was in fact to lessen the headache of mixing these. I actually can't stand using pladv() or plenv() for pagination -- I always use plbop/pleop. Seems much more well defined that way. pladv(0) is the carriage return of printing pages (Where's the carriage? Does it come with horses and a princess? :) But by keeping AT_BOP and AT_EOP status flags, throwing in an extra plbop() or an extra pleop() when you're not sure if you've advanced to the next page never hurts. To be clear, the latter statement means a primary goal of AT_BOP and AT_EOP was to suppress empty pages that crept into the plotting session by mistake or sloppy programming. That's not been changed overall, correct? -- Maurice LeBrun - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Interestingly, the following article on SVG editors just appeared on linuxtoday.com today. http://www.linux.com/feature/148630 -- Maurice LeBrun - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't eliminate legend string problem in Ada example 17
On Thursday, August 14, 2008 at 03:29:28 (-0700) Jerry writes: Just a note that I can't seem to fix the problem in Ada example 17 (stripchart demo) wherein all of the legend strings appear on the plot identical to the fourth one. I've tried a lot of things and at this point I'm afraid it will have to be a known issue. The crux is matching e.g. this declaration in x17c.c: const char *legline[4]. I suppose this is a pointer to a four-element array of pointers to char which are to be interpreted as strings, probably with null terminators. (How does one know for sure?) This concept is reinforced by the documentation on plstripc. This is the current structure in the Ada bindings--a four-element array of pointers to null-terminated strings. That is the correct interpretation. I don't understand what the const in the above declaration does. I would think that it would cause the declared thing to be read-only, acquiring its values in the declaration itself, but it is in fact assigned to later in the program. For C C++, a const pointer means the memory it points to cannot be altered. The pointer can. So for example const char *foo = bar; (or later reassignment) is perfectly legit. -- Maurice LeBrun - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Can't eliminate legend string problem in Ada example 17
On Thursday, August 14, 2008 at 10:18:32 (-0700) Alan W. Irwin writes: On 2008-08-14 09:58-0500 Maurice LeBrun wrote: For C C++, a const pointer means the memory it points to cannot be altered. The pointer can. So for example const char *foo = bar; (or later reassignment) is perfectly legit. After years of dabbling at C, this pointer stuff still makes my head spin so could you expand a bit more, Maurice? What actually happens with the above statement? After the declaration of foo as a pointer to a const char is foo initialized as a pointer to the first character in the const bar string? Correct. Or would a better way to look at it be that all character strings like bar can be interpreted as pointers so the above is simply a pointer assignment? This too is correct. All string literals in a program are stored in the executable, as a `strings program` will demonstrate. The proper way to refer to these is via a const char* since they are considered fixed. If you want a char* string that's modifiable, you need to define a character buffer and copy a string into it. Whenever unsure, just construct a simple test and try it (I keep several handy for that purpose). For example, what if you assign a literal to a char* and then try to modify it? char *foo = 0; foo[0] = 1; then gcc complains: tst.cc: In function ‘int main(int, char**)’: tst.cc:15: error: invalid conversion from ‘const char*’ to ‘char’ because apparently it's smart enough to know that even tho foo is defined as char*, it's actually pointing to a const char*. I'm no language lawyer, but it would seem that this syntax is supported for legacy reasons. Is this a good example of the later reassignment you referred to? *foo = whatever; or would it be foo = whatever; ? The latter. *foo gives you what foo is pointing at. E.g. char *foo = 0123; char single = *foo; or char single = foo[0]; then single == '0'. It helps to remember that *foo and foo[0] mean exactly the same thing. The first seems consistent with the mnemonic for the declaration, but I am virtually positive the latter is correct instead since *foo would refer to the first read-only character in bar which would make no sense for an assignment. Right, since you are assigning to a pointer. If you assign to a char, you're ok. Thanks in advance for trying to deal with my confusion on these issues. I guess the start of my confusion all these years has been what I consider to be a rather illogical mnemonic for pointer declarations using the dereferencing operator. I guess I just got off on the wrong foot with C pointers and have never recovered. :-) :) It's a little wierd coming from a Fortran environment, for sure. But good stuff to know. -- Maurice LeBrun - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] New website
Looks extremely nice, very professional. On Friday, July 25, 2008 at 14:18:51 (+0200) Werner Smekal writes: Hi list, we created a new website, based on php scripts, css and a little javascript. You can view the result here: http://plplot.sf.net/index_new.php I would like everybody who is interested to visit the new homepage and tell us how you like it, if there are any spelling mistakes, layout problems, missing content and features, bad links. I'm still working on: * make the examples page complete: Fortran77, Ada and Ocaml examples are missing * Development page is still without content * css has still one validating error * file size not correctly displayed in the Documentation page The old homepage is still the current one, but we intend to replace the old with the new one within two weeks. The old one will then still be reachable, but will be removed after some months. Thanks, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: [EMAIL PROTECTED] web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Maurice LeBrun - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Uniform indentation style for our docbook files
On Monday, June 2, 2008 at 20:04:43 (-0700) Alan W. Irwin writes: With some encouragement from Andrew and because I need it for an external xml project, I have tried out emacs for the first time and really like it. Part of that liking is due to the fact that I was using my previous jed editor in emacs emulation/edt emulation mode for all these years and all the basic commands turn out to be the same once I load the edt emulation mode for emacs. (Yep, that's the vax edt editor from the 70's which had a lot of rabid fans including me.) Don't you mean 80's? :) I cut my teeth on VMS too. -- Maurice LeBrun - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] [Perldl] PLPlot -- how to install?
On Friday, April 18, 2008 at 02:02:22 (-0700) Jerry writes: As a Mac user since 1984 I sympathize with Craig's frustration with installing PLplot. Neither of the two normal installation methods is supported: a single drag-and-drop or a package installer. Reading the PLplot installation wiki is probably enough to drive away most Mac users who are considering using PLplot. The good news with OS X is we gain access to an enormous body of software; the bad news is that it is hard to install. But here's more good news: PLplot is supported on MacPorts, www.macports.org. (It is also on Fink, http://www.finkproject.org/, but the version is a little out of date. People seem to prefer MacPorts over Fink anyway.) I haven't tried the MacPorts installation method but I think it should go well. If you don't like messing with the command line, get PortAuthority ($) or Porticus (free). I think you should try it and let us know how it goes. (The MacPorts maintainer is not one of the PLplot developers.) As a plplot developer since 1990, I sympathize with your problems. My involvement started as a personal project to free myself of commercial graphics packages on high performance computing platforms running some variant of Unix. The interest in it grew much faster than the few people supporting it could commit to (basically myself and Geoffrey Furnish at the time). Our initial calls for help supporting the package on multiple platforms in the 1994-1995 timeframe went essentially unanswered. Fortunately, between the license adopted (LGPL) and the intervention of some dedicated developers (Alan Rafael), a true core team eventually emerged. The core team has now expanded considerably. It now belongs to everyone, and is actively maintained. That makes it a success in my book, compared to all the open source projects that eventually wither and die. So, cheers on our success. The rest is up to us all. -- Maurice LeBrun - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Making PLXcairoDrawableInfo structure public
On Wednesday, April 9, 2008 at 09:27:32 (+0930) Jonathan Woithe writes:
Currently the PLXcairoDrawableInfo structure used to pass an external X
drawable in to the xcairo driver is private to cairo.h. This means that
anyone using this feature must define their own structure to do this which
opens up the possibility that they could get the field ordering wrong. It
also makes it much harder for us to update the structure in future if this
were ever an issue since it would force all users of external X drawables
to find their structure definitions and change them. If an error were made
the compiler would not pick it up and this could lead to some very odd
symptoms.
The patch below (against svn rev 8364) addresses this by moving the
definition of PLXcairoDrawableInfo from drivers/cairo.c into
include/plplot.h. It is still protected by the PLD_xcairo so at least in
theory its presence should not cause any trouble when plplot is compiled on
a system without X windows. However, I do not profess to be an expert in
this area so I'll defer to the judgement of others. Is this a reasonable
solution to the problem?
Even if this particular solution is not adopted I think we need to come up
with some way of making PLXcairoDrawableInfo visible to users.
Here's the proposed code to be added to plplot.h:
+/*
+ * Structure for passing external drawables to xcairo devices via
+ * the PLESC_DEVINIT escape function.
+ */
+#if defined(PLD_xcairo)
+#include X11/X.h
+#include X11/Xlib.h
+typedef struct {
+ Display *display;
+ Drawable drawable;
+} PLXcairoDrawableInfo;
+#endif
We've managed to keep X11 and other driver-specific headers out of plplot.h
for a long time, and I hesitate to start now. Although a particular
plplot distribution may have PLD_xcairo defined, that doesn't mean the user
has any need for it. In which case you are sucking in a lot of unnecessary
stuff to all user code that includes plplot.h.
So I'd prefer an alternate solution, something along the lines of one of:
1. Given that this kind of capability may be useful and/or desired for more
than one driver, generalize the concept. The pointer could be a (void *),
easy enough. The Drawable on my system resolves to:
X.h:typedef XID Drawable;
Xdefs.h:typedef unsigned long XID;
so an unsigned long would do the trick. Then cast accordingly in the
driver.
This approach has been generally followed in the past with colors, input
events, event handlers, etc. But it can be tricky.
2. Give up on the idea of genericity for everything and go with a separate
X-windows specific plplot include file, e.g. plplotX.h. This is tempting
since you could add as many convenient definitions as you wished. I've
almost done this on several occasions. But resisted the temptation since
I thought the generic solution was a better way to go, when practical.
--
Maurice LeBrun
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] bad plplotd.pc on *ubuntu gutsy
Am trying to update my environment to all the latest stuff. Unfortunately I'm
getting an illegal link line entry when I build:
$ cat pkgcfg/plplotd.pc
libdir=/home/mjl/tools_tcl8.4.18/lib
includedir=/home/mjl/tools_tcl8.4.18/include/plplot
drvdir=/home/mjl/tools_tcl8.4.18/lib/plplot5.9.0/driversd
Name: PLplot
Description: Scientific plotting library (double precision)
Requires:
Version: 5.9.0
Libs: -L${libdir} -lplplotd -L/usr/lib -lSM -lICE -L/usr/lib -lX11 -L/usr/lib
-lXext -L/home/mjl/tools_tcl8.4.18/lib -ltcl -L/home/mjl/tools_tcl8.4.18/lib
-ltk -L/usr/lib -lSM -lICE -L/usr/lib -lX11 -L/usr/lib -lXext
-L/home/mjl/tools_tcl8.4.18/lib/itcl3.3 -litcl3.3
-L/home/mjl/tools_tcl8.4.18/lib/itk3.3 -litk3.3
-L/home/mjl/tools_tcl8.4.18/lib -ltcl -L/home/mjl/tools_tcl8.4.18/lib -ltk
-L/usr/lib -lSM -lICE -L/usr/lib -lX11 -L/usr/lib -lXext -l/usr/lib/libm.so
^^
-lcsirocsa -L/usr/lib -lfreetype
...
Anyone with similar experience / know how to fix this?
--
Maurice LeBrun
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] bad plplotd.pc on *ubuntu gutsy
On Friday, March 21, 2008 at 18:10:59 (-0700) Alan W. Irwin writes: On 2008-03-21 19:04-0500 Maurice LeBrun wrote: -L/usr/lib -lSM -lICE -L/usr/lib -lX11 -L/usr/lib -lXext -l/usr/lib/libm.so ^^ -lcsirocsa -L/usr/lib -lfreetype ... Anyone [...]know how to fix this? That is a bug that was introduced by my recent MATH_LIB change. It is now fixed (revision 8310). Sorry I didn't spot that myself. Thanks, that did the trick. -- Maurice LeBrun - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] plimagefr coordinate transform support - complete
On Wednesday, March 19, 2008 at 10:14:30 (-0700) Alan W. Irwin writes: On 2008-03-19 10:59-0400 Hezekiah M. Carty wrote: To sum up, I would like to submit patches in the follow steps: (1) Add coordinate transform to plimagefr and disable the dev_fastimg rendering path, but without removing the dev_fastimg code. (2) Update dev_fastimg to work with the updated plimagefr, but only use it for non-transformed images. (3) Update example 20 with some examples of what plimagefr can do, with pages to illustrate both fixed color ranges and coordinate transformations. Does this sound like a reasonable compromise? Hi Hez: Actually after sleeping on it, I am leaning toward saying do (1) (with code commentary where you do the disabling in plimage.c, xwin.c, etc., about why it was necessary) and leave (2) as a would-be-nice rather than a requirement since it sounds like it might be a lot of work which you could more productively spend on the OCaml bindings, for example. However, I don't feel right making this decision alone because I haven't used -dev xwin or the plimage capability for my own PLplot needs, and somebody who has more of a vested interest in those parts of PLplot may feel a lot stronger about their speed than I do. Thus, I am going to need advice/help from the other PLplot core developers on the decision about (1) and (2) so please step forward, guys, and comment. I use -dev xwin extensively (and its client, plframe) but not plimage. That said, doing (1) and leaving/documenting (2) as a nice-to-have sounds fine to me, unless someone can make a case otherwise. Ideally someone would play with dev_fastimg vs !dev_fastimg and see if there's a noticeable difference on mondern hardware. I'm sure many here have seen hardware advances make irrelevant some optimizations done previously, or at least mitigate performance concerns. For example, the X driver was first developed on 8-bit r/w color displays and sharing a single r/w colormap was the norm. If this didn't suffice for the application, a custom colormap could be used (which I never liked very much). Seems so quaint now. :) But when I went to 16 or 24 bit r/o colormaps on a Linux box years later, the performance degradation of swapping out colors really didn't seem to matter much. One of these days I'd like to give the xwin driver a bit of housecleaning, starting with chopping out the custom colormap support that was never really used anyway. -- Maurice LeBrun - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl 8.5
On Tuesday, January 8, 2008 at 16:11:13 (-0800) Alan W. Irwin writes: Maurice, there is a question at the end for you about the current status of itcl. .. N.B. itcl is not compatible with Tcl 8.5, and is probably going to be a problem for all future versions of Tcl because it appears not to be maintained any more. I hope that's not the case. Last time there was an itcl-breaking Tcl release, there was a subsequent itcl update to fix everything IIRC. So while it might not be an active project in the conventional sense, that doesn't mean someone won't step in to fix it to work with the latest Tcl. http://sourceforge.net/project/showfiles.php?group_id=13244 shows the last itcl release was a release candidate (!) done almost thre years ago. From the itcl FAQ, itcl is not a pure Tcl extension; it has to patch the Tcl core. Debian testing package dependencies show the latest itcl package depends on the tcl 8.4 package and is inconsistent with tcl 8.5. That FAQ entry sounds old. True at one time, but currently AFAIK itcl does represent a pure extension. Once namespaces some other needed core Tcl support was added ages ago, the need to patch Tcl went away. Again, this is all by memory so YMMV. So my strong advice is to disable itcl and itk if you are going to try Tcl/Tk 8.5. Orion, interference from itcl may be the cause of your ctest time troubles with Tcl 8.5. Maurice, I would appreciate your further comments on the itcl situation. Is it not compatible with tcl 8.5 because that version of Tcl uses its own OO approach or is OO not going to be available at all for the Tcl future unless somebody starts actively supporting itcl? I'll take a look but it might not be this week. -- Maurice LeBrun - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] First pngcairo results for my FreeEOS research
Alan W. Irwin writes: I suggest you have a look at http://freeeos.sourceforge.net/alternate_paper_figures/eff_fit_fig3.png to give you a taste of what is possible with pngcairo. For this result, I am using the default text and graphics antialiasing provided by libcairo. It turns out the graphics antialiasing causes the 3D figure to be translucent, but I am happy with that side effect since I think it looks cool. Nice. -- Maurice LeBrun - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] color alpha? Was Re: First pngcairo results for my FreeEOS research
Hazen Babcock writes: This reminds me that many graphics drivers these days support a color alpha (or translucency value) as well the standard red, green and blue. Any thoughts on extending PLplot to support this? It could be as simple as adding a alpha value to the PLStream data structure, which the user could set with say plsalpha, and which would be used or ignored by the graphics driver as appropriate. I've been interested in translucency for awhile now, but completely unable to find time to look into it. I'd avoid a plsalpha for the same reason that I deprecated plrgb() -- it's a whole lot nicer to set up a set of standard colors and calls to manipulate them. So I would prefer that if we were to support translucency in the core, every color have a translucency attribute (defaulting to none, i.e. the way it is now). Of course we'd need a bunch of new API calls for setting color values, maybe take the existing ones and add on a x (for extended), that allowed the user to specify RGB + translucency. Any other attributes needed? -- Maurice LeBrun - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] What to do about plmeta/plrender?
Alan W. Irwin writes: Hi Maurice, I still haven't seen your original post to plplot-general, Yeah, I need to figure out why my post was blocked: X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=addgroup_id=1atid=21 1.0 FORGED_RCVD_HELO Received: contains a forged HELO I can post to plplot-devel just fine, so there must be some subtle difference in the mailing list settings. Will look into it. but from the quoted version of it it appears you confirm the -a option problem as a long-term one for plmeta/plrender. Right. Probably not too hard to fix, but as mentioned it's difficult to find motivation / time since I don't really use it any more. On top of that long-known issue, I also found the additional serious plmeta/plrender problem with fonts this morning. Yup. From this evidence it appears plmeta/plrender is not keeping up, and the question I want to discuss is what should we do about that. The options I see are as follows: (1) Fix the issues with the current low-level version of -dev plmeta/plrender. However, nobody has stepped forward to do this, and the track record appears to be poor for keeping this combination maintained. (2) Issue some sort of warning message with -dev plmeta that some options (such as -a and decent fonts) are closed off forever by using this device. (3) write a high-level replacement of plmeta/plrender that doesn't require so much maintenance. The idea would be to store all the plplot commands and their arguments in a plmeta file and have plrender read back this file and run the given commands with the exact given arguments. If I recall correctly, the current plmeta does not save exact arguments so that, e.g., plrender using -dev plmeta does not give the same output as the input. When this issue was discussed years ago, I think the reason given was something to do with size of result/bandwidth. So if we move to saving exact arguments (e.g., 64-bit floating-point arrays if that is the input) there may be a bandwidth issue. OTOH, bandwidth issues are not quite as important as they used to be. Furthermore, plmeta has had a long and honorable history, and it certainly does have some appeal to store your results now as a plmeta file and have access to all PLplot improvements (e.g. better fonts) from then on. So taking this high-level approach might be worthwhile (assuming we can find a volunteer to programme it). Note one can gradually add higher level capabilities to the existing metafile and renderer. That was my long term plan to keep it current, starting with strings approach (I still have that code around). A bite-sized approach to improving it may fit better with available time for development than a rewrite from scratch. One big problem is that plplot was designed since day 1 centered around a physical description of the output device. So abstracting out the higher level view while retaining the ability to exactly reproduce the physical device plot has always been a challenge. Unfortunately a long time has elapsed since I studied these issues in detail, so my memory is fuzzy on the issues involved (although I do remember it made my head hurt :). (4) Give up on this whole approach by officially deprecating plmeta/plrender now with the view of removing it later (say just after the forthcoming stable release). I was quite dismayed this morning to discover the -a issue with plmeta, but obviously it doesn't affect that many users since apparently this limitation has been with us from the first with very few complaints about it. However, I believe the lack of access to modern fonts is a much more serious issue since it leaves such a bad impression of PLplot capabilities. Thus, regardless of the decision about which of the above options we decide to take, we should change the default option for plmeta to off so that users would have to specifically enable it. Maurice, do you agree with at least this step? It could be seen as the start to (4) or else as a temporary measure until one of the other options is taken. I can see marking them as unmaintained and not building either by default, as long as there's an easy way to include them in the build again. Removal seems a drastic step for now. Priorities change, and who knows what will be important again in a few years. -- Maurice LeBrun - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Plplot-devel mailing list Plplot-devel
Re: [Plplot-devel] Cairo Driver Family
(trying to catch up on email) Alan W. Irwin writes: Once -ori 0, -ori 1, -ori 2, etc., work, then for fun try -ori 0.3 (i.e., non-integer -ori values). You will find a long-standing PLplot bug for that case which doesn't give correct plotted results (the rectangular viewport gets sheared into a parallogram) for non-integer -ori values if the aspect ratio is different from unity. Since the problem disappears for a unity aspect ratio, I think the x length is being taken rather then the appropriate y length or vice versa somewhere deep in the rotation code. But nobody has ever been able to track down the incorrect logic (which is, of course, a very low priority since integer -ori values are the ones that tend to be used). Right. When I wrote the driver interface orientation code, I originally held orientation to integer values. But then I realized, why not have some fun and make it more general. The shear problem showed up right away, and having (over) filled my capacity for fun projects at the time :), I left it at that. -- Maurice LeBrun - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Cairo-related devices and interactive capabilities of PLplot
Alan W. Irwin writes: On 2007-05-18 22:35-0400 Hazen Babcock wrote: This feature sounds pretty straightforward to add. Would we pass back the key pressed in the keysym element of the PLGraphicsIn structure? How about the Encoding, i.e. ASCII? utf8? ucs4? ... If UCS-4 is available from Cairo, that would be great since that is what we use internally for the character strings that are plotted. Furthermore, the proposed plcursor routine should translate that UCS-4 to UTF-8 for output of the key that was struck to also be consistent with the way that UTF-8 is consistently used for all the input character strings for PLplot (before they are translated immediately to our internal UCS-4 representation). What proposed plcursor routine? Of course, if we do use UCS-4 internally to represent the character struck, then we will need to extend PLGraphicsIn to store the UCS-4 representation. I understand if you append a new element (UCS-4 in this case) to PLGraphicsIn, that does not constitute a backwards-incompatible change to the API. Agreed. -- Maurice LeBrun - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] good cmake article
PLplot is mentioned too. http://dot.kde.org/1172083974/ -- Maurice LeBrun - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Tcl 8.5
Orion Poplawski writes: Could the Tcl interface folks take a look at trying to compile plplot against Tcl 8.5? It's been put into Fedore Development and plplot compile fails with: .. I may be able to look into it over the weekend. If someone beats me to it, I won't complain tho. :) -- Maurice LeBrun[EMAIL PROTECTED] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] proposed freetype changes
Arjen Markus writes: Werner Smekal wrote: Hello Andrew, Ok, sounds good. Only problem I see is, that the value of these variables will likely not be defined, since it's not cpp and I have no constructor where I can set them. And than I can't find out, what was set or not (since they may and will have any value). But I'll have a look and commit the changes if I find a solution (or if this problem doesn't exist anyway). One way to detect missing values is to initialise these variables to a known reserved value. My favourite is -999.0: - It can be represented exactly (!) in single and double precision, so no comparison problems as with -99.99 or the like - Because it is a negative value, it is much less likely to occur in (measurement) data than, say, 999.0 - It stands out: it is obviously a constructed value Great minds think alike: $ grep UNDEF include/plplotP.h #define PL_UNDEFINED -999 :) -- Maurice LeBrun - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] cmake itcl/itk
Alan W. Irwin writes: On 2007-01-09 06:27-0600 Maurice LeBrun wrote: I'm trying my first cmake build (ok feel free to rag on me for being such a laggard :), and those two were inexplicably not detected in my usual prefix area that contains all my tcl/tk/itcl/itk builds. Try setting CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH appropriately. That worked, thanks. But I'm surprised that: $(CMAKE_INSTALL_PREFIX)/include and $(CMAKE_INSTALL_PREFIX)/lib are not automatically at the front of CMAKE_INCLUDE_PATH CMAKE_LIBRARY_PATH by default. Our build systems have had that property for an eternity. Would it be hard to add? -- Maurice LeBrun[EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] cmake itcl/itk
A ghostly figure emerges from the mist.. Has anyone gotten the cmake build to auto-detect itcl itk? I'm trying my first cmake build (ok feel free to rag on me for being such a laggard :), and those two were inexplicably not detected in my usual prefix area that contains all my tcl/tk/itcl/itk builds. -- Maurice LeBrun - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Debian packages
Andrew Ross writes: Are there any debian / ubuntu developers out there who would be willing to take over maintainance of the debian packages, with our help? Might be a good idea to send this query out on plplot-general to reach a broader audience. -- Maurice LeBrun - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
