[Rd] building R under mingw 4.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, We're developing a Qt application that links against R using Rcpp. Qt5 requires Mingw 4.7, where as R seems to require Mingw 4.6. This makes linking against R problematic. Has anyone successfully built R with Mingw 4.7 (or 4.8)? Is this possible? Is this something being worked on? with thanks Jonathon - -- don't use google, use duckduckgo instead: https://duckduckgo.com/supportus.html -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJSLGDuAAoJEH277gjmPGDYVc8QALEu2p+jF/i5Xw9nzT507/5F 0zDvuvCqgjwLs14JRC8H6P5uyJB914qmYXYwwpGF0XhzZG80EyZyYRGKeeoGXdXg zrA0LCf9v518GHdhqfv7B3tZKdajBlUkSf6SgEQUArviChIo/laR2UBFqvj0EvVF U/tsO3EGirSu+p5KGR6bttmTJWXR/x+cRGxP2bwne0EbRYdKMEfdSfnT/bRpmydl VtUI5kzH7ZJ72ARTI43SRZFCTZQT+lmPk9h4TvdwipFyJjZG1aCoMOAnhwxOzKZ6 2j+cGv221V+8w5Bw+3u6TOlFd6EG8Mh5MaU2Ct0wHDTsgWXomzJMX5IM4GbTF0ms mYmOyo+j93sGvO0b3C0mIdOLIB99m6ZJ6DrwemYTMZENnAQiCirYMinP/7yl7ut7 6ciRSxDB0B19qTOlSFN007hCDqzwddv5f0aDyQJIy3WNklwWAwAaN1HKcxTqJAVz CD4tttB0tKyvXILG15RI9ksKLxJyFX41LrUp6V+19HMmymN5GmlMO63pZeHAH1hw cX5UdW7TQb+GZ0RZKZjcESlPBflxD6GtYP+wjtfb7tStyLiKx51wsYp7/hsFzDzf AHc8gXwY7DfQTV17m+VuHE4k8+4FGD+wuvD7CotrZRZJ992pewxlJl9/IZD81+zk fmf6A5soIC+2lq6v7ct1 =1o1e -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] building R under mingw 4.7
On 08/09/2013 12:35, Jonathon Love wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, We're developing a Qt application that links against R using Rcpp. We are guessing on Windows, not mentioned here. Qt5 requires Mingw 4.7, where as R seems to require Mingw 4.6. This > makes linking against R problematic. AFAICS there are no such versions, and in any case R on Windows supports Mingw-w64 (not Mingw which is a separate project). 'R' does not require any particular compiler: you can compile your application with whatever you like, and compile R in the same way. -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Comments requested on "changedFiles" function
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 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 in the temp directory) gets
deleted (which can happen after a moderate amount of time of
inactivity on some systems), then the file_test('-nt', ...) will
always return false, even if the file has changed.
If that happened without user intervention, I think it would break other
things in R -- the temp directory is supposed to last for the whole session.
But I should be checking anyway.
Yes, it does break other things in R -- my experience has been that
the help system seems to be the one that is impacted the most by this.
FWIW, I've never seen the entire R temp directory deleted, just
individual files and subdirectories in it, but even that probably
depends on how the machine is configured. I suspect only a few users
ever notice this, but my R use is probably somewhat anomalous and I
think it only happens to R sessions that I haven't used for a few
days.
I use Windows and never see this; deleting temp files is up to me, not
to the system. But my understanding was the *nix systems should only
clean up /tmp on restart, and I don't think an R session will survive a
restart.
However, you have convinced me that the use of the timestamp file is not
beneficial enough to be the default. I'll leave it as an option, but
add warnings that it might be unreliable.
* If files get added or deleted between the two calls to list.files in
fileSnapshot, it will fail with an error.
Yours won't work if path contains more than one directory. This is probably
a reasonable restriction, but it's inconsistent with list.files, so I'd like
to avoid it if I can find a way.
I'm currently unsure what the behaviour when comparing snapshots with
multiple directories should be.
Presumably we should have the property that (horribly abusing notation
for succinctness):
compareSnapshots(c(a1, a2), c(a1, a2))
is the same as concatenating (in some form)
compareSnapshots(a1, a1) and compareSnapshots(a2, a2)
and there's a bunch of ways we could concatenate -- we could return a
list of results, or a single result where each of the 'added, deleted,
modified' fields are a list, or where we concatenate the 'added,
deleted, modified' fields together into three simple vectors.
Concatenating the vectors together like this is appealing, but unless
you're using the full names, it doesn't include the information of
which directory the changes are in, and using the full names doesn't
work in the case where you're comparing different sets of directories,
e.g. compareSnapshots(c(a1, a2), c(b1, b2)), where there is no
sensible choice for a full name. The list options don't have this
problem, but are harder to work with, particularly for the common case
where there's only a single directory. You'd also have to be somewhat
careful with filenames that occur in both directories.
Maybe I'm just being dense, but I don't see a way to do this thats
clear, easy to use and wouldn't confuse users at the moment.
The way I've done this is to require full.names when multiple dirs are
on the path. I've reduced it to one list.files() call per dir, by
iterating over the path variable and using your approach of calling it
with full.names = FALSE, then adding the dir if necessary.
I haven't adopted your change that forces comparison of only size and
mtime from file.info. I don't see a big cost in storing whatever
file.info returns (which is system dependent; on Windows I don't see the
user and group related columns; on Unix I don't see the exe column).
Users might want to detect changes to anything there, and I shouldn't
make it harder for them.
I've also kept the special-casing of md5sum; it really needs to be
wrapped in suppressWarnings() (on Unix only). And I've kept the options
to specify what changedFiles checks among the file.info columns; I can
see that you might want a snapshot with everything, but sometimes only
want to be told about changes in a subset of the attributes.
I've uploaded
if
anyone is interested.
Duncan Murdoch
Karl
Duncan Murdoch
* If the path is on a remote file system, tempdir is local, and
there's significant clock skew, then you can get incorrect results.
Unfortunately, these aren't just theoretical scenarios -- I've had the
misfortune to run up against all of them in the past.
I've attached code that's loosely based on your implementation that
solves these problems AFAICT. Alternatively, Hadley's code handles
all of these correctly, with the exception that compare_state do
Re: [Rd] Comments requested on "changedFiles" function
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, 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 in the temp directory) gets
deleted (which can happen after a moderate amount of time of
inactivity on some systems), then the file_test('-nt', ...) will
always return false, even if the file has changed.
>>>
>>>
>>>
>>> If that happened without user intervention, I think it would break other
>>> things in R -- the temp directory is supposed to last for the whole
>>> session.
>>> But I should be checking anyway.
>>
>>
>> Yes, it does break other things in R -- my experience has been that
>> the help system seems to be the one that is impacted the most by this.
>> FWIW, I've never seen the entire R temp directory deleted, just
>> individual files and subdirectories in it, but even that probably
>> depends on how the machine is configured. I suspect only a few users
>> ever notice this, but my R use is probably somewhat anomalous and I
>> think it only happens to R sessions that I haven't used for a few
>> days.
>
>
> I use Windows and never see this; deleting temp files is up to me, not to
> the system. But my understanding was the *nix systems should only clean up
> /tmp on restart, and I don't think an R session will survive a restart.
>
> However, you have convinced me that the use of the timestamp file is not
> beneficial enough to be the default. I'll leave it as an option, but add
> warnings that it might be unreliable.
>
>
>>
* If files get added or deleted between the two calls to list.files in
fileSnapshot, it will fail with an error.
>>>
>>>
>>>
>>> Yours won't work if path contains more than one directory. This is
>>> probably
>>> a reasonable restriction, but it's inconsistent with list.files, so I'd
>>> like
>>> to avoid it if I can find a way.
>>
>>
>> I'm currently unsure what the behaviour when comparing snapshots with
>> multiple directories should be.
>>
>> Presumably we should have the property that (horribly abusing notation
>> for succinctness):
>>compareSnapshots(c(a1, a2), c(a1, a2))
>> is the same as concatenating (in some form)
>>compareSnapshots(a1, a1) and compareSnapshots(a2, a2)
>> and there's a bunch of ways we could concatenate -- we could return a
>> list of results, or a single result where each of the 'added, deleted,
>> modified' fields are a list, or where we concatenate the 'added,
>> deleted, modified' fields together into three simple vectors.
>> Concatenating the vectors together like this is appealing, but unless
>> you're using the full names, it doesn't include the information of
>> which directory the changes are in, and using the full names doesn't
>> work in the case where you're comparing different sets of directories,
>> e.g. compareSnapshots(c(a1, a2), c(b1, b2)), where there is no
>> sensible choice for a full name. The list options don't have this
>> problem, but are harder to work with, particularly for the common case
>> where there's only a single directory. You'd also have to be somewhat
>> careful with filenames that occur in both directories.
>>
>> Maybe I'm just being dense, but I don't see a way to do this thats
>> clear, easy to use and wouldn't confuse users at the moment.
>
>
> The way I've done this is to require full.names when multiple dirs are on
> the path. I've reduced it to one list.files() call per dir, by iterating
> over the path variable and using your approach of calling it with full.names
> = FALSE, then adding the dir if necessary.
>
> I haven't adopted your change that forces comparison of only size and mtime
> from file.info. I don't see a big cost in storing whatever file.info
> returns (which is system dependent; on Windows I don't see the user and
> group related columns; on Unix I don't see the exe column).
> Users might want to detect changes to anything there, and I shouldn't make
> it harder for them.
>
> I've also kept the special-casing of md5sum; it really needs to be wrapped
> in suppressWarnings() (on Unix only). And I've kept the options to specify
> what changedFiles checks among the file.info columns; I can see that you
> might want a snapshot with everything, but sometimes only want to be told
> about changes in a subset of the attributes.
>
> I've uploaded
> if anyone
> is interested.
Works well.
Scott
--
Scott Kostyshak
Economics PhD Candidate
Princeton University
__
R-devel@r-project.org mailing list
