Chris - OK, so here's my elevator-speech summary of what I think needs to happen on my side for the next point release of PDL, with tentative due-dates:
1) Write a Prima tutorial with a major focus on PDL::Graphics::Prima by the end of July 2) Write a pod document with simple "mappings" of basic PGPLOT, PLplot, and GnuPlot commands to PDL::Graphics::Prima by mid-August 3) Basic docs cleanup for PDL::Graphics::Prima by September 4) Write a chapter for PDL::Book about P::G::Prima by September In addition, PDL::Graphics::Prima will get new features as I have time. I will *not* worry about actually performing the next point release (as I wipe my brow). Did I miss anything? David On Mon, Jul 16, 2012 at 6:05 AM, chm <[email protected]> wrote: > My responses are below to the various points. For clarity, > I've edited out the text not being addressed in my response. > > --Chris > > > On 7/13/2012 11:56 PM, David Mertens wrote: > >> >>> I propose the standard display graphics for >>> PDL be based on the Prima graphics toolkit >>> by Karasik et. al. and the current code for >>> PDL::Graphics::Prima by David Mertens. >>> >>> >> This endorsement means a lot. I have stated before that this has been a >> goal of my work with PDL::Graphics::Prima, and it means a lot that you >> think we should focus on this as a working default. >> > > Thanks for developing it. > > > To clarify, I am working on making PDL::Graphics::Prima flexible and >> powerful. I have even started working on a Cairo backend, which would make >> it possible to create publication-quality figures. However, gnuplot, >> PLplot, and PGPLOT are currently superior for making professional plots. >> The proposal here is to have a working mess-with-my-data plotting library. >> When it comes time to produce something for publication, we can and should >> encourage variety. >> > > Yes, this is a "Keep it Simple" graphics that can grow > in the future but the goal is to have the 90% solution > as soon as possible. > > A start would be to review the common usage >> >>> of PGPLOT, PLplot, and Gnuplot to come up with >>> a Top 10 of use cases to implement. They >>> should be *very* simple to use and have smart >>> defaults so the common case versions of the >>> Top 10 can be done in 1-line or less. :-) >>> >>> >> "Or less." Ha! >> >> I have thus far *not* focused on targeting the major use cases of these >> >> three plotting libraries, simply as a matter of time. However, if users of >> these can point me to things that these libraries do well and which >> P::G::Prima can emulate, I will be happy to do so. I will also be more >> than >> happy to say, "This feature is stolen from Other::Lib, so if you like it >> you should check out Other::Lib." >> > > The first thing is just a table of the basic functionality > and general equivalences and what the differences are. > The idea is that someone used to line $x,$y in PGPLOT > might have a similar routine that could do the same > general thing. > > > In particular, I have a function called "imag_plot". I would really like >> for that to emulate PGPLOT's imag function, but I'm not sure how it >> handles >> the contrast. Any pointers? >> > > Take a look at the source code? Per my comment above, > I think something like a linear stretch with 1% > saturation at the tails would be a good first > cut. Improvements can be made down the line. > > * The use of Prima will provide an easy >>> to use, default GUI environment for more >>> sophisticated and user friendly PDL >>> applications. >>> >>> >> In my opinion, this is a *major* win and a second major reason for my >> >> choosing Prima. I foresee that interactive data analysis will only become >> more common, so having a full GUI toolkit is far more useful than simply >> having a plotting library. (Which reminds me that I need to write a >> tutorial on this in the PDL::Graphics::Prima docs...) >> > > Docs would be good. :-) > > > All of that means that I will have a harder time justifying PDL-related >> programming at work. I still intend to do a little bit of Perl development >> at work, but it will have to be more constrained. Might I be able to lead >> the next point release? Maybe, but I can't commit to it quite yet. I think >> I know what needs to happen and how to do it, it's just a matter of having >> enough time. >> > > I was hoping you could take care of the PDL::Graphics::Prima > part, not dumping the whole release on you... > > > At any rate, I think the time is right >> >>> for this to happen and the sooner the >>> better. >>> >>> Thoughts, comments, "volunteers"? >>> >>> --Chris >>> >>> >> If we move forward with this, I foresee the following work ahead (in >> addition to any other changes such as 64-bit support, etc): >> > > I've rearrange the points in my suggested order > of priority. Again, I think the existing PDL::Graphics::Prima > covers most of the bases. What would be most valuable here is > docs/tutorial and a chapter on that in the PDL Book. > > > 2) I will need to substantially improve the documentation for >> PDL::Graphics::Prima, including one (or more) primers on Prima itself. >> > > 6) The above documentation substitutions will necessitate a number of >> additional P::G::Prima::Simple functions for those one-liners Chris was >> talking about. >> > > 5) We will need to write chapters for gnuplot and P::G::Prima. >> > > I would like to see a chapter on Gnuplot but that is not > this project. I'm hoping that it will come when the > win32 issues with the PDL::Graphics::Gnuplot are fixed > and the release is ready for prime time. > > > 4) We will need to go through the PDL::Book and replace basic examples to >> use P::G::Prima. (Obviously, the chapters on PLplot and PGPLOT will >> continue to use those libraries.) >> > > The first iteration is the chapter on PDL::Graphics::Prima > for the book. After the module is in general use, we can > address the issue of retroactive changes to doc refs. > > 1) I will need to implement a number of planned features for >> PDL::Graphics::Prima that I have been dragging out including refined axis >> tweaks (including multiple axes), both text and drawn figure annotations, >> and (based on the previous item) at least basic support for legends. (An >> important feature that *won't* get attention for this point release is the >> Cairo backend. Sad.) >> > > 3) We will need to comb through the PDL documentation and look for >> examples >> and synopses that use PGPLOT (and possibly PLplot) and replace them with >> P::G::Prima code. >> > > The goal of the Top 10 use cases was to allow you to > limit any new development to the least amount with > the most impact. This is more important if you will > be working on PDL issues outside of work time. > > > 7) Does this mean that PDL::Drawing::Prima and PDL::Graphics::Prima should >> be added to the PDL core? Or, should we simply recommend the CPAN >> distributions that are already available? (I actually prefer the latter, >> and would add PDL::Stats to the recommendation list.) >> > > Leaving it on CPAN is good for me. We just need to > ensure that the various cpan, cpanm,... tools all > a 1-click capable so the new user doesn't have > problems getting the modules. > > Per discussions from a while ago, I think a lean, > mean, core PDL with a clean way for non-core > modules to tie in to the documentation and an > existing PDL core install seamlessly would be > better than making the core PDL even bigger. > > > Notice that there isn't a lot of PDL code that needs to change here, just >> some of the docs. >> > > Yes, exactly. > > > I am on board with this proposal. I might be able to be orchestrate the >> release, but I'd appreciate if somebody else could step up here. >> > > I was hoping you would do the PDL::Graphics::Prima > stuff as I don't have time to learn Prima and > P::G::P just to be able to document it. I have > a link to a very good presentation on using > P::G::P that might give you some ideas. Now, > if I could only remember the speaker's name... :-) > > > > > > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
