[Rd] Lazy loading errors building its package in a chroot
Trying to build its_1.0.4 in a chroot environment to update the corresponding Debian package, I get * Installing *source* package 'its' ... ** R ** inst ** save image Loading required package: Hmisc Hmisc library by Frank E Harrell Jr Type library(help='Hmisc'), ?Overview, or ?Hmisc.Overview') to see overall documentation. NOTE:Hmisc no longer redefines [.factor to drop unused levels when subsetting. To get the old behavior of Hmisc type dropUnusedLevels(). Attaching package 'Hmisc': The following object(s) are masked from package:stats : ecdf Creating a new generic function for "names" in "its" Creating a new generic function for "names<-" in "its" Creating a new generic function for "print" in "its" Creating a new generic function for "start" in "its" Creating a new generic function for "end" in "its" Creating a new generic function for "summary" in "its" Creating a new generic function for "diff" in "its" Creating a new generic function for "union" in "its" Creating a new generic function for "intersect" in "its" ** preparing package for lazy loading Error in loadNamespace(name) : There is no package called 'its' Execution halted ERROR: lazy loading failed for package 'its' make: *** [R_any_arch] Error 1 pbuilder: Failed autobuilding of package The package installs fine when built on the command-line. This is somehow related to the reduced environment provided in the chroot -- I recall having seen (and fixed) the error when other packages where needed during build time. Hmisc is installed. Nothing else outside of R-base should be needed. I think I am overlooking something simple, but a couple of simple attempts didn't get me anywhere. The chroot isn't a problem per se as several dozen CRAN packages get built that way into Debian packages. Puzzled, Dirk -- If you don't go with R now, you will someday. -- David Kane on r-sig-finance, 30 Nov 2004 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug on log.p argument with all stat function (PR#7420)
Dear R Developers: I have been playing with R, release 2.0.1 for a week now and have detected = that all stat functions related to distribution probabilities have the same= problem: 1.- The log.p parameter of all distribution functions, when set to TRUE, re= turns a extrange value. Accoding to the manual, when set to true, it should return log(p) probabili= ty. So to my understanding, setting to true this parameters is the same as = getting the LOG of the same function with this parameter set to false. > pt (1.1, 5, F, T) [1] 0.8392746 > pt (1.1, 5, T, T) [1] 0.5168608 > log(pt (1.1, 5, F, T)) [1] -0.1752173 1.- The first line is the lower tail cumulative probability of a 1.1 on a S= tudent T distribution with 5 degrees of freedom. 2.- The second line is the lower tail cumulative probability of a 1.1 on a = Student T distribution with 5 degrees of freedom on a log scale 3.- The third line is the same as the second, but calculated mannually inst= ead of using the log.p parameters Why line 2 and 3 do not return the same result? Reciba un cordial saludo, =0D Jos=E9 Luis Casado Mart=EDnez -- European Computing Consultants C/ Hermanos Garc=EDa Noblejas, N=BA 39, 5=AA, N 1 28037 Madrid Telf.: 34-91-406 19 15. Fax: 34-91-406 19 16 Movil: 34-607-750 316 -- _ Mensaje analizado y protegido, tecnologia antivirus www.trendmicro.es [[alternative HTML version deleted]] __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [MailServer Notification]To Sender virus found and action taken. (PR#7422)
ScanMail for Microsoft Exchange has detected virus-infected attachment(s).
Sender = [EMAIL PROTECTED]
Recipient(s) = Urquijo, Lucas {D/CC~Madrid}
Subject = Mail System ([EMAIL PROTECTED])
Scanning time = 12/14/2004 6:51:21 PM
Engine/Pattern = 7.000-1004/2.297.00
Action on virus found:
The message body contains HTML_Netsky.P virus. ScanMail has deleted the message
body.
Warning to sender. ScanMail has detected and cleaned a virus in an email you
sent. The subject of the message is: Mail System ([EMAIL PROTECTED]) The
recipient: Urquijo, Lucas {D/CC~Madrid} has also been notified.
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Multiple options for a package
On Tue, 14 Dec 2004, Eric Lecoutre wrote: Hi, Thanks Prof for this suggestion. I did get an insight into sm source code and will adopt a similar strategy. BTW, I am discovering unlockBinding, which will be convenient. I agree that package-related options should disappear when package is unload. But what happen if within the same session the user reattach the package? Should the package-default options be restored or the previously defined options kept. And from a session to an other? Well, graphics parameters start from the defaults for each new device (and each new session), and people don't seem to find that awkward. Package hooks give users a way to set options at each invocation of a package (?setHook), and even to save and restore them if they want. Best, Eric At 14:30 14/12/2004, Prof Brian Ripley wrote: I don't see why package options need have anything to do with options(). It seems to me that they really should be stored in the package namespace (and so disappear when the package is detached). One package which does this is 'sm' (although that has been ported from S-PLUS and is not the cleanest R-only mechanism). I also don't see why you need to save options to file _within a session_, and the R testing framework does not do so -- take a look at what massage-examples does. But if you do save options, remember that some are read-only. I think you would find .readRDS and allies (see the help page) more convenient. Eric Lecoutre UCL / Institut de Statistique Voie du Roman Pays, 20 1348 Louvain-la-Neuve Belgium tel: (+32)(0)10473050 [EMAIL PROTECTED] http://www.stat.ucl.ac.be/ISpersonnel/lecoutre If the statistics are boring, then you've got the wrong numbers. -Edward Tufte -- 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 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: Hooks, docs [was [Rd] Multiple options for a package]
On Tue, 14 Dec 2004, Simon Urbanek wrote:
> Brian,
>
> thanks for the useful hints! In fact, that code features several
> interesting techniques.
> While reading one of the related docs I stumbled upon a slight problem
> in the UserHooks {base} docs:
>
> pkgname character string: the package/namespace name. If versioned
> install has been used, pkgname should the unversioned name of the
> package and any version information will be stripped.
`should be'
> The last sentence doesn't make too much sense to me - either there's a
> verb missing after the "should" or it should go away altogether
> (depending on what was really meant ...) or there's a better way to put
> it...
It's awkward to have to discuss versioned package names, but they are
treated inconsistently so we need to.
> ... and since we're talking about hooks - is there some standard as of
> what custom hook names should look like? Or maybe the hook parameters?
> (I noticed the one used in grid doesn't supply any parameters at
> all...) And finally how should hooks be documented (or the other way
> round - how does one look for hook documentation)?
We haven't prescribed anything. Hooks are usually documented under the
functions which call them, and need to accept whatever arguments the caller
might provide.
> Thanks,
> Simon
>
> On Dec 14, 2004, at 8:30 AM, Prof Brian Ripley wrote:
>
> > I also don't see why you need to save options to file _within a
> > session_, and the R testing framework does not do so -- take a look at
> > what massage-examples does. But if you do save options, remember that
> > some are read-only. I think you would find .readRDS and allies (see
> > the help page) more convenient.
--
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
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Multiple options for a package
Hi, Thanks Prof for this suggestion. I did get an insight into sm source code and will adopt a similar strategy. BTW, I am discovering unlockBinding, which will be convenient. I agree that package-related options should disappear when package is unload. But what happen if within the same session the user reattach the package? Should the package-default options be restored or the previously defined options kept. And from a session to an other? Best, Eric At 14:30 14/12/2004, Prof Brian Ripley wrote: I don't see why package options need have anything to do with options(). It seems to me that they really should be stored in the package namespace (and so disappear when the package is detached). One package which does this is 'sm' (although that has been ported from S-PLUS and is not the cleanest R-only mechanism). I also don't see why you need to save options to file _within a session_, and the R testing framework does not do so -- take a look at what massage-examples does. But if you do save options, remember that some are read-only. I think you would find .readRDS and allies (see the help page) more convenient. Eric Lecoutre UCL / Institut de Statistique Voie du Roman Pays, 20 1348 Louvain-la-Neuve Belgium tel: (+32)(0)10473050 [EMAIL PROTECTED] http://www.stat.ucl.ac.be/ISpersonnel/lecoutre If the statistics are boring, then you've got the wrong numbers. -Edward Tufte __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug on log.p argument with all stat function (PR#7420)
[EMAIL PROTECTED] wrote: > Dear R Developers: > > I have been playing with R, release 2.0.1 for a week now and have detected = > that all stat functions related to distribution probabilities have the same= > problem: > > 1.- The log.p parameter of all distribution functions, when set to TRUE, re= > turns a extrange value. > > Accoding to the manual, when set to true, it should return log(p) probabili= > ty. So to my understanding, setting to true this parameters is the same as = > getting the LOG of the same function with this parameter set to false. > > >>pt (1.1, 5, F, T) > > [1] 0.8392746 > >>pt (1.1, 5, T, T) > > [1] 0.5168608 > >>log(pt (1.1, 5, F, T)) > > [1] -0.1752173 > > 1.- The first line is the lower tail cumulative probability of a 1.1 on a S= > tudent T distribution with 5 degrees of freedom. > 2.- The second line is the lower tail cumulative probability of a 1.1 on a = > Student T distribution with 5 degrees of freedom on a log scale > 3.- The third line is the same as the second, but calculated mannually inst= > ead of using the log.p parameters > > Why line 2 and 3 do not return the same result? Please NEVER submit bug reports twice, in particular not an unsensible one! One time ncp = 1, one time ncp = 0, so what's that surprising? Uwe Ligges > Reciba un cordial saludo, > =0D > Jos=E9 Luis Casado Mart=EDnez > -- > European Computing Consultants > C/ Hermanos Garc=EDa Noblejas, N=BA 39, 5=AA, N 1 > 28037 Madrid > Telf.: 34-91-406 19 15. Fax: 34-91-406 19 16 > Movil: 34-607-750 316 > -- > > > _ > Mensaje analizado y protegido, tecnologia antivirus www.trendmicro.es > [[alternative HTML version deleted]] > > __ > [EMAIL PROTECTED] mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
