Hi, Alan,
On Mar 14, 2010, at 10:29 , Alan W. Irwin wrote:
> That is revision 10869 should be the same as
> David's tree that produced his patch
I can confirm that r10869 contains all the changes from my patch.
Thanks again,
Dave
---
On Mar 13, 2010, at 16:43 , Alan W. Irwin wrote:
> I have committed this patch (revision 10864).
Thanks, Alan!!!
> Thanks, Dave, for all your work on this arbitrary storage of 2D data
> API.
You're welcome. Thanks for including it!
Dave
-
On Sun, Mar 14, 2010 at 12:29 PM, Alan W. Irwin
wrote:
> On 2010-03-14 10:06-0700 Alan W. Irwin wrote:
>
>> On 2010-03-14 09:46-0500 Hezekiah M. Carty wrote:
>>
>>> The patch or patch application to Subversion seems to be incomplete.
>>> cmake fails from a fresh source tree with this error:
>>>
>>
On 2010-03-14 10:06-0700 Alan W. Irwin wrote:
> On 2010-03-14 09:46-0500 Hezekiah M. Carty wrote:
>
>> The patch or patch application to Subversion seems to be incomplete.
>> cmake fails from a fresh source tree with this error:
>>
>> -- Configuring done
>> CMake Error in src/CMakeLists.txt:
>> C
On 2010-03-14 09:46-0500 Hezekiah M. Carty wrote:
> The patch or patch application to Subversion seems to be incomplete.
> cmake fails from a fresh source tree with this error:
>
> -- Configuring done
> CMake Error in src/CMakeLists.txt:
> Cannot find source file "plf2ops.c". Tried extensions .c
On Sat, Mar 13, 2010 at 7:43 PM, Alan W. Irwin
wrote:
> Hi Dave (with question for Andrew at the end):
>
> On 2010-03-12 16:24-0800 David MacMahon wrote:
>
>> This is a roll-up of all previous PLplot patches related to supporting
>> arbitrary storage of 2D user data. This patch is based on (and s
Hi Dave (with question for Andrew at the end):
On 2010-03-12 16:24-0800 David MacMahon wrote:
> This is a roll-up of all previous PLplot patches related to supporting
> arbitrary storage of 2D user data. This patch is based on (and should
> apply cleanly to) svn/trunk r10859.
I did some tests o
This is a roll-up of all previous PLplot patches related to supporting
arbitrary storage of 2D user data. This patch is based on (and should
apply cleanly to) svn/trunk r10859.
Adds support for arbitrary storage of 2D user data. This is very
similar to the technique employed by some existing fu
On Feb 22, 2010, at 10:37 , David MacMahon wrote:
> On Feb 22, 2010, at 6:42 , Andrew Ross wrote:
>
>> 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 s
On Feb 22, 2010, at 10:37 , David MacMahon wrote:
> The patch under discussion should maintain 100% backwards
> compatibility; any case where it doesn't is a bug!
I found a rather embarrassing oversight: it seems that I moved the
converted implementation of c_plgriddata into plfgriddata, but I
Hi, Andrew,
Thanks for your review and thoughtful comments! Here are some replies.
On Feb 22, 2010, at 6:42 , Andrew Ross wrote:
> 1) Using structures of function pointers in C is clearly the way to
> implement this, but it might give us headaches for some languages
> where
> either function
On Mon, Feb 22, 2010 at 09:37:33AM -0600, Maurice LeBrun wrote:
> 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
> > s
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,
>
On Tue, Feb 16, 2010 at 09:15:10AM +0100, Arjen Markus wrote:
> On 2010-02-16 09:07, Alan W. Irwin wrote:
> > On 2010-02-15 14:10-0500 Hazen Babcock wrote:
> >
> >> David MacMahon wrote:
> >>> Adds support for arbitrary storage of 2D user data. This is very
> >>> similar to the technique employed
On 2010-02-16 11:53-0800 David MacMahon wrote:
>> However, I strongly second Arjen's plea to at least convert
>> one example (example 16?) to using the new 2D array API directly so that
>> all
>> the issues of porting it to the various languages (including perl/PDL) can
>> be worked out.
>
> Sinc
On Feb 16, 2010, at 9:24 , Alan W. Irwin wrote:
> From the description, it sounds like the current 2D array API has been
> reimplemented as a wrapper for the Dave's new 2D array API. So
> just testing
> the normal examples with the current 2D array API should indirectly
> exercise
> the new
Hi, Alan,
On Feb 16, 2010, at 0:07 , Alan W. Irwin wrote:
> Dave, I thank you for your implementation work. It takes courage to
> be the
> first to implement something that is going to be thoroughly (I hope)
> reviewed by others, and I thank you for that courage!
At the risk of sounding like a
On 2010-02-16 08:53-0700 Doug Hunt wrote:
> Hi Alan, all: Would this change require re-writing the perl interface to the
> 2D functions?
Eventually.
> Would this be required right away, or would there be backwards
> compatible variants left around to ease the transition?
No and yes.
>
> It
Hi Alan, all: Would this change require re-writing the perl interface to
the 2D functions? Would this be required right away, or would there be
backwards compatible variants left around to ease the transition?
It might be useful to know which demos are affected by this.
Thanks,
Doug Hunt
On 2010-02-16 09:07, Alan W. Irwin wrote:
> On 2010-02-15 14:10-0500 Hazen Babcock wrote:
>
>> David MacMahon wrote:
>>> Adds support for arbitrary storage of 2D user data. This is very
>>> similar to the technique employed by some existing functions (e.g.
>>> plfcont and plfshade) that use "eval
On 2010-02-15 14:10-0500 Hazen Babcock wrote:
> David MacMahon wrote:
>> Adds support for arbitrary storage of 2D user data. This is very
>> similar to the technique employed by some existing functions (e.g.
>> plfcont and plfshade) that use "evaluator" functions to access 2D user
>> data that is
David MacMahon wrote:
> Adds support for arbitrary storage of 2D user data. This is very
> similar to the technique employed by some existing functions (e.g.
> plfcont and plfshade) that use "evaluator" functions to access 2D user
> data that is stored in an arbtrary format. The new approach exte
22 matches
Mail list logo
