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
[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 URL: 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-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
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 fromURL: 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/) 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?
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 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, snip / 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] .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
rip...@stats.ox.ac.uk 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] 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
[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
[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
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
