Re: [Rd] R CMD INSTALL and file permission settings
Hi Dan, On 9 July 2013 at 19:52, Dan Tenenbaum wrote: | Picking up a somewhat old thread...what is the final status of this? In r-patched and r-devel, check the NEWS file. | It doesn't look like an option was added to control the permissions of | installed package files. | It also seems that the --group-writable option to R CMD INSTALL is not | present in R-3.0.1. | | So are we back to where we started? | | FWIW, I'd prefer a solution that respects the umask and is honored in | install.packages(), update.packages(), etc. In my use case users will We have something which is (in the eyes of all who played along here) better and simpler. Instead of passing an explicit option down (which has to cope with the different entry paths for this), the install function now checks for group-write mode of the target target directory. If present, the installation will use group-write too on file and its new directories. Easier, and quite elegant. Have a go and see if it fits your bill -- no umask fiddling, no teaching all users to change habits, no inotify. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD INSTALL and file permission settings
On Sat, Jun 15, 2013 at 4:38 PM, Simon Urbanek
wrote:
>
> On Jun 15, 2013, at 2:42 PM, Martin Maechler wrote:
>
>>> Dirk Eddelbuettel
>>>on Sat, 15 Jun 2013 10:45:04 -0500 writes:
>>
>>> On 15 June 2013 at 07:00, Dirk Eddelbuettel wrote:
>>> |
>>> | On 15 June 2013 at 07:47, Simon Urbanek wrote: | |
>>> Because update.packages() doesn't restore the
>>> group-writable bit. Which leads us to my point that this
>>> is not what you really want.
>>> |
>>> | Ooops. I'll take another look.
>>
>>> Done. "It works." For fairly generous definitions of
>>> working. I'll detail:
>>
>>> i) My initial patch only used options() to set things.
>>> Martin was not to enthralled with this and guided the
>>> patch towards using --group-writable as an option.
>>
>>> ii) With --group-writable, installation works but updates
>>> fail as noticed by Simon.
>>
>>> iii) If we fall back to using options() [ or an
>>> environment variable ], things works. A log is below.
>>
>> Hmm, but this only works if everyone who calls update.packages() also has
>> this options() setting, no?
>> Why would the update keep the package files group writable otherwise ?
>> If the updater has no group-writable option she can still update
>> the package you installed, but you can no longer, right?
>>
>> I still think the approach to abolish all settings and just
>> trigger group-writable package installation *when* the library
>> directory is group writable is so simple we should adopt it,
>> and can forget all options/ command line arguments / environment
>> variables about this topic.
>>
>
> I fully agree. Also thanks for summarizing the discussion earlier today - it
> was dead on.
>
Picking up a somewhat old thread...what is the final status of this?
It doesn't look like an option was added to control the permissions of
installed package files.
It also seems that the --group-writable option to R CMD INSTALL is not
present in R-3.0.1.
So are we back to where we started?
FWIW, I'd prefer a solution that respects the umask and is honored in
install.packages(), update.packages(), etc. In my use case users will
be installing packages most often within R with install.packages() (as
opposed to R CMD INSTALL from the command line), and they will
probably use install.packages() rather than update.packages() even for
packages that are already installed.
I'll probably use the inotify hack suggested earlier in the short term.
Thanks,
Dan
> Thanks,
> Simon
>
>
>
>> Martin
>>
>>> iv) I guess those of you who want the --group-writeable
>>> option need to ensure it also works for update.packages()
>>> as new option?
>>
>>> I am happy with what we have right now as it works in the
>>> context established by my patch. Martin's addition of
>>> --group-writable is a bit more ambitious and we may need
>>> to enhance update.package(), or tell everybody to also
>>> (??) use the option() setting, or environment variable.
>>
>>> Two things follow, a quick test script and a log from the
>>> script.
>>
>>> Dirk
>>
>>
>>> Script
>>>
>>> #!/bin/bash
>>>
>>> ## we use digest as an example as it is pretty small
>>> cd ~/svn/digest
>>> ls -l digest_0.6.?.tar.gz
>>>
>>> ## we make two assumptions:
>>> ##
>>> ## a) R-devel (called via a shell script wrapper)
>>> ~/bin/R-devel.sh --version | head -1
>>> ##
>>> ## b) An option has been set
>>> cat /usr/local/lib/R-devel/lib/R/etc/Rprofile.site
>>>
>>> ## now install an older version so that we can upgrade later
>>> ## this is running as 'edd' ie me
>>> ~/bin/R-devel.sh CMD INSTALL digest_0.6.2.tar.gz
>>>
>>> ls -ld /usr/local/lib/R/site-library/digest/
>>> ls -lR /usr/local/lib/R/site-library/digest/
>>>
>>> ## now try the upgrade as another user in the group
>>> sudo su lmp -c '~edd/bin/R-devel.sh -e
>>> "update.packages(repos=\"http://cran.r-project.org\";, ask=FALSE,
>>> lib.loc=\"/usr/local/lib/R/site-library\")"'
>>>
>>> ls -ld /usr/local/lib/R/site-library/digest/
>>> ls -lR /usr/local/lib/R/site-library/digest/
>>>
>>>
>>>
>>> Session log
>>>
>>> edd@max:~$ /tmp/testRupgrade.sh
>>> -rw-r--r-- 1 edd edd 53344 Nov 25 2012 digest_0.6.0.tar.gz
>>> -rw-r--r-- 1 edd edd 76839 Jan 21 09:25 digest_0.6.1.tar.gz
>>> -rw-r--r-- 1 edd edd 76771 Jan 25 11:33 digest_0.6.2.tar.gz
>>> -rw-r--r-- 1 edd edd 78002 Feb 16 06:35 digest_0.6.3.tar.gz
>>> R Under development (unstable) (2013-06-14 r62964) -- "Unsuffered
>>> Consequences"
>>> options("group.writable.pkgs"=TRUE)
>>> * installing to library ‘/usr/local/lib/R/site-library’
>>> * installing *source* package ‘digest’ ...
>>> ** libs
>>> ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG
>>> -I/usr/local/include-fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c
>>> aes.c -o aes.o
>>> ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG
>>> -I/usr/local/include-fpic -O3 -g0 -Wall -pipe -pedantic -std=gnu99 -c
>>> crc32.c -o crc32.o
>>> ccache gcc-4.7 -I/usr/local/lib/R-devel/lib/R/include -DNDEBUG
>>> -I/usr/local/include
[Rd] probable bugs in stats::loglin calculation of pearson chisq
In running the following example of a loglinear model for the Titanic data, I was surprised to see NaN reported for the Pearson chisq > loglin(Titanic, margin=list(1:3, 4)) 2 iterations: deviation 2.273737e-13 $lrt [1] 671.9622 $pearson [1] NaN $df [1] 15 $margin $margin[[1]] [1] "Class" "Sex" "Age" $margin[[2]] [1] "Survived" Tracing it back, this occurs because there are zeros in the fitted/expected frequencies for children among the Crew. > # get fitted (expected) values > fitted <- loglin(Titanic, margin=list(1:3, 4), fit=TRUE)$fit 2 iterations: deviation 2.273737e-13 > fitted[Class="Crew",,Age="Child",] Survived Sex No Yes Male0 0 Female 0 0 I certainly understand the difference between sampling zeros and structural zeros, and this distinction seems properly implemented in loglin() via the start= argument, but only in the calculation of Pearson chisq, not for LRT. I think this is a code bug, but if there is a reason for the difference, it should be documented in the help for loglin. Another probable bug is that the calculation of of the LRT chisq also takes zero fitted values into account, while the calculation of the Pearson chisq does not, and leads to the NaN result for my example. It occurs in the following portion of the code for loglin: fit <- z$fit attributes(fit) <- attributes(table) observed <- as.vector(table[start > 0]) expected <- as.vector(fit[start > 0]) pearson <- sum((observed - expected)^2/expected) observed <- as.vector(table[table * fit > 0]) expected <- as.vector(fit[table * fit > 0]) lrt <- 2 * sum(observed * log(observed/expected)) I don't understand the reasons for the different calculations of observed & expected for pearson & lrt. FWIW, below is how I calculate these in my mosaics.sas program start chisq(obs, fit); *-- Find Pearson and likelihood ratio chisquares; gf = sum ( (obs - fit)##2 / ( fit + (fit=0) ) ); lr = 2 # sum ( obs # log ( (obs+(obs=0)) / (fit + (fit=0)) ) ); return (gf // lr); finish; -Michael -- Michael Friendly Email: friendly AT yorku DOT ca Professor, Psychology Dept. & Chair, Quantitative Methods York University Voice: 416 736-2100 x66249 Fax: 416 736-5814 4700 Keele StreetWeb: http://www.datavis.ca Toronto, ONT M3J 1P3 CANADA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is difftime a "class"
difftime is an S3 class, not an S4 class. To convert it, include the line
setOldClass("difftime")
and the setMethod call should work.
On 7/9/2013 6:03 AM, Dan Murphy wrote:
I am trying to write S4 methods with "difftime" in the signature but
am being "informed" (? not a warning or error) that "difftime" is not
a class. Nevertheless, dispatch takes place. Should I simply ignore
that "information"? Here is a toy example:
setClass("foo", contains = "Date")
setMethod("+", c("foo", "difftime"), function(e1, e2) callNextMethod())
in method for ‘+’ with signature ‘"foo","difftime"’: no definition for
class “difftime”
[1] "+"
x<- new("foo", as.Date("2013-06-30"))
dt<- as.difftime(1, units = "days")
x + dt
[1] "2013-07-01"
Thank you,
Dan Murphy
__
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] Is difftime a "class"
I am trying to write S4 methods with "difftime" in the signature but
am being "informed" (? not a warning or error) that "difftime" is not
a class. Nevertheless, dispatch takes place. Should I simply ignore
that "information"? Here is a toy example:
> setClass("foo", contains = "Date")
> setMethod("+", c("foo", "difftime"), function(e1, e2) callNextMethod())
in method for ‘+’ with signature ‘"foo","difftime"’: no definition for
class “difftime”
[1] "+"
> x <- new("foo", as.Date("2013-06-30"))
> dt <- as.difftime(1, units = "days")
> x + dt
[1] "2013-07-01"
Thank you,
Dan Murphy
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
