Re: [Rd] typo in docs for unlink()
PS, I should have said that I'm reading the docs for unlink in R-2.10.0 on a Linux system. The docs that appear in a Windows installation of R are different (the Windows docs do not mention that not all systems support recursive=TRUE). Here's a plea for docs to be uniform across all systems! Trying to write R code that works on all systems is much harder when the docs are different across systems, and you might only see system specific notes on a different system than the one you're working on. -- Tony Plate Tony Plate wrote: The VALUE section in the help for 'unlink' says: | 0| for success, |1| for failure. Not deleting a non-existent file is not a failure, nor is being unable to delete a directory if |recursive = FALSE|. However, missing values in |x| result are regarded as failures. The last phrase doesn't make sense to me. Should it be either "missing values in x are regarded as failures" or "missing values in x result in failure" ? Also, after reading the docs, I'm still unable to work out if unlink() will return 1 when the user tries to recursively delete a directory on systems that don't support recursive=T. The DETAILS section says "recursive=TRUE is not supported on all platforms, and may be ignored, with a warning", which could be interpreted as implying no special action when recursive=TRUE is not implemented (other than a warning()), and the VALUE section doesn't say what the return value will be under such conditions. I've skimmed the various *_unlink functions in src/main/platform.c, and it looks like they all implement recursive=TRUE, so I'm still in the dark about the required behavior on systems that don't support it. Could this be clarified in the help file? thanks, Tony Plate __ 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] typo in docs for unlink()
The VALUE section in the help for 'unlink' says: | 0| for success, |1| for failure. Not deleting a non-existent file is not a failure, nor is being unable to delete a directory if |recursive = FALSE|. However, missing values in |x| result are regarded as failures. The last phrase doesn't make sense to me. Should it be either "missing values in x are regarded as failures" or "missing values in x result in failure" ? Also, after reading the docs, I'm still unable to work out if unlink() will return 1 when the user tries to recursively delete a directory on systems that don't support recursive=T. The DETAILS section says "recursive=TRUE is not supported on all platforms, and may be ignored, with a warning", which could be interpreted as implying no special action when recursive=TRUE is not implemented (other than a warning()), and the VALUE section doesn't say what the return value will be under such conditions. I've skimmed the various *_unlink functions in src/main/platform.c, and it looks like they all implement recursive=TRUE, so I'm still in the dark about the required behavior on systems that don't support it. Could this be clarified in the help file? thanks, Tony Plate __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] polygon kills X-server (PR#14055)
xs4all.nl> writes: > > Full_Name: Ludo Pagie > Version: 2.10.0 > OS: linux, ubuntu, 8.04 > Submission from: (NULL) (83.163.218.221) > > when I make a polygon with 100,000 vertices my X-server is being > killed. This occurs in R-2.9.0 and a freshly installed R-2.10.0 > I'm running Ubuntu with a locally compiled R: > [snip] It took quite a while, and every time I obscure the window it hangs R while it redraws, but that all seems as expected. The rest of my system seems to be running fine while it works on that (one core is pegged at 100% CPU, but the other is handling everything OK). Linux bolker-lap2 2.6.27-15-generic #1 SMP Tue Oct 20 06:52:09 UTC 2009 i686 GNU/Linux Ubuntu 8.10 for what it's worth, I'm not running a window manager with any fancy screen effects (don't know if that would matter??) R 2.10.0, stock Ubuntu installation __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Typo in 2.10.0 NEWS file (PR#14054)
whor...@pixar.com wrote: Full_Name: Rick Sayre Version: 2.10.0 OS: linux/windows/os x Submission from: (NULL) (138.72.146.168) Man, it feels ungrateful to report this, but it looks like in the process of having my wish PR#13758 fulfilled, a typo snuck in to the "NEWS" releasenotes: o New as.raw() method for "tclObj" objects (wish of PR#13578). I'm pretty sure that's a typo, and should be 13758 instead of 13578. Perhaps "nobody cares", but I mention it for completeness. [and thanks for the new method!] Maybe they do and maybe they don't, but I fixed it anyway. You're not getting yet another NEWS entry for #14054 though... -- 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 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] polygon kills X-server (PR#14055)
Full_Name: Ludo Pagie Version: 2.10.0 OS: linux, ubuntu, 8.04 Submission from: (NULL) (83.163.218.221) when I make a polygon with 100,000 vertices my X-server is being killed. This occurs in R-2.9.0 and a freshly installed R-2.10.0 I'm running Ubuntu with a locally compiled R: uname -a Linux onyx 2.6.24-24-generic #1 SMP Tue Aug 18 16:22:17 UTC 2009 x86_64 GNU/Linux xlower = -2e6:2e6 xupper = rev(xlower) ylower = runif(length(xlower)) yupper = ylower+.1 plot(NA,xlim=range(xlower),ylim=range(ylower)) idx=1:1 # it draws fine for lower number of vertices: polygon(x=c(xlower[idx],xupper[idx]),y=c(ylower[idx],yupper[idx]),col='grey') # but X is killed when I draw 10 vertices or more idx=1:10 # I've commented the next call to prevent people accidently # killing their X? #polygon(x=c(xlower[idx],xupper[idx]),y=c(ylower[idx],yupper[idx]),col='grey') > sessionInfo() R version 2.10.0 (2009-10-26) x86_64-unknown-linux-gnu locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base I've posted above to the R-help list and got replies from Uwe Ligges saying it also killed his Windows completely. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Alphanumeric tools::file_path_sans_ext() (PR#14050)
> arnima writes:
> The file_path_sans_ext() function in the 'tools' package does not handle
> alphanumeric file extensions correctly:
>require(tools)
>file_path_sans_ext("song.txt") # song, correct
>file_path_sans_ext("song.mp3") # song.mp3, wrong
> The help page states that "only purely alphanumeric extensions are
> recognized", which I had expected. To fulfill this, the function body
> should be
>sub("([^.]+)\\.[[:alnum:]]+$", "\\1", x)
> instead of the current definition:
>sub("([^.]+)\\.[[:alpha:]]+$", "\\1", x)
> Thanks,
> Arni
Thanks, fixed now.
Best
-k
> __
> 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] compiling R-2.10.0 on solaris - lib_I_dbg_gen.so.1: version `DBG_GEN_5.1' not found
Hi,
I'm having trouble compiling R-2.10.0 (R-patched_2009-11-02.tar.gz) on
solaris 10 and am hoping for some advice. I'm getting errors about
having the wrong version of lib_I_dbg_gen.so.1 ("version `DBG_GEN_5.1'
not found"), when it gets to the step of compiling recommended
packages (cluster).
I think we do have the right version of lib_I_dbg_gen.so.1 on the
system somewhere, but we also have older versions in other places. I
think it may be to do with our system having several versions of gcc
and lib_I_dbg_gen.so.1 in different places, including some old
versions, and me not managing to tell R where to find the right one -
perhaps some modifications to my setenv commands will fix this? I also
think we might have some non-standard library locations.
I'm not the sysadmin, and I'm a little out of my depth talking about
libraries etc. I asked our sysadmin for some advice, but for now we
are drawing a blank. If no-one has any ideas I may be able to ask them
to spend some more time trying to figure this out.
Here's what I'm doing to try to compile R: (my default path and
LD_LIBRARY_PATH have never worked for compiling R, hence the setenv
commands)
setenv LD_LIBRARY_PATH /opt/SUNW0scgfss/4.0.3/prod/lib:/opt/gcc/lib:/
opt/gcc/lib/gcc/sparc-sun-solaris2.10:/opt/SUNWspro/lib:/usr/lib:/usr/
openwin/lib
setenv PATH /opt/gcc/bin:/bin:/sbin:/usr/sbin:/etc:/opt/SUNWspro/bin:/
usr/ccs/bin:/usr/sfw/bin
unsetenv R_HOME
./configure --enable-R-shlib R_PAPERSIZE='letter' --prefix='/home/
btrask/traskdata'
make
Here's some information on compiler versions, etc, etc
[72] bedrock:/home/jayoung> uname -a
SunOS bedrock 5.10 Generic_139555-08 sun4v sparc SUNW,Sun-Fire-T200
[17] bedrock:/home/jayoung> which gcc
/opt/gcc/bin/gcc
[18] bedrock:/home/jayoung> gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /net/tibia/export/bldmstr/nightly/
20060817_mars_gcc.s10.opt.tarbuild/src/configure --prefix=/opt/gcc --
enable-shared --with-system-zlib --enable-checking=release --disable-
libmudflap --enable-languages=c,c++ --enable-version-specific-runtime-
libs --with-gxx-include-dir=/opt/gcc/include/c++/4.0.3 --with-cpu=v9
Thread model: posix
gcc version 4.0.3 (gccfss)
[21] bedrock:/home/jayoung> ldd /opt/gcc/libexec/gcc/sparc-sun-
solaris2.10/4.0.3/cc1
lib_I_dbg_gen.so.1 =>/opt/SUNW0scgfss/4.0.3/prod/lib/
lib_I_dbg_gen.so.1
libsunir.so => /opt/gcc/bin/../../SUNW0scgfss/4.0.3/prod/
lib/sys/libsunir.so
libc.so.1 => /usr/lib/libc.so.1
libmd5.so.1 => /usr/lib/libmd5.so.1
libdl.so.1 =>/usr/lib/libdl.so.1
libelf.so.1 => /usr/lib/libelf.so.1
liblni.so.1 => /opt/SUNW0scgfss/4.0.3/prod/lib/sys/
liblni.so.1
libm.so.2 => /usr/lib/libm.so.2
/platform/SUNW,Sun-Fire-T200/lib/libc_psr.so.1
libmd.so.1 =>/usr/lib/libmd.so.1
/platform/SUNW,Sun-Fire-T200/lib/libmd_psr.so.1
[22] bedrock:/home/jayoung> version /opt/SUNW0scgfss/4.0.3/prod/lib/
lib_I_dbg_gen.so.1
version of "/opt/SUNW0scgfss/4.0.3/prod/lib/lib_I_dbg_gen.so.1": Sun
Debug Information DBG_GEN 5.1.17 gcc2ir_lang 2006/08/17
And here's the error I get during the make process:
begin installing recommended package cluster
* installing *source* package 'cluster' ...
** libs
gcc -std=gnu99 -I/home/jayoung/source_codes/R/R-2.10.0/solaris_6/R-
patched/include -I/usr/local/include-fPIC -g -O2 -c clara.c -o
clara.o
ld.so.1: cc1: fatal: lib_I_dbg_gen.so.1: version `DBG_GEN_5.1' not
found (required by file /opt/gcc/libexec/gcc/sparc-sun-
solaris2.10/4.0.3/cc1)
ld.so.1: cc1: fatal: lib_I_dbg_gen.so.1: open failed: No such file or
directory
gcc: Internal error: Killed (program cc1)
Please submit a full bug report to
http://forum.sun.com/jive/jorum.jspa?forumID=321>.
*** Error code 1
make: Fatal error: Command failed for target `clara.o'
Current working directory /tmp/RtmpJReZec/R.INSTALL2781446b/cluster/src
ERROR: compilation failed for package 'cluster'
* removing '/home/jayoung/source_codes/R/R-2.10.0/solaris_6/R-patched/
library/cluster'
*** Error code 1
The following command caused the error:
MAKE="make" R_LIBS= ../../../bin/R CMD INSTALL --no-lock -l "../../../
library" cluster.tgz > cluster.ts.out 2>&1 || (cat cluster.ts.out &&
exit 1)
make: Fatal error: Command failed for target `cluster.ts'
Current working directory /home/jayoung/source_codes/R/R-2.10.0/
solaris_6/R-patched/src/library/Recommended
*** Error code 1
The following command caused the error:
make stamp-recommended
make: Fatal error: Command failed for target `recommended-packages'
Current working directory /home/jayoung/source_codes/R/R-2.10.0/
solaris_6/R-patched/src/library/Recommended
*** Error code 1
The following command caused the error:
(cd src/library/Recommended && make)
make: Fat
[Rd] NetCDF output in R
Dear CSAG R users,
I will be glad if someone can point out what I am doing wrong or not doing at
all in this.
I am trying to write out netcdf file in R. I have 26 time step but only the
first time step is written.
For example:
>library(ncdf)
>path <- '/home/work/'
>forecast <- open.ncdf(paste(path,'cam.1980.2005.nc',sep=""))
> fore <- get.var.ncdf(forecast,'ppt')
> lon <- get.var.ncdf(forecast,'lon')
> lat <- get.var.ncdf(forecast,'lat')
>dim(fore)[3]
>26
> times <- 1:dim(fore)[3]
> write.netcdf.time(paste(path,'cam_fore.nc',sep=""), fore,lon,lat,times)
[1] "put.var.ncdf: warning: you asked to write 1440 values, but the passed data
array has 37440 entries!"
[[1]]
[1] 6
Warning message:
In 1:nt : numerical expression has 26 elements: only the first used
# function for writing out the netcdf file #
write.netcdf.time <- function(filename='outputfile.nc',data,lons,lats,nt){
lon <- dim.def.ncdf('lon','degrees_east',lons)
lat <- dim.def.ncdf('lat','degrees_north',lats)
times <- 1:nt
tdim <- dim.def.ncdf('time','days since 1980-01-01', times, unlim=TRUE)
# levs <- dim.def.ncdf('lev','pressure',levs)
var <- var.def.ncdf('data','unitless',list(lon,lat,tdim),-999.9)
ncid <- create.ncdf(filename,list(var))
put.var.ncdf(ncid, var, data)
close.ncdf(ncid)
}
##end of function###
Thank you.
Nana Browne
There is no key to happiness. The door is always open.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in 2.10.0 NEWS file (PR#14054)
Full_Name: Rick Sayre Version: 2.10.0 OS: linux/windows/os x Submission from: (NULL) (138.72.146.168) Man, it feels ungrateful to report this, but it looks like in the process of having my wish PR#13758 fulfilled, a typo snuck in to the "NEWS" releasenotes: o New as.raw() method for "tclObj" objects (wish of PR#13578). I'm pretty sure that's a typo, and should be 13758 instead of 13578. Perhaps "nobody cares", but I mention it for completeness. [and thanks for the new method!] Cheers --Rick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in all.equal() or in the plm package
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> project.org] On Behalf Of Arne Henningsen
> Sent: Tuesday, November 10, 2009 2:24 AM
> To: Duncan Murdoch; r-devel@r-project.org; Yves Croissant;
> giovanni_mi...@generali.com; Achim Zeileis
> Subject: Re: [Rd] Bug in all.equal() or in the plm package
>
> On Mon, Nov 9, 2009 at 12:24 PM, Duncan Murdoch
> wrote:
> > Arne Henningsen wrote:
> >>
> >> I noticed that there is a (minor) bug either the command all.equal()
> >> or in the "plm" package. I demonstrate this using an example taken
> >> from the documentation of plm():
> >>
> >
> > I'm not sure this is a bug, but I'd call it at least a design flaw.
> The
> > problem is that the length.Formula method in the Formula package
> (which plm
> > depends on) returns a vector of length 2. Now there's nothing in R
> that
> > requires length() to return a scalar,
No, but outside of R, length is a one dimensional real number
except perhaps in some esoteric mathematics, so I'm puzzled
why length in R would be redefined to produce non-scalars.
> >but all.equal assumes it does,
> and I'd
> > guess there are lots of other places this assumption is made.
>
> Okay, let's call it "design flaw". Given that the "unusual" behaviour
> of length.Formula() causes this problem, I suggest that the
> length.Formula() method should be changed. Maybe to something like
>
> R> a <- as.Formula( y ~ x | z | w )
> # current behaviour:
> R> length(a)
> [1] 1 3
> # suggested behaviour:
> R> length(a)
> [1] 2
> R> length(a[[1]])
> [1] 1
> R> length(a[[2]])
> [1] 3
>
How about
# Total number of variables in model
R> length(a)
[1] 4
# Predictor variables (on the right hand side) pred(a) or rhs(a)
R> length(pred(a))
[1] 3
# Response variables (on the left hand side) resp(a) or lhs(a)
R> length(resp(a))
[1] 1
so all lengths of a formula's components can
be obtained as scalars.
R> length(a)
[1] 3
is what R 2.9.1 produced, and may often be what is expected
for the length of a formula, so the above could be
# Total number of variables in model
R> length(total(a))
[1] 4
# Predictor variables (on the right hand side) pred(a) or rhs(a)
R> length(a)
[1] 3
# Response variables (on the left hand side) resp(a) or lhs(a)
R> length(resp(a))
[1] 1
Steve McKinney
> This would be more consistent with the usual behaviour of length, e.g.
> R> b <- list( 1, 1:3 )
> R> length(b)
> [1] 2
> R> length(b[[1]])
> [1] 1
> R> length(b[[2]])
> [1] 3
>
> /Arne
>
>
> >> ==
> >> R> data("Produc", package="plm")
> >> R> zz <- plm(log(gsp)~log(pcap)+log(pc)+log(emp)+unemp,
> >> + data=Produc, index=c("state","year"))
> >> R> all.equal(zz,zz)
> >> [1] TRUE
> >> Warning message:
> >> In if (length(target) != length(current)) return(paste("target,
> >> current differ in having response: ", :
> >> the condition has length > 1 and only the first element will be
> used
> >>
> >>>
> >>> all.equal(zz$formula,zz$formula)
> >>>
> >>
> >> [1] TRUE
> >> Warning message:
> >> In if (length(target) != length(current)) return(paste("target,
> >> current differ in having response: ", :
> >> the condition has length > 1 and only the first element will be
> used
> >>
> >>>
> >>> class(zz$formula)
> >>>
> >>
> >> [1] "pFormula" "Formula" "formula"
> >> ==
> >>
> >> The last commands show that the warning message comes from comparing
> >> the elements "formula", which are of the class "pFormula"
> (inheriting
> >> from "Formula" and "formula"). It would be great if this issue could
> >> be fixed in the future.
> >>
> >> Thanks a lot,
> >> Arne
>
> --
> Arne Henningsen
> http://www.arne-henningsen.name
>
> __
> 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] Installing and compiling C code for R-windows
Having PP.o and PP.so will break things if (as I suspect) they are from a different architecture. Your colleague's testing should have picked that up (R CMD check will warn you) but you can try deleting them. Also, I think you have ignored all the comments about not installing R into a path with spaces in if you want to compile packages -- although it usually works, we do not support it. On Tue, 10 Nov 2009, Hartley, Andrew wrote: Hi r-devers, This is the first time I've tried to install a package from source on Windows, so please bear with me. I'm trying to install a package written (and tested) by a colleague in C for R on linux, and I am trying to install it on windows following the directions here - http://cran.r-project.org/doc/manuals/R-admin.html#The-Windows-toolset and here - http://www.murdoch-sutherland.com/Rtools/ I installed Rtools (but not InnoSetup or LaTeX because of permissions problems on my PC, although I don't think they are essential). I checked my environment variables are pointing to the correct tools, and then I ran the following: R CMD INSTALL --library="C:/R/library" --no-chm PP --no-chm is obsolete: are you perchance not using a current version of R (see the posting guide)? The package is called PP, and contains the following files: ls -R PP PP: DESCRIPTION R man src svn-commit.tmp~ PP/R: PP.R PP/man: PP.Rd pp.get.longs.Rd pp.ppw.Rdpp.strip.extra.Rd pp.close.file.Rd pp.open.file.Rd pp.print.Rd pp.write.Rd pp.get.lats.Rdpp.ppa.Rdpp.read.Rd tmp PP/src: PP.c PP.o PP.so makefile.old The result is (based on my limited knowledge) quite promising, but it seems to be unable to link libraries. Here's what I get: * Installing *source* package 'PP' ... ** libs making DLL ... The hint is here: there is no sign that PP.c was compiled. gcc -shared -s -o PP.dll tmp.def PP.o -LC:/PROGRA~1/R/R-29~1.2/bin -lR Cannot export SwapEndian: symbol not found Cannot export close_file_c: symbol not found Cannot export open_file_c: symbol not found . Etc I don't have any experience compiling C code, so I'm a bit stumped. Do I need to override the default gcc settings by editing the makefile? Or have I missed something more obvious? Please let me know if you need any additional info. Kind regards, Andy [[alternative HTML version deleted]] -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Installing and compiling C code for R-windows
Hi r-devers, This is the first time I've tried to install a package from source on Windows, so please bear with me. I'm trying to install a package written (and tested) by a colleague in C for R on linux, and I am trying to install it on windows following the directions here - http://cran.r-project.org/doc/manuals/R-admin.html#The-Windows-toolset and here - http://www.murdoch-sutherland.com/Rtools/ I installed Rtools (but not InnoSetup or LaTeX because of permissions problems on my PC, although I don't think they are essential). I checked my environment variables are pointing to the correct tools, and then I ran the following: R CMD INSTALL --library="C:/R/library" --no-chm PP The package is called PP, and contains the following files: >ls -R PP PP: DESCRIPTION R man src svn-commit.tmp~ PP/R: PP.R PP/man: PP.Rd pp.get.longs.Rd pp.ppw.Rdpp.strip.extra.Rd pp.close.file.Rd pp.open.file.Rd pp.print.Rd pp.write.Rd pp.get.lats.Rdpp.ppa.Rdpp.read.Rd tmp PP/src: PP.c PP.o PP.so makefile.old The result is (based on my limited knowledge) quite promising, but it seems to be unable to link libraries. Here's what I get: * Installing *source* package 'PP' ... ** libs making DLL ... gcc -shared -s -o PP.dll tmp.def PP.o -LC:/PROGRA~1/R/R-29~1.2/bin -lR Cannot export SwapEndian: symbol not found Cannot export close_file_c: symbol not found Cannot export open_file_c: symbol not found . Etc I don't have any experience compiling C code, so I'm a bit stumped. Do I need to override the default gcc settings by editing the makefile? Or have I missed something more obvious? Please let me know if you need any additional info. Kind regards, Andy [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Makevars or Makevars.in
On Tue, 10 Nov 2009, Paul Gilbert wrote:
I am just trying to adjust one of my packages so the C code builds in
Windows. This is code that has been around for a long time, and I'm am only
a casual reader of C, so it has had the "if it is not broken don't touch it"
approach for many years. The section 1.2.1 "Using Makevars" of "Writing R
extensions" starts:
"Sometimes writing your own configure script can be avoided by supplying a
file Makevars: also one of the most common uses of a configure script is to
make Makevars from Makevars.in." ...
I am still a bit confused about whether packages src/ should have, in
addition to Makevars.win, a file Makevars or a file Makevars.in. The rest of
the section seems to imply that the file should be Makevars, but the first
four examples I pulled of CRAN all have Makevars.in. My confusion is about
whether R scripts will automatically turn Makevars.in into Makevars or would
I need my own configure script to do this (and I am hoping not to need a
configure script).
Which is preferred? (And could the first paragraph of the section be made
more explicit?)
I think you need to read the earlier mentions of Makevars in that
manual: your confusion seems to be that you have jumped in to a later
section. The only use of src/Makevars.in is that it is a conventional
name for a template file for configure to turn into src/Makevars. As
the manual says
The default rules can be tweaked by setting macros in a file
@file{src/Makevars} ... There are platform-specific file names on
Windows: @file{src/Makevars.win} takes precedence over
@file{src/Makevars}.
So to tweak the make rules you need src/Makevars: if you need a
platform-specific version you need src/Makevars and src/Makevars.win.
You may choose to use configure (or configure.win) to make these, but
you do not need to (and packages using e.g. LAPACK or BLAS do not do
so).
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Makevars or Makevars.in
I am just trying to adjust one of my packages so the C code builds in
Windows. This is code that has been around for a long time, and I'm am
only a casual reader of C, so it has had the "if it is not broken don't
touch it" approach for many years. The section 1.2.1 "Using Makevars"
of "Writing R extensions" starts:
"Sometimes writing your own configure script can be avoided by supplying
a file Makevars: also one of the most common uses of a configure script
is to make Makevars from Makevars.in." ...
I am still a bit confused about whether packages src/ should have, in
addition to Makevars.win, a file Makevars or a file Makevars.in. The
rest of the section seems to imply that the file should be Makevars, but
the first four examples I pulled of CRAN all have Makevars.in. My
confusion is about whether R scripts will automatically turn Makevars.in
into Makevars or would I need my own configure script to do this (and I
am hoping not to need a configure script).
Which is preferred? (And could the first paragraph of the section be
made more explicit?)
Thanks,
Paul
La version française suit le texte anglais.
This email may contain privileged and/or confidential in...{{dropped:26}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Summary methods
On Sun, Nov 8, 2009 at 2:26 PM, Doran, Harold wrote:
> I've defined the following for objects of a class called jml
>
> summary.jml <- function(object, ...){
> tab <- cbind(Estimate = coef(object),
> StdError = object$se,
> Infit = object$Infit,
> Outfit = object$Outfit)
> res <- list(call = object$call, coefficients = tab,
> N = nrow(object$Data), iter = object$Iterations)
> class(res) <- "summary.jml"
> res
> }
>
> print.summary.jml <- function(x, ...){
> cat("Call:\n")
> print(x$call)
> cat("\n")
> cat("Number of iterations to completion:", x$iter, "\n")
> cat("Number of individuals used in estimation:", x$N, "\n")
> cat("\n")
> printCoefmat(x$coefficients)
> }
>
> Use of the methods on a fitted jml object yields:
>
>> summary(aa)
> Call:
> jml2.formula(formula = ~V1 + V2 + V3 + V4 + V5 + V6 + V7 + V8 +
> V9 + V10, data = itemDat, bias = F)
>
> Number of iterations to completion: 6
> Number of individuals used in estimation: 486
>
> StdError Infit Outfit
> [1,] -0.380346 0.103002 1.007466 0.9935
> [2,] 0.025939 0.104052 1.003050 1.0083
> [3,] 2.563784 0.171174 0.941453 0.9414
> [4,] -2.930519 0.156923 1.010786 1.0515
> [5,] 1.139241 0.118932 0.978101 1.1424
> [6,] -1.461751 0.111563 1.030612 1.2709
> [7,] 0.486202 0.107986 1.008374 1.0394
> [8,] -0.497102 0.103117 0.961431 0.9012
> [9,] -0.486478 0.103099 1.001752 0.9829
> [10,] 1.541029 0.129214 1.010011 0.9150
>
> Two questions. First, why is the name of the first column empty instead of
> "Estimate" as I have specified in the summary method?
Because you are using cbind to create the table. Use data.frame
instead. I think that will also help with the alignment issue.
> Second, I am struggling to get the row names of the coefficients to align
> with the formula call. For example, instead of
>
> StdError Infit Outfit
> [1,] -0.380346 0.103002 1.007466 0.9935
>
> I would prefer
>
> StdError Infit Outfit
> V1 -0.380346 0.103002 1.007466 0.9935
>
> This also occurs in my print method
>
> print.jml <- function(x, digits = 2, ...){
> cat("\nCall:\n", deparse(x$call), "\n\n", sep = "")
> cat("Coefficients:\n")
> print.default(format(coef(x), digits = digits), print.gap=2,
> quote = FALSE)
> invisible(x)
> }
>
> Which produces
>
>> win
> Call:
> jml2.default(dat = itemDat[, 1:10])
>
> Coefficients:
> [,1]
> [1,] -0.38034638
> [2,] 0.02593937
> [3,] 2.56378422
> [4,] -2.93051899
> [5,] 1.13924076
> [6,] -1.46175119
> [7,] 0.48620247
> [8,] -0.49710150
> [9,] -0.48647770
> [10,] 1.54102895
>
> Thank you
> Harold
>
>> sessionInfo()
> R version 2.10.0 (2009-10-26)
> i386-pc-mingw32
>
> locale:
> [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] MASS_7.3-3 lme4_0.999375-32 Matrix_0.999375-31 lattice_0.17-26
> [5] MiscPsycho_1.4 statmod_1.4.1
>
> loaded via a namespace (and not attached):
> [1] grid_2.10.0 plink_1.2-2 tools_2.10.0
> __
> 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] Bug in all.equal() or in the plm package
On Mon, Nov 9, 2009 at 12:24 PM, Duncan Murdoch wrote:
> Arne Henningsen wrote:
>>
>> I noticed that there is a (minor) bug either the command all.equal()
>> or in the "plm" package. I demonstrate this using an example taken
>> from the documentation of plm():
>>
>
> I'm not sure this is a bug, but I'd call it at least a design flaw. The
> problem is that the length.Formula method in the Formula package (which plm
> depends on) returns a vector of length 2. Now there's nothing in R that
> requires length() to return a scalar, but all.equal assumes it does, and I'd
> guess there are lots of other places this assumption is made.
Okay, let's call it "design flaw". Given that the "unusual" behaviour
of length.Formula() causes this problem, I suggest that the
length.Formula() method should be changed. Maybe to something like
R> a <- as.Formula( y ~ x | z | w )
# current behaviour:
R> length(a)
[1] 1 3
# suggested behaviour:
R> length(a)
[1] 2
R> length(a[[1]])
[1] 1
R> length(a[[2]])
[1] 3
This would be more consistent with the usual behaviour of length, e.g.
R> b <- list( 1, 1:3 )
R> length(b)
[1] 2
R> length(b[[1]])
[1] 1
R> length(b[[2]])
[1] 3
/Arne
>> ==
>> R> data("Produc", package="plm")
>> R> zz <- plm(log(gsp)~log(pcap)+log(pc)+log(emp)+unemp,
>> + data=Produc, index=c("state","year"))
>> R> all.equal(zz,zz)
>> [1] TRUE
>> Warning message:
>> In if (length(target) != length(current)) return(paste("target,
>> current differ in having response: ", :
>> the condition has length > 1 and only the first element will be used
>>
>>>
>>> all.equal(zz$formula,zz$formula)
>>>
>>
>> [1] TRUE
>> Warning message:
>> In if (length(target) != length(current)) return(paste("target,
>> current differ in having response: ", :
>> the condition has length > 1 and only the first element will be used
>>
>>>
>>> class(zz$formula)
>>>
>>
>> [1] "pFormula" "Formula" "formula"
>> ==
>>
>> The last commands show that the warning message comes from comparing
>> the elements "formula", which are of the class "pFormula" (inheriting
>> from "Formula" and "formula"). It would be great if this issue could
>> be fixed in the future.
>>
>> Thanks a lot,
>> Arne
--
Arne Henningsen
http://www.arne-henningsen.name
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
