Re: [Rd] parallel build for package? (equivalent of make -j8)
Peter Dalgaard wrote: Whit Armstrong wrote: I have a package that takes about 20 minutes to compile which tends to prolong the compile/test/compile cycle. Does anyone know how to get R CMD check or R CMD INSTALL to use parallel make? I looked at R CMD INSTALL --help, but I don't see anything obvious arguments to do this. Platform? Does MAKE=make -j8 R CMD INSTALL ... not work? I cannot believe this works safely, at least when installing into the same library, because of R's lock mechanism that locks a library if *one* installation is running ... Best, Uwe (Beware: Here there be Tygers. Parallel makes have their surprises) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] normal-bracket50bracket-normal?
These usually indicate incorrect files. Have you looked at the
experimental Rd parser in R-devel to see if it pinpoints an error?
For example, in both Fperm.Rd and compareDerivatives.Rd there is an
\itemize{} construct inside \value, which is incorrect as \value is itself
an implicit \itemize. Please do check the description in 'Writing R
Extensions' (and \value is definitely quirky).
On Sun, 30 Nov 2008, Spencer Graves wrote:
Hello:
I've found structures like normal-bracket50bracket-normal in
help files for R packages including the following:
* mergeprepare and mergematrices in a document dated
March 3, 2004 by Richard Mott; the second contains
normal-bracket30bracket-normal.
Which is insufficient for the rest of us to get access to it.
* Fperm.fd and tperm.fd in the fda package; these help pages
were written primarily by Giles Hooker.
* compareDerivatives in the maxLik package; this help page was
written by Ott Toomet and me.
What can we do to eliminate this nonsense comment?
Constructs like this seem to be generated in perl code used in R
CMD processing
(https://svn.r-project.org/R/trunk/share/perl/R/Rdconv.pm).
Thanks,
Spencer Graves
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
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] parallel build for package? (equivalent of make -j8)
On Mon, 1 Dec 2008, Uwe Ligges wrote: Peter Dalgaard wrote: Whit Armstrong wrote: I have a package that takes about 20 minutes to compile which tends to prolong the compile/test/compile cycle. Does anyone know how to get R CMD check or R CMD INSTALL to use parallel make? I looked at R CMD INSTALL --help, but I don't see anything obvious arguments to do this. Platform? Does MAKE=make -j8 R CMD INSTALL ... not work? I cannot believe this works safely, at least when installing into the same library, because of R's lock mechanism that locks a library if *one* installation is running ... It does say 'package' (singular). It you know what you are doing you can switch off the locking (and you also need to worry about installing dependencies in the right order, at least for source installs). I don't see the issue though: if you run R CMD INSTALL on a package directory (rather than a tarball), 'make' will only re-make the compiled code whose sources have changed. Or is 'compile' being used loosely for 'install' (and even so it is rare for the bits that are always done, e.g. dumping R code, to take long). Best, Uwe (Beware: Here there be Tygers. Parallel makes have their surprises) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] 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
[Rd] Legal problems
Hello R-devel, I have legal problems and perhaps you can help me. Long story short: Do have the licence of R the linking exception? http://en.wikipedia.org/wiki/GPL_linking_exception Is it possible to build a frontend for R under the e.u.l.a. or another proprietary licence? Greetings Wilm -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unrelated software install triggering an error from R's install script on Mac OS X 10.5
Simon Urbanek wrote: On Dec 1, 2008, at 6:11 AM, Laurent Gautier wrote: Stefan Evert wrote: The steps needed to generate the error are: - install a binary distribution of R (default location) - add R to the PATH Did you actually add /Library/Frameworks/R.framework/Resources/bin/ to your PATH? You're not supposed to do that! What made you think so? Coming from an UNIX background, adding a directory like bin/ to the PATH does not appear unreasonable. ... if you really want those files to prepend your PATH. You get what you deserve ;) I this case you don't want that and this is true for all unix platforms. The point seems to be slightly missed here: the result of installing R is that there is no R executable in the path, and that adding the only bin/ directory coming with the install to be path results in a broken system. This directory contains a range of support scripts for R which are not intended for direct use from the command line or other programs. In my installation, there's just a symlink from /usr/bin/R to the R binary in the directory above, which AFAIK is the only program you need to invoke directly. I am relatively new to OS X, so I cannot tell whether this is an R specificity, or the way things are usually done on OS X are somewhat very different from the UNIX way. Then you seem to be very unfamiliar with the unix way as it appears... Ah ! the flourishing pronouncements on the R-lists... I am surprised by this cherry pick one executable in bin/ / don't touch the PATH. You are apparently unaware of the way R is setup ... Note that on most unix systems this is exactly what you get - the R_HOME/bin directory is tucked away in /usr/local/lib/R/bin which is never on your PATH since R installs the user-visible scripts to /usr/local/bin. The same happens here. I guess that we this comparing apples with oranges here: a default R install is leaving binaries in the path when performing a default install, which does not seem to be the case here (therefore forcing a hunt for the executable for the R console and resulting in the present thread). The point here is that there is no user-exposed bin/ directory (or copying of the right executables by default to a place commonly agreed by some UNIX audiences as proper for binaries), and that the only bin/ found contains executables one should not get in his/her PATH. In your case, R's INSTALL script, which implements the R CMD INSTALL functionality masks the standard install program in /usr/bin/install, so Python's installer now picks up a completely wrong program. Even if you edit R's INSTALL script, it'll do something entirely different from what you expect. To my great dismay I am hearing here that Mac OS X is not case-sensitive. Mac OS X is case-sensitive. Case-sensitivity is an option of the mounted file system and you can choose either. It is common to use case-insensitive fs for historical reasons (compatibility with older software), but you don't have to. BTW, putting the R binary directory ahead of system directories such as /usr/bin in your PATH is an even worse idea than including it there in the first place. ;-) I am used to the fact that adding a bin/ directory in the PATH (and *ahead* of all other components in the PATH) is the way to add custom binaries. If you want to override the system ones, yes. But you better know what you're doing ;). I cannot exclude that I am missing some specificities of Mac OS X, but that idea seems to be at least shared by the fink project (their default install puts /sw/bin ahead of all the rest). .. which leads to quite a few problems on its own. That's why you're entirely on your own if you do so (and likely to run into problems where Fink replaces systems parts with non-standard binaries). I suppose that there is a documentation for R-on-OS-X and that I overlooked it. You overlooked quite a bit of documentation of unix and R - pretty much none of it is OS X - specific. Cheers, S __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] parallel build for package? (equivalent of make -j8)
Prof Brian Ripley wrote: On Mon, 1 Dec 2008, Uwe Ligges wrote: Peter Dalgaard wrote: Whit Armstrong wrote: I have a package that takes about 20 minutes to compile which tends to prolong the compile/test/compile cycle. Does anyone know how to get R CMD check or R CMD INSTALL to use parallel make? I looked at R CMD INSTALL --help, but I don't see anything obvious arguments to do this. Platform? Does MAKE=make -j8 R CMD INSTALL ... not work? I cannot believe this works safely, at least when installing into the same library, because of R's lock mechanism that locks a library if *one* installation is running ... It does say 'package' (singular). Good point, I thought we were talking about parallelizing many packages' installations. One should read the original question more carefully rather than starting from a response. My apologies for the nonsense - and you all know fortune(talking nonsense) anyway: Uwe Ligges: I just told nonsense, stepclass() does not make sense with randomForest(), obviously ... (wonder why nobody shouted?). Douglas Bates: Oh, we're just so used to you talking nonsense that we don't bother to point it out any more :-) -- Uwe Ligges and Douglas Bates R-help (July 2005) Best, Uwe It you know what you are doing you can switch off the locking (and you also need to worry about installing dependencies in the right order, at least for source installs). I don't see the issue though: if you run R CMD INSTALL on a package directory (rather than a tarball), 'make' will only re-make the compiled code whose sources have changed. Or is 'compile' being used loosely for 'install' (and even so it is rare for the bits that are always done, e.g. dumping R code, to take long). Best, Uwe (Beware: Here there be Tygers. Parallel makes have their surprises) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Legal problems
On Mon, 1 Dec 2008, Wilm Schumacher wrote: Hello R-devel, I have legal problems and perhaps you can help me. You really do need ask legally qualified people about legal problems, not least because you have not even stated the jurisdiction that applies. Long story short: Do have the licence of R the linking exception? http://en.wikipedia.org/wiki/GPL_linking_exception I suggest you read the actual licence (see the start of every R session). Is it possible to build a frontend for R under the e.u.l.a. or another proprietary licence? (EULA usually means 'End User Licence Agreement', and is not well defined.) These licences are about distribution, not building nor using. So you need to consult with your lawyers about exactly what you want to do (and you have not told us). Greetings Wilm -- Brian D. Ripley, [EMAIL PROTECTED] 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] Rtools28 - undefined references with gfortran
On Wed, 26 Nov 2008, John Nolan wrote: I recently upgraded to Rtools28 to build a package under Windows. I see that g77 is no longer in Rtools, but it does have gfortran, and it uses version: GNU Fortran (GCC) 4.2.1-sjlj (mingw32-2) I am compiling some old fortran code as part of a larger project. When I do that, I get undefined references: gcc.exe: s_cmp.o: No such file or directory gcc.exe: s_copy.o: No such file or directory gcc.exe: s_cat.o: No such file or directory gcc.exe: F77_aloc.o: No such file or directory I don't see these entry points in any of the accompanying library files. I hunted around and found the above functions in an old MinGW library libg2c.lib libg2c.a, perhaps? When I link them in, I get different undefined references: ilaenv.o:ilaenv.f:(.text+0x55): undefined reference to `_gfortran_compare_string dlamch.o:dlamch.f:(.text+0x3bf): undefined reference to `_gfortran_pow_r8_i4' dormlq.o:dormlq.f:(.text+0x281): undefined reference to `_gfortran_concat_string Any guidance on how to solve this problem? Give a reproducible example (or at least all the steps you used) : see the posting guide. At a guess you are using gcc.exe to link Fortran code, not gfortran.exe. You can sometimes do that by adding -lgfortran to the link line. But don't expect your helpers to be prepared to guess John Nolan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] 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] file.access() on network (mounted) drive on Windows Vista?
It is a 'feature' of Windows Vista. Why not just use tryCatch()? The older version of file.access() used to report access when there was none, so the error have happened both ways. (I think any OS with multiple filesystems potentially has problems like this: we saw them with Unix (Solaris) file systems mounted on MacOS X via Samba, even when the same thing works correctly on Linux.) On Wed, 26 Nov 2008, Henrik Bengtsson wrote: Hi, I have a writable and readable file on a small network file system (Cisco NSLU2 Unslung; non-NTFS) that I access via a mounted drive on Windows Vista. My problem could be due to a funny file system/server, but here it goes: pathname - Q:/foo.txt cat(file=pathname, Hello world!\n) readLines(pathname) [1] Hello world! file.info(pathname) size isdir mode mtime ctime Q:/foo.txt 14 FALSE 666 2008-11-26 11:45:53 2008-11-26 11:45:53 atime exe Q:/foo.txt 2008-11-26 11:45:57 no The mode == 666 reported by file.info() indicates that it is readable writable by all users. This is also what Windows Vista file properties reports. So far so good. However, when I use file.access() to test for file permissions, I get: file.access(pathname, 0) # 0 test for existence. Q:/foo.txt 0 file.access(pathname, 1) # 1 test for execute permission. Q:/foo.txt -1 file.access(pathname, 2) # 2 test for write permission. Q:/foo.txt -1 file.access(pathname, 4) # 4 test for read permission. Q:/foo.txt -1 I obviously can write to and read from the file, and this is what file.info()$mode says too. However, file.access() tells a different story. More troubleshooting: When I log into the file server and do: # chmod ugo-w foo.txt # ls -l foo.txt -r-xr-1 admineveryone 14 Nov 26 11:48 foo.txt The changes in permission are seen by file.info(): file.info(pathname) size isdir mode mtime ctime Q:/foo.txt 14 FALSE 444 2008-11-26 11:48:50 2008-11-26 11:48:50 atime exe Q:/foo.txt 2008-11-26 11:56:40 no The output from file.access() remains the same though. From help(file.info) I read: File modes are probably only useful on NTFS file systems, and it seems all three digits refer to the file's owner. The execute/search bits are set for directories, and for files based on their extensions (e.g., '.exe', '.com', '.cmd' and '.bat' files). 'file.access' will give a more reliable view of read/write access availability to the R process. From what I conclude, file.access() is not reliable in this case. Is this a feature or a bug? I need a cross-platform test for file permissions, and I am looking for safer workaround. For instance, could it be that a zero result from file.access() can be trusted, but a -1 could occur either from a true lack of permission as well as a failure to test for the permission? If that would be case, I could try other measures (e.g. try to open the file) whenever I receive a -1 before throwing an exception. Any feedback or suggestions would be great. Thanks /Henrik sessionInfo() R version 2.8.0 Patched (2008-10-21 r46766) i386-pc-mingw32 locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MON ETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] 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] handling a matrix and .C
You should not have started with R/C API without reading this (first
link in google): Writing R Extensions. For your particular question
you want pages 72+ and sections 5.9.3 and 5.9.4, possibly further as
well
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Wilm Schumacher
Sent: 24 November 2008 18:59
To: r-devel@r-project.org
Subject: [Rd] handling a matrix and .C
Hello R-devel,
I want to write extensions for R in C (maybe C++ and Fortran
later) and it works fine, but there is one problem, which I
cannot solve (in my view).
I want to handle a matrix from R in C. For arrays there is
as.double(...), but nothing for a matrix.
I searched a while, but didn't find something.
Last I looked at the source code of e1071 and of the core
itself and recognized (I hope I understood this), that you
(and the e1071 people) use as.double() and give .C an
array and one have to parse the matrix again in the C function.
This sounds a little complicate. Isn't there another way? A
more adapted way?
Greetings
Wilm
ps: I joined the R-devel list, but didn't get an confirmation
mail. I hope this is normal
--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
**
Please consider the environment before printing this email or its attachments.
The contents of this email are for the named addressees ...{{dropped:19}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug repo may have stalled
We have a local certificate problem on our servers. As a result, fetchmail may not be fetching mails to be processed by the bug tracker. I expect that the problem wil go away by itself fairly soon, but please don't do anything silly (like sending the same report 15 times). -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unrelated software install triggering an error from R's install script on Mac OS X 10.5
I guess that we this comparing apples with oranges here: a default R install is leaving binaries in the path when performing a default install, which does not seem to be the case here (therefore forcing a hunt for the executable for the R console and resulting in the present thread). Well, the assumption seems to be that end users who just run an installer without reading the associated documentation won't be interested in a command-line version and will just start the R GUI that shows up in their /Applications folder ... The point seems to be slightly missed here: the result of installing R is that there is no R executable in the path, and that adding the only bin/ directory coming with the install to be path results in a broken system. ... and that people who add directories to their PATH tend to read instructions carefully. The download page for the Mac OS X binaries says: You may also want to read the R FAQ and R for Mac OS X FAQ. and in the Mac OS X FAQ you'll easily find the necessary instructions for using the command-line version: 3 Command line version of R The command line version of R is identical to R as used on other unix operating systems. Therefore general documentation forR applies to this version as well. On each release (and patched-release) ready to use binaries are distributed through CRAN. These binaries come with a common installer used by R.app so please read the related notes (see How to get R.app). To use Ryou probably need to add a symbolic link on your system as the R binary is located inside the framework. Suppose you have the/usr/local/bin directory on your system (if you do not have one, you can use /usr/bin instead) you should just type in your Terminal (a root password is required) sudo ln -s /Library/Frameworks/R.framework/Resources/R /usr/local/ bin/R Assuming that you have /usr/local/bin in your PATH environment variable, you will be able to launch R from any location on your system just by typing R. In this way, when you install a new version of the R.framework this link will point to the latest R binary. I suppose that with doing things the Unix way you've probably been referring to the package managers / installers that most Linux distributions use and which do indeed make their installed programs available from the command line. Best regards, Stefan Evert [ [EMAIL PROTECTED] | http://purl.org/stefan.evert ] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] normal-bracket50bracket-normal?
Dear Prof. Ripley:
Thanks very much. It looks like removing the \itemize from
within \value should fix the problem, though I haven't fully tested it
yet. I previously removed that from Fperm.fd and the problem is fixed
there. I haven't yet tested it with tperm.fd and compareDerivatives.
Thanks again.
Spencer
Prof Brian Ripley wrote:
These usually indicate incorrect files. Have you looked at the
experimental Rd parser in R-devel to see if it pinpoints an error?
For example, in both Fperm.Rd and compareDerivatives.Rd there is an
\itemize{} construct inside \value, which is incorrect as \value is
itself an implicit \itemize. Please do check the description in
'Writing R Extensions' (and \value is definitely quirky).
On Sun, 30 Nov 2008, Spencer Graves wrote:
Hello:
I've found structures like normal-bracket50bracket-normal in
help files for R packages including the following:
* mergeprepare and mergematrices in a document dated
March 3, 2004 by Richard Mott; the second contains
normal-bracket30bracket-normal.
Which is insufficient for the rest of us to get access to it.
* Fperm.fd and tperm.fd in the fda package; these
help pages were written primarily by Giles Hooker.
* compareDerivatives in the maxLik package; this help
page was written by Ott Toomet and me.
What can we do to eliminate this nonsense comment?
Constructs like this seem to be generated in perl code used in R
CMD processing
(https://svn.r-project.org/R/trunk/share/perl/R/Rdconv.pm).
Thanks,
Spencer Graves
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Small bug in axis.POSIXct
Dear developers,
the tick marks and labels produced by axis.POSIXct look strange for time
horizons of a few hours, see the following example:
plot(seq(as.POSIXct(14:00,format=%H:%M),as.POSIXct(18:00,format=%H:%M),length.out=20),1:20)
This (copypaste error?) is easily fixed, see the attached patch (for
revision 47031).
Best wishes,
Martin
--
Dr. Martin Becker
Statistics and Econometrics
Saarland University
Campus C3 1, Room 206
66123 Saarbruecken
Germany
diff -u --recursive trunk.orig/src/library/graphics/R/datetime.R
trunk/src/library/graphics/R/datetime.R
--- trunk.orig/src/library/graphics/R/datetime.R2008-07-20
18:18:38.0 +0200
+++ trunk/src/library/graphics/R/datetime.R 2008-12-01 17:27:32.0
+0100
@@ -29,10 +29,10 @@
sc - 60
if(missing(format)) format - %M:%S
} else if (d 1.1*60*60*24) {# hours
-sc - 60*24
+sc - 60*60
if(missing(format)) format - %H:%M
} else if (d 2*60*60*24) {
-sc - 60*24
+sc - 60*60
if(missing(format)) format - %a %H:%M
} else if (d 7*60*60*24) {# days of a week
sc - 60*60*24
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] trivial spelling correction
Good evening,
Spotted a very minor spelling mistake in the source for the grep help.
And thanks to R-Core for all their work - it's a tribute to R-Core,
that these sort of problems are rare indeed.
Best regards,
Sean O'Riordain
Dublin
[EMAIL PROTECTED]:~/R/RSVN/R/trunk/src/library/base/man$ svn diff
Index: grep.Rd
===
--- grep.Rd (revision 47031)
+++ grep.Rd (working copy)
@@ -102,7 +102,7 @@
For \code{sub} and \code{gsub} a character vector of the same length
and with the same attributes as \code{x} (after possible coercion).
- Elements of character vectors \code{x} which are not subsituted will
+ Elements of character vectors \code{x} which are not substituted will
be return unchanged (including any declared encoding). If
\code{useBytes = FALSE}, either \code{perl = TRUE} or \code{fixed =
TRUE} and any element of \code{pattern}, \code{replacement} and
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] file.access() on network (mounted) drive on Windows Vista?
Hi, thank you very much for this information. I now know that it is safer to use tryCatch() to test for this. Details: I have a function pn - getReadablePathname(pn) that I use to assess that a pathname (which also follows Windows Shortcuts) passed to a function specifies a file that exists and that can be read. If not, it throws an exception. I only need to update this function to try to open the file for reading (rb) and then try to read a raw byte (for an even more trusted result). If this fails, I conclude that the file is not a readable pathname. I also have an analogus getWritablePathname(). /Henrik On Mon, Dec 1, 2008 at 4:44 AM, Prof Brian Ripley [EMAIL PROTECTED] wrote: It is a 'feature' of Windows Vista. Why not just use tryCatch()? The older version of file.access() used to report access when there was none, so the error have happened both ways. (I think any OS with multiple filesystems potentially has problems like this: we saw them with Unix (Solaris) file systems mounted on MacOS X via Samba, even when the same thing works correctly on Linux.) On Wed, 26 Nov 2008, Henrik Bengtsson wrote: Hi, I have a writable and readable file on a small network file system (Cisco NSLU2 Unslung; non-NTFS) that I access via a mounted drive on Windows Vista. My problem could be due to a funny file system/server, but here it goes: pathname - Q:/foo.txt cat(file=pathname, Hello world!\n) readLines(pathname) [1] Hello world! file.info(pathname) size isdir mode mtime ctime Q:/foo.txt 14 FALSE 666 2008-11-26 11:45:53 2008-11-26 11:45:53 atime exe Q:/foo.txt 2008-11-26 11:45:57 no The mode == 666 reported by file.info() indicates that it is readable writable by all users. This is also what Windows Vista file properties reports. So far so good. However, when I use file.access() to test for file permissions, I get: file.access(pathname, 0) # 0 test for existence. Q:/foo.txt 0 file.access(pathname, 1) # 1 test for execute permission. Q:/foo.txt -1 file.access(pathname, 2) # 2 test for write permission. Q:/foo.txt -1 file.access(pathname, 4) # 4 test for read permission. Q:/foo.txt -1 I obviously can write to and read from the file, and this is what file.info()$mode says too. However, file.access() tells a different story. More troubleshooting: When I log into the file server and do: # chmod ugo-w foo.txt # ls -l foo.txt -r-xr-1 admineveryone 14 Nov 26 11:48 foo.txt The changes in permission are seen by file.info(): file.info(pathname) size isdir mode mtime ctime Q:/foo.txt 14 FALSE 444 2008-11-26 11:48:50 2008-11-26 11:48:50 atime exe Q:/foo.txt 2008-11-26 11:56:40 no The output from file.access() remains the same though. From help(file.info) I read: File modes are probably only useful on NTFS file systems, and it seems all three digits refer to the file's owner. The execute/search bits are set for directories, and for files based on their extensions (e.g., '.exe', '.com', '.cmd' and '.bat' files). 'file.access' will give a more reliable view of read/write access availability to the R process. From what I conclude, file.access() is not reliable in this case. Is this a feature or a bug? I need a cross-platform test for file permissions, and I am looking for safer workaround. For instance, could it be that a zero result from file.access() can be trusted, but a -1 could occur either from a true lack of permission as well as a failure to test for the permission? If that would be case, I could try other measures (e.g. try to open the file) whenever I receive a -1 before throwing an exception. Any feedback or suggestions would be great. Thanks /Henrik sessionInfo() R version 2.8.0 Patched (2008-10-21 r46766) i386-pc-mingw32 locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MON ETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] 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] parallel build for package? (equivalent of make -j8)
yes, this was just a parallel build within one package. Thanks very much for your help. -Whit On Mon, Dec 1, 2008 at 6:01 AM, Uwe Ligges [EMAIL PROTECTED] wrote: Prof Brian Ripley wrote: On Mon, 1 Dec 2008, Uwe Ligges wrote: Peter Dalgaard wrote: Whit Armstrong wrote: I have a package that takes about 20 minutes to compile which tends to prolong the compile/test/compile cycle. Does anyone know how to get R CMD check or R CMD INSTALL to use parallel make? I looked at R CMD INSTALL --help, but I don't see anything obvious arguments to do this. Platform? Does MAKE=make -j8 R CMD INSTALL ... not work? I cannot believe this works safely, at least when installing into the same library, because of R's lock mechanism that locks a library if *one* installation is running ... It does say 'package' (singular). Good point, I thought we were talking about parallelizing many packages' installations. One should read the original question more carefully rather than starting from a response. My apologies for the nonsense - and you all know fortune(talking nonsense) anyway: Uwe Ligges: I just told nonsense, stepclass() does not make sense with randomForest(), obviously ... (wonder why nobody shouted?). Douglas Bates: Oh, we're just so used to you talking nonsense that we don't bother to point it out any more :-) -- Uwe Ligges and Douglas Bates R-help (July 2005) Best, Uwe It you know what you are doing you can switch off the locking (and you also need to worry about installing dependencies in the right order, at least for source installs). I don't see the issue though: if you run R CMD INSTALL on a package directory (rather than a tarball), 'make' will only re-make the compiled code whose sources have changed. Or is 'compile' being used loosely for 'install' (and even so it is rare for the bits that are always done, e.g. dumping R code, to take long). Best, Uwe (Beware: Here there be Tygers. Parallel makes have their surprises) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unrelated software install triggering an error from R's install script on Mac OS X 10.5
On Dec 1, 2008, at 6:38 PM, Laurent Gautier wrote: Simon Urbanek wrote: On Dec 1, 2008, at 6:11 AM, Laurent Gautier wrote: Stefan Evert wrote: The steps needed to generate the error are: - install a binary distribution of R (default location) - add R to the PATH Did you actually add /Library/Frameworks/R.framework/Resources/bin/ to your PATH? You're not supposed to do that! What made you think so? Coming from an UNIX background, adding a directory like bin/ to the PATH does not appear unreasonable. ... if you really want those files to prepend your PATH. You get what you deserve ;) I this case you don't want that and this is true for all unix platforms. The point seems to be slightly missed here: the result of installing R is that there is no R executable in the path, Clearly a false statement, look in /usr/bin (both R and Rscript are installed there) - hence there is no need for you to add anything ... which is why I think this discussion is quite redundant ;). Cheers, S and that adding the only bin/ directory coming with the install to be path results in a broken system. This directory contains a range of support scripts for R which are not intended for direct use from the command line or other programs. In my installation, there's just a symlink from /usr/ bin/R to the R binary in the directory above, which AFAIK is the only program you need to invoke directly. I am relatively new to OS X, so I cannot tell whether this is an R specificity, or the way things are usually done on OS X are somewhat very different from the UNIX way. Then you seem to be very unfamiliar with the unix way as it appears... Ah ! the flourishing pronouncements on the R-lists... I am surprised by this cherry pick one executable in bin/ / don't touch the PATH. You are apparently unaware of the way R is setup ... Note that on most unix systems this is exactly what you get - the R_HOME/bin directory is tucked away in /usr/local/lib/R/bin which is never on your PATH since R installs the user-visible scripts to /usr/local/ bin. The same happens here. I guess that we this comparing apples with oranges here: a default R install is leaving binaries in the path when performing a default install, which does not seem to be the case here (therefore forcing a hunt for the executable for the R console and resulting in the present thread). The point here is that there is no user-exposed bin/ directory (or copying of the right executables by default to a place commonly agreed by some UNIX audiences as proper for binaries), and that the only bin/ found contains executables one should not get in his/her PATH. In your case, R's INSTALL script, which implements the R CMD INSTALL functionality masks the standard install program in / usr/bin/install, so Python's installer now picks up a completely wrong program. Even if you edit R's INSTALL script, it'll do something entirely different from what you expect. To my great dismay I am hearing here that Mac OS X is not case- sensitive. Mac OS X is case-sensitive. Case-sensitivity is an option of the mounted file system and you can choose either. It is common to use case-insensitive fs for historical reasons (compatibility with older software), but you don't have to. BTW, putting the R binary directory ahead of system directories such as /usr/bin in your PATH is an even worse idea than including it there in the first place. ;-) I am used to the fact that adding a bin/ directory in the PATH (and *ahead* of all other components in the PATH) is the way to add custom binaries. If you want to override the system ones, yes. But you better know what you're doing ;). I cannot exclude that I am missing some specificities of Mac OS X, but that idea seems to be at least shared by the fink project (their default install puts /sw/bin ahead of all the rest). .. which leads to quite a few problems on its own. That's why you're entirely on your own if you do so (and likely to run into problems where Fink replaces systems parts with non-standard binaries). I suppose that there is a documentation for R-on-OS-X and that I overlooked it. You overlooked quite a bit of documentation of unix and R - pretty much none of it is OS X - specific. Cheers, S __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
