[Rd] Return values from .Call and garbage collection
Hi all, I'm posting this here as it discusses an issue with an external C library. If it would be better in R-Help, then I'll repost. I'm using an external library which I've written, which provides a large set of data (>500MB in a highly condensed format) and the tools to return values from the data. The functionality has been tested call by call and using valgrind and works fine, with no memory leaks. After retrieval, I process the data in R. A specific function is causing a problem that appears to be related to the garbage collector (judging by symptoms). In the C code, a Matrix is created using PROTECT(retVal = allocMatrix(INTSXP, x, y)); Values are written into this matrix using INTEGER(retVal)[translatedOffset]=z; where "translatedOffset" is a conversion from a row/column pair to an offset as shown in R-exts.pdf. The last two lines of the function call are: UNPROTECT(1); return retVal; The shared library was compiled with R CMD SHLIB and is called using .Call. Which returns our completed SEXP object to R where processing continues. In R, we continue to process the data, replacing -1s with NAs (I couldn't find a way to do that in that would make it back into R), sorting it, and trimming it. All of these operations are carried out on the original data. If I carry out the processing step by step from the interpreter, everything is fine and the data comes out how I would expect. But when I run the R code to carry out those steps, every now and again (Around 1/5th of the time), the returned data is garbage. I'm expecting to receive a bias per iteration that should be -5 <= bias <= 5, but for the garbaged data, I'm getting results of the order of 100s of thousands out (eg. -220627.7). If I call the routine which carries out the processing for one iteration from the intepreter, sometimes I get the correct data, sometimes (with the same frequency) I get garbage. There are two possibilities that I can envisage. 1) Race condition: R is starting to execute the R code after the .Call before the .Call has returned, thus the data is corrupted. 2) Garbage collector: the GC is collecting my data between the UNPROTECT(1); call and the assignment to an R variable. The created matrices can be large (where x > 1000, y > 10), but the garbage doesn't appear to be related to the size of the matrix. Any ideas what steps I could take to proceed with this? Or other possibilities than those I've suggested? For reasons of confidentiality I'm unable to release test code, and the large dataset might make testing difficult. Thanks in advance -- Jon Senior __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Return values from .Call and garbage collection [Additional information added]
Hi all, I'm posting this here as it discusses an issue with an external C library. If it would be better in R-Help, then I'll repost. I'm using an external library which I've written, which provides a large set of data (>500MB in a highly condensed format) and the tools to return values from the data. The functionality has been tested call by call and using valgrind and works fine, with no memory leaks. After retrieval, I process the data in R. A specific function is causing a problem that appears to be related to the garbage collector (judging by symptoms). In the C code, a Matrix is created using PROTECT(retVal = allocMatrix(INTSXP, x, y)); Values are written into this matrix using INTEGER(retVal)[translatedOffset]=z; where "translatedOffset" is a conversion from a row/column pair to an offset as shown in R-exts.pdf. The last two lines of the function call are: UNPROTECT(1); return retVal; The shared library was compiled with R CMD SHLIB and is called using .Call. Which returns our completed SEXP object to R where processing continues. In R, we continue to process the data, replacing -1s with NAs (I couldn't find a way to do that in that would make it back into R), sorting it, and trimming it. All of these operations are carried out on the original data. If I carry out the processing step by step from the interpreter, everything is fine and the data comes out how I would expect. But when I run the R code to carry out those steps, every now and again (Around 1/5th of the time), the returned data is garbage. I'm expecting to receive a bias per iteration that should be -5 <= bias <= 5, but for the garbaged data, I'm getting results of the order of 100s of thousands out (eg. -220627.7). If I call the routine which carries out the processing for one iteration from the intepreter, sometimes I get the correct data, sometimes (with the same frequency) I get garbage. There are two possibilities that I can envisage. 1) Race condition: R is starting to execute the R code after the .Call before the .Call has returned, thus the data is corrupted. 2) Garbage collector: the GC is collecting my data between the UNPROTECT(1); call and the assignment to an R variable. The created matrices can be large (where x > 1000, y > 10), but the garbage doesn't appear to be related to the size of the matrix. R version 2.8.1 (2008-12-22), running on Fedora 10 on a Centrino dual-core with 3GB of RAM. Any ideas what steps I could take to proceed with this? Or other possibilities than those I've suggested? For reasons of confidentiality I'm unable to release test code, and the large dataset might make testing difficult. Thanks in advance -- Jon Senior __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Return values from .Call and garbage collection
- R is not multithreaded (or so it was) and thus race condition cannot
occur
- I would think there is no call to GC at the time of assignment of the
return value to a variable. GC is only called within other R calls as R
as mentioned above is not multithreaded
Most likely issue is your code itself, out of range indexing, failure to
initialise all elements of the allocated structure correctly, 1 and not
0-based indexing, use of other R variables for initialisation that
should have been protected but were not etc.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Jon Senior
> Sent: 27 January 2009 12:09
> To: r-devel@r-project.org
> Subject: [Rd] Return values from .Call and garbage collection
>
> Hi all,
>
> I'm posting this here as it discusses an issue with an
> external C library. If it would be better in R-Help, then I'll repost.
>
> I'm using an external library which I've written, which
> provides a large set of data (>500MB in a highly condensed
> format) and the tools to return values from the data. The
> functionality has been tested call by call and using valgrind
> and works fine, with no memory leaks. After retrieval, I
> process the data in R. A specific function is causing a
> problem that appears to be related to the garbage collector
> (judging by symptoms).
>
> In the C code, a Matrix is created using
>
> PROTECT(retVal = allocMatrix(INTSXP, x, y));
>
> Values are written into this matrix using
>
> INTEGER(retVal)[translatedOffset]=z;
>
> where "translatedOffset" is a conversion from a row/column
> pair to an offset as shown in R-exts.pdf.
>
> The last two lines of the function call are:
>
> UNPROTECT(1);
> return retVal;
>
> The shared library was compiled with R CMD SHLIB and is
> called using .Call.
>
> Which returns our completed SEXP object to R where processing
> continues.
>
> In R, we continue to process the data, replacing -1s with NAs
> (I couldn't find a way to do that in that would make it back
> into R), sorting it, and trimming it. All of these operations
> are carried out on the original data.
>
> If I carry out the processing step by step from the
> interpreter, everything is fine and the data comes out how I
> would expect. But when I run the R code to carry out those
> steps, every now and again (Around 1/5th of the time), the
> returned data is garbage. I'm expecting to receive a bias per
> iteration that should be -5 <= bias <= 5, but for the
> garbaged data, I'm getting results of the order of 100s of
> thousands out (eg. -220627.7). If I call the routine which
> carries out the processing for one iteration from the
> intepreter, sometimes I get the correct data, sometimes (with
> the same frequency) I get garbage.
>
> There are two possibilities that I can envisage.
> 1) Race condition: R is starting to execute the R code after
> the .Call before the .Call has returned, thus the data is corrupted.
> 2) Garbage collector: the GC is collecting my data between
> the UNPROTECT(1); call and the assignment to an R variable.
>
> The created matrices can be large (where x > 1000, y >
> 10), but the garbage doesn't appear to be related to the
> size of the matrix.
>
> Any ideas what steps I could take to proceed with this? Or
> other possibilities than those I've suggested? For reasons of
> confidentiality I'm unable to release test code, and the
> large dataset might make testing difficult.
>
> Thanks in advance
>
> --
> Jon Senior
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
**
Please consider the environment before printing this email or its attachments.
The contents of this email are for the named addressees ...{{dropped:19}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Return values from .Call and garbage collection [Additional information added]
On 27/01/2009 7:11 AM, Jon Senior wrote: Hi all, I'm posting this here as it discusses an issue with an external C library. If it would be better in R-Help, then I'll repost. I'm using an external library which I've written, which provides a large set of data (>500MB in a highly condensed format) and the tools to return values from the data. The functionality has been tested call by call and using valgrind and works fine, with no memory leaks. After retrieval, I process the data in R. A specific function is causing a problem that appears to be related to the garbage collector (judging by symptoms). In the C code, a Matrix is created using PROTECT(retVal = allocMatrix(INTSXP, x, y)); Values are written into this matrix using INTEGER(retVal)[translatedOffset]=z; where "translatedOffset" is a conversion from a row/column pair to an offset as shown in R-exts.pdf. The last two lines of the function call are: UNPROTECT(1); return retVal; The shared library was compiled with R CMD SHLIB and is called using .Call. Which returns our completed SEXP object to R where processing continues. In R, we continue to process the data, replacing -1s with NAs (I couldn't find a way to do that in that would make it back into R), sorting it, and trimming it. All of these operations are carried out on the original data. If I carry out the processing step by step from the interpreter, everything is fine and the data comes out how I would expect. But when I run the R code to carry out those steps, every now and again (Around 1/5th of the time), the returned data is garbage. I'm expecting to receive a bias per iteration that should be -5 <= bias <= 5, but for the garbaged data, I'm getting results of the order of 100s of thousands out (eg. -220627.7). If I call the routine which carries out the processing for one iteration from the intepreter, sometimes I get the correct data, sometimes (with the same frequency) I get garbage. There are two possibilities that I can envisage. 1) Race condition: R is starting to execute the R code after the .Call before the .Call has returned, thus the data is corrupted. 2) Garbage collector: the GC is collecting my data between the UNPROTECT(1); call and the assignment to an R variable. The created matrices can be large (where x > 1000, y > 10), but the garbage doesn't appear to be related to the size of the matrix. R version 2.8.1 (2008-12-22), running on Fedora 10 on a Centrino dual-core with 3GB of RAM. Any ideas what steps I could take to proceed with this? Or other possibilities than those I've suggested? For reasons of confidentiality I'm unable to release test code, and the large dataset might make testing difficult. This sounds like a situation where gctorture() would help a lot. After gctorture(TRUE), R will do a garbage collection before every allocation, so gc related errors will be much more likely to surface. As long as most of the work of your code is happening in C, this won't slow things down to be impossibly slow, as it sometimes does when all the work is in R. It won't tell you where the error is, but making it happen reproducibly should help with that. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] small bug in base::formatC (PR#13474)
Full_Name: Bernd Bischl
Version: 2.8.1
OS: Windows XP Professional
Submission from: (NULL) (129.217.207.95)
Hi,
there seems to be a small bug in formatC:
formatC("foo", format="s", mode="charcacter")
Error in formatC("foo", format = "s", mode = "charcacter") :
'mode' must be "double" ("real") or "integer"
?formatC
says:
mode: "double" (or "real"), "integer" or "character". Default: Determined from
the storage mode of x
I tested this in the 2.8.1 release and the latest development version, both on
XP Professional.
sessionInfo for the second one:
R version 2.9.0 Under development (unstable) (2009-01-22 r47686)
i386-pc-mingw32
locale:
LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Regards,
Bernd Bischl
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Return values from .Call and garbage collection
On Tue, 27 Jan 2009 12:25:12 - "Sklyar, Oleg \(London\)" wrote: > Most likely issue is your code itself, out of range indexing, failure to > initialise all elements of the allocated structure correctly, 1 and not > 0-based indexing, use of other R variables for initialisation that > should have been protected but were not etc. Apologies one and all. Oleg was right. I was writing into a Matrix but my method for doing so was wrong. Error fixed, and now it's all behaving. Thanks. -- Jon Senior __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] uninitialised value in R (PR#13476)
Hi,
I get an "Conditional jump or move depends on uninitialised value(s)"
from valgrind when using 'solve' in combination with some simple
C-code. (I did not use other functions of R besides 'solve'.)
In detail: running
R --vanilla -d "valgrind --tool=memcheck --memcheck:leak-check=yes
--num-callers=20 "
and calling
.Call("XXX")
nd <- 3
solve(diag(nd) , as.vector(1:nd))
.Call("XXX")
gives the above valgrind message for the second call of "XXX".
Without "solve" in the middle, there is no message
from valgrind.
Best regards,
Martin
/// C source file u.cc
#include "u.h"
SEXP XXX() {
SEXP ans;
PROTECT (ans = allocVector(INTSXP, 1));
INTEGER(ans)[0] = 1;
UNPROTECT(1);
return ans;
}
/// header file u.h
#ifndef RFsimu_public_H
#define RFsimu_public_H 1
#include
#include
#include
#include
extern "C" SEXP XXX();
#endif /* RF_simu_PUBLIC_H*/
--please do not edit the information below--
Version:
platform = i686-pc-linux-gnu
arch = i686
os = linux-gnu
system = i686, linux-gnu
status = Under development (unstable)
major = 2
minor = 9.0
year = 2009
month = 01
day = 13
svn rev = 47573
language = R
version.string = R version 2.9.0 Under development (unstable)
(2009-01-13 r47573)
Locale:
LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads, package:base
--
Prof. Dr. Martin Schlather
Institut für Mathematische Stochastik & Zentrum für Statistik
Georg-August-Universität Göttingen
Goldschmidtstr. 7, 5.111
D -- 37077 Göttingen
schlat...@math.uni-goettingen.de
http://www.stochastik.math.uni-goettingen.de/~schlather
http://zfs.uni-goettingen.de/
phone: +49 (0)551 39 17 2131 fax : +49 (0)551 39 13 505
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Package (PR#13475)
Full_Name: Partho Bhowmick Version: 2.8.1 OS: Windows XP Submission from: (NULL) (199.43.48.131) While trying to install package sn (I have tried multiple mirrors), I get the following message trying URL 'http://www.revolution-computing.com/cran/bin/windows/contrib/2.8/sn_0.4-10.zip' Content type 'application/zip' length 320643 bytes (313 Kb) opened URL downloaded 313 Kb package 'sn' successfully unpacked and MD5 sums checked Error in normalizePath(path) : path[1]: The system cannot find the file specified __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] small bug in base::formatC (PR#13474)
On Jan 27, 2009, at 8:20 , bernd_bis...@gmx.net wrote:
Full_Name: Bernd Bischl
Version: 2.8.1
OS: Windows XP Professional
Submission from: (NULL) (129.217.207.95)
Hi,
there seems to be a small bug in formatC:
formatC("foo", format="s", mode="charcacter")
Error in formatC("foo", format = "s", mode = "charcacter") :
'mode' must be "double" ("real") or "integer"
I think you meant "character", not "charcacter" ;).
Anyway, thanks, it should be now fixed.
Cheers,
S
?formatC
says:
mode: "double" (or "real"), "integer" or "character". Default:
Determined from
the storage mode of x
I tested this in the 2.8.1 release and the latest development
version, both on
XP Professional.
sessionInfo for the second one:
R version 2.9.0 Under development (unstable) (2009-01-22 r47686)
i386-pc-mingw32
locale:
LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.
1252;LC_MONETARY=German_Germany.
1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Regards,
Bernd Bischl
__
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] Package (PR#13475)
On 1/27/2009 10:15 AM, partho_bhowm...@ml.com wrote: Full_Name: Partho Bhowmick Version: 2.8.1 OS: Windows XP Submission from: (NULL) (199.43.48.131) While trying to install package sn (I have tried multiple mirrors), I get the following message trying URL 'http://www.revolution-computing.com/cran/bin/windows/contrib/2.8/sn_0.4-10.zip' Content type 'application/zip' length 320643 bytes (313 Kb) opened URL downloaded 313 Kb package 'sn' successfully unpacked and MD5 sums checked Error in normalizePath(path) : path[1]: The system cannot find the file specified It works for me. I suspect it's a permission problem or something similar on your system. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] uninitialised value in R (PR#13476)
Hi Martin,
I wasn't able to compile your files. Replacing "extern "C" SEXP XXX();"
by "SEXP XXX();" solve the issue and I got no message from valgrind -
I'm not sure this is what you really want to do though.
I hope this might help.
Cheers,
Mathieu
schlat...@math.uni-goettingen.de a écrit :
Hi,
I get an "Conditional jump or move depends on uninitialised value(s)"
from valgrind when using 'solve' in combination with some simple
C-code. (I did not use other functions of R besides 'solve'.)
In detail: running
R --vanilla -d "valgrind --tool=memcheck --memcheck:leak-check=yes
--num-callers=20 "
and calling
.Call("XXX")
nd <- 3
solve(diag(nd) , as.vector(1:nd))
.Call("XXX")
gives the above valgrind message for the second call of "XXX".
Without "solve" in the middle, there is no message
from valgrind.
Best regards,
Martin
/// C source file u.cc
#include "u.h"
SEXP XXX() {
SEXP ans;
PROTECT (ans = allocVector(INTSXP, 1));
INTEGER(ans)[0] = 1;
UNPROTECT(1);
return ans;
}
/// header file u.h
#ifndef RFsimu_public_H
#define RFsimu_public_H 1
#include
#include
#include
#include
extern "C" SEXP XXX();
#endif /* RF_simu_PUBLIC_H*/
--please do not edit the information below--
Version:
platform = i686-pc-linux-gnu
arch = i686
os = linux-gnu
system = i686, linux-gnu
status = Under development (unstable)
major = 2
minor = 9.0
year = 2009
month = 01
day = 13
svn rev = 47573
language = R
version.string = R version 2.9.0 Under development (unstable)
(2009-01-13 r47573)
Locale:
LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads, package:base
--
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package (PR#13475)
You can put a trace on normalizePath to get the name of the offending
input file name. E.g.,
> trace(normalizePath, Quote(cat("normalizePath: path=", path,
"\n")))
Tracing function "normalizePath" in package "utils"
[1] "normalizePath"
> install.packages("sn")
trying URL
'http://cran.fhcrc.org/bin/windows/contrib/2.8/sn_0.4-10.zip'
Content type 'application/zip' length 320643 bytes (313 Kb)
opened URL
downloaded 313 Kb
Tracing normalizePath(lib) on entry
normalizePath: path= E:/PROGRA~1/R/R-28~1.1/library
package 'sn' successfully unpacked and MD5 sums checked
Tracing normalizePath(tmpd) on entry
normalizePath: path=
C:\DOCUME~1\wdunlap\LOCALS~1\Temp\Rtmp2XNJo1/downloaded_packages
The downloaded packages are in
C:\Documents and Settings\wdunlap\Local
Settings\Temp\Rtmp2XNJo1\downloaded_packages
updating HTML package descriptions
It looks like your second call to normalizePath caused the problem.
If the error message from normalizePath included the offending file
name it would be easier to track down the problem. E.g.,
> normalizePath(c(".", "no such file.txt"))
Error in normalizePath(path) :
path[2]="no such file.txt": The system cannot find the file
specified
instead of just
> normalizePath(c(".", "no such file.txt"))
Error in normalizePath(path) :
path[2]: The system cannot find the file specified
The following, barely tested, patch does this on Windows. I don't
know if
...[printf]... "%ls", filenameToWchar(string,FALSE)
is the proper way to display an R string.
Index: extra.c
===
--- extra.c (revision 47193)
+++ extra.c (working copy)
@@ -1107,13 +1107,13 @@
if (!GetFullPathNameW(filenameToWchar(el, FALSE), MAX_PATH,
wtmp, &wtmp2)
|| !GetLongPathNameW(wtmp, wlongpath, MAX_PATH))
- errorcall(call, "path[%d]: %s", i+1,
formatError(GetLastError()));
+ errorcall(call, "path[%d]=\"%ls\": %s", i+1,
filenameToWchar(el,FALSE), formatError(GetLastError()));
wcstoutf8(longpath, wlongpath, wcslen(wlongpath)+1);
SET_STRING_ELT(ans, i, mkCharCE(longpath, CE_UTF8));
} else {
if (!GetFullPathName(translateChar(el), MAX_PATH, tmp,
&tmp2)
|| !GetLongPathName(tmp, longpath, MAX_PATH))
- errorcall(call, "path[%d]: %s", i+1,
formatError(GetLastError()));
+ errorcall(call, "path[%d]=\"%ls\": %s", i+1,
filenameToWchar(el, FALSE), formatError(GetLastError()));
SET_STRING_ELT(ans, i, mkChar(longpath));
}
}
It might be nice to include the current directory also.
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of
> partho_bhowm...@ml.com
> Sent: Tuesday, January 27, 2009 7:15 AM
> To: r-de...@stat.math.ethz.ch
> Cc: r-b...@r-project.org
> Subject: [Rd] Package (PR#13475)
>
> Full_Name: Partho Bhowmick
> Version: 2.8.1
> OS: Windows XP
> Submission from: (NULL) (199.43.48.131)
>
>
> While trying to install package sn (I have tried multiple mirrors),
> I get the following message
>
> trying URL
> 'http://www.revolution-computing.com/cran/bin/windows/contrib/
2.8/sn_0.4-10.zip'
> Content type 'application/zip' length 320643 bytes (313 Kb)
> opened URL
> downloaded 313 Kb
>
> package 'sn' successfully unpacked and MD5 sums checked
> Error in normalizePath(path) :
> path[1]: The system cannot find the file specified
>
> __
> 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] Package (PR#13475)
On 1/27/2009 2:02 PM, William Dunlap wrote:
You can put a trace on normalizePath to get the name of the offending
input file name. E.g.,
> trace(normalizePath, Quote(cat("normalizePath: path=", path,
"\n")))
Tracing function "normalizePath" in package "utils"
[1] "normalizePath"
> install.packages("sn")
trying URL
'http://cran.fhcrc.org/bin/windows/contrib/2.8/sn_0.4-10.zip'
Content type 'application/zip' length 320643 bytes (313 Kb)
opened URL
downloaded 313 Kb
Tracing normalizePath(lib) on entry
normalizePath: path= E:/PROGRA~1/R/R-28~1.1/library
package 'sn' successfully unpacked and MD5 sums checked
Tracing normalizePath(tmpd) on entry
normalizePath: path=
C:\DOCUME~1\wdunlap\LOCALS~1\Temp\Rtmp2XNJo1/downloaded_packages
The downloaded packages are in
C:\Documents and Settings\wdunlap\Local
Settings\Temp\Rtmp2XNJo1\downloaded_packages
updating HTML package descriptions
It looks like your second call to normalizePath caused the problem.
If the error message from normalizePath included the offending file
name it would be easier to track down the problem. E.g.,
> normalizePath(c(".", "no such file.txt"))
Error in normalizePath(path) :
path[2]="no such file.txt": The system cannot find the file
specified
instead of just
> normalizePath(c(".", "no such file.txt"))
Error in normalizePath(path) :
path[2]: The system cannot find the file specified
The following, barely tested, patch does this on Windows. I don't
know if
...[printf]... "%ls", filenameToWchar(string,FALSE)
is the proper way to display an R string.
I think your patch looks okay; I'll put it in. Thanks!
Duncan Murdoch
Index: extra.c
===
--- extra.c (revision 47193)
+++ extra.c (working copy)
@@ -1107,13 +1107,13 @@
if (!GetFullPathNameW(filenameToWchar(el, FALSE), MAX_PATH,
wtmp, &wtmp2)
|| !GetLongPathNameW(wtmp, wlongpath, MAX_PATH))
- errorcall(call, "path[%d]: %s", i+1,
formatError(GetLastError()));
+ errorcall(call, "path[%d]=\"%ls\": %s", i+1,
filenameToWchar(el,FALSE), formatError(GetLastError()));
wcstoutf8(longpath, wlongpath, wcslen(wlongpath)+1);
SET_STRING_ELT(ans, i, mkCharCE(longpath, CE_UTF8));
} else {
if (!GetFullPathName(translateChar(el), MAX_PATH, tmp,
&tmp2)
|| !GetLongPathName(tmp, longpath, MAX_PATH))
- errorcall(call, "path[%d]: %s", i+1,
formatError(GetLastError()));
+ errorcall(call, "path[%d]=\"%ls\": %s", i+1,
filenameToWchar(el, FALSE), formatError(GetLastError()));
SET_STRING_ELT(ans, i, mkChar(longpath));
}
}
It might be nice to include the current directory also.
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of
partho_bhowm...@ml.com
Sent: Tuesday, January 27, 2009 7:15 AM
To: r-de...@stat.math.ethz.ch
Cc: r-b...@r-project.org
Subject: [Rd] Package (PR#13475)
Full_Name: Partho Bhowmick
Version: 2.8.1
OS: Windows XP
Submission from: (NULL) (199.43.48.131)
While trying to install package sn (I have tried multiple mirrors),
I get the following message
trying URL
'http://www.revolution-computing.com/cran/bin/windows/contrib/
2.8/sn_0.4-10.zip'
Content type 'application/zip' length 320643 bytes (313 Kb)
opened URL
downloaded 313 Kb
package 'sn' successfully unpacked and MD5 sums checked
Error in normalizePath(path) :
path[1]: The system cannot find the file specified
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inherited Methods in r-devel (for package maintainers mainly)
These changes have been reverted (temporarily, I strongly hope) to sort out some incompatibilities with the Matrix recommended package. They will be available on a branch for experimentation, once I sort out how to work with svn branches. John John Chambers wrote: A recently committed revison of R-devel (47740) has introduced a new mechanism for ordering superclasses consistently, with related changes for selecting inherited methods. As part of the process, a function testInheritedMethods has been introduced that examines method selection for the relevant subclasses and reports ambiguities. Maintainers of packages that have methods involving multiple arguments are encouraged to run testInheritedMethods for the relevant generic functions (e.g., the binary operators). The new method selection is unambiguous for single-argument selection. It's preferable to find such ambiguities during package development or revision, rather than having users encounter ambiguous method selection later on. In that spirit, ambiguous method selection is no longer a warning, just a message. The new mechanism for class ordering and method selection is described in a draft paper at http://stat.stanford.edu/~jmc4/classInheritance.pdf (later likely to be part of a submission to the R Journal). John __ 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
