Thanks for everyone's comments on this. I have now committed a version
to R-devel. I don't plan to backport it to 3.0.2 (coming out in a
couple of weeks), but it should appear in 3.1.0 in the spring, and it's
conceivable it could make it into 3.0.3 (not yet scheduled).
Duncan Murdoch
__
On Sun, Sep 8, 2013 at 10:55 AM, Duncan Murdoch
wrote:
> On 13-09-06 11:07 PM, Karl Millar wrote:
>>
>> On Fri, Sep 6, 2013 at 7:03 PM, Duncan Murdoch
>> wrote:
>>>
>>> On 13-09-06 9:21 PM, Karl Millar wrote:
Hi Duncan,
I like the interface of this version a lot better, b
On 13-09-06 11:07 PM, Karl Millar wrote:
On Fri, Sep 6, 2013 at 7:03 PM, Duncan Murdoch wrote:
On 13-09-06 9:21 PM, Karl Millar wrote:
Hi Duncan,
I like the interface of this version a lot better, but there's still a
bunch of implementation details that need fixing:
* As previously mentione
On Fri, Sep 6, 2013 at 7:03 PM, Duncan Murdoch wrote:
> On 13-09-06 9:21 PM, Karl Millar wrote:
>>
>> Hi Duncan,
>>
>> I like the interface of this version a lot better, but there's still a
>> bunch of implementation details that need fixing:
>>
>> * As previously mentioned, there are important ca
On 13-09-06 9:21 PM, Karl Millar wrote:
Hi Duncan,
I like the interface of this version a lot better, but there's still a
bunch of implementation details that need fixing:
* As previously mentioned, there are important cases where the mtime
values change in ways that this code doesn't detect.
*
Hi Duncan,
I like the interface of this version a lot better, but there's still a
bunch of implementation details that need fixing:
* As previously mentioned, there are important cases where the mtime
values change in ways that this code doesn't detect.
* If the timestamp file (which is usually i
On Fri, Sep 6, 2013 at 7:40 PM, Scott Kostyshak wrote:
> On Fri, Sep 6, 2013 at 3:46 PM, Duncan Murdoch
> wrote:
>> On 06/09/2013 2:20 PM, Duncan Murdoch wrote:
>>>
>>> I have now put the code into a temporary package for testing; if anyone
>>> is interested, for a few days it will be downloadab
On 13-09-06 7:40 PM, Scott Kostyshak wrote:
On Fri, Sep 6, 2013 at 3:46 PM, Duncan Murdoch wrote:
On 06/09/2013 2:20 PM, Duncan Murdoch wrote:
I have now put the code into a temporary package for testing; if anyone
is interested, for a few days it will be downloadable from
fisher.stats.uwo.c
On Fri, Sep 6, 2013 at 3:46 PM, Duncan Murdoch wrote:
> On 06/09/2013 2:20 PM, Duncan Murdoch wrote:
>>
>> I have now put the code into a temporary package for testing; if anyone
>> is interested, for a few days it will be downloadable from
>>
>> fisher.stats.uwo.ca/faculty/murdoch/temp/testpkg_1.
I have now put the code into a temporary package for testing; if anyone
is interested, for a few days it will be downloadable from
fisher.stats.uwo.ca/faculty/murdoch/temp/testpkg_1.0.tar.gz
This uses two functions:
fileSnapshot -- takes a snapshot
changedFiles -- compares two snapshots, or on
On 06/09/2013 2:20 PM, Duncan Murdoch wrote:
I have now put the code into a temporary package for testing; if anyone
is interested, for a few days it will be downloadable from
fisher.stats.uwo.ca/faculty/murdoch/temp/testpkg_1.0.tar.gz
Sorry, error in the URL. It should be
http://www.stats.u
On 13-09-06 2:46 AM, Karl Millar wrote:
Comments inline:
On Wed, Sep 4, 2013 at 6:10 PM, Duncan Murdoch wrote:
On 13-09-04 8:02 PM, Karl Millar wrote:
Hi Duncan,
I think this functionality would be much easier to use and understand if
you split it up the functionality of taking snapshots
Comments inline:
On Wed, Sep 4, 2013 at 6:10 PM, Duncan Murdoch wrote:
>
> On 13-09-04 8:02 PM, Karl Millar wrote:
>>
>> Hi Duncan,
>>
>> I think this functionality would be much easier to use and understand if
>> you split it up the functionality of taking snapshots and comparing them
>> into s
> This approach does have the difficulty that users could attempt to compare
> snapshots that were taken with different options and that can't be
> compared, but that should be an easy error to detect.
FYI I implemented that approach in testthat:
https://github.com/hadley/testthat/blob/master/R/wa
On Thu, Sep 5, 2013 at 6:48 AM, Duncan Murdoch wrote:
> On 13-09-04 11:36 PM, Scott Kostyshak wrote:
>>
>> On Wed, Sep 4, 2013 at 1:53 PM, Duncan Murdoch
>> wrote:
>>>
>>> In a number of places internal to R, we need to know which files have
>>> changed (e.g. after building a vignette). I've jus
Dear Duncan,
This certainly looks useful. Might you consider adding the ability to
supply an alternative digest function? Details below.
I often use a homemade "make" type function which starts by looking at
modification times e.g. in a private package
https://github.com/jefferis/nat.utils/
On 05/09/2013 12:32 PM, Dr Gregory Jefferis wrote:
Dear Duncan,
This certainly looks useful. Might you consider adding the ability to
supply an alternative digest function? Details below.
Thanks, that's a good idea.
Duncan Murdoch
I often use a homemade "make" type function which starts by
On 13-09-04 11:36 PM, Scott Kostyshak wrote:
On Wed, Sep 4, 2013 at 1:53 PM, Duncan Murdoch wrote:
In a number of places internal to R, we need to know which files have
changed (e.g. after building a vignette). I've just written a general
purpose function "changedFiles" that I'll probably comm
On Wed, Sep 4, 2013 at 1:53 PM, Duncan Murdoch wrote:
> In a number of places internal to R, we need to know which files have
> changed (e.g. after building a vignette). I've just written a general
> purpose function "changedFiles" that I'll probably commit to R-devel.
> Comments on the design (o
On 13-09-04 8:02 PM, Karl Millar wrote:
Hi Duncan,
I think this functionality would be much easier to use and understand if
you split it up the functionality of taking snapshots and comparing them
into separate functions.
Yes, that's another possibility. Some more comment below...
In addit
Hi Duncan,
I think this functionality would be much easier to use and understand if
you split it up the functionality of taking snapshots and comparing them
into separate functions. In addition, the 'timestamp' functionality seems
both confusing and brittle to me. I think it would be better to s
21 matches
Mail list logo
