Re: [Rd] S4 changes - sp fails
On Fri, 1 Sep 2006, Prof Brian Ripley wrote:
> Roger,
>
> I had managed to run R CMD check on sp successfully on r39021 and r39043
> (current) in my nightly checks. (There are a couple of tests where the
> show/print method is not being invoked, but that is not new.)
>
> All I can suggest is to install R from scratch (make distclean), and then
> reinstall all relevant packages. At a guess, your interactive use and R
> CMD check are picking up different libraries.
Brian,
I added .libPaths() and sessionInfo() to the offending example, and tried
with a fresh svn checkout built in a fresh directory and installed in a
fresh directory (no sp or methods in /home/rsb/topics/r_libs, which was
set with export R_LIBS=):
> data(state)
> .libPaths()
[1] "/home/rsb/topics/packages/sp-bundle/sp.Rcheck"
[2] "/home/rsb/topics/r_libs"
[3] "/home/rsb/topics/Rtobe240/lib/R/library"
> sessionInfo()
R version 2.4.0 Under development (unstable) (2006-08-31 r39045)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_GB;LC_NUMERIC=C;LC_TIME=en_GB;LC_COLLATE=en_GB;LC_MONETARY=en_GB;LC_
MESSAGES=en_GB;LC_PAPER=en_GB;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREME
NT=en_GB;LC_IDENTIFICATION=C
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
other attached packages:
sp
"0.8-19"
> dd2dms(state.center$x)
Error in function (classes, fdef, mtable) :
unable to find an inherited method for function "initialize", for
signature "integer"
Execution halted
I also tried to replicate the problem by making a new, very small, package
with just the apparently offending files:
spS4:
DESCRIPTION man/ NAMESPACE R/
spS4/man:
char2dms.Rd DMS-class.Rd
spS4/R:
AAA.R dms.R
and edited DESCRIPTION, NAMESPACE, and AAA.R to suit. In this setting
there was no problem. I'll carry on looking. None of these files has
changed between released 0.8-18 and CVS 0.8-19.
Roger
>
> There are around a dozen S4-using packages on CRAN that are currently
> failing their checks: some look like newly-discovered bugs but some look
> like problems in S4 dispatch (even of S3 dispatch for S3 generics turned
> into S4 generics). More are producing apparently incorrect warnings.
>
> Brian
>
>
> On Thu, 31 Aug 2006, Roger Bivand wrote:
>
> > Under R version 2.4.0 (2006-08-30 r39024), sp fails CMD check following
> > the latest changes in methods.
> >
> > The failures are in running examples and occur in CMD check:
> >
> > > data(state)
> > > dd2dms(state.center$x)
> > Error in function (classes, fdef, mtable) :
> > unable to find an inherited method for function "initialize", for
> > signature "integer"
> >
> > Offending code:
> >
> > deg <- as(floor(dd), "integer")
> >
> > After replacing by as.integer(floor(dd)), it fails on the local class
> > definition:
> >
> > > dd2dms(state.center$x)
> > Error in function (classes, fdef, mtable) :
> > unable to find an inherited method for function "initialize", for
> > signature "DMS"
> >
> > Installing sp, example("DMS-class") runs successfully interactively
> > (other examples do too).
> >
> > The methods package is declared as Depends: in DESCRIPTION, and
> > import(methods) in NAMESPACE;
> >
> > .onLoad <- function(lib, pkg) require(methods) is in the first R source
> > file in Collate: order.
> >
> > Should the methods package be being invoked in some other way, is there a
> > reason why the installed package appears to run examples successfully that
> > fail under CMD check?
> >
> > Roger
> >
> >
>
>
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 changes - sp fails
Since writing that, I have found that there is a similar problem with
testing mvoutliers (which does load sp), and it depends on exactly what
has been done in what order. (I'll forward to you the exact description.)
I now suspect there is a protection problem in the new S4 dispatch code.
Using gctorture/valgrind may help locate it.
Brian
On Fri, 1 Sep 2006, Roger Bivand wrote:
> On Fri, 1 Sep 2006, Prof Brian Ripley wrote:
>
> > Roger,
> >
> > I had managed to run R CMD check on sp successfully on r39021 and r39043
> > (current) in my nightly checks. (There are a couple of tests where the
> > show/print method is not being invoked, but that is not new.)
> >
> > All I can suggest is to install R from scratch (make distclean), and then
> > reinstall all relevant packages. At a guess, your interactive use and R
> > CMD check are picking up different libraries.
>
> Brian,
>
> I added .libPaths() and sessionInfo() to the offending example, and tried
> with a fresh svn checkout built in a fresh directory and installed in a
> fresh directory (no sp or methods in /home/rsb/topics/r_libs, which was
> set with export R_LIBS=):
>
> > data(state)
> > .libPaths()
> [1] "/home/rsb/topics/packages/sp-bundle/sp.Rcheck"
> [2] "/home/rsb/topics/r_libs"
> [3] "/home/rsb/topics/Rtobe240/lib/R/library"
> > sessionInfo()
> R version 2.4.0 Under development (unstable) (2006-08-31 r39045)
> i686-pc-linux-gnu
>
> locale:
> LC_CTYPE=en_GB;LC_NUMERIC=C;LC_TIME=en_GB;LC_COLLATE=en_GB;LC_MONETARY=en_GB;LC_
> MESSAGES=en_GB;LC_PAPER=en_GB;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREME
> NT=en_GB;LC_IDENTIFICATION=C
>
> attached base packages:
> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> [7] "base"
>
> other attached packages:
> sp
> "0.8-19"
> > dd2dms(state.center$x)
> Error in function (classes, fdef, mtable) :
> unable to find an inherited method for function "initialize", for
> signature "integer"
> Execution halted
>
> I also tried to replicate the problem by making a new, very small, package
> with just the apparently offending files:
>
> spS4:
> DESCRIPTION man/ NAMESPACE R/
>
> spS4/man:
> char2dms.Rd DMS-class.Rd
>
> spS4/R:
> AAA.R dms.R
>
> and edited DESCRIPTION, NAMESPACE, and AAA.R to suit. In this setting
> there was no problem. I'll carry on looking. None of these files has
> changed between released 0.8-18 and CVS 0.8-19.
>
> Roger
>
> >
> > There are around a dozen S4-using packages on CRAN that are currently
> > failing their checks: some look like newly-discovered bugs but some look
> > like problems in S4 dispatch (even of S3 dispatch for S3 generics turned
> > into S4 generics). More are producing apparently incorrect warnings.
> >
> > Brian
> >
> >
> > On Thu, 31 Aug 2006, Roger Bivand wrote:
> >
> > > Under R version 2.4.0 (2006-08-30 r39024), sp fails CMD check following
> > > the latest changes in methods.
> > >
> > > The failures are in running examples and occur in CMD check:
> > >
> > > > data(state)
> > > > dd2dms(state.center$x)
> > > Error in function (classes, fdef, mtable) :
> > > unable to find an inherited method for function "initialize", for
> > > signature "integer"
> > >
> > > Offending code:
> > >
> > > deg <- as(floor(dd), "integer")
> > >
> > > After replacing by as.integer(floor(dd)), it fails on the local class
> > > definition:
> > >
> > > > dd2dms(state.center$x)
> > > Error in function (classes, fdef, mtable) :
> > > unable to find an inherited method for function "initialize", for
> > > signature "DMS"
> > >
> > > Installing sp, example("DMS-class") runs successfully interactively
> > > (other examples do too).
> > >
> > > The methods package is declared as Depends: in DESCRIPTION, and
> > > import(methods) in NAMESPACE;
> > >
> > > .onLoad <- function(lib, pkg) require(methods) is in the first R source
> > > file in Collate: order.
> > >
> > > Should the methods package be being invoked in some other way, is there a
> > > reason why the installed package appears to run examples successfully
> > > that
> > > fail under CMD check?
> > >
> > > Roger
> > >
> > >
> >
> >
>
>
--
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] S4 changes - sp fails
On Fri, 1 Sep 2006, Prof Brian Ripley wrote:
> Since writing that, I have found that there is a similar problem with
> testing mvoutliers (which does load sp), and it depends on exactly what
> has been done in what order. (I'll forward to you the exact description.)
Thanks.
I reran the interactive test:
library(sp, lib.loc="sp.Rcheck")
example("DMS-class")
which ran without problems.
> .libPaths()
[1] "/home/rsb/topics/r_libs"
[2] "/home/rsb/topics/Rtobe240/lib/R/library"
> list.files(.libPaths()[1])
[1] "abind""maptools" "pixmap" "RColorBrewer" "R.css"
[6] "rgdal""SparseM" "spdep""tripack"
> sessionInfo()
R version 2.4.0 Under development (unstable) (2006-08-31 r39045)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_GB;LC_NUMERIC=C;LC_TIME=en_GB;LC_COLLATE=en_GB;LC_MONETARY=en_GB;LC_
MESSAGES=en_GB;LC_PAPER=en_GB;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREME
NT=en_GB;LC_IDENTIFICATION=C
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
other attached packages:
sp
"0.8-19"
>
> I now suspect there is a protection problem in the new S4 dispatch code.
> Using gctorture/valgrind may help locate it.
Running check --use-gct sp now.
Roger
>
> Brian
>
> On Fri, 1 Sep 2006, Roger Bivand wrote:
>
> > On Fri, 1 Sep 2006, Prof Brian Ripley wrote:
> >
> > > Roger,
> > >
> > > I had managed to run R CMD check on sp successfully on r39021 and r39043
> > > (current) in my nightly checks. (There are a couple of tests where the
> > > show/print method is not being invoked, but that is not new.)
> > >
> > > All I can suggest is to install R from scratch (make distclean), and then
> > > reinstall all relevant packages. At a guess, your interactive use and R
> > > CMD check are picking up different libraries.
> >
> > Brian,
> >
> > I added .libPaths() and sessionInfo() to the offending example, and tried
> > with a fresh svn checkout built in a fresh directory and installed in a
> > fresh directory (no sp or methods in /home/rsb/topics/r_libs, which was
> > set with export R_LIBS=):
> >
> > > data(state)
> > > .libPaths()
> > [1] "/home/rsb/topics/packages/sp-bundle/sp.Rcheck"
> > [2] "/home/rsb/topics/r_libs"
> > [3] "/home/rsb/topics/Rtobe240/lib/R/library"
> > > sessionInfo()
> > R version 2.4.0 Under development (unstable) (2006-08-31 r39045)
> > i686-pc-linux-gnu
> >
> > locale:
> > LC_CTYPE=en_GB;LC_NUMERIC=C;LC_TIME=en_GB;LC_COLLATE=en_GB;LC_MONETARY=en_GB;LC_
> > MESSAGES=en_GB;LC_PAPER=en_GB;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREME
> > NT=en_GB;LC_IDENTIFICATION=C
> >
> > attached base packages:
> > [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> > [7] "base"
> >
> > other attached packages:
> > sp
> > "0.8-19"
> > > dd2dms(state.center$x)
> > Error in function (classes, fdef, mtable) :
> > unable to find an inherited method for function "initialize", for
> > signature "integer"
> > Execution halted
> >
> > I also tried to replicate the problem by making a new, very small, package
> > with just the apparently offending files:
> >
> > spS4:
> > DESCRIPTION man/ NAMESPACE R/
> >
> > spS4/man:
> > char2dms.Rd DMS-class.Rd
> >
> > spS4/R:
> > AAA.R dms.R
> >
> > and edited DESCRIPTION, NAMESPACE, and AAA.R to suit. In this setting
> > there was no problem. I'll carry on looking. None of these files has
> > changed between released 0.8-18 and CVS 0.8-19.
> >
> > Roger
> >
> > >
> > > There are around a dozen S4-using packages on CRAN that are currently
> > > failing their checks: some look like newly-discovered bugs but some look
> > > like problems in S4 dispatch (even of S3 dispatch for S3 generics turned
> > > into S4 generics). More are producing apparently incorrect warnings.
> > >
> > > Brian
> > >
> > >
> > > On Thu, 31 Aug 2006, Roger Bivand wrote:
> > >
> > > > Under R version 2.4.0 (2006-08-30 r39024), sp fails CMD check following
> > > > the latest changes in methods.
> > > >
> > > > The failures are in running examples and occur in CMD check:
> > > >
> > > > > data(state)
> > > > > dd2dms(state.center$x)
> > > > Error in function (classes, fdef, mtable) :
> > > > unable to find an inherited method for function "initialize",
> > > > for
> > > > signature "integer"
> > > >
> > > > Offending code:
> > > >
> > > > deg <- as(floor(dd), "integer")
> > > >
> > > > After replacing by as.integer(floor(dd)), it fails on the local class
> > > > definition:
> > > >
> > > > > dd2dms(state.center$x)
> > > > Error in function (classes, fdef, mtable) :
> > > > unable to find an inherited method for function "initialize",
> > > > for
> > > > signature "DMS"
> > > >
> > > > Installing sp, example("DMS-class") runs successfully interactively
> > > > (other examples do too).
> > > >
> > > > The methods pack
[Rd] round() increases or decreases (PR#9195)
Full_Name: Gael Millot Version: 2.3.1. OS: XP Submission from: (NULL) (195.220.102.23) Hello. I have a strange behavior with round() when it has to deal with 5. It sometimes rounds up, sometimes rounds down. Example : coma effect : > round(0.5,0) [1] 0 > round(0.25,1) [1] 0.2 > round(0.225,2) [1] 0.23 Previous number effect : > round(0.35,1) [1] 0.3 > round(0.45,1) [1] 0.5 It also happens with signif() Is it normal ? Many thanks. Gael. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Date conversion with as.POSIXct and as.POSIXlt (PR#9196)
Full_Name: Erich Neuwirth Version: 2.3.1 OS: Windows XP, Linux Submission from: (NULL) (131.130.135.167) Converting Sys.Date() to a POSIX compliant time type in different ways produces inconsistent results: > Sys.date() [1] "2006-09-01" > as.POSIXct(Sys.Date()) [1] "2006-09-01 02:00:00 CEST" > as.POSIXlt(Sys.Date()) [1] "2006-09-01" > as.POSIXct(as.POSIXlt(Sys.Date())) [1] "2006-09-01 01:00:00 CEST" Applying as.POSIXct directly or first applying as.POSIXlt and then applying as.POSIXct produces different results. This happens on Linux with timezone "CEST" > Sys.time() [1] "2006-09-01 11:03:36 CEST" and on Windows with timezone "W. Europe Daylight Time" > Sys.time() [1] "2006-09-01 11:11:15 W. Europe Daylight Time" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] round() increases or decreases (PR#9195)
G'day Gael, > "GM" == gael millot <[EMAIL PROTECTED]> writes: GM> I have a strange behavior with round() when it has to deal GM> with 5. [...] It also happens with signif() GM> Is it normal ? The "Details" section in the help page of round (?round or help(round)) suggests yes. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Date conversion with as.POSIXct and as.POSIXlt (PR#9196)
[EMAIL PROTECTED] writes:
> Full_Name: Erich Neuwirth
> Version: 2.3.1
> OS: Windows XP, Linux
> Submission from: (NULL) (131.130.135.167)
>
>
> Converting Sys.Date() to a POSIX compliant time type in different ways
> produces inconsistent results:
> > Sys.date()
> [1] "2006-09-01"
> > as.POSIXct(Sys.Date())
> [1] "2006-09-01 02:00:00 CEST"
> > as.POSIXlt(Sys.Date())
> [1] "2006-09-01"
> > as.POSIXct(as.POSIXlt(Sys.Date()))
> [1] "2006-09-01 01:00:00 CEST"
>
> Applying as.POSIXct directly or first applying as.POSIXlt and then
> applying as.POSIXct produces different results.
>
> This happens on Linux with timezone "CEST"
> > Sys.time()
> [1] "2006-09-01 11:03:36 CEST"
> and on Windows with timezone "W. Europe Daylight Time"
> > Sys.time()
> [1] "2006-09-01 11:11:15 W. Europe Daylight Time"
Or,
> as.POSIXct(Sys.Date()) - as.POSIXlt(Sys.Date())
Time difference of 1 hours
> as.POSIXct(Sys.time()) - as.POSIXlt(Sys.time())
Time difference of -0.0003409386 secs
Whereas
> Sys.putenv("TZ"="GMT")
> as.POSIXct(Sys.Date()) - as.POSIXlt(Sys.Date())
Time difference of 0 secs
and
> Sys.putenv("TZ"="EST")
> as.POSIXct(Sys.Date()) - as.POSIXlt(Sys.Date())
Time difference of -5 hours
So the difference is that as.POSIXct works in GMT whereas as.POSIXlt
works in the local timezone w/o DST corrections, the point of the
latter likely being that
> as.POSIXlt(as.Date("2006-7-1"))-as.POSIXlt(as.Date("2006-1-1"))
Time difference of 181 days
comes out as an integer number of days.
BTW, the habit of format.POSIXlt dropping off the time when it is
exactly 01:00 in CEST (i.e. would have been midnight, save for
Daylight Savings Time) is a bit confusing too...
I'm not sure any of this is actual bugs (Brian will tell us soon
enough), but it does appear at least to be underdocumented.
--
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] Date conversion with as.POSIXct and as.POSIXlt (PR#9196)
You misunderstand the role of timezones. as.POSIXct(Sys.Date()) is in UTC, as documented. as.POSIXlt(Sys.Date()) does not have a timezone (POSIXlt objects do not need one). as.POSIXct(as.POSIXlt(Sys.Date())) means as.POSIXct(as.POSIXlt(Sys.Date()), tz="") which is asking to interpret this in the local timezone. I've expanded the documentation, but I see no sign you had studied it so that it unlikely to help you. On Fri, 1 Sep 2006, [EMAIL PROTECTED] wrote: > Full_Name: Erich Neuwirth > Version: 2.3.1 > OS: Windows XP, Linux > Submission from: (NULL) (131.130.135.167) > > > Converting Sys.Date() to a POSIX compliant time type in different ways > produces inconsistent results: > > Sys.date() > [1] "2006-09-01" > > as.POSIXct(Sys.Date()) > [1] "2006-09-01 02:00:00 CEST" > > as.POSIXlt(Sys.Date()) > [1] "2006-09-01" > > as.POSIXct(as.POSIXlt(Sys.Date())) > [1] "2006-09-01 01:00:00 CEST" > > Applying as.POSIXct directly or first applying as.POSIXlt and then > applying as.POSIXct produces different results. > > This happens on Linux with timezone "CEST" > > Sys.time() > [1] "2006-09-01 11:03:36 CEST" > and on Windows with timezone "W. Europe Daylight Time" > > Sys.time() > [1] "2006-09-01 11:11:15 W. Europe Daylight Time" > > __ > 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] Date conversion with as.POSIXct and as.POSIXlt (PR#9196)
Note that there is some discussion in the help desk article in R News 4/1 and a table of tested conversions at the end of that article.If x is of class "Date" then for converting from Date to POSIXct the table suggests as.POSIXct(format(x)) or as.POSIXct(format(x), tz = "GMT") according to whether you want the current time zone or GMT. On 9/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Full_Name: Erich Neuwirth > Version: 2.3.1 > OS: Windows XP, Linux > Submission from: (NULL) (131.130.135.167) > > > Converting Sys.Date() to a POSIX compliant time type in different ways > produces inconsistent results: > > Sys.date() > [1] "2006-09-01" > > as.POSIXct(Sys.Date()) > [1] "2006-09-01 02:00:00 CEST" > > as.POSIXlt(Sys.Date()) > [1] "2006-09-01" > > as.POSIXct(as.POSIXlt(Sys.Date())) > [1] "2006-09-01 01:00:00 CEST" > > Applying as.POSIXct directly or first applying as.POSIXlt and then > applying as.POSIXct produces different results. > > This happens on Linux with timezone "CEST" > > Sys.time() > [1] "2006-09-01 11:03:36 CEST" > and on Windows with timezone "W. Europe Daylight Time" > > Sys.time() > [1] "2006-09-01 11:11:15 W. Europe Daylight Time" > > __ > 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] Date conversion with as.POSIXct and as.POSIXlt (PR#9196)
On Fri, 1 Sep 2006, Peter Dalgaard wrote: [...] > I'm not sure any of this is actual bugs (Brian will tell us soon > enough), but it does appear at least to be underdocumented. (Your message crossed mine.) I think it is not a bug and actually explicitly documented in ?as.POSIXlt. What may help those who have not read that documentation is to stick the UTC timezone on the conversion to POSIXlt. Getting > as.POSIXlt(Sys.Date()) [1] "2006-09-01 UTC" > as.POSIXct(as.POSIXlt(Sys.Date())) [1] "2006-09-01 UTC" > as.POSIXct(as.POSIXlt(Sys.Date()), tz="") [1] "2006-09-01 01:00:00 GMT Daylight Time" might be helpful to non-readers. -- 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] as.environment(NULL)
Hi
In NEWS, it says
R CMD check now tests that the package can be loaded, and that
the package and namespace (if there is one) can each be loaded
in startup code (before the standard packages are loaded).
For package "onion", I think I have followed all of
sections 1.6.1 - 1.6.6 of R-exts, and it passes R CMD check for
R-2.3.1.
However, using R version 2.4.0 Under development (unstable)
(2006-08-31 r39045)
under MacOSX 10.4.7, I get this:
* checking R files for non-ASCII characters ... OK
* checking whether the package can be loaded ... ERROR
Error in get("Re", pos = NULL, mode = "function") :
using 'as.environment(NULL)' is defunct
Error: unable to load R code in package 'onion'
Error: package/namespace load failed for 'onion'
Execution halted
It looks like this package has a loading problem: see the messages for
details.
in 00check.log.
I don't understand what I have to do to fix this.
In my NAMESPACE file there are lots of lines like this:
S3method("Re", quaternion)
S3method("Im", quaternion)
S3method("i", quaternion)
S3method("j", quaternion)
S3method("k", quaternion)
what do I have to do to make onion work under R-devel?
--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 changes - sp fails
On Fri, 1 Sep 2006, Roger Bivand wrote:
> On Fri, 1 Sep 2006, Prof Brian Ripley wrote:
>
> > Since writing that, I have found that there is a similar problem with
> > testing mvoutliers (which does load sp), and it depends on exactly what
> > has been done in what order. (I'll forward to you the exact description.)
On a different RHEL 4 i386 with R version 2.4.0 (2006-09-01 r39049), and
fully updated sp CVS from
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/r-spatial checkout sp
CND check sp passes with no error (with RColorBrewer the only installed
package in a test library).
I'll try again on the first machine (which is also RHEL 4 i386, but where
R was at 2006-08-31 r39045, and where there may have been configuration
issues (wrong library path?).
Roger
>
> Thanks.
>
> I reran the interactive test:
>
> library(sp, lib.loc="sp.Rcheck")
> example("DMS-class")
>
> which ran without problems.
>
> > .libPaths()
> [1] "/home/rsb/topics/r_libs"
> [2] "/home/rsb/topics/Rtobe240/lib/R/library"
> > list.files(.libPaths()[1])
> [1] "abind""maptools" "pixmap" "RColorBrewer" "R.css"
> [6] "rgdal""SparseM" "spdep""tripack"
> > sessionInfo()
> R version 2.4.0 Under development (unstable) (2006-08-31 r39045)
> i686-pc-linux-gnu
>
> locale:
> LC_CTYPE=en_GB;LC_NUMERIC=C;LC_TIME=en_GB;LC_COLLATE=en_GB;LC_MONETARY=en_GB;LC_
> MESSAGES=en_GB;LC_PAPER=en_GB;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREME
> NT=en_GB;LC_IDENTIFICATION=C
>
> attached base packages:
> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> [7] "base"
>
> other attached packages:
> sp
> "0.8-19"
>
> >
> > I now suspect there is a protection problem in the new S4 dispatch code.
> > Using gctorture/valgrind may help locate it.
>
> Running check --use-gct sp now.
>
> Roger
>
> >
> > Brian
> >
> > On Fri, 1 Sep 2006, Roger Bivand wrote:
> >
> > > On Fri, 1 Sep 2006, Prof Brian Ripley wrote:
> > >
> > > > Roger,
> > > >
> > > > I had managed to run R CMD check on sp successfully on r39021 and
> > > > r39043
> > > > (current) in my nightly checks. (There are a couple of tests where the
> > > > show/print method is not being invoked, but that is not new.)
> > > >
> > > > All I can suggest is to install R from scratch (make distclean), and
> > > > then
> > > > reinstall all relevant packages. At a guess, your interactive use and
> > > > R
> > > > CMD check are picking up different libraries.
> > >
> > > Brian,
> > >
> > > I added .libPaths() and sessionInfo() to the offending example, and tried
> > > with a fresh svn checkout built in a fresh directory and installed in a
> > > fresh directory (no sp or methods in /home/rsb/topics/r_libs, which was
> > > set with export R_LIBS=):
> > >
> > > > data(state)
> > > > .libPaths()
> > > [1] "/home/rsb/topics/packages/sp-bundle/sp.Rcheck"
> > > [2] "/home/rsb/topics/r_libs"
> > > [3] "/home/rsb/topics/Rtobe240/lib/R/library"
> > > > sessionInfo()
> > > R version 2.4.0 Under development (unstable) (2006-08-31 r39045)
> > > i686-pc-linux-gnu
> > >
> > > locale:
> > > LC_CTYPE=en_GB;LC_NUMERIC=C;LC_TIME=en_GB;LC_COLLATE=en_GB;LC_MONETARY=en_GB;LC_
> > > MESSAGES=en_GB;LC_PAPER=en_GB;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREME
> > > NT=en_GB;LC_IDENTIFICATION=C
> > >
> > > attached base packages:
> > > [1] "methods" "stats" "graphics" "grDevices" "utils"
> > > "datasets"
> > > [7] "base"
> > >
> > > other attached packages:
> > > sp
> > > "0.8-19"
> > > > dd2dms(state.center$x)
> > > Error in function (classes, fdef, mtable) :
> > > unable to find an inherited method for function "initialize", for
> > > signature "integer"
> > > Execution halted
> > >
> > > I also tried to replicate the problem by making a new, very small,
> > > package
> > > with just the apparently offending files:
> > >
> > > spS4:
> > > DESCRIPTION man/ NAMESPACE R/
> > >
> > > spS4/man:
> > > char2dms.Rd DMS-class.Rd
> > >
> > > spS4/R:
> > > AAA.R dms.R
> > >
> > > and edited DESCRIPTION, NAMESPACE, and AAA.R to suit. In this setting
> > > there was no problem. I'll carry on looking. None of these files has
> > > changed between released 0.8-18 and CVS 0.8-19.
> > >
> > > Roger
> > >
> > > >
> > > > There are around a dozen S4-using packages on CRAN that are currently
> > > > failing their checks: some look like newly-discovered bugs but some
> > > > look
> > > > like problems in S4 dispatch (even of S3 dispatch for S3 generics
> > > > turned
> > > > into S4 generics). More are producing apparently incorrect warnings.
> > > >
> > > > Brian
> > > >
> > > >
> > > > On Thu, 31 Aug 2006, Roger Bivand wrote:
> > > >
> > > > > Under R version 2.4.0 (2006-08-30 r39024), sp fails CMD check
> > > > > following
> > > > > the latest changes in methods.
> > > > >
> > > > > The failures are in running exa
Re: [Rd] as.environment(NULL)
Your code contains
onion.R:"Re.default" <- get("Re",pos=NULL,mode="function")
onion.R:"Im.default" <- get("Im",pos=NULL,mode="function")
and has been giving deprecated warnings for a while (and ?get does not say
NULL is allowable). The relevant NEWS item is
o Use of NULL as an environment is now an error.
You need pos="package:base" there.
On Fri, 1 Sep 2006, Robin Hankin wrote:
> Hi
>
> In NEWS, it says
>
> R CMD check now tests that the package can be loaded, and that
> the package and namespace (if there is one) can each be loaded
> in startup code (before the standard packages are loaded).
>
>
> For package "onion", I think I have followed all of
> sections 1.6.1 - 1.6.6 of R-exts, and it passes R CMD check for
> R-2.3.1.
>
>
> However, using R version 2.4.0 Under development (unstable)
> (2006-08-31 r39045)
> under MacOSX 10.4.7, I get this:
>
>
> * checking R files for non-ASCII characters ... OK
> * checking whether the package can be loaded ... ERROR
> Error in get("Re", pos = NULL, mode = "function") :
> using 'as.environment(NULL)' is defunct
> Error: unable to load R code in package 'onion'
> Error: package/namespace load failed for 'onion'
> Execution halted
>
> It looks like this package has a loading problem: see the messages for
> details.
>
>
>
>
>
> in 00check.log.
>
> I don't understand what I have to do to fix this.
> In my NAMESPACE file there are lots of lines like this:
>
>
> S3method("Re", quaternion)
> S3method("Im", quaternion)
> S3method("i", quaternion)
> S3method("j", quaternion)
> S3method("k", quaternion)
>
>
> what do I have to do to make onion work under R-devel?
>
>
>
> --
> Robin Hankin
> Uncertainty Analyst
> National Oceanography Centre, Southampton
> European Way, Southampton SO14 3ZH, UK
> tel 023-8059-7743
>
> __
> 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] [<-.POSIXlt changes order of attributes (PR#9197)
This is a multi-part message in MIME format.
--090203020600020104020707
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Hello!
I was doing some tests with identical() and found out that [<-.POSIXlt
method changes order of attributes. This example shows that:
x <- strptime("1900-1-1", format="%Y-%m-%d")
x <- c(x)
y <- c(x, x+1)
x1 <- x
y1 <- y
attributes(x)
$names
[1] "sec" "min" "hour" "mday" "mon" "year" "wday" "yday" "isdst"
$class
[1] "POSIXt" "POSIXlt"
$tzone
[1] "" "CET" "CEST"
identical(attributes(x), attributes(y))
TRUE
x[1] <- NA
attributes(x)
$names
[1] "sec" "min" "hour" "mday" "mon" "year" "wday" "yday" "isdst"
$tzone
[1] "" "CET" "CEST"
$class
[1] "POSIXt" "POSIXlt"
y[1] <- NA
attributes(y)
$names
[1] "sec" "min" "hour" "mday" "mon" "year" "wday" "yday" "isdst"
$tzone
[1] "" "CET" "CEST"
$class
[1] "POSIXt" "POSIXlt"
identical(attributes(x), attributes(x1))
FALSE
identical(attributes(y), attributes(y1))
FALSE
This can be solved with either:
Index: R/src/library/base/R/datetime.R
===
--- R/src/library/base/R/datetime.R (revision 39045)
+++ R/src/library/base/R/datetime.R (working copy)
@@ -713,10 +713,10 @@
{
if(!as.logical(length(value))) return(x)
value <- as.POSIXlt(value)
-cl <- oldClass(x)
+att <- attributes(x)
class(x) <- class(value) <- NULL
for(n in names(x)) x[[n]][i] <- value[[n]]
-class(x) <- cl
+attributes(x) <- att
x
}
or in the same way as it is done in [.<-POSIXct method
Index: R/src/library/base/R/datetime.R
===
--- R/src/library/base/R/datetime.R (revision 39045)
+++ R/src/library/base/R/datetime.R (working copy)
@@ -714,9 +714,11 @@
if(!as.logical(length(value))) return(x)
value <- as.POSIXlt(value)
cl <- oldClass(x)
+tz <- attr(x, "tzone")
class(x) <- class(value) <- NULL
for(n in names(x)) x[[n]][i] <- value[[n]]
class(x) <- cl
+attr(x, "tzone") <- tz
x
}
I have checked both versions in r-devel with make check-all and all went
fine.
Regards, Gregor
--
Lep pozdrav / With regards,
Gregor Gorjanc
--
University of Ljubljana PhD student
Biotechnical Faculty
Zootechnical Department URI: http://www.bfro.uni-lj.si/MR/ggorjan
Groblje 3 mail: gregor.gorjanc bfro.uni-lj.si
SI-1230 Domzale tel: +386 (0)1 72 17 861
Slovenia, Europefax: +386 (0)1 72 17 888
--
"One must learn by doing the thing; for though you think you know it,
you have no certainty until you try." Sophocles ~ 450 B.C.
--
--090203020600020104020707
Content-Type: application/x-gzip;
name="datetime.R.patchVer1.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="datetime.R.patchVer1.gz"
H4sICH7v90QCA2RhdGV0aW1lLlIucGF0Y2hWZXIxAKVOz0vDMBQ+m7/ieUvosmxMGYpCwdNg
qFSEQekhTbMazBJJ0tkh/u+atE5vO/guyft+vW9lGtlfQ8G8E0yr2nF3YDX3khWs4UEGtZPT
At3+fxCl9NSdM+zkXnllDSyuZheXBGVZdtr0bt2rMi0I+3YgKM+BLueLyXwG2fjmOYIPBHHU
Fp9zP9W2VYJrrKVpwwvec91JQgg4GTpncE8GdcLhhsK35fHhabXRYdQiGnmhI2l1c6e599GW
RZiHkEwhOFV3QfpjoBh1kR7+Q1zc75/X60G1tQ4bUAYM3yUzgb4sTVWVqorK5EnAT42/qccO
v8fHNkN6j+ATAfoCTtG/r/sBAAA=
--090203020600020104020707
Content-Type: application/x-gzip;
name="datetime.R.patchVer2.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="datetime.R.patchVer2.gz"
H4sICCXw90QCA2RhdGV0aW1lLlIucGF0Y2hWZXIyAKWOwUoDMRCGz+Ypxp4S0jQuVqSisOCp
UFRWBGHZQ7qbrsE0kSSt6YLvrtmIBxF6cC5J/vm+mSxNJ+MVVNy7lmu1dsId+Fp4ySveiSCD
2spZhW7+X4gxdmzPCXZyr7yyBs4XZ/MLgiilx6V3616V6aG1bweCyhLYZTGfLoCmoyigLBGk
Uht8KvxM2161QmMtTR9e8F7onSSEgJNh5wyOJNNjDtcMvpSH+8flsw7fbO63OjWt7m618D5p
NMVhGJ0QHI5TmITBGjn5UTKZiHzPA9P77mm1ytTGOmxAGTBiKxNOINa1aZpaNYkcnTH4a2r+
xe/9qReGzEcEHwjQJ/Ktnoj7AQAA
--090203020600020104020707--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Date conversion with as.POSIXct and as.POSIXlt (PR#9196)
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> On Fri, 1 Sep 2006, Peter Dalgaard wrote:
>
> [...]
>
> > I'm not sure any of this is actual bugs (Brian will tell us soon
> > enough), but it does appear at least to be underdocumented.
>
> (Your message crossed mine.)
>
> I think it is not a bug and actually explicitly documented in ?as.POSIXlt.
> What may help those who have not read that documentation is to stick the
> UTC timezone on the conversion to POSIXlt. Getting
Hmmm, which part of ?as.POSIXlt didn't I understand? I can't seem to
spot anything pointing to -lt being different from -ct conversion (in
a week-old version of r-devel). What I do see is:
The 'as.POSIX*' functions convert an object to one of the two
classes used to represent date/times (calendar dates plus time to
the nearest second). They can convert a wide variety of objects,
including objects of the other class and of classes '"Date"',
'"date"' (from package 'date' or 'survival'), '"chron"' and
'"dates"' (from package 'chron') to these classes. Dates are
treated as being at midnight UTC.
The last sentence would appear not to be true for as.POSIXlt; dates
are treated as midnight in the _current_ timezone ignoring DST (which
of course is undetectable in Oxford because that _is_ UTC in your
timezone) .
> > as.POSIXlt(Sys.Date())
> [1] "2006-09-01 UTC"
> > as.POSIXct(as.POSIXlt(Sys.Date()))
> [1] "2006-09-01 UTC"
> > as.POSIXct(as.POSIXlt(Sys.Date()), tz="")
> [1] "2006-09-01 01:00:00 GMT Daylight Time"
>
> might be helpful to non-readers.
I have
> as.POSIXct(as.POSIXlt(Sys.Date()), tz="")
[1] "2006-09-01 01:00:00 CEST"
and of course the whole issue is that
> dput(as.POSIXlt(Sys.Date(), tz="UTC"))
structure(list(sec = 0, min = 0, hour = 0, mday = 1, mon = 8,
year = 106, wday = 5, yday = 243, isdst = 0), .Names = c("sec",
"min", "hour", "mday", "mon", "year", "wday", "yday", "isdst"
), class = c("POSIXt", "POSIXlt"))
> dput(as.POSIXlt(Sys.Date()))
structure(list(sec = 0, min = 0, hour = 0, mday = 1, mon = 8,
year = 106, wday = 5, yday = 243, isdst = 0), .Names = c("sec",
"min", "hour", "mday", "mon", "year", "wday", "yday", "isdst"
), class = c("POSIXt", "POSIXlt"))
are exactly the same -- the tz arg is ignored.
The documentation in ?POSIXlt does have some hints about POSIXlt being
converted to current locale, but I still find the whole thing a bit
unclear.
--
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] Date conversion with as.POSIXct and as.POSIXlt (PR#9196)
On Fri, 1 Sep 2006, Peter Dalgaard wrote: > Prof Brian Ripley <[EMAIL PROTECTED]> writes: > > > On Fri, 1 Sep 2006, Peter Dalgaard wrote: > > > > [...] > > > > > I'm not sure any of this is actual bugs (Brian will tell us soon > > > enough), but it does appear at least to be underdocumented. > > > > (Your message crossed mine.) > > > > I think it is not a bug and actually explicitly documented in ?as.POSIXlt. > > What may help those who have not read that documentation is to stick the > > UTC timezone on the conversion to POSIXlt. Getting > > Hmmm, which part of ?as.POSIXlt didn't I understand? I can't seem to > spot anything pointing to -lt being different from -ct conversion (in > a week-old version of r-devel). What I do see is: > > The 'as.POSIX*' functions convert an object to one of the two > classes used to represent date/times (calendar dates plus time to > the nearest second). They can convert a wide variety of objects, > including objects of the other class and of classes '"Date"', > '"date"' (from package 'date' or 'survival'), '"chron"' and > '"dates"' (from package 'chron') to these classes. Dates are > treated as being at midnight UTC. > > The last sentence would appear not to be true for as.POSIXlt; dates > are treated as midnight in the _current_ timezone ignoring DST (which > of course is undetectable in Oxford because that _is_ UTC in your > timezone) . As it tells you it was treated as being in UTC, you need to tell subsequent conversions that it is a time in UTC, e.g. as.POSIXct(as.POSIXlt(Sys.Date()), tz="UTC") It is as.POSIXct() that is doing 'dates are treated as midnight in the _current_ timezone ignoring DST', and that is what the documentation of argument 'tz' says will happen. (Since UTC has no DST, it has specified that DST is not in effect, as that is part of a POSIXlt object.) In your version of R, as.POSIXlt(Sys.Date()) did not specify a timezone (they are optional). Now it does. > The documentation in ?POSIXlt does have some hints about POSIXlt being > converted to current locale, but I still find the whole thing a bit > unclear. Which is why I have (I hope) clarified it so tz="UTC" is not needed explicitly anymore. -- 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] S4 changes - sp fails
General comments. A number of packages will likely be showing weird
warnings on attach() about packages being out of date. Likely caused by
a confusion when two packages define the same generic. The bug is being
worked on, but there are some issues of package design that will need
discussion later.
Early revisions with the new code did have a C-level problem but that is
now fixed AFAIK, so any hard evidence of protection problems would be
valuable.
There have been some changes, up to svn revision 39037 at the moment,
but there will be some more. All reports are appreciated. Some are
easier for me to check out than others (I'm working from a home setup
that does not have all of CRAN available (!) so it takes time to test a
package with many dependencies in "CMD check"s view of things.)
John
Roger Bivand wrote:
> On Fri, 1 Sep 2006, Roger Bivand wrote:
>
>
>> On Fri, 1 Sep 2006, Prof Brian Ripley wrote:
>>
>>
>>> Since writing that, I have found that there is a similar problem with
>>> testing mvoutliers (which does load sp), and it depends on exactly what
>>> has been done in what order. (I'll forward to you the exact description.)
>>>
>
> On a different RHEL 4 i386 with R version 2.4.0 (2006-09-01 r39049), and
> fully updated sp CVS from
>
> cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/r-spatial checkout sp
>
> CND check sp passes with no error (with RColorBrewer the only installed
> package in a test library).
>
> I'll try again on the first machine (which is also RHEL 4 i386, but where
> R was at 2006-08-31 r39045, and where there may have been configuration
> issues (wrong library path?).
>
> Roger
>
>
>> Thanks.
>>
>> I reran the interactive test:
>>
>> library(sp, lib.loc="sp.Rcheck")
>> example("DMS-class")
>>
>> which ran without problems.
>>
>>
>>> .libPaths()
>>>
>> [1] "/home/rsb/topics/r_libs"
>> [2] "/home/rsb/topics/Rtobe240/lib/R/library"
>>
>>> list.files(.libPaths()[1])
>>>
>> [1] "abind""maptools" "pixmap" "RColorBrewer" "R.css"
>>
>> [6] "rgdal""SparseM" "spdep""tripack"
>>
>>> sessionInfo()
>>>
>> R version 2.4.0 Under development (unstable) (2006-08-31 r39045)
>> i686-pc-linux-gnu
>>
>> locale:
>> LC_CTYPE=en_GB;LC_NUMERIC=C;LC_TIME=en_GB;LC_COLLATE=en_GB;LC_MONETARY=en_GB;LC_
>> MESSAGES=en_GB;LC_PAPER=en_GB;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREME
>> NT=en_GB;LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
>> [7] "base"
>>
>> other attached packages:
>> sp
>> "0.8-19"
>>
>>
>>> I now suspect there is a protection problem in the new S4 dispatch code.
>>> Using gctorture/valgrind may help locate it.
>>>
>> Running check --use-gct sp now.
>>
>> Roger
>>
>>
>>> Brian
>>>
>>> On Fri, 1 Sep 2006, Roger Bivand wrote:
>>>
>>>
On Fri, 1 Sep 2006, Prof Brian Ripley wrote:
> Roger,
>
> I had managed to run R CMD check on sp successfully on r39021 and r39043
> (current) in my nightly checks. (There are a couple of tests where the
> show/print method is not being invoked, but that is not new.)
>
> All I can suggest is to install R from scratch (make distclean), and then
> reinstall all relevant packages. At a guess, your interactive use and R
> CMD check are picking up different libraries.
>
Brian,
I added .libPaths() and sessionInfo() to the offending example, and tried
with a fresh svn checkout built in a fresh directory and installed in a
fresh directory (no sp or methods in /home/rsb/topics/r_libs, which was
set with export R_LIBS=):
> data(state)
> .libPaths()
>
[1] "/home/rsb/topics/packages/sp-bundle/sp.Rcheck"
[2] "/home/rsb/topics/r_libs"
[3] "/home/rsb/topics/Rtobe240/lib/R/library"
> sessionInfo()
>
R version 2.4.0 Under development (unstable) (2006-08-31 r39045)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_GB;LC_NUMERIC=C;LC_TIME=en_GB;LC_COLLATE=en_GB;LC_MONETARY=en_GB;LC_
MESSAGES=en_GB;LC_PAPER=en_GB;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREME
NT=en_GB;LC_IDENTIFICATION=C
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
other attached packages:
sp
"0.8-19"
> dd2dms(state.center$x)
>
Error in function (classes, fdef, mtable) :
unable to find an inherited method for function "initialize", for
signature "integer"
Execution halted
I also tried to replicate the problem by making a new, very small, package
with just the apparently offending files:
spS4:
>>
Re: [Rd] Date conversion with as.POSIXct and as.POSIXlt (PR#9196)
On 1 September 2006 at 06:25, Gabor Grothendieck wrote: | Note that there is some discussion in the help desk article | in R News 4/1 and a table of tested conversions at | the end of that article.If x is of class "Date" then for | converting from Date to POSIXct the table suggests | as.POSIXct(format(x)) or as.POSIXct(format(x), tz = "GMT") | according to whether you want the current time zone or GMT. Could we get something like this table into the on-line documentation? Incidentally, just yesterday I was just mud-wrestling the same DST and TZ issue ... Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] setMethod("Logic", ...)
Hi
In V&R the "polynomial" class is explicitly specified to have no
logical operators:
setMethod("Logic", signature(e1="polynomial"), function(e1,e2){stop
("...")})
I too have a class of objects for which I want to
specify that Logic operators do not work, but executing
setClass("brob",
representation = representation
(x="numeric",positive="logical"),
prototype = list(x=numeric(),positive=logical())
)
setMethod("Logic",signature(e1="brob"), function(e1,e2)
{
stop("No logic currently implemented for brob objects")
}
)
gives me
Error in setMethod("Logic", signature(e1 = "brob"), function(e1, e2) { :
no existing definition for function 'Logic'
?Math seems to imply that there is no "Logic" group.
So, what is the correct way to specify that logical operations are
not allowed for "brob" objects?
--
Robin Hankin
Uncertainty Analyst
National Oceanography Centre, Southampton
European Way, Southampton SO14 3ZH, UK
tel 023-8059-7743
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crashes in Mac OS 10.4 when Find is used (PR#9192)
Matt, This is not an R bug or r-devel issue. The proper email list is R-SIG- Mac. Maybe the 1st step we can try is to install the latest version of the R.app, which you can find at http://r.research.att.com/ . Can you please download the nightly build of just the R.app GUI and see if the problem still occurs? I have tried many times on my system and can't reproduce the problem. Thanks, Rob On Aug 31, 2006, at 7:42 AM, [EMAIL PROTECTED] wrote: > Full_Name: Matt Fantle > Version: 1.16 > OS: Mac OS 10.4.7 > Submission from: (NULL) (128.118.174.213) > > > Problem: R crashes when 'Command-f' is pressed to begin "Find" > Frequency: This problem is intermittant. Once R crashes, the only > solution is > to restart R and try to Find again. There is no regularity to the > problem. If > R is opened by double-clicking on a ".R" file, the problem might be > there. If R > is opened by double-clicking the application or alias, the problem > may also > still be there. > > Log report: > OS Version: 10.4.7 (Build 8J135) > Report Version: 4 > > Command: R > Path:/Applications/R.app/Contents/MacOS/R > Parent: WindowServer [60] > > Version: 1.16 (3198) > > PID:474 > Thread: 0 > > Exception: EXC_BREAKPOINT (0x0006) > Code[0]:0x0001 > Code[1]:0x9295f120 > > > Thread 0 Crashed: > 0 com.apple.Foundation 0x9295f120 _NSRaiseError + 264 > 1 com.apple.AppKit 0x937c9274 -[NSCarbonMenuImpl > performActionWithHighlightingForItemAtIndex:] + 160 > 2 com.apple.AppKit 0x937c8ce4 -[NSMenu > performKeyEquivalent:] + 272 > 3 com.apple.AppKit 0x937c88c4 -[NSApplication > _handleKeyEquivalent:] > + 220 > 4 com.apple.AppKit 0x936d2408 -[NSApplication > sendEvent:] + 2944 > 5 org.R-project.R 0xb730 -[RController > handleReadConsole:] + 88 > (RController.m:869) > 6 org.R-project.R 0x0002c0b8 Re_ReadConsole + 108 > (Rcallbacks.m:137) > 7 org.R-project.R 0x0003223c run_REngineRmainloop + 300 > (Rinit.c:341) > 8 org.R-project.R 0x0002aa1c -[REngine runREPL] + 68 > (REngine.m:167) > 9 org.R-project.R 0x0001d340 main + 680 (main.m:101) > 10 org.R-project.R 0x2e8c _start + 340 (crt.c:272) > 11 org.R-project.R 0x2d34 start + 60 > > Thread 1: > 0 libSystem.B.dylib 0x9000b268 mach_msg_trap + 8 > 1 libSystem.B.dylib 0x9000b1bc mach_msg + 60 > 2 com.apple.CoreFoundation 0x907dbb78 __CFRunLoopRun + 832 > 3 com.apple.CoreFoundation 0x907db47c CFRunLoopRunSpecific + 268 > 4 com.apple.Foundation 0x92939598 -[NSConnection > sendInvocation:] + 1468 > 5 com.apple.Foundation 0x92938034 -[NSObject > (NSForwardInvocation) > forward::] + 408 > 6 libobjc.A.dylib 0x90a430b0 _objc_msgForward + 176 > 7 com.apple.Foundation 0x9293839c -[NSDistantObject > methodSignatureForSelector:] + 268 > 8 com.apple.Foundation 0x92937f04 -[NSObject > (NSForwardInvocation) > forward::] + 104 > 9 libobjc.A.dylib 0x90a430b0 _objc_msgForward + 176 > 10 org.R-project.R 0xacc0 -[RController readThread:] > + 2436 > (RController.m:613) > 11 com.apple.Foundation 0x92944194 forkThreadForFunction + 108 > 12 libSystem.B.dylib 0x9002bc28 _pthread_body + 96 > > Thread 2: > 0 libSystem.B.dylib 0x9002c2e8 semaphore_wait_signal_trap > + 8 > 1 libSystem.B.dylib 0x90030dcc pthread_cond_wait + 480 > 2 com.apple.Foundation 0x9294b300 -[NSConditionLock > lockWhenCondition:] + > 68 > 3 com.apple.AppKit 0x9376a708 -[NSUIHeartBeat > _heartBeatThread:] + > 324 > 4 com.apple.Foundation 0x92944194 forkThreadForFunction + 108 > 5 libSystem.B.dylib 0x9002bc28 _pthread_body + 96 > > Thread 3: > 0 libSystem.B.dylib 0x9000b268 mach_msg_trap + 8 > 1 libSystem.B.dylib 0x9000b1bc mach_msg + 60 > 2 com.apple.CoreFoundation 0x907dbb78 __CFRunLoopRun + 832 > 3 com.apple.CoreFoundation 0x907db47c CFRunLoopRunSpecific + 268 > 4 com.apple.Foundation 0x9296b69c > +[NSURLConnection(NSURLConnectionInternal) _resourceLoadLoop:] + 264 > 5 com.apple.Foundation 0x92944194 forkThreadForFunction + 108 > 6 libSystem.B.dylib 0x9002bc28 _pthread_body + 96 > > Thread 4: > 0 libSystem.B.dylib 0x9000b268 mach_msg_trap + 8 > 1 libSystem.B.dylib 0x9000b1bc mach_msg + 60 > 2 com.apple.CoreFoundation 0x907dbb78 __CFRunLoopRun + 832 > 3 com.apple.CoreFoundation 0x907db47c CFRunLoopRunSpecific + 268 > 4 com.apple.Foundation 0x9296c7dc +[NSURLCache > _diskCacheSyncLoop:] + > 152 > 5 com.apple.Foundation 0x92944194 forkThreadForFunction + 108 > 6 libSystem.B.dylib 0x9002bc28 _pthread_body + 96 > > Thread 5: > 0 libSystem.B.dylib 0x9000b268 mach_msg_trap + 8 > 1 libSystem.B.dylib 0x9000b1bc mach_msg + 60 > 2 com.apple.CoreFoundation 0x907dbb78 __CFRunLoopRun + 8
Re: [Rd] Thai locale not working on Mac OSX (PR#9175)
th_TH does not exist at locale of OSX. I should be able to handle Thai character string in UTF-8 locale such as en_US.UTF-8. There is also a method of preparing th_TH local with localedef. 2006/8/27, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > Full_Name: Hutcha Sriplung > Version: R-2.3.1 > OS: Mac OSX > Submission from: (NULL) (61.90.155.1) > > > I am using Mac OSX 10.4.7 and find that locale setting is not working > properly. > > > > Sys.getlocale() > [1] "C" > > Sys.setlocale(category="LC_ALL",locale="th_TH") > [1] "C" > > When I change locale to some other languages such as french, chinese, and > japanese, it works fine but not with some other languages such as Bahasa > Indonesia and Bahasa Malaysia. Thai locale is OK on Windows and Linux. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > > -- EI-JI Nakama <[EMAIL PROTECTED]> "\u4e2d\u9593\u6804\u6cbb" <[EMAIL PROTECTED]> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] read.ssd (foreign) 'wishes': enable long variable names, add output object to windows example
Hello,
A couple of quick 'wishes' for read.ssd in the foreign package:
1) Enable long variable names by adding 'options validvarname=v6;' line
directly before doing 'proc copy', e.g. (from my own alteration of
read.ssd):
#export the data
st7 <- "options validvarname=v6;\n"
st8 <- paste("proc copy in=src2rd out=rd;\n")
st9 <- paste("select", "tempfile", ";\n", sep = " ")
...and corresponding 'cat' to 'tmpProg', of course.
2) Add output object to windows example in the help file. In v0.8-15
help file for 'foreign', no object is indicated, causing R to kill the
output if run as-is - potentially confusing for newbies.
Thank you for this useful function!
-Greg
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overriding InitTempDir
Jeffrey Horner wrote:
> For embedded projects, one may want to eliminate the per-session temp
> directory created by InitTempDir() and just use a system-specific temp
> directory. Here's my solution:
>
> extern char *R_TempDir;
>
> void my_InitTempDir()
> {
> char *tmp;
>
> if (R_TempDir){
> if (rmdir(R_TempDir) != 0){
> perror("Fatal Error: could not remove R's TempDir!");
> exit(1);
> }
> }
>
> tmp = getenv("TMPDIR");
> if (tmp == NULL) {
> tmp = getenv("TMP");
> if (tmp == NULL) {
> tmp = getenv("TEMP");
> if (tmp == NULL)
> tmp = "/tmp";
> }
> }
>
> R_TempDir=tmp;
>
> if (setenv("R_SESSION_TMPDIR",tmp,1) != 0){
> perror("Fatal Error: couldn't set/replace R_SESSION_TMPDIR!");
> exit(1);
> }
> }
>
> This function is called after Rf_initEmbeddedR; it's seems like a hack
> but it works. Does anyone have other solutions?
I just found a fault with the above solution, but only if a program that
embeds R calls the R edit function; highly unlikely. Nevertheless, It
turns out that soon after InitTempDir is called, InitEd is called and
sets the variable DefaultFileName (which is hidden by storage class
static, unlike R_TempDir) to a temporary filename located in the
directory which was just deleted by my_initTempDir.
> Maybe InitTempDir could check if R_TempDir was not NULL and then just
> return.
So it would be nice if the above (InitTempDir only creating a directory
when R_TempDir is NULL) could be added to R-trunk.
Note also that in the case that R_TempDir is set to a system-specific
temp directory, the program would then have to set it back to NULL as
the new function Rf_endEmbeddedR now tests to see if R_TempDir has been set:
/* use fatal !=0 for emergency bail out */
void Rf_endEmbeddedR(int fatal)
{
unsigned char buf[1024];
char * tmpdir;
R_RunExitFinalizers();
CleanEd();
if(!fatal) KillAllDevices();
if((tmpdir = R_TempDir)) {
snprintf((char *)buf, 1024, "rm -rf %s", tmpdir);
R_system((char *)buf);
}
if(!fatal && R_CollectWarnings)
PrintWarnings();/* from device close and .Last */
fpu_setup(FALSE);
}
Jeff
--
http://biostat.mc.vanderbilt.edu/JeffreyHorner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [<-.POSIXlt changes order of attributes (PR#9197)
Please point us to the documentation that says attributes are ordered.
E.g. R-lang.texi says
All objects except @code{NULL} can have one or more attributes attached
to them. Attributes are stored as a list where all elements are named.
(although in fact they are stored in a pairlist).
I know of tens of functions that change the order of attributes, and
did look at teaching identical() that they are not ordered. But
since they are stored as a pairlist, it would be quite expensive.
(Given that attributes seem to be growing in use, another internal storage
mechanism is becoming more appropriate.)
BTW, all.equal() does not assume attributes are ordered.
On Fri, 1 Sep 2006, [EMAIL PROTECTED] wrote:
> This is a multi-part message in MIME format.
> --090203020600020104020707
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 7bit
>
> Hello!
>
> I was doing some tests with identical() and found out that [<-.POSIXlt
> method changes order of attributes. This example shows that:
>
> x <- strptime("1900-1-1", format="%Y-%m-%d")
> x <- c(x)
> y <- c(x, x+1)
> x1 <- x
> y1 <- y
>
> attributes(x)
> $names
> [1] "sec" "min" "hour" "mday" "mon" "year" "wday" "yday" "isdst"
>
> $class
> [1] "POSIXt" "POSIXlt"
>
> $tzone
> [1] "" "CET" "CEST"
>
> identical(attributes(x), attributes(y))
> TRUE
>
> x[1] <- NA
> attributes(x)
> $names
> [1] "sec" "min" "hour" "mday" "mon" "year" "wday" "yday" "isdst"
>
> $tzone
> [1] "" "CET" "CEST"
>
> $class
> [1] "POSIXt" "POSIXlt"
>
> y[1] <- NA
> attributes(y)
> $names
> [1] "sec" "min" "hour" "mday" "mon" "year" "wday" "yday" "isdst"
>
> $tzone
> [1] "" "CET" "CEST"
>
> $class
> [1] "POSIXt" "POSIXlt"
>
> identical(attributes(x), attributes(x1))
> FALSE
>
> identical(attributes(y), attributes(y1))
> FALSE
>
> This can be solved with either:
>
> Index: R/src/library/base/R/datetime.R
> ===
> --- R/src/library/base/R/datetime.R (revision 39045)
> +++ R/src/library/base/R/datetime.R (working copy)
> @@ -713,10 +713,10 @@
> {
> if(!as.logical(length(value))) return(x)
> value <- as.POSIXlt(value)
> -cl <- oldClass(x)
> +att <- attributes(x)
> class(x) <- class(value) <- NULL
> for(n in names(x)) x[[n]][i] <- value[[n]]
> -class(x) <- cl
> +attributes(x) <- att
> x
> }
>
> or in the same way as it is done in [.<-POSIXct method
>
> Index: R/src/library/base/R/datetime.R
> ===
> --- R/src/library/base/R/datetime.R (revision 39045)
> +++ R/src/library/base/R/datetime.R (working copy)
> @@ -714,9 +714,11 @@
> if(!as.logical(length(value))) return(x)
> value <- as.POSIXlt(value)
> cl <- oldClass(x)
> +tz <- attr(x, "tzone")
> class(x) <- class(value) <- NULL
> for(n in names(x)) x[[n]][i] <- value[[n]]
> class(x) <- cl
> +attr(x, "tzone") <- tz
> x
> }
>
> I have checked both versions in r-devel with make check-all and all went
> fine.
>
> Regards, Gregor
>
>
>
--
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] Overriding InitTempDir
It is conventional for people proposing changes to R to set out a
compelling case as to why they are needed. I have not seen any case here.
Can we please have one?
Someone will have to think through the ramifications of such a change (and
BTW using edit() in an R console is not at all unlikely), and continue to
maintain it for years to come. I have to say that in the past I have
accepted quite a few user suggestions that became maintenance nightmares,
so I have become very wary.
It's not really a good time: R-devel is about to start solidifying towards
2.4.0, and we have quite a few issues to work through (e.g. the internal
changes to S4 methods).
On Fri, 1 Sep 2006, Jeffrey Horner wrote:
> Jeffrey Horner wrote:
> > For embedded projects, one may want to eliminate the per-session temp
> > directory created by InitTempDir() and just use a system-specific temp
> > directory. Here's my solution:
> >
> > extern char *R_TempDir;
> >
> > void my_InitTempDir()
> > {
> > char *tmp;
> >
> > if (R_TempDir){
> > if (rmdir(R_TempDir) != 0){
> > perror("Fatal Error: could not remove R's TempDir!");
> > exit(1);
> > }
> > }
> >
> > tmp = getenv("TMPDIR");
> > if (tmp == NULL) {
> > tmp = getenv("TMP");
> > if (tmp == NULL) {
> > tmp = getenv("TEMP");
> > if (tmp == NULL)
> > tmp = "/tmp";
> > }
> > }
> >
> > R_TempDir=tmp;
> >
> > if (setenv("R_SESSION_TMPDIR",tmp,1) != 0){
> > perror("Fatal Error: couldn't set/replace R_SESSION_TMPDIR!");
> > exit(1);
> > }
> > }
> >
> > This function is called after Rf_initEmbeddedR; it's seems like a hack
> > but it works. Does anyone have other solutions?
>
> I just found a fault with the above solution, but only if a program that
> embeds R calls the R edit function; highly unlikely. Nevertheless, It
> turns out that soon after InitTempDir is called, InitEd is called and
> sets the variable DefaultFileName (which is hidden by storage class
> static, unlike R_TempDir) to a temporary filename located in the
> directory which was just deleted by my_initTempDir.
>
> > Maybe InitTempDir could check if R_TempDir was not NULL and then just
> > return.
>
> So it would be nice if the above (InitTempDir only creating a directory
> when R_TempDir is NULL) could be added to R-trunk.
>
> Note also that in the case that R_TempDir is set to a system-specific
> temp directory, the program would then have to set it back to NULL as
> the new function Rf_endEmbeddedR now tests to see if R_TempDir has been set:
>
> /* use fatal !=0 for emergency bail out */
> void Rf_endEmbeddedR(int fatal)
> {
> unsigned char buf[1024];
> char * tmpdir;
>
> R_RunExitFinalizers();
> CleanEd();
> if(!fatal) KillAllDevices();
> if((tmpdir = R_TempDir)) {
> snprintf((char *)buf, 1024, "rm -rf %s", tmpdir);
> R_system((char *)buf);
> }
> if(!fatal && R_CollectWarnings)
> PrintWarnings();/* from device close and .Last */
> fpu_setup(FALSE);
> }
>
> Jeff
>
--
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] Interface for package supplied random number generator
This really is not a good time for us (and apparently you've know about this for a year). Could you come back to it once 2.4.0 is released (due Oct 23)? [We are busy with getting R-devel ready for 2.4.0, and I think that other mechanisms for this have been mooted, again at a time which was not opportune.] On Thu, 31 Aug 2006, Josef Leydold wrote: > Hi, > > As you probably know, there is a problem with the interface for adding uniform > random number generators in R (see by article in R News 5/2, November 2005). > There exists a mechanism called "user-supplied" that allows users of R > to run their own generator in R. However, there is no such mechanism for > package writers. Those who want to add their own generators abuse > RNGkind(kind="user-supplied") for their purpose. > The problem with this approach is that it relies on the unique existence of > the > function "user_unif_rand". When two packages are loaded that use this > interface, > then at least one package is broken. If the user herself loads a shared > library > that contains such a function, some of the functionalities of all the > corresponding packages are broken. > > When writing my paper I found the following packages on CRAN that abuse this > interface (meanwhile there might be more packages): > > randaes_0.1.tar.gz > rlecuyer_0.1.tar.gz > rsprng_0.3-1.tar.gz > rstream_1.1.tar.gz > SuppDists_1.0-13.tar.gz > > what makes the situation even more complicated is the fact that some of these > packages are loaded automaticall by other packages. > For example, package 'rlecuyer' is loaded by > > snow_0.2-1.tar.gz > snowFT_0.0-1.tar.gz > varSelRF_0.6-2.tar.gz > > To solve this problem, Stefan Theussl and I have tried to extend the mechanism > for random number generators in the following way: > > - we have added a new kind of generators: "package-supplied" > > - this generator kind needs functions named 'package_unif_rand', > 'package_unif_init', > 'package_unif_nseed', and 'package_unif_seedloc' > (analogously to the functions for kind "user-supplied") > > - RNGkind has an additional optional argument: > RNGkind <- function(kind = NULL, normal.kind = NULL, PACKAGE = "") > argument 'PACKAGE' is only used for the new generator kind > "package-supplied" > > - similarly the function set.seed needs the optinal argument 'PACKAGE' > > Since I need such an extended interface (and I assume that other package > write do also) I ask whether this extension can be included into R. > We have implemented a first experimental version of this modified interface. > A patch against the development snapshot R-devel_2006-08-30.tar.gz is > available. > However, it is a little bit too long (239 lines) to be posted here. > > Of course suggestions for an alternative approach are welcome. > > Josef > > > -- 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] setMethod("Logic", ...)
Accordng to the S4groupGeneric page, there is no such group.
My guess as to why:
Those operators are not S3 generic in R, and S4 dispatch is piggy-backed
on S3 dispatch (not necessarily, but for convenience).
On Fri, 1 Sep 2006, Robin Hankin wrote:
> Hi
>
>
> In V&R the "polynomial" class is explicitly specified to have no
> logical operators:
>
> setMethod("Logic", signature(e1="polynomial"), function(e1,e2){stop
> ("...")})
>
>
> I too have a class of objects for which I want to
> specify that Logic operators do not work, but executing
>
>
>
> setClass("brob",
> representation = representation
> (x="numeric",positive="logical"),
> prototype = list(x=numeric(),positive=logical())
> )
>
> setMethod("Logic",signature(e1="brob"), function(e1,e2)
>{
> stop("No logic currently implemented for brob objects")
>}
> )
>
>
> gives me
>
>
> Error in setMethod("Logic", signature(e1 = "brob"), function(e1, e2) { :
> no existing definition for function 'Logic'
>
>
> ?Math seems to imply that there is no "Logic" group.
>
> So, what is the correct way to specify that logical operations are
> not allowed for "brob" objects?
>
>
>
>
>
> --
> Robin Hankin
> Uncertainty Analyst
> National Oceanography Centre, Southampton
> European Way, Southampton SO14 3ZH, UK
> tel 023-8059-7743
>
> __
> 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] Interface for package supplied random number generator
On Fri, 1 Sep 2006, Prof Brian Ripley wrote: > This really is not a good time for us (and apparently you've know about > this for a year). Could you come back to it once 2.4.0 is released (due > Oct 23)? Oops, a backspace failed: Oct 3. > > [We are busy with getting R-devel ready for 2.4.0, and I think that other > mechanisms for this have been mooted, again at a time which was not > opportune.] > > On Thu, 31 Aug 2006, Josef Leydold wrote: > > > Hi, > > > > As you probably know, there is a problem with the interface for adding > > uniform > > random number generators in R (see by article in R News 5/2, November 2005). > > There exists a mechanism called "user-supplied" that allows users of R > > to run their own generator in R. However, there is no such mechanism for > > package writers. Those who want to add their own generators abuse > > RNGkind(kind="user-supplied") for their purpose. > > The problem with this approach is that it relies on the unique existence of > > the > > function "user_unif_rand". When two packages are loaded that use this > > interface, > > then at least one package is broken. If the user herself loads a shared > > library > > that contains such a function, some of the functionalities of all the > > corresponding packages are broken. > > > > When writing my paper I found the following packages on CRAN that abuse this > > interface (meanwhile there might be more packages): > > > > randaes_0.1.tar.gz > > rlecuyer_0.1.tar.gz > > rsprng_0.3-1.tar.gz > > rstream_1.1.tar.gz > > SuppDists_1.0-13.tar.gz > > > > what makes the situation even more complicated is the fact that some of > > these > > packages are loaded automaticall by other packages. > > For example, package 'rlecuyer' is loaded by > > > > snow_0.2-1.tar.gz > > snowFT_0.0-1.tar.gz > > varSelRF_0.6-2.tar.gz > > > > To solve this problem, Stefan Theussl and I have tried to extend the > > mechanism > > for random number generators in the following way: > > > > - we have added a new kind of generators: "package-supplied" > > > > - this generator kind needs functions named 'package_unif_rand', > > 'package_unif_init', > > 'package_unif_nseed', and 'package_unif_seedloc' > > (analogously to the functions for kind "user-supplied") > > > > - RNGkind has an additional optional argument: > > RNGkind <- function(kind = NULL, normal.kind = NULL, PACKAGE = "") > > argument 'PACKAGE' is only used for the new generator kind > > "package-supplied" > > > > - similarly the function set.seed needs the optinal argument 'PACKAGE' > > > > Since I need such an extended interface (and I assume that other package > > write do also) I ask whether this extension can be included into R. > > We have implemented a first experimental version of this modified > > interface. > > A patch against the development snapshot R-devel_2006-08-30.tar.gz is > > available. > > However, it is a little bit too long (239 lines) to be posted here. > > > > Of course suggestions for an alternative approach are welcome. > > > > Josef > > > > > > > > -- 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] R-Project logo in SVG format
I have a file named Rlogo-5.svg, created by downloading Rlogo-5.png, opening it with Adobe Illustrator, Saving as SVG. I didn't tinker with any of Illustrator's options with regard to how, exactly, to save it, since I pretty much don't know what they mean. Whether it is of any use to anyone, or whether it is truly scalable, I have no idea. All I know is that Illustrator claims it is an SVG file. Took about 2 minutes, all together (writing this email took longer). If any R Core member (or anyone else, for that matter), wants a copy, please let me know. I don't want to burden lots of people with a file they probably don't want. I've emailed a copy separately to Lars. -Don At 8:41 AM -0400 8/31/06, Lars D. Noodén wrote: >Hi, > >I'm looking for a version of the R-Project logo in SVG format. I've found >the bitmapped versions, > http://developer.r-project.org/Logo/ > >but would prefer a scalable version as it usually looks better when >printed. > >Where may I find one? >-Lars > >Lars Nooden ([EMAIL PROTECTED]) > On the Internet, nobody knows you're a dog ... > ... until you start barking. > >__ >R-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-devel -- -- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Overriding InitTempDir
Prof Brian Ripley wrote:
> It is conventional for people proposing changes to R to set out a
> compelling case as to why they are needed. I have not seen any case here.
> Can we please have one?
Here's the case for RApache:
An Apache server built with the prefork multi-processing module creates
and destroys many processes, and if it loads the RApache module, this
means that each server process initializes its own R interpreter,
thereby creating many new temp directories. Now, the Apache API provides
shutdown hooks to allow modules (such as with RApache) to do cleanup
work, e.g. remove temporary directories, before a process is destroyed,
but there are occasions when processes just die. I'd like RApache to
fail a little more gracefully, in this case, by not leaving around a
(usually empty) temp directory.
>
> Someone will have to think through the ramifications of such a change (and
> BTW using edit() in an R console is not at all unlikely), and continue to
> maintain it for years to come. I have to say that in the past I have
> accepted quite a few user suggestions that became maintenance nightmares,
> so I have become very wary.
Understood, but I have to say that I'm even more confused about how a
program that embeds R is expected to shut itself down with the
introduction of Rf_endEmbeddedR. Does this implicitly deprecate the use
of overriding the callback R_CleanUp?
>
> It's not really a good time: R-devel is about to start solidifying towards
> 2.4.0, and we have quite a few issues to work through (e.g. the internal
> changes to S4 methods).
Of course, that does seem a bit more important.
>
>
> On Fri, 1 Sep 2006, Jeffrey Horner wrote:
>
>> Jeffrey Horner wrote:
>>> For embedded projects, one may want to eliminate the per-session temp
>>> directory created by InitTempDir() and just use a system-specific temp
>>> directory. Here's my solution:
>>>
>>> extern char *R_TempDir;
>>>
>>> void my_InitTempDir()
>>> {
>>> char *tmp;
>>>
>>> if (R_TempDir){
>>> if (rmdir(R_TempDir) != 0){
>>> perror("Fatal Error: could not remove R's TempDir!");
>>> exit(1);
>>> }
>>> }
>>>
>>> tmp = getenv("TMPDIR");
>>> if (tmp == NULL) {
>>> tmp = getenv("TMP");
>>> if (tmp == NULL) {
>>> tmp = getenv("TEMP");
>>> if (tmp == NULL)
>>> tmp = "/tmp";
>>> }
>>> }
>>>
>>> R_TempDir=tmp;
>>>
>>> if (setenv("R_SESSION_TMPDIR",tmp,1) != 0){
>>> perror("Fatal Error: couldn't set/replace R_SESSION_TMPDIR!");
>>> exit(1);
>>> }
>>> }
>>>
>>> This function is called after Rf_initEmbeddedR; it's seems like a hack
>>> but it works. Does anyone have other solutions?
>> I just found a fault with the above solution, but only if a program that
>> embeds R calls the R edit function; highly unlikely. Nevertheless, It
>> turns out that soon after InitTempDir is called, InitEd is called and
>> sets the variable DefaultFileName (which is hidden by storage class
>> static, unlike R_TempDir) to a temporary filename located in the
>> directory which was just deleted by my_initTempDir.
>>
>>> Maybe InitTempDir could check if R_TempDir was not NULL and then just
>>> return.
>> So it would be nice if the above (InitTempDir only creating a directory
>> when R_TempDir is NULL) could be added to R-trunk.
>>
>> Note also that in the case that R_TempDir is set to a system-specific
>> temp directory, the program would then have to set it back to NULL as
>> the new function Rf_endEmbeddedR now tests to see if R_TempDir has been set:
>>
>> /* use fatal !=0 for emergency bail out */
>> void Rf_endEmbeddedR(int fatal)
>> {
>> unsigned char buf[1024];
>> char * tmpdir;
>>
>> R_RunExitFinalizers();
>> CleanEd();
>> if(!fatal) KillAllDevices();
>> if((tmpdir = R_TempDir)) {
>> snprintf((char *)buf, 1024, "rm -rf %s", tmpdir);
>> R_system((char *)buf);
>> }
>> if(!fatal && R_CollectWarnings)
>> PrintWarnings();/* from device close and .Last */
>> fpu_setup(FALSE);
>> }
>>
>> Jeff
>>
>
--
http://biostat.mc.vanderbilt.edu/JeffreyHorner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R svn log problem
The svn log seems to be missing again. This also happened 10 days ago. On 8/21/06, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > The R svn log usually available at: > > http://developer.r-project.org/R.svnlog.2006 > > seems to be missing. > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R svn log problem
On 9/1/2006 3:53 PM, Gabor Grothendieck wrote: > The svn log seems to be missing again. This also happened > 10 days ago. > > On 8/21/06, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: >> The R svn log usually available at: >> >> http://developer.r-project.org/R.svnlog.2006 >> >> seems to be missing. Fixed now. There was a transient failure to connect to the server last night; I'll change the script so that if this happens, the old log is left online. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] typo in as.POSIXlt.Rd example
In the R 2.4.0 as.POSIXlt.Rd example section: https://svn.r-project.org/R/trunk/src/library/base/man/as.POSIXlt.Rd "GMT" is mispelled as "GNT". That example does not appear in 2.3.1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
