Re: [Rd] Windows build not running on r-forge
On Mon, 28 Mar 2011, S Ellison wrote: Please forgive any mis-post, and do feel free to point me to a more appropriate list if this isn't properly R-dev. I have a package on R-forge that shows correct linux and other *nix builds, but no windows build. The log for the patched version shows the error below, which appears to be due to a lack of /src files, a problem that does not halt the *nix builds. The package contains no compiled code (src is intentionally empty). Log as follows: * installing to library 'R:/lib/R/CRAN/2.12' * installing *source* package 'metRology' ... ** libs *** arch - i386 Error in file.copy(Sys.glob("src/*"), ss, recursive = TRUE) : no files to copy from * removing 'R:/lib/R/CRAN/2.12/metRology' Run time: 1.27 seconds. Advice would be welcome on what I can do about it...? Don't have an empty 'src' directory: that is not a valid source package. And please do tell us the version of R as per the posting guide. I am guessing 2.12.2 here. Steve Ellison *** This email and any attachments are confidential. Any use...{{dropped:8}} __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- 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] R-2-13-alpha invalid subscript when checking for unstated dependencies
R version 2.13.0 alpha (2011-03-27 r55091) This error occurs when R CMD check'ing a Bioconductor package: * checking for unstated dependencies in R code ... WARNING Error in e[keep] : invalid subscript type 'list' Execution halted See the information on DESCRIPTION files in the chapter 'Creating R packages' of the 'Writing R Extensions' manual. It is because the author has a sub-expression to 'require' that exceeds the width.cutoff=60L default argument of deparse, e.g., require(gsub("onereallyquitelongstring", "anotherreallyquitelongstring", variablename), character.only=TRUE) This results in a list rather than vector in (one of) tools::QC.R:4106 or 4258. -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows build not running on r-forge
Please forgive any mis-post, and do feel free to point me to a more appropriate list if this isn't properly R-dev. I have a package on R-forge that shows correct linux and other *nix builds, but no windows build. The log for the patched version shows the error below, which appears to be due to a lack of /src files, a problem that does not halt the *nix builds. The package contains no compiled code (src is intentionally empty). Log as follows: * installing to library 'R:/lib/R/CRAN/2.12' * installing *source* package 'metRology' ... ** libs *** arch - i386 Error in file.copy(Sys.glob("src/*"), ss, recursive = TRUE) : no files to copy from * removing 'R:/lib/R/CRAN/2.12/metRology' Run time: 1.27 seconds. Advice would be welcome on what I can do about it...? Steve Ellison *** This email and any attachments are confidential. Any use...{{dropped:8}} __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] another import puzzle
On 03/26/2011 12:19 PM, Ben Bolker wrote: > ["Namespace dependency not required: lme4a"] > I think "dependence" works better than "dependency" in English, too I'm not a native English speaker, but "dependency" is a pretty standard software engineering term for this kind of relationship. I.e., "lme4a" is the dependency, or rather has been declared as such, but it is not needed. Davor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Fortran successful, R locks up.
Duncan and Brian, Thanks again for the help with this. As it turns out the suggestion of setting the GFORTRAN_STDIN_UNIT=-1 has the library working for Mac, Linux, and Windows, so it appears to be in a STDIN read somewhere. Of the 1100 read statements in the code, none are from stdin, or unit 5. Oddly enough, without the environment variable set, everything runs fine looping within a script called from command line (-f) which I delve into a bit below. So, we are functional on repo binaries, and standard linux distros, but intel fortran and xlf appear to have issues still... not a big deal, but if anyone is willing to give me suggestions on other things I can use to try to debug this issue, I would love to clear it up. Sorry for not giving all the background information. I am working/testing on Mac OSX(gfortran 4.2.3, intel fortran 11), Linux (gfortran 4.1.2, intel fortran 11) , WindowsXP (gfortran 4.5), and AIX(xlf v12.1). Right now the environment variable will work I believe since we are just trying to get the standard r-forge distro binaries to work with the package, though I shall keep looking for the STDIN that appears to have been opened. > Sys.setenv(GFORTRAN_STDIN_UNIT=-1) > library.dynam("rswat","EcoHydrology") > .Fortran("junk",3) SWAT Run Successful [1] 0 [[1]] [1] 3 > > Just a bit more information here on this issue. Without the Sys.setenv(GFORTRAN_STDIN_UNIT=-1) function, the .Fortran call runs fine in a loop when called from command line script file (-f) call. When called from interactive session, it runs successfully, then gets stuck in an endless loop of lines 911, 912, 904 in in ../../../../R-2.12.1/src/unix/sys-std.c . There appears to be no STDIO in the routines, and to make sure, I am now closing all the stdio units at the end of the run. DRF28: dan$ cat test.R library.dynam("rswat","EcoHydrology") for (i in 0:5){ .Fortran("junk",i) print(paste("success",i)) } DRF28: dan$ r -q -f test.R > library.dynam("rswat","EcoHydrology") > for (i in 0:5){ + .Fortran("junk",i) + print(paste("success",i)) + } SWAT Run Successful [1] 0 [1] "success 0" SWAT Run Successful [1] 1 [1] "success 1" SWAT Run Successful [1] 2 [1] "success 2" SNIP On Sat, Mar 26, 2011 at 11:49 PM, Prof Brian Ripley wrote: > You seem to have missed the force of the warning in 'Writing R Extensions'. > > If you include *any* Fortrann I/O in your package code, you are at risk from > it interfering with C I/O, whether or not that Fortran I/O is called. > > On some platforms with gfortran, merely loading such a package's DSO/DLL > calls the libgfortran initialization functions and they reset the process' > stdin, causing the behaviour you saw. > > You have not told us what compilers etc you are using. On some versions of > gfortran you can avoid this by setting the environment variables > > GFORTRAN_STDOUT_UNIT > GFORTRAN_STDERR_UNIT > > to -1: these tell gfortran not to use C stdout/stderr (and because of what I > can only see is a bug, it was the use of those which resets stdin). > > > On Fri, 25 Mar 2011, Daniel Fuka wrote: > >> Thanks Duncan for helping me along the way. I am working in OSX, >> Linux, and Windows, and gdb is helping me trace it along to what >> appears to be an endless processor intensive loop in sys-std.c . >> Below, I have pasted the output. All files are closed as verified by >> lsof. There is absolutely no stdio other than what I have put in a >> call to R library's subroutine intpr, all other io is routed to files, >> which are all successfully closed. The entire routine successfully >> runs, and spits out the output from intpr. Is there supposed to be >> something returned from the Fortran routine that Rstd_ReadConsole is >> looking for? I have attached the final lines of the fortran >> subroutine, as well as the gdb steps post fortran routine. Any >> additional help is greatly appreciated! > > ... > > -- > 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, UK Fax: +44 1865 272595 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in tools::compactPDF() in 2.13-0-alpha
On Sun, 2011-03-27 at 09:00 -0400, Duncan Murdoch wrote: > On 11-03-27 8:48 AM, Gavin Simpson wrote: > > Dear List, > > > > There seems to be an bug in compactPDF() or at least an inconsistency > > with the documented behaviour. > > Thanks, looks easy to fix. I'll make the correction. (A bit more below...) Thanks Duncan, > >> compactPDF("../analogue/pkg/inst/doc/analogue_methods.pdf", gs_cmd = > >> "/usr/bin/") > > That won't work: you need the full path to the gs_cmd, not just its > home directory. Ah; I wasn't sure exactly what R expected here and tried several versions including the full path before diving into the code to see what the problem was. The call I included just happened to be the last one I had tried in my R session. All the best, G > Duncan Murdoch > > > NULL > > > > no matter what I do. > > > > This is with: > > > >> sessionInfo() > > R version 2.13.0 alpha (2011-03-27 r55077) > > Platform: x86_64-unknown-linux-gnu (64-bit) > > > > locale: > > [1] LC_CTYPE=en_GB.utf8 LC_NUMERIC=C > > [3] LC_TIME=en_GB.utf8LC_COLLATE=en_GB.utf8 > > [5] LC_MONETARY=C LC_MESSAGES=en_GB.utf8 > > [7] LC_PAPER=en_GB.utf8 LC_NAME=C > > [9] LC_ADDRESS=C LC_TELEPHONE=C > > [11] LC_MEASUREMENT=en_GB.utf8 LC_IDENTIFICATION=C > > > > attached base packages: > > [1] tools stats graphics grDevices utils datasets > > [7] methods base > > > > Thanks, > > > > Gavin > -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% Dr. Gavin Simpson [t] +44 (0)20 7679 0522 ECRC, UCL Geography, [f] +44 (0)20 7679 0565 Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/ UK. WC1E 6BT. [w] http://www.freshwaters.org.uk %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (or feature) in alpha 2.13?
Thanks very much, Duncan. Norm On Sun, Mar 27, 2011 at 08:57:08AM -0400, Duncan Murdoch wrote: > Fixed now. Because of the internal change to srcref records > > \item \code{"srcref"} attributes now include two additional > line number values, recording the line numbers in the order they > were parsed. > > the code that saved the current location didn't recognize the record, > and skipped saving it. > > Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in tools::compactPDF() in 2.13-0-alpha
On 11-03-27 8:48 AM, Gavin Simpson wrote: Dear List, There seems to be an bug in compactPDF() or at least an inconsistency with the documented behaviour. Thanks, looks easy to fix. I'll make the correction. (A bit more below...) The documentations states: Details: This by default makes use of ‘qpdf’, available fromhttp://qpdf.sourceforge.net/>, including a Windows binary. If ‘gs_cmd’ is non-empty, GhostScript is used. I don't have qpdf on my system so planned to use ghostscript. However, the code for compactPDF() has as it's first few lines: if (!nzchar(Sys.which(qpdf))) return() So because I don't have qpdf, compactPDF() always returns NULL: nzchar(Sys.which(Sys.getenv("R_QPDF", "qpdf"))) [1] FALSE compactPDF("../analogue/pkg/inst/doc/analogue_methods.pdf", gs_cmd = "/usr/bin/") That won't work: you need the full path to the gs_cmd, not just its home directory. Duncan Murdoch NULL no matter what I do. This is with: sessionInfo() R version 2.13.0 alpha (2011-03-27 r55077) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_GB.utf8 LC_NUMERIC=C [3] LC_TIME=en_GB.utf8LC_COLLATE=en_GB.utf8 [5] LC_MONETARY=C LC_MESSAGES=en_GB.utf8 [7] LC_PAPER=en_GB.utf8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_GB.utf8 LC_IDENTIFICATION=C attached base packages: [1] tools stats graphics grDevices utils datasets [7] methods base Thanks, Gavin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (or feature) in alpha 2.13?
On 11-03-27 7:42 AM, Duncan Murdoch wrote: On 11-03-26 7:41 PM, Norm Matloff wrote: The pattern (I can make a simple example if needed): > source("x.R") > options(error=recover) > x<- ... > f(x) # f() from x.R (subscript bounds error, now in recover()) Selection: 1 Browse[1]> where In the output from "where," there should be information on the line number at which the user code blew up. It's there in 2.12, but not in 2.13, from what I can see. That's not intentional. I'll see what went wrong... Duncan Murdoch Fixed now. Because of the internal change to srcref records \item \code{"srcref"} attributes now include two additional line number values, recording the line numbers in the order they were parsed. the code that saved the current location didn't recognize the record, and skipped saving it. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in tools::compactPDF() in 2.13-0-alpha
Dear List, There seems to be an bug in compactPDF() or at least an inconsistency with the documented behaviour. The documentations states: Details: This by default makes use of ‘qpdf’, available from http://qpdf.sourceforge.net/>, including a Windows binary. If ‘gs_cmd’ is non-empty, GhostScript is used. I don't have qpdf on my system so planned to use ghostscript. However, the code for compactPDF() has as it's first few lines: if (!nzchar(Sys.which(qpdf))) return() So because I don't have qpdf, compactPDF() always returns NULL: > nzchar(Sys.which(Sys.getenv("R_QPDF", "qpdf"))) [1] FALSE > compactPDF("../analogue/pkg/inst/doc/analogue_methods.pdf", gs_cmd = > "/usr/bin/") NULL no matter what I do. This is with: > sessionInfo() R version 2.13.0 alpha (2011-03-27 r55077) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_GB.utf8 LC_NUMERIC=C [3] LC_TIME=en_GB.utf8LC_COLLATE=en_GB.utf8 [5] LC_MONETARY=C LC_MESSAGES=en_GB.utf8 [7] LC_PAPER=en_GB.utf8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_GB.utf8 LC_IDENTIFICATION=C attached base packages: [1] tools stats graphics grDevices utils datasets [7] methods base Thanks, Gavin -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% Dr. Gavin Simpson [t] +44 (0)20 7679 0522 ECRC, UCL Geography, [f] +44 (0)20 7679 0565 Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/ UK. WC1E 6BT. [w] http://www.freshwaters.org.uk %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug (or feature) in alpha 2.13?
On 11-03-26 7:41 PM, Norm Matloff wrote: The pattern (I can make a simple example if needed): > source("x.R") > options(error=recover) > x<- ... > f(x) # f() from x.R (subscript bounds error, now in recover()) Selection: 1 Browse[1]> where In the output from "where," there should be information on the line number at which the user code blew up. It's there in 2.12, but not in 2.13, from what I can see. That's not intentional. I'll see what went wrong... Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel